I am interested in using a non-standard depth buffer to deal with a large dynamic range in distance in a single scene. The best solution out there seems to be using reversed-z buffers with floating point depth values. It is great because there is no slowdown because it can still use the hardware depth pipeline (unlike for things like log or linear depths).
The main trick is to put zNear= the far distance and zFar = the nearer distance.
e.g. self.cam.node().getLens().setNearFar(5000,0.1)
OpenGL is fine with this ā does Panda3d object? Even if it does I assume a workaround would not be too much work but there are additional steps as well.
The author lists 5 key steps to make it work:
1) Depth buffer must use 0 to 1 not -1 to+1 (glClipControl does this)
2) Float 32 bit z-buffer ā takes advantage of float/exp representation to preserve resolution near 0
3) Depth buffer Clear to 0 (far)
4) Flip depth comparison to greater than
5) Special perspective matrix (because the scene is mirror-reversed otherwise)
Are there any road blocks to doing this in Panda? For example, I didnāt see how glClipControl was exposed to the user in Panda. I have also struggled a bit convincing the renderer to use a 32 bit float (not fixed) depth buffer. The last awkward part seemed to be the need to generate your own perspective matrix and thus forgo the nice automatically made matrix features of Panda.
I have heard of this technique, and am happy to consider how it can best be implemented in Panda3D. It does unfortunately rely on OpenGL functionality that has been added in 4.5, so cannot be used if compatibility with older hardware is your goal.
Adding a config variable to change the OpenGL depth range convention using glClipControl should be fairly trivial, and am happy to check in such a change shortly. In the meantime, you could hack this using PyOpenGL to make the call.
Creating a floating point depth buffer is supported in Panda3D, but I donāt think this works for the default window framebuffer, merely because it doesnāt seem like GLX/WGL gives us a way to explicitly request float depth buffer. You can however render the scene to a GraphicsBuffer, which you create by passing a FrameBufferProperties on which you called fbp.setFloatDepth(True). Let me know if you need help with this.
Inverting the near/far clip should work in theory (we should fix it if it doesnāt), but I donāt think thatās all there is to it, since by default it maps depth to the -1ā¦1 depth range. The DirectX renderer already needs to adjust the projection matrix to take this into account. I think we will also need whatever variable will control glClipControl to also make this adjustment to the projection matrix.
You could in the meantime use a MatrixLens to supply your own projection matrix.
I think I will also look into adding a config variable that automatically reverses the projection matrix, depth func and depth clear if this functionality is available. If you think we need greater control than a global config setting, perhaps we will need to add a special ādepth modeā setting to FrameBufferProperties that controls this.
FWIW, passing float("inf") as far distance is explicitly allowed in Panda3D.
Thatās a really good point regarding older hardware. OpenGL 4.5 is 2014 or so so hopefully becoming well supported in drivers now. In particular, DirectX uses 0 to 1 for the depth buffer so hardware has been supporting 0 to 1 for a long time. They also mention an extension which may help for older hardware: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_clip_control.txt
That extension was introduced when OpenGL 4.5 was released; it is standard practice to release an extension version of all functionality alongside every core release. Even if a device can support this extension without supporting the rest of OpenGL 4.5, it would still need a recent enough driver.
Also note that not all hardware is capable of supporting OpenGL 4.5. In particular, pre-DX11 hardware is generally unlikely to support it. But they may still be able to support the GL_ARB_clip_control functionality.
According to this report, only 21% of submissions support GL_ARB_clip_control, but this may vary drastically depending on audience. It does appear that there exist pre-OpenGL 4.x cards that support this extension nonetheless, so it will certainly still help to check for the extension.
There is however a vendor-specific extension (GL_NV_depth_buffer_float) that lets us produce the same result by allowing us to call glDepthRangedNV(-1, 1), which cancels out the default OpenGL depth remapping. It at least covers NVIDIA GPUs from GeForce 8 upwards, which is pretty much all NVIDIA GPUs one needs to care about at this point. It also appears that AMD has added support for it to their drivers, as confirmed by the above report. No Intel hardware, though.
You can now set gl-depth-zero-to-one true in Config.prc, which calls glClipControl to activate GL_ZERO_TO_ONE, and also automatically adjusts the projection matrix to project to the [0,1] range instead of the default [-1,1].
I had also implemented the fallback implementation using GL_NV_depth_buffer_float, but I have commented it out for now because thereās one more piece missing: it requires adding an additional clip plane on the near (or far, in case of reverse rendering) side, as not doing so would yield negative depth values. I donāt have time for that today, but I may get around to it soon.
I have also verified that a reverse near/far works in Panda3D. However, I do not believe setting the near distance to infinity works yet. I will have to look into that as well.
With this setting, you still need to change the depth clear value, the depth test attribute, flip the near/far range and use an FBO with float depth, but this is all possible via the Panda3D API. Let me know if you run into any trouble or need any help.
Thanks again! I tested the new code. Reverse-z depth buffers work really well in Panda. I made a quick demo that gets a factor of 100 more range in the depth buffer without z-fighting (based on the shader-terrain sample) with a water layer than z-fights with the terrain depending on the depth buffer method.
Two versions to try: main_zfight.py ā ā standard depth buffers with Near/Far 0.01 to 5000 (has z-fighting issues) main_reversez.py āā reverse z with Near/Far 0.0001 to 5000 with no problems
Based on tests in the other links above it should be able to do even better in different set-ups. Note that my quick hack approach to creating a float depth buffer via a GraphicsBuffer is extremely ugly ā I added a modified renderSceneInto and createBuffer. I am sure there is a better/neater way to do this. If you can give me some pointers on a more direct way to use GraphicsBuffer I can make a much cleaner demo.
Also ā it works really well but doesnāt fail very gracefully. That is, if I try to make zNear even smaller (say 0.00001) the whole scene just disappears. I guess some kind of round-off could be zeroing all the depths at this point as its a pretty impressive ratio.
My apologies ā main.py is left over from the shader-terrain sample and should not be there.
The two relevant files are main_zfight.py and main_reversez.py
I did some more experimenting. You can make the first argument pretty much as large as you want without problems, e.g. setNearFar(5e30,0.0001) still works fine.
This makes sense as its just like letting the standard depth buffer zFar-> Infinity which is allowed as rdb mentioned.
The real limitation is the second argument (the near cut off for reversez).
For example, problems occurs for setNearFar(anything, 0.00001) on this demo.
Given that far doesnāt matter, the important distance is from camera to the geometry in the scene which is about 1000 in the demo so this means the ratio when the problems start is about 1000/0.00001=1e9.
As I mentioned above, it isnāt failing gracefully. The scene just disappears. However, I donāt think it should fail and I can fiddle with the view a little (rotate it or scroll it) and get the scene to come back and there are no zfighting issues ā the depth tests are still great. If you keep fiddling for some orientations it disappears again and occasionally just parts of it disappear.
To put it another way, if the depth buffer ranges from 0->1 and the first argument is really large then
the mapping is just z_NDC = 0.00001/z_eye which maps everything nicely into 0 to 1.
Thereās no round-off issue for this expression if z_eye and z_NDC are 32 bit floats. This makes me think it isnāt a depth thing at all.
It make me wonder if the clipping or culling is acting up instead? Perhaps its not quite right when you reverse near and far. I know shader terrain does the cull itself every frame. It gets matrices from panda to do this. It also has its own shaders (though they donāt mess with the depth). However the water quad is just a standard piece of panda geometry with no special shader so it is just doing whatever panda would normally do.
It may be that a round off issue occurs in the culling or clipping. However the expressions there are also pretty straight forward (at least in eye -> NDC) so it isnāt clear how that would happen. It is possible that the overall MVP matrix has roundoff issues.
I havenāt actually found a near/far combination where reversez has zfighting issues on this test case ā the clip/cull issue seems to occur first and just remove the scene from view.
Note that I am saying this just in the interests of making sure nothing was overlooked in case someone really needed to push the depth range to crazy extremes. Being able to use a near cut-off of 0.0001 on a scene extending roughly to 1000 is already perfect for what I am doing in practice.
This is really cool. It is nice to see how effective it is.
Iām currently working on changing the culling in Panda to support infinite frusta (both near and far). The reason why 5e30 works is actually because Panda is limiting the depth based on the lens-far-limit setting, not because it actually supports a bounding volume that goes to infinity.
As for why a tiny near distance fails, I will also look into this; it might have something to do with the fact that Panda generally considers floats smaller than 1\times 10^{-6} to be zero.
You can set view-frustum-cull false in Config.prc to experiment with disabling culling altogether, or you can explicitly set an OmniBoundingVolume as the cameraās cull bounds.
I tried: view-frustrum-cull false but it didnāt seem to help.
I did try this: lens-far-limit 1e-10
I tried a range of values ā smaller was not always better.
In many cases the water plane worked but the terrain disappeared!
This is tricky to disentangle. The terrain does its own cull and it therefore doing its own matrix operations in C++ on the CPU separate to the GPU. There are still special rotation angles I was able to find where the terrain would come back. even for self.camLens.set_near_far(5e30,0.00001) and lens-far-limit 1e-10.
I also tried to test the suggestion that 1e-6 was effectively zero. I did this by increasing all scales by a factor of 100, so that the scene is now ~ 100,000 wide and 100,000 from the camera. The ratio where problems occur stayed the same ā it fails for 0.001 instead of 0.00001
As mentioned earlier, Upchurch and Desbrun studied this and came up with two main recommendations to minimize roundoff error:
Use an infinite far plane.
Keep the projection matrix separate from other matrices, and apply it in a separate operation in the vertex shader, rather than composing it into the view matrix.
With further experimentation, I see now that my initial approach was a bit naĆÆve; I was just letting Panda continue to generate a GL-style projection matrix and only later convert it to a D3D-style matrix via a matrix multiplication. The problem is with one of the terms of the projection matrix, which approaches -1 as n goes to \infty:
\lim_{n \to \infty} \frac{f + n}{f - n} = -1
Precision of an infinitesimal far distance near -1 is nothing short of terrible, whereas when generating the D3D matrix, the values approach 0, allowing the far distance to enjoy the fullest range of floating-point precision:
\lim_{n \to \infty} \frac{f}{f - n} = 0
I have checked in a change that makes Panda take the limits directly when you explicitly set the near distance to float("inf"). This means it will now be better to set it to infinity than to a very large value. However, I will still want to let Panda generate the D3D-style matrix to begin with, rather than throwing away useful precision.
Your point about keeping the projection matrix separate is good as well. It is easy to change the terrain shader to keep the modelview and projection matrices separate, by adding this to the inputs:
Addendum: regarding ShaderMeshTerrain, it is indeed a problem in the culling, because if I comment out this line in shaderTerrainMesh.cxx, I can make the far distance as small as I want and the terrain will still show up:
if (intersection == BoundingVolume::IF_no_intersection) {
// No intersection with frustum
return;
}
Itās not yet clear to me why the test is failing, I will have to investigate this further.
