Quote:Original post by RealMarkP
- What's the best way to incorporate sorting into this architecture (By shader, texture, or other)?

Typically this is done with a render queue. When the renderable graph is queried and iterated, the renderables are pushed into some kind of render queue container. This container is either sorted on insert, or passed off to another thread and sorted as a whole.

Sorting usually goes by:

1.) Render target
2.) Opaque/Transparent
3.) Shader
4.) Texture

And i'm always curious where vertex buffer fits in. Sometimes i think it should be before the shader sort, and sometimes i think it's after texture, it depends on how you store stuff in the vbo. if the VB is all of one material then sorting it with material is pretty much the same as sorting by the material.

So a sorted list may look like this:

Rt1 - Opaque  - Shader 1   *obj1   *obj2  - Shader 2   *obj3 - Transparent  - Shader 3   *obj4   *obj5Rt2 - Opaque  - Shader 1   *obj 6 - Transparent  - Shader 3   *obj 7   *obj 8

//There are fancy bit hacking tricks to make this a single integer compare.
bool DrawCall::operator < (const DrawCall &right) const
{
return (RTID < right.RTID)
|| (Opaque && !right.Opaque)
|| (ShaderID < right.ShaderID)
|| (Opaque == Depth < right.Depth);
}

Quote:Original post by RealMarkP
- How could a state sorting (or push/pop) render graph be incorporated?

Your states could be appended to the sort list i provided. You'd just give each property a particular sort order and include that in your operator < (). My renderer has one function SetRenderState(RenderState, bool) which is the only point of access for the renderstates. Inside here you could check if the state was already set (if it's a particularly expensive state to set). Although i think the api takes care of this for you now days. At least with the late model d3ds.

It just depends, what's going to take longer, copying a huge vertex buffer over and over, or switching materials over and over, it may come out benefitial to switch materials more often than VBs, only profiling would tell.

Also, even if they're at the end, they should be sorted, to minimize needless switching.

Ultimately (it's most intuitive), i put the VB at the end of the list.

If the depth is encoded in each drawcall when it's added then they can be sorted later with the main sorting routine. In my example I sorted opaque objects front to back while transparent objects are sorted back to to front.

[Edited by - bzroom on April 30, 2009 3:19:50 PM]

Quick 2p: I found the 'Renderstate change costs' article here helpful when I was looking at designing something similar.

How do you handle meshes with multiple textures? Multiple VBs per mesh or something else?

Heh...I ask because I am curious myself. My current engine I got around it by just requiring that every game model only have one texture on it.

The way I thought about it is to have each texture assigned to a material that has render settings and needed shaders. Then all the tris assigned to that material go in their own VB. And a 'mesh' is just a collection of VBs. This way I think you could have multiple textures and have each piece go through the sorting.

In your new UML diagram, I don't think a Model 'is a' SceneObject? It's not really a 'scene object' or 'cullable' until it's in the scene graph?
Shouldn't your concrete object 'have a' model instead? That works better in my mind...

For the rendering question raised by stupid, I've been thinking about this myself recently: when an object 'draws' itself it sends off its polys to a central renderer which stores them by pertinent hashed 'material' state (and can e.g. sort blended polys) then draws everything in this sorted state, minimising state changes and allowing separate materials (and :. textures) on a single mesh. Maybe put each material in a VB at this stage.

The only thing stopping me doing this so far is the lack of mechanism to flag my 3d model assets with per-poly materials in a satisfactory way (using Blender, which lacks nice user data specification).