Skip to main content
gamedev.net
🔒 Locked

Sorting the render queue

Started by dietepiet Aug 22, 2008 at 8:41 AM 0 replies 1.5k views
Original Post
dietepiet
dietepiet
Hi all, Reading this forum, many times when someone asks how to sort their render queue, the replayed order is something like (from most important to least important) pixel shader -> vertex shader -> texture -> vertex buffer -> vertex layout -> render states In my DX9 engine, a lot of objects use multipass rendering, the same geometry and texture is used to render multiple times with different shaders and render states (additive lighting passes). It is most obvious to render these passes right after each other, so I only have to change the shaders and a few render states (I think this is also somewhat along the lines multi-pass ID3DXEffect's are used) . My question is, is it worthy to sort all passes of all objects on shaders anyway, having to set the geometry, texture and shader-constants multiple times? I know, the best way to know is to build it, but it would take a lot of work compared to my current solution. thanks, Dietger
jollyjeffers
jollyjeffers
I'm not a fan of these "definitive" lists of state change ordering. Mostly they're just a form of the MSDN documentation's list which in itself isn't a hard and fast rule.

Consider it in terms of state at the time of rendering. For your application to gain correct results from a ::Draw**() call the pipeline must be configured in a certain way. I know, that sounds pretty darned obvious but ultimately you want to get from one draw call to the next with the minimum number of changes to that state.

It's quite easy to express this in terms of a graph where the edge length/weight is the cost for changing state. You can then remove edges where dependencies occur. With a little bit of graph theory you can then traverse this graph in an optimal order at runtime.

I played around with a prototype of this and it was possible to expose a ComputeEdgeLength(start,finish) which allowed for rapid prototyping of performance metrics to solve the problem.

But then again, you ultimately just end up with a form of scene graph if you're not careful, and thats not necessarily a good thing [grin]

bottom line: state optimization is important, but go for one that suits your application and don't feel that there is somehow a "holy grail" of state ordering that you must follow to the letter.

hth
Jack
<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ |

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.