I've run in to some problems with the D3DRS_DEPTHBIAS render state after converting an older game's D3D8 renderer to D3D9.

D3D9 replaced the old (and poorly supported) D3DRS_ZBIAS with D3DRS_DEPTHBIAS, but it doesn't seem possible to get it to work the same way that ZBIAS did. This game renders shadows and other "decals" onto the ground as flat textures, and to avoid the obvious z-fighting issues that would result would set D3DRS_ZBIAS to 2 when rendering decals in the D3D8 renderer (which I did not write).

The best approximation of the old D3D8 behavior that I've been able to come up with is setting D3DRS_DEPTHBIAS to -0.00003 when rendering shadows. This works fine for shadows on flat terrain that are relatively close to the camera, but when the camera is far above a shadowed object, the shadow will draw on top of the object itself. This can also happen even on near objects if they are on uneven terrain.

It doesn't seem possible to solve this by manipulating the DEPTHBIAS value alone, as no change fixes it entirely without causing other problems.

Is there any way to solve this? Failing that, is there a more modern technique for rendering decals that could be used? I would much rather avoid lots of rewriting as I'm not very familiar with D3D and didn't write any of the original code, but if that is the only option...


Try using D3DRS_SLOPESCALEDEPTHBIAS in addition to D3DRS_DEPTHBIAS. A typical value would be -1.0 for the slope-scaled depth bias, and some very small negative value for the constant depth bias. See the MSDN for a little more information on these flags. The slope-scaled depth bias automatically scales the amount of bias based on the polygon's orientation with respect to the screen; this allows you to use a smaller constant bias, which hopefully will avoid causing the problem you mentioned of objects appearing behind their own shadows when too far away.

There are also some alternative approaches to this problem discussed in this article.

  • \$\begingroup\$ Much appreciated! D3DRS_SLOPESCALEDEPTHBIAS and a smaller depth bias cleared it right up. \$\endgroup\$ – Trunk Apr 29 '12 at 6:33

It is worth noting that neither option will truly fix every case as there are several problem points with decals, some of which are not 'depth bias' related, that everyone really should be aware of:

The floating point precision of the verts of the meshes can be damaged by transforming them temporarily into world space units before going into viewspace units (which then get fed into the projection matrix). The numerical precision artifact here, is that as the camera translates or rotates, the vertices on the floor and the decal will round to fairly large varying floating point values, and each vertex will do this at a different rate, so the decals will tend to wobble and oscillate which tends to make them to partially into the floor some varying amount depending on the view. This numerical precision problem is fixed by keeping everything in view space units, which means changing all lighting and other computations to be relative to the view (which itself is defined as 0,0,0 at the camera). This problem also occurs with shadowmapping for the same reason, and is harder to fix (but there is more room to cheat with shadowmaps).

Depth Bias and Slope Scale Depth bias are themselves problematic for fixing decals, as they both add a fixed linear offset to the projected depth of the polygon. If you are rendering perspective projections the depth is not linear, it is a curve. This fixed offset can be not enough of a delta when the polygon is far away from the camera, and way too much when the polygons are close to the camera. Disabling depth bias entirely and projecting the polygons some fixed world space units away from the surface (depending on the distance to the camera) is much more reliable and won't come back to haunt you months later when someone sticks a big decal on a mesh in some situation that wasn't tuned with the bias numbers you used.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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