It is true that it does not decrease the number of drawprimitive calls, but it helps with keeping the number state changes low, as the similar calls have values near each other.

I think that lowering the number drawprimitive calls is more of a preprocessing step (done either when creating the geometry or at load time). That would include things like merging vertexbuffers and maybe textures of a mesh to render a mesh in optimally one call (or even multiple objects in one call).

I should make clear that the sum value of rendering call (including the state changes with drawprimitive()) is simply used to get a position in rendering queue. It does not represent any kind of frequency or anything like that. It's just a artificial value to get a index in the rendering queue.

The "importancy" in the first message means mostly the cost of state change of that resource type.

Quote:Essentially he's setting out a mathematical value that represents a tree, with highest priority (presumably the most expensive things to change) nodes closer towards the root node.

Exactly. This system is like inverse version of radix sorting. It is a bit unfortunate that it makes loading resources after the actual loading sequence a bit harder, but fortunately not impossible.

Quote:But sorting resources according to usage should be done each frame because the objects you rendering are changing each frame.

Yes. The actual sorting must be done each frame, but calculating those values can be done beforehand.

Quote:also you forgot front to back rendering which is a must for complicated pixel shaders.you can take one rendering pass to fill the z buffer before rendering to solve this.

Maybe depth could be added as an "weight" too? The system should allow sorting by anything that can be represented numerically. Of course, precision becomes an issue at some point, but i doubt that there is need to sort by more than, lets say five states. At least doubles should be enough!