Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply an epsilon offset to layers #44

Open
karimnaaji opened this issue Aug 11, 2017 · 3 comments
Open

Apply an epsilon offset to layers #44

karimnaaji opened this issue Aug 11, 2017 · 3 comments

Comments

@karimnaaji
Copy link
Member

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:

screen shot 2017-08-11 at 15 16 46

@matteblair
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants