-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Remove the dependency on ApproximateTerrainHeights from GroundPrimitive and GroundPolylinePrimitive #8480
Comments
Seems like this could also fix the issue I've been having with GroundPrimitives on a lunar ellipsoid (see #7552) |
Is the team still thinking of moving this direction? We're highly interested in either moving away from the approximateTerrainHeights dependency or being able to at least swap in different values at runtime |
Issue with this reported in #11385. |
Also reported in #10274 |
Issue with this reported in #11570. |
Issue with this reported in #11616. |
Manifestation of this reported in #11791. |
Currently
GroundPrimitive
andGroundPolylinePrimitive
set their shadow volume bounds based onapproximateTerrainHeights.json
, a file full of earth's min and max heights at different longitudes/latitudes. If a user has a custom terrain dataset or uses terrain exaggeration, these approximate heights no longer work and the ground geometry will be clipped.To fix exaggeration, we could add a
height
vertex attribute and scale it by terrain exaggeration in the shader. This is a little tricky because there's no more room for attributes for polylines. We could oct encode one of the normals to make space but I don't know if that's a good idea. Another option is to use a uniform or batch table entry with the min and max height, but since the geometry is created in the worker after the batch table / uniforms is created, it doesn't know the values. Also we would need a geodetic surface normal to offset the vert in the right direction. I would prefer baking the exaggeration into the verts if possible. Would need some rearchitecting.For custom terrain datasets, I don't know... the polyline geometry would have to be rebuilt whenever the terrain underneath it changes.
See #8436 (comment) for an example of polylines breaking.
The text was updated successfully, but these errors were encountered: