Antialiasing has artifacts when logarithmic depth buffer is enabled

[asbjornlystrup]

When the logarithmic depth buffer is enabled, antialiasing fails in areas where geometry intersects or lines up. See screenshot below. It feels like this would be a common issue, but I couldn't find any other post on it.

With logarithmic depth buffer enabled. Notice the jagged, aliased lines.

With logarithmic depth buffer disabled.

I've encountered this on desktop computers. I've seen it on both Linux Ubuntu and Fedora, in the Chrome browser. I don't remember how it looks in Windows, but it seems a bit strange if it would be different there?

Right now we're at version 0.129.0 of threejs, but it's always been like this since we started using logarithmic depth (1-2 years ago), and it happens with all geometry.

Is it like this for everyone else? Any idea how to fix it, or is it something we just have to live with?

Thanks.

[Mugen87]

Do you mind sharing a live link that demonstrates the aliasing?

[Mugen87]

I have tested webgl_camera_logarithmicdepthbuffer on three systems (Android, macOS and Windows) with latest Chrome and I don't see the reported aliasing.

I've seen it on both Linux Ubuntu and Fedora, in the Chrome browser. I don't remember how it looks in Windows, but it seems a bit strange if it would be different there?

Um, could be a GPU driver related issue. In this case, you might want to try to update the driver or switch to one from a different vendor.

[mrdoob]

Indeed. Sounds like a Linux driver issue indeed.
Unfortunately there's not much we can do about this.

[asbjornlystrup]

The logarithmic depth buffer example doesn't have any intersecting geometry (or geometries in contact with each other), so it doesn't show the issue. That example works fine on my end as well. I made a JSFiddle and tested it on Windows now, and the same bug is present there as on Linux. (EDIT: See post below for live link.)

You can see the left intersection from blue to teal has no antialiasing:

If you go into the fiddle's code and disable the logarithmicDepthBuffer by changing logarithmicDepthBuffer: true to logarithmicDepthBuffer: false, the antialiasing works as expected:

[WestLangley]

@asbjornlystrup Please update your example to the current three.js revision.

//

Hmmm... I'm seeing the same issue on my M1 iMac.

@Mugen87 Disabling EXT_frag_depth in WebGL1 or WebGL2 forces three.js to emulate logarithmic depth buffer in software, and the problem disappears. Can you confirm?

// hack WebGLProgram.js
rendererExtensionFragDepth: false, // isWebGL2, || extensions.has( 'EXT_frag_depth' ),

[asbjornlystrup]

Please update your example to the current three.js revision.

Here's the fiddle with v128 (I didn't manage to find an online source for v129): https://jsfiddle.net/kdLxsf9u/4/

[Mugen87]

Okay, with the new fiddle I see the problem on Windows and macOS.

@Mugen87 Disabling EXT_frag_depth in WebGL1 or WebGL2 forces three.js to emulate logarithmic depth buffer in software, and the problem disappears. Can you confirm?

Yes.

[mrdoob]

Would it be a bad idea to stop relying on EXT_frag_depth for this feature and emulate instead?

[Mugen87]

I guess I would first report the issue to the Chromium team. Maybe it's possible to fix this in the browser implementation/ANGLE.

[mrdoob]

I guess I would first report the issue to the Chromium team. Maybe it's possible to fix this in the browser implementation/ANGLE.

I can reproduce on Firefox and Safari too though.

Also, here's a "easier to see" version of the fiddle: https://jsfiddle.net/gs231L0u/

[Mugen87]

Maybe related (source):

I haven't come that far with my code yet, but I presume that assigning to gl_FragDepth will break the logic of MSAA, where the fragment shader is executed once per pixel of the rasterized element. It means that in this case it outputs the same depth value for all MSAA pixel samples, which is not what we want - it disables the antialiasing.

[mrdoob]

That makes me more confident that we should just use the emulated logarithmic depth buffer code.