Sorting priorities

[MrFloopy]

With the advent of technologies such as hw occlusion culling, HW T&L (therefore very high poly counts), per pixel lighting etc, the given priorities for state/depth/vis sorting has changed.

In the past if you were using a bsp based indoor engine you would sort by depth (either front to back or vice versa depending on your usage). In higher poly scenes you would sort by texture/render state first.

How do you feel this has changed (if at all).

I have found this to be the best case for mixed indoor outdoor rendering:

sort by:
handle transparancy last as depth sorted first but for opaque polys:

assuming your choice of visibility algo:
1) vertex shader / pixel shader combo
2) decal / normal map

thoughts?

 

[darkblu]

snip
I have found this to be the best case for mixed indoor outdoor rendering:

sort by:
handle transparancy last as depth sorted first but for opaque polys:

assuming your choice of visibility algo:
1) vertex shader / pixel shader combo
2) decal / normal map

thoughts?

you completely discard the (base) texture itself as a render state factor?

ed: base

 

[MrFloopy]

you completely discard the (base) texture itself as a render state factor?

No, thats the decal map. Would normally call it diffuse map but that can now be confusing when using a normal map for diffuse lighting calculations.

 

[Hyp-X]

[Theoretical example]
Assume I have a mesh in a static Vertex Buffer / Index Buffer.
The mesh has 2 different materials (different textures/render states).

There are many objects in the 3D scene that are instances of this mesh.

Possible rendering algorithms:
a.)

Sort objects front-to-back.
For each object {
   Set World transformation for the object
   Set Material 1
   Draw first part of the mesh
   Set Material 2
   Draw second part of the mesh
}

b.)

Sort objects front-to-back.
Set Material 1
For each object {
   Set World transformation for the object
   Draw first part of the mesh
}
Set Material 2
For each object {
   Set World transformation for the object
   Draw second part of the mesh
}

Which is the better?
The first algorithm might be faster to render, because it utilizes Z-occlusion better.
The second one might use less CPU time, becuse selecting textures/setting render states costs CPU.

Opinions?

 

[ERP]

Which is the better?

Unfortunately it largely depends on the dataset, how much overdraw, texture filtering modes and what the real bottlenecks are.

Personally I'd run a test on a reasonable facimily of the final dataset, I think you'll find the difference marginal (And it could go either way) unless you have a LOT of Vertex/Pixel Shader changes per object. It should be pretty easy in well architected code to try both out.

The only really expensive state changes left are Vertex and Pixel Shader loads, and this isn't going to change since the reason it's expensive is the amount of data it puts into the pushbuffer.


FWIW we used a combination of both methods. In some phases of rendering we render by object and in others by material.

 

[Kristof]

As ERP said its probabaly going to depend on the specific case, different bottlenecks, etc... My view on it is that now that hardware is getting more and more flexible we need the graphics engines to become just as flexible and adaptive. Different graphics hardware, different systems (cpus, bandwidth, etc) will act differently and will quite possibly have different optimal settings.

K-

 

[Rodéric]

Any simple design to build a flexible and adaptative 3D engine, then, Kristof ?

atm I sort by shaders (and can sort by depth within a shader list).

By shader I mean any code setting textures, texEnv...
(Like the Quake3Arena shaders generalised, and of course true pixel/vertex programs/shaders)

 

[Hyp-X]

atm I sort by shaders (and can sort by depth within a shader list).

By shader I mean any code setting textures, texEnv...
(Like the Quake3Arena shaders generalised, and of course true pixel/vertex programs/shaders)

That's what I called "material". (I got the name from MAX which we export out models from.)

I did limited testing for changing the sorting priority.
So far I wasn't able to spot _any_ speed difference.
After reading how very important it is I was quite surprised.
Maybe I didn't do the right tests.
Also I mostly checked the speed of the rendering, not the CPU utilization.

The thing I noticed matters the most is the number of triangles/DrawPrimitive call. The higher the ratio, the better, it will be less likely to be CPU bottlenecked.

Unfortunately it's very hard to influence this number when models are created by the artists (other than trying to convince them to produce "engine friendly" stuff - which I constantly do).

 

[Rodéric]

yep buffer size are important better be large but not too large either

I think the best is between 600 & 10000 vertices.