Exaggerating Elevation

[Thomas-F]

I am interested in being able to change the vertical exaggeration of the map surface, so that elevation data is scaled. I'd like to be able to provide a scaling factor, and scale the vertical axis by that value, and also be able to change that exaggeration scaling factor for the same elevation data source.

For example, using an exaggeration scaling factor of 5, I'd want to visualize elevation data as if the altitude at each point was 5x higher. So starting with the following, with no exaggeration:

After applying an exaggeration scaling factor of 5, it should look more like:

The way I implemented it to get the screenshots above, I tried scaling the `ArcGISMap` transform's Y-component, and initially it looked fine like in the screenshots. However, based on some other threads, it sounds like changing the ArcGISMap transform scale is not really supported. I started seeing some issues like tiles becoming disconnected after experimenting with this and changing the map origin position a bit:

Another approach I've considered is doing it in a vertex shader, however I can't find a way to use a custom map tile material.

So what I'm looking for is a more robust way I might be able to achieve the exaggerated elevation effect I'm aiming for.

Thanks!

[mbd]

Hi @Thomas-F , interesting strategies!

We managed to make it work exagerating elevation data in arcGIS first and creating a hosted layer to use it as elevation source in Unity afterwards.

Sorry it is not clear and detailed explanations but my collegue should post our solution soon on this post:

Re: lidar data as elevation source - Esri Community

Let me know if you develop new solutions for that purpose.

[Thomas-F]

Thanks @mbd - appreciate the link, and will keep an eye on your post.

For our use case we would ideally like to be able to vary the exaggeration at runtime without needing to prepare the exaggerated data externally first so that we can use many different exaggeration scales without needing a separate dataset for each.

Unfortunately I haven't found a solution yet, and thinking more on the vertex shader approach I mentioned in my initial post, that has some major caveats such as the mesh collider of the map surface not taking exaggeration into account.

It looks like the kind of capability we'd like is something that's provided by the ArcGIS Maps SDK for JavaScript by specifying an `exaggeration` property on an elevation layer as described here. A similar API in the Unity Maps SDK would be ideal, but as far as I can tell this doesn't appear to be supported here yet.

[Thomas-F · Accepted solution]

Update

Although this doesn't feel like a truly supported or ideal solution, I've managed to get this working by scaling the vertical axis of the ArcGIS Map transform.

The reason for the issues with disconnecting tiles in my original post seems to be related to changing the map transform scale very soon after changing the map origin, camera location, and extents centre when changing the target map position in my application. Providing a long enough time is waited (e.g. 1 second) after changing the target map position, scaling the vertical axis of the transform does not result in the tiles disconnecting.

Some additional information about my setup if it helps anyone:

I am using a Local map with extents. When I say "changing the target map position in my application",  I mean changing the ArcGISMapComponent's origin, the ArcGISCamera's position, and the extents geographic centre so that the map is centred about a different geographical location.

[wengyuan1110]

Hi @Thomas-F, In my case, I have pan (set ArcGISMapComponent's origin and extent) and zoom (ArcGISMapComponent's localscale and extent). I have tiles disconnecting issue as well. I try your method to wait for 1 second, the disconnecting issue still exists. Do you have any other solution for this? Thank you.

[Thomas-F]

This only seemed to work for scaling the y component of the transform. Scaling the x and z components too always seems to result in disconnected tiles.

No alternative solutions to what's outlined above I'm afraid. The most robust way we could find for elevation exaggeration was to scale the y component, but only after allowing sufficient time for other map updates to happen, and similarly, not doing any other updates until some time has passed after scaling. Unfortunately it's not very scientific and I don't know the reasons for why this is the case since I'm not sure what's going on in the source, but this seemed to work okay, at least as a proof of concept - I haven't done vigorous testing of this yet.

[wengyuan1110]

Noted. Thank for the reply.