Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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

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?

share|improve this question
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. – Nathan Reed Feb 2 '14 at 20:44
@NathanReed thanks – TravisG Feb 2 '14 at 20:48
up vote 2 down vote accepted

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.

share|improve this answer
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. – Nathan Reed Feb 2 '14 at 20:48

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.