Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on a project with procedural geometry, and will potentially have lots of opaque faces overlapping within the same model. Imagine an onion's layers. My understanding is it is better to draw the outermost layers first so inner layers' pixels can be discarded quickly by z-buffer test. If so, does that mean I should put the outermost triangles first in the index buffer for the best performance?

For reference, I'm using Unity.

share|improve this question
If you are absolutley sure thats the problem, then you should absolutley do it. – Tordin Aug 1 '13 at 8:12
up vote 2 down vote accepted

In theory draw order only matters when using multiple draw calls. Since video cards have a parallel architecture for vertex and fragment processing, the rendering order inside of a given mesh is non-deterministic. Of course this means that your method may work on some or even all of your target devices, but trusting undocumented and somewhat random features is usually a bad idea.

So you basically have to make a choice between multiple draw calls or some overdraw.

However you may not have to worry about it - even mobile graphics cards can render way more than you would expect nowadays. Some mobile architectures like PowerVR even have special handling for this exact case to reduce the overhead.

You can also try only rendering part of the mesh via occlusion culling or some other method, while having Unity's static batching enabled. But usually heavy premature optimization is a bad idea.

share|improve this answer
In fact modern GPUs parallelize across draw calls as well, where possible, so if you issue several draw calls in succession, they might all run simultaneously. That being said, triangles will generally get drawn in approximately the order you submitted them, if you have a large enough workload to saturate the GPU. – Nathan Reed Aug 1 '13 at 16:43
"Commands are always processed in the order in which they are received, although there may be an indeterminate delay before the effects of a command are realized. This means, for example, that one primitive must be drawn completely before any subsequent one can affect the framebuffer." -from the OpenGL specification and D3D states the same i just couldn´t fins a good source. Although you are right that early-z is still not deterministic, Z-Test fails after the fragment shader are!! – Luis W Aug 1 '13 at 17:58
@LuisW Yes, early-Z is what's relevant here as the question is about performance. The API specs do require that the end result is as if primitives were totally serialized (which matters for blending etc.), but the HW of course does things in parallel as much as it can in real life. – Nathan Reed Aug 1 '13 at 21:23
What if he does deffered shading? In that case saving fillrate is definetly performance relevant and you will be able to reduce fillrate alot if you order your geometry inside your drawcall. – Luis W Aug 1 '13 at 21:32

Generally there are two factors which you can reduce by Z-ordering your geometry:

  1. Fragment calculations: If your setup supports Early-Z the GPU will perform a depthbuffer test right before the fragments shader is executed and thus avoid all the calculations if the fragment fails the test

  2. Fillrate reduction: Fillrate is basically how much memory you write into your screen-buffer. Fillrate can become a major performance problem if it's very high.

So should you do it or not? First of all, you can do it, it shouldn´t hurt and if you can do it without spending much time on it, why not? If it will cost alot of time though you might be better of if you don´t do it at first. Later when you test your game and you run into performance problems you should figure out what causes those problems and eliminate them by optimising those sections. That´s the point where you might figure out that the Fragment shading of your procedural geometry is too expensive or your fillrate is too high and that´s when it becomes nececesary to do that kind of optimisation.

Hope this helps!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.