This might be a naive question as I’m not graphics programmer, I just dabble into it once in a while. Anyway, would you see a way how to handle scoped commands within your system? By “scoped” I mean things like glPushMatrix()/glPopMatrix() or glEnable(GL_BLEND)/glDisable(GL_BLEND) command pairs, anything that defines a scope of sorts, sets a state for the scope that anything rendered within the scope is affected by.

If I used the extension for commands you describe I’d still have to make sure that the draw calls generated within a scope (and no others) are still between the scope delimiting commands after sorting. That could be done by introducing the “scope” into the sorting key somehow, probably close to its MSB. However, some possible use cases I have in my head seem to indicate there could be clashes trying to determine the importance of the categories.

For the material and texture sorting question, the same applies. On PC you’ll have the driver doing things behind your back somewhat, whereas we explicitly upload textures, and vertex and fragment shaders. We also explicitly handle patching of parameters to the shaders etc. so we know exactly in what order things will be presented to the hardware and we can therefore sort things to account for that. There’s no uploading of textures or shaders “behind our back.”

Perhaps someone more familiar with the atrocities performed by PC drivers can comment directly on your questions!

One thing i’m wondering though, at the lower level, do you optimize anything with your VBO’s? For example, if you have a few small models (chairs, tables, whatever), do you have an equal amount of VBO’s or do you combine them into a larger one somewhere and then just render parts? And if so, at what point do you do that? Or do you just have a whole bunch of smaller vbo’s, accepting the statechanges for those?

One idea i had was that whenever i load the world, it will determine the primitive count (triangles usually) of all the static objects and spread them over various VBO’s (i have yet to find the “magic” number of vbo size). When the vbo is “full” it will add the next model to a new vbo and so on. What is your view on this idea?

Another thing i was wondering; in most modern games you’d rarely see the same texture used twice, as about 90% of the rendered scene would be unique for materials (except maybe for the used shader). Would you then choose to only depth-sort and completely ignore materials if thats the case? In a typical scene i’ve seen theres barely any texture used twice, and if it is it’d be something used a lot, which would then be instanced anyway

First, I wanted to indicate that several fields of the key are irrelevant for a command key and can be reused for relevant data. This is nice because if all data you need fits within the key, you don’t need to even fetch the value field. Of course, you can use the value field to store data too like you outlined. Whichever works best for you.

Second, I wanted to introduce the concept of one (or more) “sequence ID” field within the key for a command, which would allow several commands to be sorted together (which is actually a likely need). This second reason is why you’d want to put these bits in the key instead of the value field.

Now about this key,value scheme that you suggested here. I wanted to know why are you adding the command id itself to the key (I’m referring to the second figure), doesn’t it make more sense to have the command id on the value part, perhaps among with some parameters for the command? We don’t need to sort the commands based on their memory address (in case of a function ptr) right?

{ 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!