Defered rendering?
by Kyrah Abattoir · in Torque 3D Professional · 05/04/2010 (5:24 am) · 7 replies
Deferred rendering is an alternative approach to rendering 3d scenes. The classic rendering approach involves rendering each object and applying lighting passes to it. So, if an object is affected by 6 lights, it will be rendered 6 times, once for each light, in order to accumulate the effect of each light. This approach is often called "forward rendering".
Deferred rendering takes another approach: first of all of the objects render their "lighting related infomation" to a texture, called the G-Buffer. This includes their colours, normals, depths and any other info that might be relevant to calculating their final colour. Afterwards, the lights in the scene are rendered as geometry (sphere for point light, cone for spotlight and full screen quad for directional light), and they use the G-buffer to calculate the colour contribution of that light to that pixel.
The motive for using deferred rendering is mainly performance related – instead of having a worst case batch count of num_objects * num_lights (if all objects are affected by all lights), you have a fixed cost of num_objects + num_lights.
Is T3D exploiting this? after reading a bit about the issue on draw calls, i would be tempted to say that it doesn't, but i'm not expert.
If it isn't, is it planned to get defered rendering supported? If done right , aparently it offers interesting performances increase.
Deferred rendering takes another approach: first of all of the objects render their "lighting related infomation" to a texture, called the G-Buffer. This includes their colours, normals, depths and any other info that might be relevant to calculating their final colour. Afterwards, the lights in the scene are rendered as geometry (sphere for point light, cone for spotlight and full screen quad for directional light), and they use the G-buffer to calculate the colour contribution of that light to that pixel.
The motive for using deferred rendering is mainly performance related – instead of having a worst case batch count of num_objects * num_lights (if all objects are affected by all lights), you have a fixed cost of num_objects + num_lights.
Is T3D exploiting this? after reading a bit about the issue on draw calls, i would be tempted to say that it doesn't, but i'm not expert.
If it isn't, is it planned to get defered rendering supported? If done right , aparently it offers interesting performances increase.
About the author
3D artist, programmer, game designer, jack of all trades, master of none.
#2
05/04/2010 (6:54 am)
so why do we still have issues related to having too many draw calls? 
#3
Either the next beta or 1.2 T3D will have hardware instancing support, which will help reduce the number of draw calls (multiple instances of the same model will be rendered with a single call). But everyone needs to follow Good Batching Practices™:
- Go out-of-your way to make entire models use a single material/texture as often as possible. A single model using two materials means two draw calls to render that model. If your model uses multiple non-tiling textures, merge those into one larger texture and adjust the UV coordinates so the entire object uses a single texture instead.
- Try to keep the number of objects casting shadows as low as possible. If possible, do a few source changes to skip rendering objects into shadows if their current LOD level is too small, depending on your game's requirements.
05/04/2010 (7:25 am)
Because everyone has issues related to too many draw calls =). Welcome to modern game development. Real time shadows also need stuff to be rendered as well, and in the case of PSSM this is multiplied by the number of splits. Either the next beta or 1.2 T3D will have hardware instancing support, which will help reduce the number of draw calls (multiple instances of the same model will be rendered with a single call). But everyone needs to follow Good Batching Practices™:
- Go out-of-your way to make entire models use a single material/texture as often as possible. A single model using two materials means two draw calls to render that model. If your model uses multiple non-tiling textures, merge those into one larger texture and adjust the UV coordinates so the entire object uses a single texture instead.
- Try to keep the number of objects casting shadows as low as possible. If possible, do a few source changes to skip rendering objects into shadows if their current LOD level is too small, depending on your game's requirements.
#4
05/04/2010 (8:25 am)
My main issue for draw calls is about using partial meshes to compose a full object, ex: making an avatar with a head model, torso, and legs, plus whatever non rigged object i want to attach to the bones.
#5
The problem is that hardware instancing cannot help in that situation: the characters are all unique, so there's hardly anything that can be instanced.
If you're serious about getting maximum performance in a MMO setting, I'd invest in studying the code that loads the models and customizing it to allow multiple parts to be merged into a single model, by merging all vertices into a single buffer, all textures into a single atlas, and modifying the vertices' UV coordinates at load time so they correctly address their sub-texture in the atlas.
You'll probably increase memory usage, since each character will have a single texture (can be deal with by generating smaller versions of the atlas texture for the LODs), but the gains in reducing draw calls should be pretty great.
05/04/2010 (9:42 am)
Is it a MMO, per chance? Draw calls are the major performance issue with most MMOs. Games like Aion will bring even i7s to their knees when too many players cluster together. The problem is that hardware instancing cannot help in that situation: the characters are all unique, so there's hardly anything that can be instanced.
If you're serious about getting maximum performance in a MMO setting, I'd invest in studying the code that loads the models and customizing it to allow multiple parts to be merged into a single model, by merging all vertices into a single buffer, all textures into a single atlas, and modifying the vertices' UV coordinates at load time so they correctly address their sub-texture in the atlas.
You'll probably increase memory usage, since each character will have a single texture (can be deal with by generating smaller versions of the atlas texture for the LODs), but the gains in reducing draw calls should be pretty great.
#6
Rock and hard place -_-
05/11/2010 (1:51 am)
Sooo on one side, recyling common parts across several characters by piecing them together like lego minifigs will save disk space and memory but will shoto drawcalls through the roof, and on the other side, merging each character as an "unique" will increase the memory footprint, and will kill the drawcalls anyway?Rock and hard place -_-
#7
(In a game with high characters counts as a MMO, you'll need to implement unloading of unused resources anyway).
05/11/2010 (5:26 am)
I wouldn't worry about memory consumption: even if all your characters are identical, each instance will keep a copy of the geometry since skinning is done on the CPU. So why not take advantage of that and make each character geometry truly unique? ;)(In a game with high characters counts as a MMO, you'll need to implement unloading of unused resources anyway).
Associate Manoel Neto
Default Studio Name