[WIP] Heightmap cascades

[arindam1993]

Intended as an approach to solve multiple issues:
#10170
#10181
#10252
#10264
#10265

A root cause shared by all of them is because a particular vector tile is assigned to one particular terrain tile.
however vector geometries, once rendered do not necessarily stay confined within the the bounds of the tile they are originally loaded in because of various style-spec props.

• *-translate properties can offset them
• circle-radius can make them extend past a tile
• fill extrusions can be stored with buffers

So the idea here is to stitch all visible DEM tiles into a single texture such that any currently rendered vertex position, can be mapped onto this texture. A simple way to do this would be to to use an orthographic projection that looks like this:

This however has a massive drawback, as pitch of the Map camera increases the trapezoid on the ground stretches very far out and becomes almost triangular, the texture size to store this would be too massive, but we don't really care about having high precision for height lookups far away from the camera. So if we can intelligently split the trapezoid into two sections, we can dedicate appropriate amount of texture size to each.

Demo:

cascades.mov

The grey box at the bottom left shows a visualization of an offscreen near framebuffer .
as the pitch increases a far texture kicks and shows up on top. Internally the resolution of the far texture is half of the near texture

@astojilj @mpulkki-mapbox @karimnaaji wdyt?

@mourner I think we can do something similar to this for #5563 as well.

Launch Checklist

• briefly describe the changes in this PR
• include before/after visuals or gifs if this PR includes visual changes
• write tests for all new functionality
• document any changes to public APIs
• post benchmark scores
• manually test the debug page
• tagged @mapbox/map-design-team @mapbox/static-apis if this PR includes style spec API or visual changes
• tagged @mapbox/gl-native if this PR includes shader changes or needs a native port
• apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'
• add an entry inside this element for inclusion in the mapbox-gl-js changelog: <changelog></changelog>

[karimnaaji]

Interesting work in progress @arindam1993 , A few questions!

Do you already know from your testing if there is any risk of perspective aliasing once you start sampling from it, which may lead to a large number of pixels in one space mapping onto the same pixel in these cascades? What I could imagine is a potential loss of precision on the DEM due to this, ideally we'd want to have a mapping 1:1 (at least on the near cascade in what you're representing), far cascade precision loss is probably 🤷 .

In the video, the cascades seem to be re-rendered whenever the camera moves, if all we care about is tile adjacency (e.g. stitching), should we have these tiles always axis aligned? Then sliding the grid only when new tile entry becomes available, and new stitching becomes required.

Once we create this large texture, would the idea be to sample those stitched DEMs on GPU side or CPU side? If it's only GPU would multitexturing help for this use case; binding all neighboring tiles when border access is required there?

[arindam1993]

Interesting work in progress @arindam1993 , A few questions!

Do you already know from your testing if there is any risk of perspective aliasing once you start sampling from it, which may lead to a large number of pixels in one space mapping onto the same pixel in these cascades? What I could imagine is a potential loss of precision on the DEM due to this, ideally we'd want to have a mapping 1:1 (at least on the near cascade in what you're representing), far cascade precision loss is probably 🤷 .

Still working on it, but currently the size of the near cascade texture is set to be the nearest, next power of two of the largest viewport dimension. My intuition is that it doesnt need to maintain aspect ratio since its a texture used for data lookup, but not sure.

In the video, the cascades seem to be re-rendered whenever the camera moves, if all we care about is tile adjacency (e.g. stitching), should we have these tiles always axis aligned? Then sliding the grid only when new tile entry becomes available, and new stitching becomes required.

yea, i thought about that too, but I want with this since it could leave a lot of blank space in the texture when the bearing of the map is not axis aligned.

Once we create this large texture, would the idea be to sample those stitched DEMs on GPU side or CPU side? If it's only GPU would multitexturing help for this use case; binding all neighboring tiles when border access is required there?

This is for GPU side only, on CPU we can use use the @mpulkki-mapbox 's MaxMipmaps to query any point in the scene efficiently. My multi-texturing do you mean binding multiple textures, i dunno that seemed very complicated bcoz for a given tile the neighboring tiles could be of different zoom level, different size, and binding all the metadata to account for that would get nasty, also we could potentially need >1 neighboring tile based on how far out features extend, in that case, well, to bind 25 textures if we need a border of 2 tiles. 😅

[ryanhamley]

Closing as stale