Blocky terrain when using high resolution data

[rbrundritt]

I've been testing several platforms to generate 3D terrain using high resolution DEM and Lidar data (0.5M to 1M resolution). I'm finding that when I load this into MapLibre and zoom in such that the high-resolution data is loaded, the map terrain becomes very blocky. I believe this is due to how the terrain mesh is generated from the height map image of the tile (I encountered similar issues with height maps in Babylon and three.js). I'm generating tiles that 512x512 in size down to zoom level 17 which should give me a resolution of just over 1 meter. Visually inspecting the tiles the data looks pretty smooth/gradient and not blocky. I created the tiles using rio-rbgify and pretty sure that's not the issue.

I also created quantized mesh tiles from the same DEM data and the difference in quality is very noticeable (it looks beautiful in comparison).

Actual behavior: MapLibre

Desired behavior: What I achieved using quantized mesh and Cesium

Steps to Trigger Behavior

maplibre-gl-js version: 4.7.1

Here is a simple app and the generated tiles that reproduces this issue.
MapLibre_HighResolutionTerrain.zip

Here is the DEM file I used to create the tiles:
club_dem_54453779.zip

Link to Demonstration

I've also uploaded a version of this here: https://rbrundritt.azurewebsites.net/Demos/MapLibre/Terrain/tile_test.html#20.14/47.5329806/-122.1391759/-60/85

Thoughts on resolution

• Consider improving the terrain meshing logic. Need to balance the cost of smoothing the mesh with the benefit of has having less triangles in the mesh.
• Add support for other terrain data formats, such as quantized mesh.

[larsmaxfield]

TL;DR: Seems to be an issue with rio-rgbify encoding interval, not MapLibre.

The source DEM file appears to be a 32-bit floating TIFF when I read it with OpenCV in Python:

import cv2

image = cv2.imread(r"club_dem_54453779.tif", -1)  # Read unchanged
print(image.dtype)  # Show type
print(image[100, 200])  # Show value at row 100, column 200

float32
188.16412

From what I understand, rio-rgbify defaults to an interval of 1 for encoding. If you keep this default interval, it will essentially round those elevation floats to the nearest whole number. This quantization then ultimately causes the blocky terrain you see.

To smoothen the terrain, you could try encoding at a finer interval with rio-rgbify by specifying interval=0.1. This will round those elevation floats to the nearest tenth. This is actually MapLibre's default for decoding terrain.

If you go finer in the interval (0.01, 0.005, etc.) to get an even smoother terrain, you will need to set the terrain encoding to "custom" and specify the encoding values in terrainSource like this:

    const interval = 0.01;
    const baseShift = 0.0;  // rio-rgbify default
    const redFactor = 256.0*256.0*interval;
    const greenFactor = 256.0*interval;
    const blueFactor = interval;

...

                terrainSource: {
                    type: 'raster-dem',
                    tiles: ['tiles/{z}/{x}/{y}.png'],
                    tileSize: 1024,
                    bounds: [-122.156627, 47.527467, -122.127463, 47.540503],
                    minzoom: 13,
                    maxzoom: 18,
                    encoding: "custom",
                    redFactor: redFactor,
                    greenFactor: greenFactor,
                    blueFactor: blueFactor,
                    baseShift: baseShift,
                },

[acalcutt]

I've been messing a bit with swissALTI 0.5 dems here

In my first attempt I had made this terarium terrain down to zoom 17 and experience the blocky terrain you mentioned.
https://stackblitz.com/edit/web-platform-qq1it1?file=index.html

I just did a new attempt in terrainRGB down to zoom 16 and it seems like it doesn't seem like it experienced that issue
https://stackblitz.com/edit/web-platform-cwvqs7?file=index.html

In my first attempt, the terrariun mbtiles, the interval isn't really adjustable so I assume that is like using the default 1 interval. In the second attempt I switched to terrainrgb with the maplibre 0.1 interval defaults. I also tried lowering the zoom 1 level based on some discussions with another user on slack (which I can't seem to find now)

There is also an option now to make a custom interval now below 0.1 if you wanted, but in my testing it seems like it increases file size.

Also, this discussion on slack
https://osmus.slack.com/archives/C03TFH5NE83/p1725381818028079

[rbrundritt]

I'll give these things a try. Thanks

[rbrundritt]

This is taking me a lot longer than I'd like to admit to get working. I have created a tiff using both Mapbox and Terrarium tiles that are correctly RGB encoded now (three band uint8). I've been passing the tif through QGIS to generate tiles quickly for testing. I'm still seeing blocky terrain in the map.

As a separate test I have a draggable marker to get the elevation, but ran into this #3736 which threw me off and had me manually converting RGB colors to verify the image was encoded correctly. map.terrain.getElevationForLngLatZoom. I have the correct elevation data in the map.

However, inspecting the DEM file after I reproject it I'm noticing that the pixel size value in the metadata is like 1.48 instead of 1, which is making me think this might be the cause of my issue. Digging into this now.

[rbrundritt]

I'm at a loss here. Everything I try brings me right back to the blocky terrain. The conversion of the 1m dem to Mercator did stretch the pixels by about 1.48 and I then corrected that to get the pixel resolution to back to 1. However, I suspect that then means a single pixel represents 1.48m now and at zoom level 17 a single pixel is approximately 1.19m/px when using 512 size tiles, which I could understand being a cause for blocky mesh generation. However, limiting to zoom level 16 where the tile resolution is about 2.39m/px, things are a bit better, but still blocky. I've literally have read through every blog post, tutorial, and forum post on stackoverflow related to rgb terrain tile generation and have hit a brick wall here.

[larsmaxfield]

Which interval(s) did you try with rio-rbgify?

[rbrundritt]

I started with 0.1, then went to 0.01 with a custom encoding, and it looks exactly the same.

[rbrundritt]

Today I tried a different tactic and tried using GDAL and rio-rgbify via command prompt based on https://github.com/watergis/dem2terrainrgb I ended up with the exact same result. So at least I'm able to rule out my mediocre python coding skills. I tried intervals of both 0.1 and 0.01 and the results where exactly the same.

I then tried generating tiles that are 1024 in size to zoom level 18 (basically two more levels of detail than what I have been using), and when Maplibre managed to render it (kept flashing and having to reload), I could still see the blocky issue.

After all that I took a closer look at the example @acalcutt provided and at first it looked ok, but with a small change to the sample I managed to reproduce the issue there too. The change I made was that I increased the max zoom level to 20 (it was 18). Here is a screenshot:

Now, I'm wondering if maybe the terrain mesh is continuing to be generated at zoom levels beyond the supplied max zoom of the tiles source, and the tiles are simply being scaled and used to generate a new mesh but isn't accounting for the change in pixel resolution. Looking at the code here:

maplibre-gl-js/src/render/terrain.ts

Line 379 in d67fc04

getTerrainMesh(): Mesh {

it doesn't look like it (although I'm not that familar with that code). If this is the case there is a potential performance enhancement here where the mesh resolution should be scaled based on the max zoom of the tile source and would result in simpler meshes (half the number of indices as the previous zoom level), or the last valid mesh could be reused and scaled. This might be the cause of this issue: #4487

[larsmaxfield]

Thanks for detailing all the troubleshooting you've done. This now goes beyond my experience and know-how — I'm not in a position to help further. Perhaps @acalcutt has an idea?

[rbrundritt]

Would it make sense for this to move back to the issues section? It appears the issue is related to over scaling of height map elevation tiles when zooming in several levels beyond the max zoom of the elevation tile source.

[HarelM]

I'm not sure I fully flow... I have terrain RGB tiles in my app and even when I zoom in a lot I still don't see these issues...