Attempting to Import Elevation Data(GeoTiff) into Unreal Engine 5.5

Development World Creation
,
1

I’ve been trying to import elevation data into Unreal Engine 5.4, but I’m not getting the results I want. I’d appreciate it if someone with experience could confirm whether this approach is correct, identify any steps I might be missing, or suggest a more effective method.

Here’s what I’ve done so far:

  1. Downloaded Data:
    I obtained elevation data from Lantmäteriet (Sweden’s mapping authority) in a 1-meter resolution raster format (GRID 1+).

  1. Converting to RAW or r16 Format
    I used OSGeo4W’s gdal_translate to convert the GeoTIFF file to .r16, which is the format Unreal Engine typically requires for heightmaps:gdal_translate -of ENVI -ot UInt16 633_58_5025_2011.tif output_file.r16Unfortunately, the results in Unreal Engine don’t match the landscape properly—they look distorted or incorrect. The only thing that somewhat resembles the landscape is a low-resolution PNG export from QGIS, but even that lacks the detail and quality I need.

  2. Activated Plugins in Unreal Engine I’ve also enabled the necessary plugins in Unreal Engine (Landmass and Landscape Patch) to work with terrain and elevation data.

  3. Import Heightmap in UE 5.4
    Selected Landscape Mode there Imported Heightmap File then click Import.

Question: Is there a specific step I’m missing to get a clean import of high-resolution elevation data into Unreal Engine? Alternatively, are there better methods or tools for converting this type of data to RAW or .r16 format specifically for Unreal Engine? Any tips on getting accurate, high-res landscape data into Unreal would be greatly appreciated.

Are there any plans to support formats other than RAW and PNG, as these don’t seem to be very common in the GIS world? I would really like to see support for GeoTIFF in Unreal Engine.

2

Yes. There is no such thing on earth.
The data is in X format - whatever that format it is in, it is only ever accurate to itself.

The engine uses PNG16 - as such, you need to convert from whatever format you have to a valid PNG16 (which gdal_translate won’t do right that way).

BUT, on top of that, you also need to normalize your data. Or at least set it up to be in the correct range, and on the correct esri format.

16bit means each pixel can represent a height value between 0 and 65535.

Based on that, you need to decide what to make and how to handle it.

You can have the values of a map that match a 1:1 earth elevation to the meter, since K2 is only 8,849m up. You can probably have that elevation represent every 1/2 meter elevation and still be Ok.

Or you can figure out what your maximum elevation is, what your minimum elevation is, and create a representation that fits your needs exactly (normalization does this too).

The engine can’t even support PNG16 correctly and you want other formats? XP
No. they haven’t changed this in 12 years. they never will. They also don’t need to really. And I hope they don’t since they’ll break what little works…

GeoTIFF is not really a thing - rather it includes meta-data that’s completely useless to the sorry excuse of a landscape system that’s part of the engine;
The engine in general is a FLAT earth. To get anything anywhere accurate YOU have to apply the correct esri format to the correct slice of the map that you are dealing with. And you are wholly SOL when dealing with coordinates that include intersections on that front.
Implementing a geotiff format isn’t going to do anything for this, particularly with their proven track record of just breaking and destroying their own engine making boneheaded changes…

On that note:
Don’t bother figuring things out in engine;
Make your map using Houdini or Blender. import a mesh.
Even a full mesh with 1 vert per meter for 20km^2 will outperform the landscape system.

And last thing:

You don’t need quality if you are using this engine’s landscape in the first place. You are limited/stuck to 1vertex per meter.
Quality would imply MUCH more than 1 vertex per meter when positioning pieces of terrain…

Try Grass Gis.
After you get your data within a 0 to 1 range you can export as PNG16 natively.

If you need to manipulate the data outside of a DCC, remember the fact that it’s data; not an image.
You CAN manipulate it, but only using programs that work natively with 16bit (or 32bit depending on what your initial data was in) - so Nip2, Krita, maybe GIMP. Though I still wouldn’t suggest doing as much if not for specific purposes that get you known “bad” results (for example, Nip2 can radial blur to remove terracing after enlargement, at the expense of accuracy of terrain data - wile also providing you an easy way to cut up map tiles off a sequence of Geotiff or whatever else you load in without running a 16GB ram system out of ram)

3

Thanks for the input, think I managed to resolve the issue, or at least get closer to a workable result.

Here’s what I did to improve the import accuracy:

  1. Analyzed the Elevation Data:
    I used gdalinfo on the original GeoTIFF to identify the elevation data range:

    gdalinfo 633_58_5025_2011.tif

    This returned a range with Min=13.690 and Max=31.930 and a NoData Value=-9999.
    Knowing these values allowed me to accurately scale the data to fit Unreal’s expected range.

  2. Updated the Conversion Command with Scaling:
    I modified the gdal_translate command to scale the input data correctly to Unreal Engine’s 16-bit heightmap range (0 to 65535):

    gdal_translate -of ENVI -ot UInt16 -scale 13.69 31.93 1 65535 -a_nodata 1 633_58_5025_2011.tif output_file.r16

    This produced a closer representation in Unreal, but I noticed the highest points were still too elevated.

  3. Refined the Maximum Value for Better Accuracy:
    By adjusting the maximum value from 31.93 to 64, the landscape appeared more accurate in the demo map, so I tried:

    gdal_translate -of ENVI -ot UInt16 -scale 13.69 64.0 1 65535 -a_nodata 1 633_58_5025_2011.tif output_file.r16

The result was much closer to what I needed, though I may still do some fine-tuning on the scaling for final accuracy. But overall, this approach has given me a workable landscape in Unreal Engine.

4

You can do more precise elevation math by applying ratios.

If your height is X, on a normalized map you apply a Z scale value that makes that accurate to ±1m
(Default of 100 should be 125m. Test it out. The range is either 256/2 or 512/2 cant remeber wich but trivial to check, just make a default landscape with a black to white elevation texture, plqce a cube. Read its Z).

The position above Z 0 in engine depends on your normalization.
If your map elevation is all above ground you can scale the result between 65535/2 and 65535 to get only positive (above z 0) values.