Some dashed lines render crooked

[nickidlugash]

I'm not sure exactly what the issue is, but some dashed lines that have sharp angles in the geometry look like this (click image for larger view):

This style looks fine for straight lines:

Here's the written style:

}, {
    "id": "road_path_steps",
    "type": "line",
    "source": "mapbox",
    "source-layer": "road",
    "filter": ["==", "type", "steps"],
    "paint": {
      "line-color": "#bba",
      "line-dasharray": [0.3, 0.2],
      "line-width": {
        "base": 1.3,
        "stops": [[15, 1.5], [20, 10]]
      }
    }

This issue existed before the big line-dash refactor, but it seems a bit worse now. @ansis Any ideas?

[ljbade]

@ansis How are you interpolating the texture coords in the line triangles?

[ansis]

Yeah, this has been around for a while. I don't think this would have gotten worse with the recent dash work because the part that causes the problem hasn't changed.

@nickidlugash the best workaround is to use "line-join": "butt" or "line-join": "round".

The tessellated line looks something like this:

A fragment's position in the dash pattern is calculated using the fragment's distance along the line.
At every corner there are two vertices, the inner one and the outer one. Both have the same distance value, even though one is actually closer than the other. This change in distance depends on the linewidth. To be able to adjust for the difference we would need to stop sharing vertices between triangles in neighboring line segments (because the adjustment is positive on one side of the corner, and negative on the other) and add a bit more information to each vertex.

It would be nice to default to "line-join": "butt" or "line-join": "round" for dashed lines, but we can't do that because dashes are paint properties and linejoins are layout properties.

[ljbade]

@ansis you sure you can't correct the skew in the shader? If you know the y texture coord, then you might be able to adjust x to account for the different lengths.

[ansis]

@ljbade you would need to skew in different directions based on which side of the corner you are on. If the vertex is shared between triangles on both sides you can't do this. So you'd have to use separate vertices, which might be ok, but it would double the number of vertices.

[ljbade]

Ah I see.

[bhousel]

Hey @ansis, I'm just really trying to understand this issue in more detail.

If we tessellate the lines like this, we can still make tristrips out of them and we can know each fragment's position along the line because vertices exist along the centerline in each grouping of 4 triangles. It does increase the # of vertices, but tristrips are fast. Would this fix the issue?

[ansis]

@bhousel I don't think that would, because the extra middle vertex wouldn't help you know the "real" distance along the line at the corners. The value at the middle of the line is already correct

[lucaswoj]

To be able to adjust for the difference we would need to stop sharing vertices between triangles in neighboring line segments (because the adjustment is positive on one side of the corner, and negative on the other) and add a bit more information to each vertex.

Do you think there is a way we could solve the problem by adding an additional attribute to each vertex?

[ansis]

Do you think there is a way we could solve the problem by adding an additional attribute to each vertex?

On top of adding another attribute (or finding a way to pack it into existing attributes) we'd have to add more vertices. The corner vertices are shared between segments, but if the slant is fixed the corner vertices need to be separate because the need to set different "distance along the line" varying values. This would fix the slant but would create potential artifacts at corners since the "distance along the line" would only be continuous in the middle of the line.

It's hard to explain with words. I should try drawing it out

It's hard to make dashed lines look nice at corners even conceptually.