Search this blog

18 February, 2008

Hidden overdraw

Overdraw is such an obvious and huge performance problem, that it not a problem at all anymore.
We have found every possible way to overcome it. We do a z-prepass, we have occlusion queries and hierarchical z-buffers (with "early-z" fail, discarding occluded triangles before shading them, causing problems with the shaders that want to modifty the fragment depth) built into every modern 3d card, ATI has also made a tool that optimizes vertex ordering of a mesh to reduce overdraw (the polygons are ordered front to back from every possible viewing direction, so it's something like from outside to inside) while also optimizing post-transform cache (as it should be always done).
And we know that alpha-blending is going to cause overdraw problems, so we draw our particle systems in small framebuffer and then compose them with the full resolution frame and z-buffer.
What we still can be missing is the "hidden" overdraw, the overdraw caused by fragments that eventually are rejected, but only too late (after pixel shading). This is most of the times caused by alpha-testing, that is not early-culled like z-testing (and it couldn't be).

The bottom line? Tassellate your polygons in those tree leaves and in those background props to fit more tightly the alphatested texture! Waste a few more vertices to save a lot of pixels (yes if you were wondering, true 3d stuff can be cheaper than alphatested polygons, in many cases)...


Alessandro Monopoli said...

These problems are very "deep" into the optimization process :)

I'd love to think to that problems, but by now we have to fight the giga-mega-rendercall occurrence :D

You know: when we draw a word, we make at least a rendercall per letter. AT LEAST :D

DEADC0DE said...

Ale: I know the situation of your company and - no they are not. But this lets me think of another post, about "mature" optimizations...