Depth: depth test is wrong when enable logarithmic depth

[Lafeu-p]

Description

When I set depthTest = true and depthWrite = false, depth testing still works as expected.
When I use WebGLRenderer or WebGPURenderer (without enabling logarithmic depth), everything works fine. However, the issue arises after I enable logarithmic depth.
The image below is the expected result.

wrong depth

The green sphere in the foreground should be occluded by the red sphere below it.

This issue has affected many visual effects in my scene, and I sincerely hope it can be resolved.

Reproduction steps

emoty

Code

// code goes here

Live example

jsfiddle example

Screenshots

No response

Version

171

Device

Desktop

Browser

Chrome

OS

MacOS

[Spiri0]

Maybe it's because you're using a MeshBasicMaterial instead of a MeshBasicNodeMaterial. In addition, the depthNode is not served. I don't know how much automatism can be expected. I have an example here that works very well. You can see the different depths through the cubes.

https://codepen.io/Spiri0/pen/vYqpRga

I optionally created a depthShader for the depthNode and did the same with the node system. Both work identically. I hope it helps you

[Lafeu-p]

Thank you for your example.

Both MeshBasicNodeMaterial and MeshBasicMaterial have the same depth issue.

I tried your example and found that enabling depth testing and disabling depth writing still results in the same issue I mentioned earlier. This issue becomes more pronounced when transparent is set to false.

I believe that depthTest, depthWrite, and similar settings should be part of the three.js's fundamental configuration. Users shouldn't need to perform additional operations; Requiring users to set a custom depthNode for all materials while also considering whether logarithmic depth is being used places an unnecessary burden on them.
@sunag

[Lafeu-p]

I have discovered a new issue. In the previous example, there was a large red sphere and a small green sphere.
red sphere;

depthTest: true;
depthWrite: true;

green sphere

depthTest: true;
depthWrite: false;

The red sphere had depth testing and depth writing enabled, while the green sphere had depth testing enabled but depth writing disabled.

This setup worked correctly. However, if I disable depth writing for the red sphere as well, a new issue arises: the green sphere always occludes the red sphere, even when the red sphere is in front. This problem persists regardless of whether depth writing is enabled or disabled for the green sphere.
red sphere;

depthTest: true;
depthWrite: false

green sphere

depthTest: true;
depthWrite: false;

example
@sunag

[sunag]

I think it is not a bug, if no material has depthWrite no object will have a depth test. However, internally the renderer sorts the objects that will be rendered first, in the case of opaque materials, the ones in the front are rendered first so that the pixels behind are discarded if depthWrite/depthTest is used, for transparent materials the ones behind are rendered first, if you set transparent=true in your materials this problem will not happen because of the internal sort in the rendering pass mentioned.

[Spiri0]

@Lafeu-p sunag raised an important point. In my example above, depth test is unnecessary because the depth information is already in the depthNode. And the depthNode is easy to use with the node system. I don't use my own depth shader in the example. This doesn't do anything differently than the node system itself. I just like to do things so that I understand them down to the last detail, hence both ways (own shader and node system).
Through the transparent cubes you can see that multi-layered transparency works very well with logarithmic depth.
It is important to be able to abandon WebGL habits in WebGPU.
Thanks to @PoseidonEnergy I like the new logarithmic depth calculation, it is more elegant than what I have done in WebGPU and before in the past in WebGL

[Lafeu-p]

@sunag Agreed, I overlooked that point.