2
\$\begingroup\$

Are there strategies to minimize depth buffer precision problems with hyperbolic depth buffers, such as the ones resulting from perspective projection matrices, or depth buffers in general?

For example, graphics APIs usually give an option to change the depth range, which might influence precision. It's possible to linearize non-linear depth buffers, for whatever reason. There's the option of floating point depth buffers, and non-floating point depth buffers. It's possible that changing the information in projection matrices has a result on the resulting range & precision of the depth buffer.

How do all of these things interact with the resulting range & precision, or with each other, and how do I get the maximum out of my depth buffer? Are there general good practices one should adopt, regardless of project specifics?

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Just a quibble about terminology - the standard perspective projection depth buffer isn't logarithmic, but reciprocal (or sometimes called hyperbolic) - it's based on 1/z rather than log z. \$\endgroup\$ Feb 2, 2014 at 20:44

1 Answer 1

4
\$\begingroup\$

Floating-point depth buffers would enhance range if they actually stored non-normalized depth values. You have a choice between 32-bit fixed-point or 32-bit floating-point depth, for all other bit-depths the depth buffer is always fixed-point. So compared to a 24-bit or 16-bit depth buffer, a floating-point depth buffer always has enhanced precision... but the reason has nothing to do with the fact that you switched to floating-point. Depth values are generally already in the range 0.0 - 1.0 whether you use floating-point or not, so by themselves nothing is gained.

An interesting property of floating-point depth buffers, however, is that if you invert the depth range and use a floating-point depth buffer you can often improve the consistency in precision near and far. Typically because of the way perspective projection works precision is distributed with a bias toward points close to the near plane. Emil Persson has a great discussion of the situation here. He also has a few articles to his name on the subject while he worked at AMD, though they are less pertinent.

Also, you should never linearize the depth buffer. This requires writing a new value to the depth buffer after rasterization, and will prevent hardware optimizations such as Hierarchical Z-Buffering and Early Depth Tests from functioning as intended. Do everything you can to maximize the precision of the non-linear depth buffer, rather than fundamentally altering what is stored in the depth buffer.

As a capstone to this entire disucssion, you should consider the following article, because it discusses the ramifications of all of the representations I mentioned above in terms of re-constructing position from depth. The takeaway point is that inverse perspective depth (1 – Z/W, 32-bit floating point) is nearly as good as linear depth, and it still benefits from hardware Z-buffer optimizations.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Linearizing the depth buffer while rendering geometry is indeed a bad idea; but it can be useful to generate a linearized version of it in a post-pass after all geometry has been rendered. Having a linearized depth buffer is useful for lots of postprocessing algorithms like deferred shading, SSAO, atmospheric haze, DOF, etc. \$\endgroup\$ Feb 2, 2014 at 20:48
  • \$\begingroup\$ @NathanReed if the depth equation is known it can be trivially re-linearized with the inverse. \$\endgroup\$
    – Khlorghaal
    Feb 10, 2016 at 22:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .