{ opaque } and { normal, additive, and subtractive translucent }

or as

{ opaque }, { normal translucent }, { additive translucent }, and { subtractive translucent }

to be the separate groups. These two alternatives will give different results, obviously.

Visually, the former is seen as correct (as long as you sort the translucent group correctly), but for games in particular we have traditionally compromised on correctness and done the latter, to cut down on state changes (to make rendering faster).

The example above though is just that though: an example. You can adjust the mapping such that you have depth be more significant than translucency if that works better for your application. You can even split it, so there’s some depth bits both above and below the translucency type. And that’s the beauty of sort-based draw call ordering!

I’m gonna take an example, please correct me if I’m wrong. You want to generate one shadow map per each light. You could create some commands that update the current light matrix, then render commands for the whole geometry, then another command that would update the light matrix,and again render commands… (but a lot of render commands would be duplicated :(.

However I have many problems still to solve (how to correctly update uniform variables…) but does it sound like a good idea ? Or generating many render and state commands like this sound too complicated ?

I doubt very much that there are any benefits to do incremental sorting. First, the code would become much more complex, which makes it hard to maintain and increases the likelihood for bugs. Second, the sorting just isn’t a bottleneck so why spend time on a more complicated solution if you don’t have to.

You said that on a PS2 you did no sorting at all while on the PS3 you did full sorting. Now I was wondering, if instead of re-inserting each render call each frame I only inserting them when they become visible and removing them when they become invisible. Then, each frame, the render queue will be pretty much the same as last frame. So instead of a full quick sort, I may use a very simple sort and only perform a few iterations to keep the queue more or less sorted.
Of course this is harder as you have to keep track of all render calls over multiple frames. Do you think this gives a significant saving on a current PC?

For your second question, recall I said “array of (key, value) pairs”. The value is a pointer to your draw call or similar where you have the material/state information available. Shader parameter changes you keep track of by doing a “diff” of the material/state information as you go from one array entry to the next.

how do you trackback the material parameters?

I was just wondering how you would imagining something like Hardware Instancing in this system, since you are not dealing with depth anymore at that point… (well you are, but instances are not per definition in the same depth area)

nice article btw, looking into it. Looking at implementing it for XNA!