Question

«I'm writing a game where I need to be able to render the scene in multiple passes that lie on the same geometric plane (the second pass is either additional lighting, a decal that I put on existing geometry, or the first pass is only a pre-pass writing Z only). I plan to use the depth is equal test in my second rendering pass. Should I expect issues with the varying precision of depth ?»

Answer

It can be tricky.

Different situations :

- you do decals rendering (to draw a shadow, or a poster on the wall, or a bullet impact), you draw some geometry on top of another geometry, though they are supposed to lie on the same plane (the math says so !), they don't share the same vertices and so there is very little chance that the rasterizer will get the same result for superposed pixels. It doesn't really matter the precision of your Z-Buffer, if the value is different then the equality test fails and so you will have z-fighting. You can use Depth bias to correct this to some extent. But note that the bigger the angle the surface does with the screen the bigger the bias needs to be (that's why there's a slope parameter in the Direct3d9 version of depth biasing, it's not a simple "add +1 to the depth value"..). Note that if you use depth bias you need to change the test from strict equality to something like bigger or equal.

- you know about Z-fighting issues and you reuse the exact same geometry. So all is well but in order to save fill rate or to limit the rendering to some part of the screen you specify a bunch of user clip planes. There are different hw implementations of user clip planes but a frequent one modifies your geometry when clipping your original triangles. Same situation as above, you end up with z-fighting. Solution 1 - use depth bias. Solution 2 - use a clipping algorithm that doesn't modify geometry and happens after rasterization (like using pixel kill in the pixel shader). But note with the second that some of your performance goals won't be met if that was the reason you used clip planes in the first place.

- You know about z-fighting issues and reuse the exact same input geometry for your multiple pass algorithm. But you have different vertex shaders for each pass. The problem with this is that there is a chance that the order of execution will change between two different vertex shaders, especially if your vertex shader tries to do "clever" things with the position. We've seen cases where for example the initial pass would do pos.z = pos.z + constant in the first pass, and let pos.z unchanged in the second pass. All is well if constant == zero ? well not quite because this simple difference will cause the hlsl compiler and the driver optimizer to generate a code different enough that the end result differs between passes. Invariance between compilation is a hard problem for a driver/compiler because the driver/compiler obviously doesn't know about the intent of the programmer, so that is the programmer responsibility to try to be strict on its own code.

Well that's the bulk of it.

If you want to learn more..

- Z-Buffer precision
- Depth only pre-pass for advanced effects
- Non perspective correct interpolation
- Near plane and far plane
- Real time rendering and programming