heh some interesting stuff from someone very experienced with engine coding who has been digging deep into torques rendering engine lately. Sure hope that they change a lot in how TSE works, I always wondered why it seemed kind of slow.
I've had a week of digging deep (and I mean deep) into the Torque rendering code (trying to fix a simply hellacious batch count in a rather simple game) and I have discovered the following (for those that did not know, like me before I got tossed on this project at work):
Torque Game Engine is geared towards support for old (Voodoo 3) level hardware. As a result, even its outdoor levels are rendered very BSP-like, in that they prefer tons of very small batches. The DTS exporter produces tristripped mesh data that creates tons of unnecessary tiny batches, and the terrain engine is no better: it's all trifans, and small ones at that (no more than 8 indices per fan). The heightmapped terrain in this game gets cut into about 140 chunks by Torque and those chunks were being drawn in about 10 pieces each (average). You can toggle a variable to fix the stupid tristripping in DTS objects but there is nothing I've seen to do the same for the terrain. I got it down from 11,000 batches/frame to what is now roughly (as of today) 2,450 by forcing Torque to use a single tristrip for its shapes, and by changing the way it draws terrain to send all of the indices for a single terrain chunk at the same time. The next experiment is to implement static geometry batching for all of the static objects in the scene.
However, I just had the realization tonight that this is almost entirely futile, unless I want to fix this very important problem: Torque has no support for VBO's. Every single thing that gets drawn has to go through the OpenGL graphics pipeline anew every frame. This means that you might as well have a Voodoo 3 in your machine for all the good that hopped-up 7950 GTX 2 will do for you, because it's all the same to Torque. The game is entirely CPU-bound right now, and there is nothing anyone can do about it without fundamentally changing the way Torque handles its vertex data. So guess what I get to do...
The seemingly very popular Synapse Gaming Lighting Pack must be used very cautiously by your designers: if you let them put dynamic lights all over the place (at least on outdoor scenes) and have everything cast and receive shadows, expect an enormous framerate hit (100% increase without shadows on our minspec machine, roughly 30% on the dual-core dev PCs).
Garage Games apparently is "very proud" of their "terrain occlusion" in outdoor scenes, whereby stuff that is behind terrain "won't be sent to be rendered". Frankly, that's bullshit. I have not yet found an instance of this, nor have I seen any code to back up this claim. Their outdoor scenes use zero culling (other than simple far clipping) and just send it all on to the drivers. Your only hope in an outdoor scene in Torque is to limit the local complexity: there is a reason the Tribes outdoor levels were designed the way they were.
Torque Game Engine's "Direct3D support" consists of a very thin layer over OpenGL and WGL. In other words, there is no D3D in Torque, no matter what anyone tells you. It's an OpenGL engine only (and the way the code looks, there is no hope of ever abstracting OpenGL from the rendering code). This is not a bad thing, of course, but if you don't look closely you might make the mistake of thinking TGE has D3D support.
I hope this enlightens a few of you who are considering using Torque for your project. I am not saying "don't do it", because there are a few good things about Torque (beyond its price), and their community is just as active as Ogre's, to boot. However, you just need to understand what it is you are getting, and getting into, when you start a Torque project: the Torque Game Engine rendering engine simply is not designed for modern hardware (and I have yet to meet one person with a good thing to say about the Torque Shader Engine, which ostensibly would include support for these modern features we take for granted in Ogre).
Torque Game Engine is geared towards support for old (Voodoo 3) level hardware. As a result, even its outdoor levels are rendered very BSP-like, in that they prefer tons of very small batches. The DTS exporter produces tristripped mesh data that creates tons of unnecessary tiny batches, and the terrain engine is no better: it's all trifans, and small ones at that (no more than 8 indices per fan). The heightmapped terrain in this game gets cut into about 140 chunks by Torque and those chunks were being drawn in about 10 pieces each (average). You can toggle a variable to fix the stupid tristripping in DTS objects but there is nothing I've seen to do the same for the terrain. I got it down from 11,000 batches/frame to what is now roughly (as of today) 2,450 by forcing Torque to use a single tristrip for its shapes, and by changing the way it draws terrain to send all of the indices for a single terrain chunk at the same time. The next experiment is to implement static geometry batching for all of the static objects in the scene.
However, I just had the realization tonight that this is almost entirely futile, unless I want to fix this very important problem: Torque has no support for VBO's. Every single thing that gets drawn has to go through the OpenGL graphics pipeline anew every frame. This means that you might as well have a Voodoo 3 in your machine for all the good that hopped-up 7950 GTX 2 will do for you, because it's all the same to Torque. The game is entirely CPU-bound right now, and there is nothing anyone can do about it without fundamentally changing the way Torque handles its vertex data. So guess what I get to do...
The seemingly very popular Synapse Gaming Lighting Pack must be used very cautiously by your designers: if you let them put dynamic lights all over the place (at least on outdoor scenes) and have everything cast and receive shadows, expect an enormous framerate hit (100% increase without shadows on our minspec machine, roughly 30% on the dual-core dev PCs).
Garage Games apparently is "very proud" of their "terrain occlusion" in outdoor scenes, whereby stuff that is behind terrain "won't be sent to be rendered". Frankly, that's bullshit. I have not yet found an instance of this, nor have I seen any code to back up this claim. Their outdoor scenes use zero culling (other than simple far clipping) and just send it all on to the drivers. Your only hope in an outdoor scene in Torque is to limit the local complexity: there is a reason the Tribes outdoor levels were designed the way they were.
Torque Game Engine's "Direct3D support" consists of a very thin layer over OpenGL and WGL. In other words, there is no D3D in Torque, no matter what anyone tells you. It's an OpenGL engine only (and the way the code looks, there is no hope of ever abstracting OpenGL from the rendering code). This is not a bad thing, of course, but if you don't look closely you might make the mistake of thinking TGE has D3D support.
I hope this enlightens a few of you who are considering using Torque for your project. I am not saying "don't do it", because there are a few good things about Torque (beyond its price), and their community is just as active as Ogre's, to boot. However, you just need to understand what it is you are getting, and getting into, when you start a Torque project: the Torque Game Engine rendering engine simply is not designed for modern hardware (and I have yet to meet one person with a good thing to say about the Torque Shader Engine, which ostensibly would include support for these modern features we take for granted in Ogre).