Chrome crashes with Terrain Layer with pitch > 60 'over fetching' tiles

[mogmog]

If I use Terrain layer with a pitch of > 60 then the number of requests rockets as it fetches tiles for areas far in the distance on the horizon that dont need the same high res version as those tiles in the fore ground.

It ends up fetching over 100Mb on the St Helena demo and kills my browser tab.

If someone can give me some clues on a strategy I can attempt fixing this but might need some help.

[kylebarron]

I don't think there's a good way around this, and so I would suggest when using the terrain layer to not increase the pitch past 60 degrees.

The reason is that the terrain layer combines heightmaps and image textures using the normal OSM tile index. That means that there's no way to have an approximate outline of the terrain in the distance without downloading and creating a mesh for every one of those tiles.

I believe this is something that other 3D formats, like Tiles3D and I3S fix... That you can quickly get a rough outline of the terrain without needing to build a mesh from scratch. The downside, of course, to those formats, is that you have to generate all the data in advance. One of the great benefits of the heightmap + image texture is that you can use any image texture without needing to do expensive and large data generation ahead of time.

One possible speedup improvement is to reduce the meshMaxError for tiles further away from the viewport. This might help the crashing, because a lower meshMaxError creates fewer triangles in the mesh, and would use less GPU memory. However this wouldn't do much to improve the speed of the rendering, since the last step of creating a mesh, which is when meshMaxError is applied, is actually very fast anyways.

The other possible improvement, which would be more invasive, would be to change the zoom level for fetching tiles far away. See this image from a Mapbox GL JS PR:

The tiles further away use data from lower zooms, which means fewer tiles to download and process.

[mogmog]

I know what you mean about it being more invasive - typically I like the fact that with Deckgl you have control of a lot of the parameters that are not always available to you with other libraries... but considering there is literally zero benefit to having full res tiles displaying on the horizon, changing the zoom level for tiles far away seems reasonable - pretty sure that's how all other libraries do it?

[mogmog]

Also, the idea of " when using the terrain layer to not increase the pitch past 60 degrees:" seems pretty dodge - how is a dev meant to know this?

[kylebarron]

Also, the idea of " when using the terrain layer to not increase the pitch past 60 degrees:" seems pretty dodge - how is a dev meant to know this?

Because the default max pitch is 60, as it is in Mapbox GL JS. You can't increase the pitch beyond that unless you manually change the parameters to MapView. If you change those parameters you need to accept the performance implications.

[mogmog]

It's ESRI and Cesium that I have familiarity with - and yeah I know what you mean they seem to have specialised formats rather than relying on 'vanilla' DEM files.

I am now experimenting with ESRI and deck layers together so that might be a work around

[kylebarron]

Well if you can access 3DTiles/I3S tiles through their API, you can just use the 3D Tiles module/layer

[ibgreen]

Some history: From the deck.gl side, we have been lobbying mapbox for a long time (since 2016, I just checked the ticket!) to add for support pitch > 60, and my understanding is that the same "infinite amount of tiles at the horizon issue" is also the reason that they did not support it.

Now that deck.gl has a growing set of tile layers, we are starting to hit the same technical limitation as mapbox did.

My expectation is certainly that deck.gl will overcome this limitation. And indeed there are a number of things we can do, most of them mentioned above:

• avoid loading tiles a certain distance from the horizon (just show a background color, or repeat last tile, or render nothing, or a grid, or ...).
• only load tiles that are bigger than a certain size in pixels.
• load lower zoom tiles for pixels close to the horizon.
• Use a request scheduler (presumably the one from the Tile3DLoader).
• etc.

In the mean-time, assuming this issue is just related to showing tile layers close to pitch 0 (i.e. not from underneath) you could just add code that hides the terrain layer while the pitch is close to the horizon (+30 to -30 degrees). This should allow avoid the crash and allow the user to "get under" the terrain.

[mogmog]

Hiding the tiles close to the horizon- It introduces a possibility of creating an Deckgl Effect that performs a fog/blur just at the horizon - in order to smooth it out.

[MacieJCzarkowskI]

@ibgreen Is there any request scheduler for layers? I have geoserver WMTS request and when pitch is more than 60 i get hundreds of them and freeze the browser.

[ibgreen]

Not in the layers, but there is indeed a request scheduler in loaders.gl, in the @loaders.gl/loader-utils module.

At the moment that implementation is rather hacky, it was put together quickly to improve 3D tile loading, however the idea is to clean it up and also use it for 2D tiles.

So there is a plan (or at least an intent), but obviously someone needs to do the actual work. FWIW, it currently looks like my team will be looking at that within the next month or so as part of a project we are working on.

@kylebarron

[Pessimistress]

@MacieJCzarkowskI The over requesting issue is not going to be solved with a request scheduler. We need to not request those tiles at all. This can be fixed with frustum culling and dynamic LOD, which I'm looking into now.