`DEPTH` write glitch

[darthLeviN]

Tested versions

godot 4.3 stable

System information

Kubuntu 22.04

Issue description

In some runs, in some shaders, if you write to the DEPTH there will be a glitch happening. This issue will not happen if you don't write to DEPTH. By setting albedo to depth i have ensured that no such glitch exists in my shader code.

https://github.com/user-attachments/assets/0d52509f-b2f8-414f-9a7c-e562abc0d0aa

Steps to reproduce

Not sure. it sometimes happens in the shader i sent. You just have to make an actual use of writing to DEPTH to end up seeing it.

However it's much more likely to happen right after shader recompilation

Minimal reproduction project (MRP)

depth_write_bug_report.zip

[clayjohn]

I took a look at the shader and I don't think there is a Godot bug. The shader itself seems to be writing a near-random value to DEPTH which is why DEPTH appears scrambled.

There are a few notable mistakes I noticed in the shader:

1. The view space ray direction is not perspective correct (missing division by w)
2. The ray hit length is always 1 (it is just the length of rd which has just been normalized)
3. The ray hit position is always the view space ray direction (which is broken because of point 1
4. The ray direction is converted into clip space then used as a depth, without a translation component, that depth doesn't make sense
5. If the code was working correctly, it would be equivalent to DEPTH = 1.0;, but the code itself introduces a bunch of errors and then writes them out.

[darthLeviN]

I took a look at the shader and I don't think there is a Godot bug. The shader itself seems to be writing a near-random value to DEPTH which is why DEPTH appears scrambled.

There are a few notable mistakes I noticed in the shader:

1. The view space ray direction is not perspective correct (missing division by w)
2. The ray hit length is always 1 (it is just the length of rd which has just been normalized)
3. The ray hit position is always the view space ray direction (which is broken because of point 1
4. The ray direction is converted into clip space then used as a depth, without a translation component, that depth doesn't make sense
5. If the code was working correctly, it would be equivalent to DEPTH = 1.0;, but the code itself introduces a bunch of errors and then writes them out.

will close this for now. while i think there is a godot but, i will resolve the code issues and comeback when i still get it.

[darthLeviN]

I took a look at the shader and I don't think there is a Godot bug. The shader itself seems to be writing a near-random value to DEPTH which is why DEPTH appears scrambled.

There are a few notable mistakes I noticed in the shader:

1. The view space ray direction is not perspective correct (missing division by w)
2. The ray hit length is always 1 (it is just the length of rd which has just been normalized)
3. The ray hit position is always the view space ray direction (which is broken because of point 1
4. The ray direction is converted into clip space then used as a depth, without a translation component, that depth doesn't make sense
5. If the code was working correctly, it would be equivalent to DEPTH = 1.0;, but the code itself introduces a bunch of errors and then writes them out.

1- w division is not needed here. the result is normalized. 2- ray hit length of 1 was a bug not it's not anything important in this sample. the orginal code was ro.y/rd.y to simulate a horizontal plane for an ocean. 3- ray hit position is always 1*ray direction in view space(although due to the bug). that should be fine mathematically. this shouldn't cause the visuals you see in the video. if i add ro and use the 4x4 matrix it makes no difference since it's the camera origin. 4- the rotation element of the view matrix is used to convert a world direction into a view direction. translation here is not needed 5- "new_depth" is never 1.0.

the outputs are anything but random, the issue does not show in albedo. i can disable the depth write, and the depth value is put into albedo and it doesn't show a sign of what you see. synchronized trigger by shader recompilation suggests that there is a synchronization problem either in godot or the driver