Mapbox-gl-js: Fix z-fighting on overlapping fills within the same layer

[tgecho]

mapbox-gl-js version: 0.25.1

Steps to Trigger Behavior

1. Add a geojson source with overlapping features and a fill layer
2. Adjust the pitch of the map
   

   Expected Behavior

The fill layers should stay smooth

Actual Behavior

The fill layers flicker as the pitch changes and looks jagged when it's not moving. This happens in at least Chrome, Firefox and Safari

https://jsfiddle.net/tgecho/brhb9wng/

[jfirebaugh]

This looks like the GL JS equivalent of https://github.com/mapbox/mapbox-gl-native/issues/6604.

[snkashis]

Yes, also happening for me in 0.26.0 with Chrome 54.0.2840.71.They are jagged during moves and also while static.

[gena]

I'm experiencing the same when the map is tilted:

The map is here: test map. The water polygons are based on the standard layers.

[nextstopsun]

Same issue here.

Do mapbox base maps also have this problem on overlapping landcover features?

[kermeat]

I also get rendering artefacts when pitching map. Tested on Chrome and FF in Linux.

[nextstopsun]

Any news here? Everything looks great until you pitch the map. I hope feature rendering order won't become random when this gets fixed.

[jfirebaugh]

For some reason, translucent fill layers are currently drawn with the depth mask enabled (i.e. writing to the depth buffer during the translucent phase), which is inconsistent with every other layer type. If that's merely an accident, then we can disable the depth mask and fix this issue for translucent fill layers. I don't see any render test failures when doing so (well, there's one, but it's incidental and we'd fix it by just updating the fixture).

This wouldn't fully fix the problem -- opaque fill layers with a color that varies via a data-driven property, like in #3702, would still z-fight.

[nextstopsun]

@jfirebaugh Thanks for diving in this issue! I guess in most cases color is data-driven because there is "visually no" z-fighting when color of overlapping features is the same.
Do you think this could be fixed for data-driven coloured layers?

[jfirebaugh]

It would be more difficult to fix this for data-driven color. The solution would have to involve one of the general techniques for solving z-fighting like adjusting the depth buffer precision (I think we already use the max though), adjusting the near/far clipping planes, using logarithmic depth buffering, or actually perturbing the z-coordinates of co-planar fill triangles in a way that doesn't affect the visual result other than fixing the fighting. Those would all be medium to large sized research projects.

[jfirebaugh]

It turns out that the fix in #5206 will resolve this issue for all kinds of fill layers. 🎉

[nextstopsun]

Really great news!
@jfirebaugh Thanks, you rock as always!
Couldn't wait for a release, so tried this out on master and got some errors.
Not sure if this is related to this particular commit, but getting

VM12703:83 Uncaught SyntaxError: Invalid or unexpected token

And

Uncaught TypeError: Cannot read property 'has3DPass' of undefined
    at Painter.render (painter.js:300)
    at e._render (map.js:1557)

in Chrome.

The former is quite a strange one but the latter seems to be related.

[indus]

big improvement :clap: - small regression :pensive:
Im now getting a 1px overlap at the dateline for layered semitransparent layers:

I was trying this with v0.40.

[conect]

For 3D-extrusions z-fighting seems still to be there:
will there be a fix available?

Thanks.