Question about how hillshade interacts with 3D terrain

[unphased]

I found that I was able to combine hillshade rendering with terrain via this code:

      map.addSource("terrain", {
        "type": "raster-dem",
        "url": `https://api.maptiler.com/tiles/terrain-rgb-v2/tiles.json?key=${MAPTILER_KEY}`,
      });

      map.addLayer({
        id: 'hillshading',
        type: 'hillshade',
        source: 'terrain',
      }, 'water');

      map.setTerrain({
        source: "terrain"
      });

...which allows me to use a basic flat map style such as https://api.maptiler.com/maps/basic/style.json and by placing the hillshade layer below water works quite well as the hillshade becomes visible over landcover fills and such but labels are unaffected.

I have observed the following:

2024-05-17_15-33-23.mp4

Hillshade rendered dynamically on the client via terrain raster DEM can respond to light relative to viewport, indeed this is the default, meaning that when I rotate the bearing I can see it re-renders the hillshade. This is very beautiful but only works well in 2D mode. When 3D terrain is enabled, this viewport-based relighting of hillshade behaves in a strange way. I guess 3D terrain has raster type layers rendered to a texture and then that becomes rendered again in a height map. So it stands to reason there is some deferment here. I just wonder what I should do to address the issue. Maybe #1082 would be relevant for if I were to want to switch to map based light direction anchoring when in 3D terrain mode.

2024-05-17_15-45-43.mp4

Another "issue" I noticed right now is that the resolution of the hillshading in particular is lower in 3D terrain mode. It's even possible to see that the zoom level of raster DEM webp tiles being loaded are of a lower zoom level when switching to 3D terrain. I would like to know if there is something I can configure to reduce this particular the reduction in detail. This discrepancy does not exist when fully zoomed in since at that point the highest resolution level of the DEM is being used for both terrain mapping and hillshade rendering.

Thanks

[unphased]

One more side question is around how i should go about fixing the height of extruded 3d buildings when 3d terrain is enabled. they seem to all use the same height within a tile but it varies across tiles. So many buildings float in the air or are underground.

[HarelM]

This is probably because the building are multi-polygon instead of a separate polygon for each building.
I think there was an issue to solve this, not sure though.
The simplest solution is to make sure building are separated.

[unphased]

gotcha, hopefully if i can separate the buildings out, then the elevation adjustment would do the trick. Perhaps there would be a performance impact, though by adding another set of hitches I suppose I could then re-join them back into per-tile geometries.

[HarelM]

The following PR fixes this:
#3841
But it is missing a render test to be merged.
Once someone will provide this render test, this issue will be solved and a new version can be carved out.

[HarelM]

Regarding hillshade, yes, terrain is draping the map on the 3D terrain, and due to texture caching, hillshade tiles will not rotate and new hill shade for new tiles will have a different direction and look odd.
And yes the resolution of tiles with terrain is reduced for performace reasons, there's an issue about that too.

[unphased]

Thanks. I will dig around and read more and I'm sure I'll find that issue.

It occurs to me that hillshade would ideally be implemented in more of a direct rendering approach not during the map offscreen texture phase but during the final rendering phase, naturally, to get per-pixel lighting. In that sense, then it should become a completely separate implementation and I would never want to apply hillshade texture when 3D terrain is active, although it is such a perfect effect in 2D mode.