In my previous post, I showed a picture depicting Mt. Rainier. However, it is obvious that the scaling is off. So I tried to fix this. After some of investigation, I finally stumbled upon the following Epic's

Now, I know the vertex resolution of my data is 9 arc seconds and if I take the simplified assumption that 1 arc second = 30.87 meters (true at the equator but changes as the longitude lines converge around the poles). Therefore, each vertex has a separation of (30.87*9) = 277.83 meters.

Because my original heightmap had a resolution of 1776x521 we are talking of a heightmap that would span 493+ km x 144+ km if scaled appropriately!

So, I had to break this png into a smaller chunk for this experiment and I turned to imagemagick (which I happened to have installed in my Ubuntu box) to get this done while preserving my 16 bit depth grayscale. Cropping in other tools, even GIMP, resulted in a reduction of the bit depth back to 8 bits grayscale . Anyways, the following command broke my png into smaller 512x512 chunks as much as possible.

convert Rainier.png -colorspace Gray -depth 16 -crop 512x512 +repage +adjoin Rainier_chunks%02d.png

However, I ran into another problem which is depicted in Figure 1. Turns out I didn't have a correct size for my heightmap.

convert Rainier.png -crop 505x505+720+0 +repage Rainier_505.png

**documentation page**. It basically explains what the default scaling of (100, 100, 100) means:*- 1 meter by 1 meter spacing between each vertex in the heightmap (or between each pixel in the png). This makes sense as each Unreal unit maps to 1 cm. Therefore, 100 cm = 1 meter.*

- 100 factor on the Z axis means that the height values get mapped to -255 m to +255 m range.- 100 factor on the Z axis means that the height values get mapped to -255 m to +255 m range.

Now, I know the vertex resolution of my data is 9 arc seconds and if I take the simplified assumption that 1 arc second = 30.87 meters (true at the equator but changes as the longitude lines converge around the poles). Therefore, each vertex has a separation of (30.87*9) = 277.83 meters.

Because my original heightmap had a resolution of 1776x521 we are talking of a heightmap that would span 493+ km x 144+ km if scaled appropriately!

So, I had to break this png into a smaller chunk for this experiment and I turned to imagemagick (which I happened to have installed in my Ubuntu box) to get this done while preserving my 16 bit depth grayscale. Cropping in other tools, even GIMP, resulted in a reduction of the bit depth back to 8 bits grayscale . Anyways, the following command broke my png into smaller 512x512 chunks as much as possible.

convert Rainier.png -colorspace Gray -depth 16 -crop 512x512 +repage +adjoin Rainier_chunks%02d.png

However, I ran into another problem which is depicted in Figure 1. Turns out I didn't have a correct size for my heightmap.

**Documentation**does do a good job explaining how to arrive to a size that is good for the engine so I settle for 505x505. Further, I used the command below to generate a 505x505 around the feature of interest: Mt. Rainier. Figure 2 depicts this heightmap.convert Rainier.png -crop 505x505+720+0 +repage Rainier_505.png

Now, at 505x505 my heightmap still spans 140+ km and, if scaled appropriately inside the Engine, its still huge. So huge that navigating through feels painfully slow even at a high camera speed due to the scale of things! Hence, I did the following trick/cheat. I decided to interpret the unreal units differently. ! unreal unit no longer meant 1 cm in my level but rather 1 meter. Hence to get the scaling correctly on the x and y axis I used (277.83, 277.83) instead of the default (100, 100). For the z axis I had to think about it for a moment. I know 100 mapped to 25500 cm (255 meters) but and based on my new interpretation this meant 25500 meters. Moreover, I knew my data was encoded so that the highest it could ever be: 8,848 meters (Mt. Everest) mapped to MAX_UINT16_T or 65535. Therefore, if 100 scaling factor corresponded to 25500 meters, my new scaling factor could be calculated as follows (8848 * 100) / 25500 = 34.69. My final scaling vector was thus

**(277.83, 277.83, 34.69).**

Figure 3 shows how my rendering looks like with the new scaling factor (which looks more like the real life Mt. Rainier).You probably noticed those ugly black spots right?. At first I thought this was an issue with my layers. But, replacing my layered Landscape material with a simple material that didn't use layers revealed the problem was with the lighting. Next, I tried increasing the lightmap resolution for my landscape but this didn't help at all. Just for kicks, I tried disabling the cast shadows property of my directional light and the black spots went away! Aha! Scaling the heightmap exposed the low resolution of my data and this in turn was causing jittery shadows as well as a couple of self intersecting shadowing artifacts. This is a known limitation of the shadow mapping technique which UE4 uses by default for directional lights unless told otherwise. The solution I found for this is to replace shadow mapping with a technique called 'Ray Trace Distance Field Shadows'. This is done easily in Unreal (last image shows the result):

**In Project settings, under Engine - Rendering, enable 'Generate Mesh Distance Fields' checkbox. Then restart the editor.****With the directional light selected, under Details panel, Look for Distance Field Shadows section and enable 'Use Ray Traced Distance Field Shadows' checkbox.****Build the level.**