On my previous post I derived the following landscape scaling vector: (277.83, 277.83, 34.69). However, I've quickly realized my mistake: While it is safe to assume a degrees of latitude to linear distance conversion remains about the same for anywhere on the globe this is obviously not true for the degrees of longitude to linear distance conversion. Reason being that the lines of longitude converge as we approach the poles. Therefore, the scaling factor for the x component of the landscape (longitude lines) needs to be different from the y component (latitude lines). The trouble is that UE4 Editor won't allow you to scale this two dimensions independently: As soon as you change the x scaling factor and press enter, the y scaling factor automatically assumes the same scaling factor value as x. This is to prevent the quads in the landscape structure to become something other than squares, or so I read in the UE forums somewhere.

I found a solution to my dillemma: Scale the heightmap so that in effect the heightmap represents linear distance as opposed to degrees of lat/lon. As a quick recap, my heightmap was build using elevation samples every 9 AS (arc seconds = 1/3600th of a degree) latitude and longitude wise. 9 AS is rougly equivalent to (30.87*9) 277.83 meters latitude wise everywhere on the globe. But longitude wise, 9 AS is only equivalent to 277.83 meters on the equator longitude wise. But my heightmap is based around Mt. Raininer USA and according to Google it is located at the lat/lon pair (46.8529°, -121.7604°). Therefore, 9 AS at that latitude is equivalent to

(277.83 m)/cos(46.85 deg) = 406.237246926 m

Moreover, assuming we want the heightmap to represent a linear distance equivalent to 501x501 9 AS posts, then we need to rescale our heighmap along the horizontal (longitude) axis by this much.

((406.237246926)/277.83)*501 = 732.551778821 or 732 if flooring.

Bottomline, we need to rescale our image from the 505x505 original dimensions to 732x505 dimensions. This meant time to get help from our friend Imagemagick.

I found a solution to my dillemma: Scale the heightmap so that in effect the heightmap represents linear distance as opposed to degrees of lat/lon. As a quick recap, my heightmap was build using elevation samples every 9 AS (arc seconds = 1/3600th of a degree) latitude and longitude wise. 9 AS is rougly equivalent to (30.87*9) 277.83 meters latitude wise everywhere on the globe. But longitude wise, 9 AS is only equivalent to 277.83 meters on the equator longitude wise. But my heightmap is based around Mt. Raininer USA and according to Google it is located at the lat/lon pair (46.8529°, -121.7604°). Therefore, 9 AS at that latitude is equivalent to

(277.83 m)/cos(46.85 deg) = 406.237246926 m

Moreover, assuming we want the heightmap to represent a linear distance equivalent to 501x501 9 AS posts, then we need to rescale our heighmap along the horizontal (longitude) axis by this much.

((406.237246926)/277.83)*501 = 732.551778821 or 732 if flooring.

Bottomline, we need to rescale our image from the 505x505 original dimensions to 732x505 dimensions. This meant time to get help from our friend Imagemagick.

The following line does the trick

convert Rainier_505.png -sample 732x501\! Rainier_732x505.png

However, -sample simply repeats some of the columns in order to achieve the size requested. This ends up creating the following 'banding' looking lighting artifact:

convert Rainier_505.png -sample 732x501\! Rainier_732x505.png

However, -sample simply repeats some of the columns in order to achieve the size requested. This ends up creating the following 'banding' looking lighting artifact:

A better solution is to use

convert Rainier_505.png -resize 732x501\! Rainier_732x505.png

The resulting heightmap here has its additional columns interpolated smoothly in order to avoid the banding problem illustrated above. A result of that is shown below.

convert Rainier_505.png -resize 732x501\! Rainier_732x505.png

The resulting heightmap here has its additional columns interpolated smoothly in order to avoid the banding problem illustrated above. A result of that is shown below.

Now, I've found the scaling factor I derived for the z component of the landscape has an issue as well. By construction, my 16-bit heightmap encodes values in a uint_16 so that 0-65535 represents heights ranging from 0-9848 meters. Mt Everest at 8,848 meters was taken as reference for the maximum value that could be encoded. The extra 1000 m are used to represent up to -1000 m below ocean. Furthermore, the default z scaling factor for a landscape is 100 and this represents -25000 to +25500 meters (yes I know I'm not using 1 UU as 1 cm but this is done so that I can move around in the editor easier).

Therefore my correct z scaling factor should be (9848 * 100)/51000 = 19.31

In summary, scaling factor (which I hope is correct this time) is

Finally, the image comparsion below shows the difference in realism that can be achieved by adding normal textures and ambient occlusion textures, per layer, to the landscape material.

Therefore my correct z scaling factor should be (9848 * 100)/51000 = 19.31

In summary, scaling factor (which I hope is correct this time) is

**(277.83, 277.83, 19.31).**In order to position my landscape so that ocean level is at 1000 units I offset the landscape on the z-axis by 9482/2 = 4924 units/meters.Finally, the image comparsion below shows the difference in realism that can be achieved by adding normal textures and ambient occlusion textures, per layer, to the landscape material.

In the images below I've added a fishnet type texture and a color gradient based on height.