Apply an epsilon offset to layers

[karimnaaji]

To solve z-fighting issues, each layer that uses different materials and lay on the same plane or have the same extrusion height should be applied an epsilon offset:

[matteblair]

Ah z-fighting, old friend.

I've never been happy with the way this is resolved in Tangram using depth offsets, I'm inclined to think about different approaches for Unity.

The projected-depth-offset trick we use in Tangram won't actually work here because we aren't touching the rendering pipeline for these (we don't want to force users to render with a particular shader).

We could offset layers in world-space z by some epsilon. This would work for certain scenarios, but requires tuning for different uses. If epsilon is too small then the polygons will resolve to the same depth at large distances, if epsilon is too large then it will be visible up close or in depth-based shader passes.

We can try more exotic solutions as well:

• For the region map tool, tile-build time is not the chief concern so we could do some more sophisticated geometry processing to "cut" the geometries of "higher" polygons out of "lower" polygons, so the overlap is eliminated. While mathematically exciting, this would probably involve lots of complicated code and may actually make rendering slower due to the larger numbers of triangles we would need to render.
• For truly co-planar geometry, we could generate the meshes as usual and then render them to a single texture per tile (or per region). This would probably be more performant for rendering, and has the nice benefit of being very easy to integrate with elevation meshes later! But it also limits the styling options of co-planar geometries: the meshes would all be effectively coalesced into a single material.

I'll keep thinking on this. A world-space z offset may be a good enough solution for now.

[karimnaaji]

For truly co-planar geometry, we could generate the meshes as usual and then render them to a single texture per tile (or per region). This would probably be more performant for rendering, and has the nice benefit of being very easy to integrate with elevation meshes later! But it also limits the styling options of co-planar geometries: the meshes would all be effectively coalesced into a single material.

I was thinking of this, but directly using something coming from a raster tile service, though styling might be more complex to generate (something paparrazzi could be helpful with), then use the raster as a texture on the quad geometry.

[karimnaaji]

Applying an epsilon offset based on numerical integer values assigned to a layer from the editor interface gives some promising results. The only blocker for now concerning this is #51 , since the epsilon value should be relative to the scaling used to generate the mesh, e.g. a mesh using a larger scale should have a larger epsilon offset in order to solve the z-fighting.