Batching renders and ordering?
Author
I've been working with directX quite a bit lately and am curious about how to effectively order my rendering. I know you want to depth order rendering to take advantage of depth buffer support, but at the same time avoid context switches on effects and textures, so what's the best practice for this?
Is it best to depth order within context switches as much as possible and not worry as much about using the depth buffer? Or is it best to do the opposite and worry more about using the depth buffer? Also, do you want to do your batching within mesh subsets or do ya want to try to stick to rendering all the subsets in a mesh at one time? Thanks in advance, and let me know if any of this doesn't quite make sense!
Depends. If you order everything by depth, your GPU performance will be better because more things will fail the Z test, saving you pixel shading performance and reducing overdraw. If you order everything by state and batch your calls (eg. textures, shaders, etc.), then you increase overdraw but decrease CPU overhead.
I tend to sort by render target first. This minimises render target changes (which are typically quite expensive). Then, for each render target, I render in 2 passes: first the opaque objects then the blended objects.
When rendering opaque objects, I sort them all by material (which is stuff like shader, texture, etc.). For each of these batches, I further sort them front-to-back to minimise overdraw.
When rendering blended objects, I just sort them all back-to-front and render, batching wherever I can (eg. when there are multiple blended objects adjacent in regards to depth, and which all share identical materials). Because opaque objects were rendered first, any blended object that's obscured by an opaque object will quickly fail the Z-test.
This system could be improved, but it seems to work well for me.
I tend to sort by render target first. This minimises render target changes (which are typically quite expensive). Then, for each render target, I render in 2 passes: first the opaque objects then the blended objects.
When rendering opaque objects, I sort them all by material (which is stuff like shader, texture, etc.). For each of these batches, I further sort them front-to-back to minimise overdraw.
When rendering blended objects, I just sort them all back-to-front and render, batching wherever I can (eg. when there are multiple blended objects adjacent in regards to depth, and which all share identical materials). Because opaque objects were rendered first, any blended object that's obscured by an opaque object will quickly fail the Z-test.
This system could be improved, but it seems to work well for me.
As a general rule, what Sc4Freak said. Sort by most expensive state changes (Generally render target, shader, vertex buffer, material, render state), and then sort in back-to-front order for transparent objects.
Only sort opaque objects front-to-back if it's very cheap to do though (I.e. if your scene isn't moving huge amounts every frame, then the order of objects will be roughly the same each frame), the Z-buffer saving won't be that great unless you have a very complex pixel shader.
Only sort opaque objects front-to-back if it's very cheap to do though (I.e. if your scene isn't moving huge amounts every frame, then the order of objects will be roughly the same each frame), the Z-buffer saving won't be that great unless you have a very complex pixel shader.
Quote:Original post by Evil Steve
Only sort opaque objects front-to-back if it's very cheap to do though (I.e. if your scene isn't moving huge amounts every frame, then the order of objects will be roughly the same each frame)
Quote:Have either of you experienced slow down due to so much sorting?Yeah, I've had a few projects over the year that had sorting appear as a bottleneck in my profiler [headshake]
One of the greatest wins I achieved there (and also pops up in lots of other algorithms) was taking advantage of temporal coherancy. Rendering order rarely changes much from frame-to-frame, characters moving around a screen at 30-60hz will still give maybe a single order change in maybe 10 frames.
Recomputing the sort order from scratch everytime is just crazy - retain the previous frame's results and re-sort that with a quick pass. Given the relatively small changes a bubble-sort every frame is plenty sufficient to juggle the few things that have actually changed...
hth
Jack
Quote:Original post by jollyjeffers
Given the relatively small changes a bubble-sort every frame is plenty sufficient to juggle the few things that have actually changed...
Remember kids: bubble sort ain't always bad, and quick sort ain't always quick. [wink]
Author
So basically I should focus on profiling out the worst offenders and caching that, then doing light weight sorts every n frames. Sounds good to me, thanks for the info :).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
