Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Changing depth range convention in projection matrices #377
I propose making the default Panda convention for depth range 0..1 instead of OpenGL's -1..1 range.
The OpenGL range was presumably originally chosen for consistency with the X and Y axes (which understandably range from -1 to 1 as well). However, this was before the advent of floating-point depth buffers, which are most precise for values around 0, so all the best depth precision is now uselessly stuck in the middle of the depth range: (source)
This is particularly relevant when doing the reverse Z trick, which involves flipping around the near/far clip planes in combination with floating-point depth buffer and infinite draw distance in order to get a truly ridiculous level of depth precision.
Depth calculations also become less precise when doing math with the projection matrix on the CPU, I've found, including determining the correct coordinates for the bounding volume. Calculations with a projection matrix generated for a 0..1 range are much more precise when the near and far values are far apart, due to the way the math works out.
Direct3D and Vulkan do not suffer from this issue, as both have defined the depth range to go from 0 to 1. This avoids the precision problem. As of OpenGL 4.5 we can use glClipControl to also set the depth range from 0 to 1 in OpenGL (presently implemented via the
My proposal is that at the very least, we change the internal projection matrix calculations in Panda3D itself to only assume a 0-1 depth range for now, and consider that the "Panda convention". The OpenGL renderer will rescale the matrix to report depth in the -1 to 1 depth range before sending it to the driver, unless
I would suggest leaving the clip-space-related shader inputs with the existing -1..1 range so that existing shadow shaders are not broken. The
This change may break any code that is directly dealing with lens projection matrices, as well as any code that is using lens extrude calls with an explicit depth value.
One way we could theoretically deal with this when we switch to an entirely SPIR-V based shader pipeline, is to rewrite all shaders to change