Announcement: VorpX - Rift 3D Driver

[MaterialDefender]

As a side project I am working on a 3D driver for the Rift for a few months now. It's called VorpX for now and will (sorry!) be a commercial project. A price has yet to be determined.

As with all drivers that try to bring older games to the Rift, this won't give you the full experience of games designed for the Rift, but it definitely aims at the best possible experience you can get with older software. This is accomplished by various features that go beyond just making a game 3D.

Main features:

- Supports DirectX9, 10 and 11 titles. About 40 games are supported already, including Crysis, Bioshock, Skyrim, Fallout 3, COD: Black Ops and many, many more. Even more to come. Detailed information on initially supported games follows as soon as the website is up (most likely mid February). Expect many current top titles.
- Stereoscopic 3D is created by using a games depth-buffer instead of rendering everything twice. The main advantage of this is high performance (max. performance loss 10%, often less, compared to usually somewhat more than 50% with 'conventional' 3d-drivers). 60fps guaranteed at all times even with high AA settings on mid range hardware. This is very important for the Rift.
- Head tracking support incl. roll for every supported game
- Innovative adaptive 3D-mode mimicking certain aspects of human vision (optional). More on that later.
- Various features to ease your life while playing games that where not made the Rift in mind. More on that later, for now I can't get too much into detail about this. Sorry.
- Mouse and keyboard operable ingame menu to tweak settings (per game)
- Integrated "WASD" and mouse to gamepad mapping (only Logitech Rumblepad so far, X-Box controller support will be added)
- Some other stuff, that will be revealed later

That's it for now. You will hear more on this in the not too distant future.

---
Finally a short disclaimer: some may remember that back in September I released a 2D-Lens Distortion Injector, that was based on DLLs that had to be copied to a games directory. This project has nothing in common with this injector. I had quite a few additional ideas after releasing that, that I thought (and think) would justify to make this a commercial project. It's a complete rewrite from scratch with many things going well beyond the functionality of the older 2D-only injector and additionally many innovative details tailored to the Rift that cannot be found in any other 3D-driver at all.

[STRZ]

Nice man

Don't forget the donation button

[MaterialDefender]

Just to clarify this: It will be commercial. Donation mandatory, so to speak.

[cybereality]

This is an interesting development. Sounds cool. Good luck, man.

[brantlew]

Cool. Would love to see some of your work in-development.

[STRZ]

Allright, important is that it's open. Is a Linux version planned?

[MSat]

Ah, I remember the mention of using the Z-buffer to generate a stereo image. I look forward to hearing more details of the VorpX.

[MaterialDefender]

@cyber: thanks, I don't expect to get rich with this.

@brantlew: I'll slap together a promotional video in the not too distant future. Until then you will have to trust me that things work quite nicely. The depth buffer based reprojection has some disadvantages, but its advantages far outweigh those. Other things I just don't want to show now. Sorry for that. Some features, although not earth shattering, are really innovative, I believe, and there still is commercial competition. Before release there will be plenty of more detailed information and most likely a demo version.

@STRZ: Sorry, if that could be misinterpreted: this is a closed source project and its Windows only. Many things are DirectX related, porting them to OpenGL (an then Linux) isn't a small feat. A predecessor, the 2D-only distortion injector was, is and will be open though.

[Kajos]

Nice going using depth for stereo. It saves the double rendering; I don't know why everybody loves this so much. The small artifacts of using depth aren't even really visible if you use the unaltered frame for the dominant eye. That's my experience atleast.

[STRZ]

@STRZ: Sorry, if that could be misinterpreted: this is a closed source project. A predecessor, the 2D-only distortion injector was, is and will be open though.

Yeah, you're entrance line of the thread, stating that you reveal what you do because Cyber is going open source was misleading me. Sorry. To be clear, i don't have a problem with that and wish you luck, but it would be nice if you don't forget Linux. You could provide a paid .deb package as your driver.

[Fredz]

Nice, very interested in your custom reprojection technique, results have not been really nice with previous attempts (Crysis 2, DDD Virtual 3D).

[MaterialDefender]

Nice, very interested in your custom reprojection technique, results have not been really nice with previous attempts (Crysis 2, DDD Virtual 3D).

Both techniques have their visual artifacts. Misplaced shadows or crosshairs and effects rendered at false depth aren't a problem with a depth based approach, for example. That combined with the huge speed advantage makes the depth based approach the better one for a Rift like device where speed really matters. I'm somewhat biased though, of course.

I can promise that in many games while playing most oft the times you won't notice any artifacts at all, if you don't start deliberately looking for them.

[Fredz]

And you don't need as much separation as on a monitor for a good result, which helps alot.

We already had lengthy discussions about these techniques here some months (years?) ago with other developers, but the consensus was that the technique was mostly doomed for any kind of decent eye separation. I don't really see why it would be any different with an HMD, I even thought it was going to be worse since the separation is a lot higher than on current 3DTVs configs (100% vs less than that most of the time - 15% by default even). I intended to try such an implementation for my Linux driver though to better see the problem.

The low resolution of the Rift could help to mitigate the results though.

I read a paper some time ago about a geometry shader implemented to render the occluded parts. They were able to have a minimal impact on performance on an old 3D engine (Quake 3 IIRC), but the results were not transposable to more recent engines. Could be a nice idea to pursue though.

[MaterialDefender]

For now let's just say, I haven't heard too bad things from anyone who tried.

Tastes are different though, and that's a good thing. For anyone who prefers the traditional approach (and its artifacts), Cybers driver will be available (now even for free).

And, as said in the first post, this thing is not just about making a game 3D.

I'll definitely take a look at the geometry shader idea, thanks!

[Okta]

Is this going to work like the fast 3d option DDD has? I found that pretty cool, not as good as true 3d but cool and fast.

[MaterialDefender]

Is this going to work like the fast 3d option DDD has? I found that pretty cool, not as good as true 3d but cool and fast.

Yep. The actual implementation most likely differs somewhat, but the general idea is the same.

[eqzitara1]

cool stuff, good luck.
Doesn't really conflict with cyber's since its two different methods and they both have different pro's. Would be good to have both. Can't wait to see a preview.

[cybereality]

I think the reprojection method has some merit. Granted, I did harshly criticize Crytek for Crysis 2 only because I thought it set a bad example for developers. But with something like the DDD driver I thought it worked decently. The best part is that is side-steps all the normal issues with injection drivers (problems with shadows, full-screen shaders, etc.). And, of course, the performance benefit is huge. So while it obviously will not look as good as a real stereo render, I think it still has a place.

[2EyeGuy]

I'm surprised that would work for life-sized reality-based 3D on a HMD.

Are you using the same parameters as in real life? Or are you going for a more subtle 3D effect?

[MaterialDefender]

My impression is, that it works better on a HMD than on a normal screen. Your eyes are closer to the screen, which means that fewer pixels displacement result in a greater percieved distance. After testing on an actual DIY-Rift the default separation was even reduced for most games compared to the settings that were determined before in a red/cyan testmode.

Whether these are real settings in terms of a scientifically correct interocular distance is hard to tell since you don't have any reference in world units or anything similar, but it's absolutely enough for a pleasing effect.

[EdZ]

Whether these are real settings in terms of a scientifically correct interocular distance is hard to tell since you don't have any reference in world units or anything similar, but it's absolutely enough for a pleasing effect.

That's a thought: might it be useful to compile a database of the interocular distance in world coordinates (e.g. by measuring the in-game head model) for many different games?

[Mart]

might it be useful to compile a database of the interocular distance in world coordinates (e.g. by measuring the in-game head model) for many different games?

This is a great idea. I'm sure we could crowd-source the data fairly quickly/easily.

[MaterialDefender]

That sounds like a great idea for a geometry based system. For this one it wouldn't help at all though, unfortunately. There is just no meaningful way to relate 3d coordinates a game uses internally to the reprojection shader parameters, not in a generalized way at least.

The good old 'If it looks right it is right' (ancient CGI saying ) approach works pretty well though.

[Fredz]

That's a thought: might it be useful to compile a database of the interocular distance in world coordinates (e.g. by measuring the in-game head model) for many different games?

Just knowing the units used in a game would be enough I think, that's what I'm using in my stereo driver, I think it's at least correct for Quake III where 1 foot = 8 units. We already had several discussions about this in other threads, IIRC I also gave units for other games and that shouldn't be hard to find for most of them.

[drifter]

my aging rig and me are very interested, hope to have the demo when the dev kit will be out

[Okta]

An issue i can think of with the DDD version is that the players weapon, being so close and large on the screen, has a lot artefacts around it like the surrounding area is being torn. Is that going to be an issue here too?

[WiredEarp]

This sounds great MaterialDefender.

A couple of things:
- the depth buffer method I imagine only clones one eye and adjusts the depth. Surely that is going to lead to cutout 3D effects, just like post converted 3D movies...? That said, post conversion doesn't seem that bad... but you will be missing the extra information visible from the other eye?

- how are you implementing the head tracking? Are you going with manipulating DirectX, or are you memhacking the games?

[eqzitara1]

*Edit above poster already asked*

[2EyeGuy]

That's a thought: might it be useful to compile a database of the interocular distance in world coordinates (e.g. by measuring the in-game head model) for many different games?

Just knowing the units used in a game would be enough I think, that's what I'm using in my stereo driver, I think it's at least correct for Quake III where 1 foot = 8 units. We already had several discussions about this in other threads, IIRC I also gave units for other games and that shouldn't be hard to find for most of them.

But he's not using the depth in game units, he's using the depth from the depth-buffer. Maybe you could work it out if you checked the near and far clipping planes, but he's just going for whatever looks right.

[MaterialDefender]

@drifter: That is the current plan, but it's not fixed yet.

@Okta: Objects really close to the camera (like weapons) get some special treatment. That works extremely well in many games, a little bit less well in others. So you might see some artifacts like this in some games. But you will have to concentrate on them deliberately to find them distracting. That at least is my experience. And by the way: due to the really huge speed benefits (that can't be stressed enough) you will be able to use graphics driver features that you normally wouldn't be able to use: Good transparency AA for example. Flickering foliage in many games is a much bigger source of distracting image artifacts than the 3D reprojection.

@WiredEarp: Yes, those 'cutout effects' are an inherent issue of any reprojection technique. They are only potentially distracting in cases like the one Okta brought up though (and treated specially, although not 100% perfect): objects close to the player that are shown against parts of the scene that are farther away. About the tracking: implementation details of all kinds I would generally like to treat as little 'trade secrets'. I hope that is no problem.

@EdZ, FredZ, 2EyeGuy: Although it would be of no use to me, I still think such a database would be a good idea. There are a ton of uses for such information. Not only for 3D purposes but even more so for modders who like to create content for any game.

[backstaia]

This is really cool
I was already wondering in the DIY thread how you got those games running on your rift. So i consider mass effect, witcher and descent already confirmed working. Nice! My body is ready for a retro Descent session. March can´t get here fast enough. Give us ARMA / DayZ suppport and you have a very happy customer. I will throw money at you...

[MaterialDefender]

This is really cool
I was already wondering in the DIY thread how you got those games running on your rift. So i consider mass effect, witcher and descent already confirmed working. Nice! My body is ready for a retro Descent session. March can´t get here fast enough. Give us ARMA / DayZ suppport and you have a very happy customer. I will throw money at you...

It's Mass Effect 2 + 3, to be precise. Mass Effect 1 isn't covered for now, but most likely will be. ArmA 2 is supported and thus DayZ, I would guess. Although this is one of the cases, where I only worked with the demo so far, so this isn't 100% confirmed. Something might have changed in later patches that breaks the driver. Unlikely, but not impossible. Many things are very game specific in a driver like this.

Descent is a special case, and a good one! It's open source, a custom build of D2X-XL, has nothing to do with VorpX. It's not quite ready for prime time though, and I don't have much time ATM to work out the last kinks. As things stand, I will send my modifications to the main D2X-XL maintainer, he seems to be interested in Rift support himself. So chances are good, that before long you get Descent with Rift support by just downloading the normal D2X-XL build. Descent is a game that, despite its age, is way beyond cool on a Rift-like device.

[MaterialDefender]

For a beta test starting in February I'd like to assemble a small and trustworthy team of testers, five or six people. This test is not meant as a promotional beta like it's usually done by some game companies, so please only apply if you have time (and are willing) to really contribute. No hard work involved. Basically just playing and writing a few e-mails. If that sounds interesting to you and you meet the following three criteria, please send me a PM, I look forward to hear from you!

1. You must have a working DIY-Rift, ideally with Hillcrest tracker. Please include a short description of your builds specs in your PM, also please include some info about your graphics card.
2. You must have some DirectX games to test the driver with. Please include a list of games in your PM, so I can check whether those are (or seem worth to be) supported.
3. You must be willing to sign a non-disclosure-agreement. Sorry for that, I promise to keep it as simple as reasonable.

Also it would be nice if you have some experience in beta testing. This is not a must though.

Optional criterion: You work at Oculus (and are willing to sign a NDA).

[WiredEarp]

About the tracking: implementation details of all kinds I would generally like to treat as little 'trade secrets'. I hope that is no problem.

No worries, I totally understand. I was only wondering as I'm doing some stuff with hacking it in, but am wondering if this will cause people to be banned if they try to play online with a hack like my one.

Actually, could this be an issue for your driver as well, considering that it must be injecting itself into the rendering path, just like a cheat?

[MaterialDefender]

VorpX does not inject itself into games directly, nor does it copy or change any DLLs. Direct mem-hacking I would consider too dangerous in this regard. VorpX works similar to Fraps, the Steam overlay, and various other programs: it injects itself into DirectX, nothing fancy.

There still might be a small chance that some anti cheat software will see this as potential cheat at first though, I won't deny that. But one advantage of closed source software is that, even if that should be case, it will be far easier to convince potentially worried gaming companies that it poses no threat. Noone is able to produce potentially malicious custom builds, and there is always someone (me in this case) who can be talked to and held accountable.

If anyone wonders: without exception this is a potential issue with any similar software.

[WiredEarp]

Sweet, I totally agree re the closed source. In the long run I think we can only achieve 100% avoidance of being picked up as a cheat, by having our software white listed by the anticheat people. As you say, this will be much easier when its not open source!

One disadvantage to this pathway, will be that it may slow down new releases, as you will probably have to have a signature generated from your executable by the various companies, and I have zero idea how long they may take to do this. Otherwise, anyone could just modify your code to actually be a cheat...

[kalabalik]

This sounds all sweet to have several drivers coming out for the rift!
I for one is a racing simulator junkie; so the obvious question is if you got any racers working?
Like Project CARS, Dirt 3, rFactor, iRacing, Live for Speed or such?

And another game I've been poking cyber about for the Vireio is the amazing Aerofly FS; a flight sim with simple controls, complex wind system and amazing graphics. Would it be possible to perhaps add any (or all ) of these to the list of supported games? I'd implode of happiness if that was the case...

[Durante]

Wouldn't Z-buffer based reprojection fail entirely for alpha effects, since they by definition do not write Z?

I like what I'm reading about this project, but I've never been a huge fan of reprojection for stereoscopy. I feel like on PC you can afford to do it right.

[TheHolyChicken]

Wouldn't Z-buffer based reprojection fail entirely for alpha effects, since they by definition do not write Z?

I like what I'm reading about this project, but I've never been a huge fan of reprojection for stereoscopy. I feel like on PC you can afford to do it right.

Perhaps... but what if the Rift gets a 120Hz screen like Oculus wants? To take proper advantage of this, the "correct" technique of moving the camera and re-rendering the scene would require you to have the power to push out ~240 FPS.

There's definitely merit to a very fast approach...

[MaterialDefender]

@kalabalik: There will be some racing games for sure, most likely not every single one from your list for now though. Aerofly FS doesn't seem to be that popular, so it might not make it into the initial release. But I have it on my list now. So maybe it will be supported later, provided it uses DirectX.

@Durante: Handling of alpha effects is game dependent, but mostly done in a way that works fine. most game programmers are smart enough to not write glass panes to the Z-buffer, for example, but the scene behind them. The Z-Buffer wouldn't make much sense for their own post processing either, if they wouldn't account for such things. And out of ~40 games that are supported ATM there was only one so far where some supposedly alpha transparent objects (spider webs and such) weren't covered correctly in the Z-Buffer. And it wasn't a hugely popular one.

Regarding speed please keep one thing in mind: for the Rift you will want to have true 60fps at all times. With a fast reprojection technique you will get that, and still have enough horse power left to use good antialiasing, which is also very important, due to the relatively low display resolution of the devkit.

@TheHolyChicken: Thanks for the support!