You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
The issue behind failing fill-extrusion-pattern tests on GL native looks like having a different cause from mapbox/mapbox-gl-js#3327:
it is related to mapbox/geojson-vt-cpp#44 and usage of fixupPolygons / wagyu here:
This is related to #8746 - while the issue #8746 is closed, ring order (input to classifyRings) in e.g. fill-extrussion-pattern/@2x render test between GL-JS and GL-native is different.
wagyu algorithm setup and checking if polygon fixup is required is expensive as much as fixing it - so we continue running wagyu for all geojson and, if attempt to restore original point order after wagyu. Even with no polygon fixup, starting point in rings is changed. This causes a disparity between GL-JS and GL-native, visible in implementation of fill-extrusion pattern.
Fixes: #15268
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
CoreThe cross-platform C++ core, aka mbglGL JS parityFor feature parity with Mapbox GL JS
The issue behind failing fill-extrusion-pattern tests on GL native looks like having a different cause from mapbox/mapbox-gl-js#3327:
it is related to mapbox/geojson-vt-cpp#44 and usage of fixupPolygons / wagyu here:
mapbox-gl-native/src/mbgl/tile/geojson_tile_data.hpp
Line 32 in 273ad43
As the order is different, edgedistance used for fill-extrusion-pattern side shader is different from gl-js. Tests now fail but are ignored.
The text was updated successfully, but these errors were encountered: