roalyr
commented
2 years ago This is a solution that makes it work so long as you tweak every single spatial material in the game that depends on depth buffer. Works for GLES3, doesn't work for GLES2 (no gl_FragDepth exposed in GLES2). Short video demonstration of logarithmic depth and absence of z-fighting (ignore clipping in the end, the meshes shown in the video are flat ~100 units in thickness and 10000 units in size).
// For logarithmic depth buffer.
const float c = 0.001; // Tested at 500 M units.
varying vec4 gl_Position;
void vertex()
{
// For logarithmic depth buffer.
gl_Position = MODELVIEW_MATRIX*vec4(VERTEX, 1.0);
}
void fragment()
{
// Logarithmic depth buffer.
DEPTH = log2(max(1e-6, 1.0 -gl_Position.z)) * c;
// Remaining frag code below ...Depth draw can be anything, depth testing must be enabled.
It works, but it breaks shaders that rely on reading and decoding depth into linear value (see .glsl files in source code that have depth referenced. Shaders below should be inspected for misbehavior:
subsurf_scattering, ssao_minify, ssao_blur, ssr, effects_blur, cube_to_dp.
It also breaks distance fade in spatial material, and the algorithm should be reviewed.
Decoding
Possible decoding formula for above-mentioned shaders could be:
linear_depth = pow(2,(depth_log + 1.0)/c) - 1.0;
Instead of:
linear_depth = 2.0 * z_near * z_far / (z_far + z_near -depth * (z_far - z_near));
But I didn't test it and it has to be checked (signs and 1.0s in the formula might fit DirectX depth instead of OpenGL, or something like that).
A possible Godot 3.x, 4.x implementation
As I see it, each shader and source code file should be tweaked with condition (an IF statement for some setting flag) that switches to either normal or logarithmic depth buffer in every instance that requires it. It requires gl_FragDepth to be exposed and written, so it can be implemented for GLES3 driver quite... trivially (as long as one is careful to catch all instances and knows how to implement switches properly that can be linked to a project options entry). Not sure about Vulkan, but if it makes use of .glsl files then it should be doable there too?
Zylann
reduz
KeyboardDanni
Calinou
Zireael07
Ansraer
clayjohn
MoritzMaxeiner
violetfrost
nickpolet
forestrf
Khasehemwy
Reverse-z buffer solution proposed
https://github.com/Khasehemwy/godot/commit/0a1554078ada94b7b10e5dcff681090fe1ad421d
Related issues
Issues related to extended z-far that I have encountered: https://github.com/godotengine/godot/issues/86275 https://github.com/roalyr/godot-for-3d-open-worlds/issues/15
Describe the project you are working on
I am working on a space game GDTLancer, which is designed to have large-scale objects at large distances (of the same magnitude as camera far plane distance maximum value) which can be reached and interacted with, such as stellar bodies, megastructures and other constructions that will be visible from far away, which means that camera far plane is set to be at a great distance (Up to 1e15-1e18 units, in my case).
Describe the problem or limitation you are having in your project
Large-scale spaces and rendering of thereof are limited by floating-point precision issues. While such things as jitter could be tackled by floating origin, things such as z-fighting for faraway objects require a solution that addresses the way things are rendered. Since the above-mentioned objects are meant to be interacted with, a double-viewport approach is not viable.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Initial solution was to implement logarithmic depth buffer since in GLES backend we had to deal with -1, +1 range. After 4.x came out we have moved onto Vulkan backend, wherein a better solution can be implemented - a reverse-z depth buffer: https://developer.nvidia.com/content/depth-precision-visualized
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
A workaround solution for logarithmic depth buffer that was used before (breaks optimization, depth-related effects and shadows
A gdshader solution for lagarithmic depth buffer is as follows: ``` // Add this before your vertex shader. // Edit "Fcoef" to adjust for desirable view distance. Lesser number means further distance limit. uniform float Fcoef = 0.001; varying float gl_Position_z; // Add this to your vertex shader. void vertex() { vec4 gl_Position = MODELVIEW_MATRIX*vec4(VERTEX, 1.0); gl_Position_z = gl_Position.z; } //Add this to your fragment shader. void fragment() { DEPTH = log2(max(1e-6, 1.0 -gl_Position_z)) * Fcoef; } ```If this enhancement will not be used often, can it be worked around with a few lines of script?
There is no way to work around this issue in a simple way, without compromising depth-related effects and shadow casting.
Is there a reason why this should be core and not an add-on in the asset library?
This is a feature that was already requested and will be requested again in future, because it allows to implement large open-world games in Godot. Reverse z depth buffer is beneficial for all kinds of 3D projects and comes at no drawbacks for performance.