# Why are depth buffer values clamped to (0, 1)?

This is a simple question.

I know that in OpenGL or other graphics API, the values stored in the depth buffer are automatically clamped to (0,1).

I just want to know why people do this instead of just keeping the actual depth values as float. Is that just because of the non-linear depth equation which makes the closer depth values more precise and the further depth values less precies?

Thank you!

(Just converting comment into an answer) It seems you might be asking one of two possible questions.

If you meant "Why doesn't the Depth buffer contain camera space Z"
then it's perhaps worth reading Why do GPUs divide clip space Z by W, for position?

If, OTOH, you just meant "why is it restricted to [0,1)?", then that's probably because old systems represented the Z-buffer depth with fixed point numbers, hence a natural [0,1) range.

Of course, later hardware arrived that could use floating-point depths; IIRC Dreamcast's depth representation was an arbitrary positive float representing $\frac{1}{w}$.

• Thanks! I just mean "why is it restricted to [0,1)?". I came up with this question when I was implementing shadow mapping. When using shadow maps, if the depth values stored in the shadow map are all between [0,1), we have to clamp the depth value of the pixel to [0,1) first and then do the comparison. If the shadow map stores the actual depth values as floats, we can just compare them directly. Sep 18 '18 at 17:52

Depth buffer values are clamped to that range because usually they are using fixed-point representation, so if clipping is disabled (by glEnable(GL_DEPTH_CLAMP)) then they can't hold anything beyond that range.

However, there isn't really a good reason for this clamping when floating point depth buffers are used. In fact GL_NV_depth_buffer_float extensions allows you to disable this clamping on Nvidia hardware for floating point buffers. Unfortunately other vendors don't have any documented way of doing that.

Also it's worth noting that unclamped floating point depth values have a minor complication: their depth offset is trickier to define. OpenGL spec resolves this by making the depth offset depend on the range of z-coordinates of the primitive. In fixed-point depth buffers, on the other hand, the offset is a function of the triangle slope only.

• OpenGL ES 3.0 which shipped in 2012 has floating point depth buffers as a required feature whose values are not clamped 0 to 1. Checking OpenGL from 2012 which is version 4.2 it has the same requirements.
– gman
Feb 1 at 15:40
• @gman: The issue is that even if the depth buffer can hold values outside the [0,1] range, the spec still requires clipping against the near plane (13.5 Primitive Clipping), effectively limiting the depth values to the [0,1] range. With reverse-Z floating point you can, at least, set the far plane at infinity, thus getting rid of the far plane clipping. I should rewrite this answer though to clarify my point. Feb 1 at 16:02
• Could you write your own depth value?
– gman
Feb 1 at 17:12
• @gman: you can, and to my understanding it should be written as-is to the depth buffer. But near/far plane clipping happens prior to rasterization and, by extension, fragment shading, so you won't have a chance to change the depth. Feb 1 at 18:17