Hello community im new here as i am sure you can tell, This is my FIRST POST!
Ive been modding with the ADK for awhile now, i haven’t got to much work to show for it ive more or less just been mucking around and testing out new things.
So about a week ago now i wanted to get a real life scale of Hawaii Oahu into unreal/ADK.
So i downloaded 3 different DEM models and used ArcMaps to export the rasta data into a 8 bit tif file, i cant seem to get a 16bit version to export so this could be my problem but i have no other way of getting this data in good detail so idk.
ill then open the tif file in photoshop and convert to 16bit (grayscales is already on) and sometimes ill play around with contrast, brightness and curves to edit the color outputs of the map, sometimes making it almost 100% white to lower the heights.
ill save a copy in PNG no compression and 2 copys of raw in macintosh and ibm pc format.
but no matter what i try i always get the same blocky looking output, witch after… dear i say it 4 days of attempting this non stop i am a little disappointed i couldn’t work this out myself.
The res, from what i can tell ive been using the correct setting Landscape Technical Guide in Unreal Engine | Unreal Engine 5.0 Documentation
being i am exporting a 8k images for a 8km walk, after i get my first map working i will be looking into rescaleing it to real size witch i thinks around 40km or something ridiculous (dont quote me on that) so ill be using 4-5 8k heightmaps with world comp. But for now i just want 1 8k heightmap to work without looking like im playing minecraft haha
you need 16 bits. no way around that, its whats causing the stepping effect. just importing into photoshop and saving as 16 bit wont automagicly reconstruct all that missing data
Yes no way to using 8 bits - it mean you only have 256 height resolution vs 16 bits (65536). The ‘stairs’ will be visible all around the world if you use 8 bits.
The spiky version in Macintosh Raw format is because the Mac used to have a different byte order from the PC (back in Motorola and PowerPC days.)
Thus, the importer reads data in the swapped format, which ends up not working right.
Why do you use Mac format at all? Once you’ve imported it into the Unreal Editor (through PNG or RAW) you can bake into the mac format from Windows just fine.
Separately: Try adding a small amount of Gaussian Blur (radius 0.5 to 1.0 or so) to the image after converting to 16 bits, to soften out any stair-stepping you might get.
You can experiment with doing this before or after the contrast/tone mapping.
I am getting these spikes with older height maps i’ve made, since 4.14. But i am not entirely sure, if the older height maps were initially at fault, or something changed in 4.14. I am not really into height maps, i have to note.
If your source DEM data is available in .bil or one of the other common DEM formats, use TerreSculptor to convert it to proper .raw/.r16 for UE or to whatever other format you want.
TerreSculptor supports more than 80 file formats including a few DEM formats. If you choose to use it, see the Reference Manual PDF or the online wiki for what file formats are supported.
If you are using some less common format, let me know what it is, I can possibly either add it to TerreSculptor or locate a conversion app to go in-between for now.
You will never get good quality terrain using 8-bit file formats, so you need to stick with 16-bit or float formats.
When you are playing with DEM files you have to keep a few things in mind:
DEM files often contain “holes” where the sample data is missing, this usually means that the data will contain a null (0) value at that location. The simplest fix for now would be to paint that out in the UE editor.
DEM files are typically in 16-bit integer format, keep it that way or convert to float, never convert to 8-bit “color image” formats like .bmp, .jpg, .png, .tif. Note that .png and .tif do support 16-bit images but not all software can read or write them.
DEM data is usually available in both I (Intel) and M (Motorola) data formats, these formats are different in how they store the bytes of data (most-significant vs least-significant byte order). DEM formats like .bil use a Header file .hdr where they specify this information. Note that TerreSculptor correctly reads this header file and properly imports/exports the data in the right I or M format.
You may have to resample the DEM data to get it to one of the optimal UE terrain resolutions, this is most easily done in TerreSculptor. Import the DEM, resample it, export it to RAW.
Not all DEM data is properly tiled. When you download DEM data from specific world coordinate in patches, often the patches do not match up and require rotation, skewing, and edge matching. Unless you have many $1000 to purchase some GIS software, this might just be easiest for now to paint any errors out in UE. TerreSculptor will eventually have skew modifiers.
The RAW format used by UE and other game engines sucks to put it plainly, there is no header information, so be sure to use proper square aspect data just to make life easier, such as 2017x2017, and be sure to choose the Intel 16-bit format.
Back in the UE3 days I did most of the terrain and heightmap docs for Epic, so my lengthy documentation and tutorials should hopefully still be on UDN, which includes information on using DEM files, satellite imagery, etc.
If you have any other questions, feel free to ask.
If you want it, this isn’t a sales-pitch, you can get TerreSculptor at www.demenzunmedia.com and it includes a free Standard Edition that can be used for commercial as well.
The heightmap “inversion” spike issues in some of the screenshots are from loading the wrong bit-endian format, Motorola versus Intel.
The endian has to be maintained from source to final. This is one of the major hassles with using RAW format files. Bad idea.
The terracing is caused by using 8-bit data instead of 16-bit data.
Running a smooth over an 8-bit source file will just result in even further detail loss and it doesn’t get rid of all of the bit-crunch terracing unless you use a large smoothing/gaussian kernel size which wipes out even more detail.
It is not worth doing as it will result in excessive detail loss.
The proper fix is to use correct 16-bit data and export/import it with the proper endian value.
even if you 16 bit it also depends on the size and reselution it is still smart to smooth it not a lot but just very little that would get rid of the spiking. and yea it is always best practice to use 16 for height maps. I font know the resolution but usually DEM maps are not real the best (At lease in my experience).
16-bits determines the altitude range, or Z axis (vertical).
That is independent to, and not related to, the “size and resolution” which is the XY axis (width and length).
16-bits is more than sufficient in altitude range to get almost any type of terrain desired, even tall mountains, in a video game or simulation.
See my comment and UDN link at the end of this post.
DEM files are available in multiple XY resolutions as well. Just like regular heightmaps and terrain files.
DEMs can be as low as 300 to 900 meters or more per sample (really low resolution, that’s 300+ meters between each altitude “pixel” or vertex) and up to 5 meters or less per sample (really high resolution).
TerreSculptor imports/exports a number of DEM formats such as those used by the USGS and others (bil, flt, hgt, etc.), and the quality of good DEMs is great so long as you get usually at least 10 to 30 meter resolution files.
There is a small library of DEM files on the TerreSculptor forums that are high resolution and look fantastic in-game.
For reference material, see all of my old original UDN documentation on Terrain, Landscape, heightmaps, DEMS, and more.
On this UDN page I authored, see the sections regarding “Heightmap Bit-Depth” and “Draw Scale Z” and “Draw Scale Z versus Altitude Range”.
Hi,
I am a bit late out here but have a workflow for getting 16bit data out of ArcGIS that might be useful to others. Save the intermediate images from the steps below as .tif. A 16bit png for UE4 is created in the final step. Note that I use 65535 values instead of 65536. This is because ArcGIS needs a value to represent “NODATA”. If your heightmap contains NODATA values then they will present themselves as spikes in UE4.
Import the heightmap into ArcGIS.
Clip out your Area of Interest (AOI) into a new raster. Here I use a square with dimensions equal to one of the landscape resolutions in UE4 (or a multiple of them)
Get the minimum & maximum values in your AOI.
Subtract the min value from the entire raster, translating it down to 0.
Multiply the entire raster by (maxvalue/65534). This maximises the utilisation of the 16bit range of values for the heightspan in you AOI.
Convert the raster from float to int.
Now you should have a grayscale raster with interger values ranging from 0 to 65534. I haven’t been able to create a png from this using the tools directly in ArcMap which means that I havent been able to fully automate this process. Instead, rightclick on the raster from step 6 in the Table of Contents and select “export”. From here export to png and you will have a 16bit height map that can be imported into UE4. In UE4 you will need to rescale the z so that it is representative using the value that you calculated in step 5.
