Antialiasing and logarithmic depth buffer

Questions
1

We are having an issue with antialiasing when the depth buffer is switched on. We are using 0.131.3

The issue:

  • If logarithmicDepthBuffer: true , then the line quality is bad, but when zoomed out, the lines will have the correct depth.
  • If logarithmicDepthBuffer: false . then the line quality is good, but when zoomed out, the lines will have the wrong depth.

Here is an example of the line quality issue:

image
image962×341 37.1 KB

image
image1035×343 58.2 KB

Here is an example of the depth issue:
image

You can view the model with the depth issue.

We also saw this issue, but it did not really solve it for us.

We would like to know if there is a workaround that can give us both good lines and good depth?

More information:

2

So the following did not work for you? Antialiasing has artifacts when logarithmic depth buffer is enabled · Issue #22017 · mrdoob/three.js · GitHub

The aliasing you see is a limitation of logarithmic depth buffer based in the EXT_frag_depthWebGL extension. It is not fixable unless you use software emulation or a complete different approach like reverse depth buffer (which is not yet supported in three.js).

3

Thanks for the reply.

So we have gone for the option you have suggested - i.e. force three.js to emulate logarithmic depth buffer in software. The approach has a few downsides, but I think for now it is the best option. Below we list the downsides, just in case others are dealing with the same issue.

First, it means we have to edit the threejs code, which is not something we really want to do. So if logarithmicDepthBufferForceEmulation could be implemented some time, it would be great.

Second, the software emulator does some strange things (is it the front clipping plane?). For now, we decided just to live with it and see what happens… Below are a couple of images to show the issue.

Untitled
Untitled673×577 55.3 KB

Third, even when using the software emulator, we still get some depth issues at certain camera rotations. But it is much less pronounced. Again… we just decided to live with it for now. The image below shows the issue. The grid lines should not be showing through the polygon that defines the base.

image

Fourth, performance-wise, we are not really sure what impact it has.