But like you've said - it's almost magical anyway the log-z equation actually utilizes only half the z-buffer range because z/w will lie in range and not as OpenGL would like. Unfortunately my engine isn't in a stage to do this test right now (need to re-enable a lot of the pipeline), but I'm confident the benefits will outweight the costs (if any).ītw. I need to do some more serious testing in a 'real' scene. But of course it depends on the application (if the bottleneck is somewhere else, for example bandwidth, it won't show up) and the hardware, so I hesitate to say that it's no problem in general. camera is at 205 kilometers from the scene and uses a field-of-view of 0.01?Ĭould that trick be used to increase precision of shadow maps ?Ĭool, I see I was unnecessarily afraid of the performance hit from disabled fast-z Cameni used a value of 1.0, but with a value of 2.0 in my setup scene, it moved the znear clipping to a few centimeters. I've also found that to control the znear clipping and reduce/remove it, you simply have to adjust the 'offset' constant in the code above. Plus, tesselating the scene more or using geometry shaders would very likely cost even more performance than that. There's a performance hit due to the fact that fast-Z is disabled, but to be honnest in my tests I haven't seen a difference in the framerate. ZBuffer precision problems will become a thing of the past, even when using large scales such as needed for a planetary engine. In fact, I went so far as testing a city with centimeter to meter details seen from thousands of kilometers away using a very very small field-of-view to simulate zooming. Quality-wise, I've found that solution to work perfectly: no artifacts at all. You're only really paying the price for a mad and a log. Note that as cameni indicated before, the 1/log(C*far+1.0) can be optimized as a constant. In the vertex shader, just use an interpolator to pass the vertex position in clip space (GLSL) (here I'm using tex coord interpolator #6): I'm proposing a solution that is much more simple and that works on pixel shaders 2.0+: simply generate the correct Z value at the pixel shader level. It was suggested to keep a high tesselation of the scene to avoid the problem, or to use geometry shaders to automatically tesselate the geometry.

As cameni explains himself in his journal, basically for negative Z values, the triangles tend to pop in/out randomly. It particularly shows on thin or huge triangles where one or more vertices fall off the edges of the screen. Unfortunately, his idea comes with a couple of very annoying artifacts, due to the linear interpolation of the logarithm (non-linear) based formula. In cameni's Journal of Lethargic Programmers, I've been very interested by his idea about using a logarithmic zbuffer.

Vindictus vertex buffer error fix