Forum Discussion
Mirroring the game output.
Anyone come up yet with a creative solution as how to output a regular rectilinear game render to the monitor while mirroring the same (distortion corrected) output to the Rift? For now everyone seems...
Well, if you've written the engine yourself, you should note the following:
The distortion shader is a post-process run on the final rendered image.
And, to render side-by-side stereoscopic images, you need to render the scene twice.
So... if you have enough of an ability to mess with the internals of your engine. (IE, you wrote it yourself), you can take one of the rendered images (doesn't really matter which; left eye or right. Both would work), then show that on the monitor, while then combining the two images and running the distortion shaders for output to the rift headset.
The downsides to this is you'd need your engine to have proper multi-monitor awareness. (Which can be done, but usually isn't; Things like Eyefinity and the like don't count, because the graphics driver makes the game think that it's dealing with a single display.)
The other downside is that a single image rendered for one eye of the rift would have a very odd resolution and aspect ratio.
(640 by 800 at an 8:10 aspect ratio...)
Of course, if presentation truly mattered, you could use a third camera, and render an entirely separate view for this external display.
(But that would have more of a performance impact - If you plan it out properly, it's still not as much as rendering a 3rd view from a completely unrelated angle, but certainly not as fast as re-using an image you're rendering anyway.)
It's more than possible create a game engine that supports multiple monitors properly, and can render multiple views to each one...
It's just not something that many people have ever done.
In fact, off the top of my head, even though I've seen the example code for it in the DirectX SDK since at least 2007, the only game I can think of that can properly recognise the existence of multiple monitors, and use more than one, is Supreme Commander 2.
And all it does with that is render the map onto the second display.
This is all an exercise in game engine coding though.
:D - Unless you have network code in the game already. (which, to be fair, a lot of games do), that's definitely not an optimal solution.
Unfortunately, the 'correct' solution, while only requiring a single PC, takes a bit of work to code, and requires that you can make low-level changes to the game engine involved...
(Particularly the way it detects graphics hardware, and how it configures it's rendering systems.)
Anyway... Building an engine from the ground up to do this wouldn't be hard. (well, as hard as writing a game engine is regardless), but modifying an existing engine to do it could range from trivial to a complete nightmare, depending on the engine.
I guess it's something to think about for anyone trying to make VR optimised game engines though...
The distortion shader is a post-process run on the final rendered image.
And, to render side-by-side stereoscopic images, you need to render the scene twice.
So... if you have enough of an ability to mess with the internals of your engine. (IE, you wrote it yourself), you can take one of the rendered images (doesn't really matter which; left eye or right. Both would work), then show that on the monitor, while then combining the two images and running the distortion shaders for output to the rift headset.
The downsides to this is you'd need your engine to have proper multi-monitor awareness. (Which can be done, but usually isn't; Things like Eyefinity and the like don't count, because the graphics driver makes the game think that it's dealing with a single display.)
The other downside is that a single image rendered for one eye of the rift would have a very odd resolution and aspect ratio.
(640 by 800 at an 8:10 aspect ratio...)
Of course, if presentation truly mattered, you could use a third camera, and render an entirely separate view for this external display.
(But that would have more of a performance impact - If you plan it out properly, it's still not as much as rendering a 3rd view from a completely unrelated angle, but certainly not as fast as re-using an image you're rendering anyway.)
It's more than possible create a game engine that supports multiple monitors properly, and can render multiple views to each one...
It's just not something that many people have ever done.
In fact, off the top of my head, even though I've seen the example code for it in the DirectX SDK since at least 2007, the only game I can think of that can properly recognise the existence of multiple monitors, and use more than one, is Supreme Commander 2.
And all it does with that is render the map onto the second display.
This is all an exercise in game engine coding though.
"Marbas" wrote:
There is one way... far from optimal, but should do the trick if presenting some rift-game to larger audiences waiting hours in line :mrgreen:
It involves using 2 pc and of course your own game project. Im not so sure you could make this work for existing games tho.
You could run your game on each computer and have some code handling some basic network connection (just to transmit your camera pos/rot) from the rift-pc to the 'public' machine hooked up to a monitor, tv or watever.
Ups: It works!, freedom of resolution choice, no performance cost. Fast enough.
Down's: 2 pc for 1 rift system is 1 pc to many.
May be worthwhile for presentations, but not much more than that Im afraid.
:D - Unless you have network code in the game already. (which, to be fair, a lot of games do), that's definitely not an optimal solution.
Unfortunately, the 'correct' solution, while only requiring a single PC, takes a bit of work to code, and requires that you can make low-level changes to the game engine involved...
(Particularly the way it detects graphics hardware, and how it configures it's rendering systems.)
Anyway... Building an engine from the ground up to do this wouldn't be hard. (well, as hard as writing a game engine is regardless), but modifying an existing engine to do it could range from trivial to a complete nightmare, depending on the engine.
I guess it's something to think about for anyone trying to make VR optimised game engines though...