Game Development Community

Modify Torque for stereoscopy

by Palex · in Torque Game Engine · 06/20/2003 (6:02 am) · 3 replies

Hello, I have post this thread in the opengl section with no response, so i'm trying here. I'm working in making Torque compatible with stereoscopic glasses under OpenGL, because my level has a poor framerate ratio with DirectX stereo mode (nvidia detonator driver).

As you probably know, under DirectX and with detonator drivers the stereo effect works fine, but in Direct3D mode I get a very very low framerate (mono and stereo). I'm working with several cards, one of them is a Geforce4 Titanium, and with all, under opengl I get five times the framerate than with directx mode on Torque. I have proved several versions of the detonator drivers a stereo drivers, patches, reconfiguring the detonator with RivaTuner... nothing, always very low framerate. But with other games, the direct3d results are similar or better than with opengl!! I think the reason is not the driver or the cards, but the Torque wrapper and the interchange of data between structures of opengl to directx wrapper. It seems to be the bottleneck problem, can anyone confirm that?

After that bad results, i have spent some days trying to modify the opengl stereo code of the Torque game engine following some opengl tutorials. The problem is with the sky and hud. Opengl don't render these two structures in one of the two stereo buffers, but i have no idea of the reason.

I have spent much time with this matter with no result, and i will appreciate very much any help. Thanks.

#1
06/20/2003 (4:54 pm)
I can tell you that the sky is "supposed" to be infinitely far away, so it should should be rendered in the exact same relative position on the screen for both eyes. The huds are going to look wierd no matter what, really. It's just a matter of placing them correctly to make them not go off the screen and still viewable under stereoscopic vision.
#2
06/23/2003 (9:48 am)
I don't know if this will help, but from a design aspect, maybe...

In my D3D9 conversions, I basically took the original render routines, I'd take the majority of the renderObject Code and put it into a renderGL() function. and then I'd write a consummate renderD3D function.

the renderObject() function would simply do a little bit of setup work (setting the matrices and such), and then just check the display driver and call the appropriate render function.

You can pretty much do the same thing for your stereo. The other handy effect of this approach is that it allows you to easily separate the tools that use stereo from those that don't.

As far as D3D performance... There are a number of optimizations I'd gone through with the D3D versions of the code for several effects that aren't there in the corresponding GL versions. For instance, I made some changes to the particle system so that it pre-calculates the entire set of particles into a vertex buffer and then renders all the particles in one shot. Also some things with static effects like the volume rendering. The vertex buffer persists and doesn't get recalculated unless the user changes some settings in the editor. In the GL version, I just calculate every volume slice on every frame.

So what did all that extra work buy me? Well, instead of D3D running at 50% of GL speed, it's up to about 73% on average on my GF4Ti, and around 85% on a Radeon9700. (some cases, like the skybox, are actually faster, and yet others, like vehicles go at 20%). FWIW, I get the feeling that even if you made Torque a pure D3D rendering engine, it'd be slower. Not that it would be the *only* game engine like that. -__-

- Parashar K.
#3
06/25/2003 (7:43 am)
Thank you both. Some things:

Chris: With the sky, it seems to be a 3d cube that always follows the player, but the stereo driver only take into account one buffer for the render of the cube!!. Related with the hud, I have proved to modify the line functions in Torque that I think it uses for windows and huds, including the third dimension with the z axis and the 3d version of the same Opengl 2d function, but have no results. Also, I have proved the same strategy with the functions that draw a texture on screen, but nothing.

Alex: Your option sounds well...and hard to code. I supose your changes are not public, if so please tell me. I think the second buffer is informed by the stereo driver, so I have some possibilities:
1. The stereo driver don't understand correctly well the geometrical information of the Torque scene added with this sky and huds, for making the second buffer.
2. There are a problem with the 3d data structures in Torque, so this driver don't make a good composition.
3. There is a bad paralax positioning for the skybox and the huds.
4. There are problems with the inserting order...

Any new help will be appreciated.