Heightmap app reference in the docs - How can I improve it?

[manticorp]

Hi community!

I am the author of a height map generator mentioned in the Terrain3d docs :

https://manticorp.github.io/unrealheightmap/

It's mentioned here:

https://terrain3d.readthedocs.io/en/latest/docs/heightmaps.html#real-world-data

I made the app originally with Unreal Engine in mind - however, it has since gained in popularity in many different fields/engines - how can I make it better for Terrain3d / Godot4?

Any feedback is welcome!

[TokisanGames]

Hi. The most useful thing would be:

1. The option to export as 16/32 bit float EXR with real heights.

Normalized heights in EXR or real heights as r16 (16-bit int) are OK as long as you print out the scale, offset, and dimensions of the source data in the included download. But both formats are more clunky. Godot can't read 16-bit PNGs or TIFF.

2. Ensuring there's an easy option for terrain resolution of 1px:1m, which is our default. We are adjustable from 1px:0.25m to 1px:100m. On your page it calculates terrain resolution, but it's controlled by output zoom. I'd rather you reversed that. Remove output and let us control output terrain resolution directly. And let that setting, and the output texture size dictate the size of the output box shown on the map.

3. You could also expand up to 16k textures. You could even allow a selection of larger areas, that slices into 8k or 16k files. We can hold terrains up to 65,536m per side

4. We prefer power of 2 sized maps. The odd sides of UE maps will get padded up to pow2 or create additional regions if over.

5. Finally, you could document what your settings do. What is smart normalize vs regular? What are norm from and to? What is generate albedo from?

[manticorp]

Hey, thanks for the response!

The option to export as 16/32 bit float EXR with real heights.

I'll see if I can make that happen!

The "None" normalisation mode is actually just real heights, so it's just a matter of learning how to export EXR in the browser, which shouldn't be too difficult.

So if you can use the 16 bit PNG output on None mode, that would give the real height values.

Ensuring there's an easy option for terrain resolution of 1px:1m, which is our default. We are adjustable from 1px:0.25m to 1px:100m. On your page it calculates terrain resolution, but it's controlled by output zoom. I'd rather you reversed that. Remove output and let us control output terrain resolution directly. And let that setting, and the output texture size dictate the size of the output box shown on the map.

Yes this has been common feedback also - I'm a bit limited by the source data as to the resolutions that can be displayed...the whole point of the app was to avoid resampling the source data, hence the fixed zoom levels!

However, I'll see if I can make that work 😁

You could also expand up to 16k textures. You could even allow a selection of larger areas, that slices into 8k or 16k files. We can hold terrains up to 65,536m per side

Yeah, that would be awesome! Someone else suggested that (tiled exports, that is) for doing super size projects.

I'll see if I can implement that, as well!

We prefer power of 2 sized maps. The odd sides of UE maps will get padded up to pow2 or create additional regions if over.

Just to check, so that would be like:

• 256px
• 512px
• 1024px
• etc

Not (2^n) +1? I know some apps prefer (2^n)+1 so that there are 2^n squares per side, and the pixels are used for vertex heights.

I can add some specific Terrain3D presets to the preset list 👍 Would the following be good?

• 256px
• 512px
• 1024px
• 2048px
• 4096px
• 8192px
• 16384px
• 32768px
• 65536px

Finally, you could document what your settings do. What is smart normalize vs regular? What are norm from and to? What is generate albedo from?

Yes the most common complaint seems to be that it's difficult to understand and use!

I do have an instructions page here (including info about the norm modes) but I should probably try and make the actual UI a bit clearer!

[TokisanGames]

So if you can use the 16 bit PNG output on None mode, that would give the real height values.

Ok, I see. However a reminder, 16-bit PNG is converted to 8-bit PNG in Godot, so we don't want to use it for heights.

256px, 512px, 1024px

Yes.

Not (2^n) +1? I know some apps prefer (2^n)+1 so that there are 2^n squares per side, and the pixels are used for vertex heights.

Each pixel represents a visual vertex. Our collision is +1.

However the UE dimensions are not +1, nor -1. They're more like -3 and are oddball. We use power of 2.

I can add some specific Terrain3D presets to the preset list 👍 Would the following be good?
256px, 512px, 1024px, 2048px, 4096px, 8192px, 16384px

Sure. We can do terrains down to 64px, but people using that won't likely be using real world data so small.

Godot can import up to 16k textures. (Their docs say it's hardware dependent and some cards can do 32k, but it's plausible that they hardcoded a 16k max).

32768px, 65536px

Terrain3D can handle this much data, but only if imported in 16k or smaller slices.

We can also import odd sizes like 5555 x 7654. It will be sliced into power of 2 sized regions, and any remainder will be padded to the next size up. But power of 2 defaults are good presets.

[manticorp]

Awesome, thanks for the detail!

I've added 16 and 32 bit EXR export to the application:

https://manticorp.github.io/unrealheightmap

Hopefully that helps!

I've also added some "power of 2" preset output options, helper tooltips, and changed the UI around a little bit to (hopefully) make it a teensy bit more friendly.

Ensuring there's an easy option for terrain resolution of 1px:1m, which is our default. We are adjustable from 1px:0.25m to 1px:100m. On your page it calculates terrain resolution, but it's controlled by output zoom. I'd rather you reversed that. Remove output and let us control output terrain resolution directly. And let that setting, and the output texture size dictate the size of the output box shown on the map.

Unfortunately, this just isn't going to be possible.

I really want to avoid resampling the data (i.e. having non integer zoom levels), so this would have to be done in post processing if the user really wanted it.

This goes doubly so because the source data isn't necessarily linear - a large area will vary in pixel/m as you go up/down latitude - which is just a facet of the map projection.

I will see if I can do tiled exports next!

[manticorp]

Aaand we now have tiled exports, for easy breaking up into sized chunks or n chunks per side 😁