LinesSegments with World Units have Visible Artifacts from Various Angles (Fat Lines Example)

[dyarosla]

Description

Artifacts can be see with World Unit lines, visible in webgl_lines_fat example. Attached image with circled problematic regions.

Reproduction steps

1. Go to https://threejs.org/examples/?q=line#webgl_lines_fat
2. Toggle world units to on.
3. Examine the scene from various angles with LineWidths > 1.

Code

Relates to LineMaterial.js

Live example

https://threejs.org/examples/?q=line#webgl_lines_fat

Screenshots

Version

r157

Device

Desktop

Browser

Chrome

OS

MacOS

[gkjohnson]

Are you able to reproduce and show the issue with just a single line segment?

The original thread on the perspective attenuated lines (#16912) contains more information on how exactly the feature works - the vertices effectively form a bounding box around the capsule and then a ray / line segment distance check is used in the fragment shader. It's possible that there's an issue in forming the bounding box vertices or something along those lines if you'd like somewhere to start and take a deeper look.

[dyarosla]

I’m unsure if this occurs on a single line segment.

Also is there any reason why this isn’t using rectangular prisms per line segment instead of three quads (as I take it this is where things landed based on that thread)? A rectangular prism will always entirely contain a capsule and I’ve had success in using them for rendering thick lines with a similar approach elsewhere.

[gkjohnson]

I’m unsure if this occurs on a single line segment.

Have you tried to reproduce it? I'm not sure where else this kind of artifact could be coming from if not reproduceable with a single segment - it looks like sharper corners near the termination of the lines.

Also is there any reason why this isn’t using rectangular prisms per line segment instead of three quads

The PR added a flag to the existing Line2 implementation which only supported screenspace thickness and therefore just used three connected quads originally. In theory those three quads (well only really two of them) could be used to fully define the projection of a rectangular prism that was facing the camera which seemed like a simple solution and didn't require changing geometry to toggle. I still think this is a fine solution as long as the math is being handled correctly.

[dyarosla]

Ok, I was able to reproduce some issues in a single line segment. They are harder to see but there are various angles under which you can see the segment breaking down. I used one line segment from 0,0,0 to 10,10,10. I looked at it from glazing angles. You can see some hard edges on both the closest end cap and the furthest endcap.

[dyarosla]

With two line segments other issues are prevalent.
See the blue cap have a hard edge here:

I think the above may be caused by not writing to the depth buffer and the red line segment's quad may be overwriting the z buffer for the blue segment, cutting that edge in. You can see other scenarios with thicker lines.

In sum I think there are two problems. One is the single line segment issue which is likely a limitation of how using quads instead of a rectangular prism behaves (or some quad calculation is wrong for the endcaps)

The second, with the jaggy edges, is likely due to the wrong zbuffer writing not using the raycast depth.

[gkjohnson]

In sum I think there are two problems. One is the single line segment issue which is likely a limitation of how using quads instead of a rectangular prism behaves (or some quad calculation is wrong for the endcaps)

The second, with the jaggy edges, is likely due to the wrong zbuffer writing not using the raycast depth.

Agreed. I mentioned the limitation of depth writing here in the original PR. If there's a simple function that gives the surface intersection of a capsule then gl_FragDepth could be be written to which would fix this issue as well as intersections with other geometry. And since discard is already used in the shader I don't think this would have a meaningful impact on performance as long as the intersection function is fast.

The quad issue would need to be handled separately. I won't be able to look into this at the moment but if you'd like to try addressing either of them I'm happy to take a look at PRs and help get the fixes merged.