I have a quick question. I’m trying to understand the reasoning behind why landscapes in UE4 are not powers of 2 like most everything else. Why is it that instead of 2048x2048 it’s actually 2017x2017? Why is it that when importing a terrain from World Machine, you have to scale up on the Z axis by 0.1953125? I consistently find information telling me to use the numbers, but not explaining why to use these numbers. Here’s a math question I don’t quite get that’s related to this:
If my terrain is 4096x4096, then multiplying by 0.1953125 gives me a Z scale of 800%. However, if my terrain is 4033x4033, then multiplying by 0.1953125 gives me a Z scale of 787.6953125. That’s a really awkward number and not nearly as simply as just a plain 800%.
Basically, I’m just asking for assistance on understanding why I’m using these numbers so that I’m not blindly typing stuff in. Thank you in advance!
That is because the way landscapes are made up in Unreal 4:
The landscape is divided in several components, which are used for LODing, streaming and such.
Then each component is divided in sections, either 1x1 (aka one component is one section) or 2x2 (aka one component has 4 sections).
Then each section finally has the vertices, which are grouped into “Quads”, aka squares made up of 4 vertices each.
For each section you can have 7x7 quads ~ 63x63 quads. Here you have your power of two vertices : 7x7 quads, if you think about it, is 8x8 vertices. 63x63 quads is 64x64 vertices. So each section is power-of-two based in the amount of vertices in each axis. However the amounts of components is not bound to power of two.
Now the important part why the end resolution numbers are so wierd:
If you have two components of 8x8 each combined it is not 16x8, as you might assume, it is 15x8, since the components are combined and share the vertex line where they meet.
So if you have one starting component and add another component you add <normal component resolution>-1 since you have to subtract the vertex line where they are combined.
In addition to that, if you choose 2x2 sections per component, another line of vertices is subtracted since the sections also meet at one vertex line on each axis. So with 2x2 sections per component the “starting point” component “loses” one vertex line, each additional component “loses” two lines : one for where the sections meet, one where this component connects to its neighbor component.
Some examples: (warning, math!)
If you have 7x7 quads per section, 1x1 sections per component and 20x20 components, then you have:
one “starting point” component with 8x8 vertices per section * 1x1 sections = 8x8 resolution
for each additional component in each direction you add 8-1 = 7 in the corresponding direction. (8 base resolution per component, -1 since we share one vertex line with the neighbors component)
So 8x8 base resolution, add 19 additional components with 7x7 each = 8+(197) x 8+(197) = resolution of 141x141
Another example : 127*127 quads per section, 2x2 sections per component, 8x8 components :
one starting point component with 128x128 vertices per section * 2x2 sections per component = 256-1x256-1 = 255x255 resolution for the starting component. (-1 because of each section sharing one vertex line with another section)
for each additional component in each direction you add 256-1-1 = 254 in the corresponding direction : (first -1 because the sections share one vertex line, another -1 because the component, as in the first example, shares a vertex line with the neighbor component)
So 255x255 base component resolution, add 7 additional components of 254 vertices in each direction = 255+(7254) x 255+(7254) = 2033x2033 overall resolution.
The most logical explanation if can think of:
A UE4 landscape with a Z axis scale of 100 can have terrain deformations from -256 meters up to +256 meters below/above the initial landscape plane. I think this has to do with how Unreal 4 will interpret the white/black height maps in terms of how high the terrain should be (“If i see on the height map a grey pixel with the RGB value of (230,230,230), how high should that be for the terrain?”).
If you use World Machine to create a landscape that has different max/min height than these ±256 meters then the Z scale needs to be adjusted so the white/grey/black colors on the height map are interpreted correctly by the Unreal 4 engine so the imported terrain has the same height values as in your World Machine program.
For example if you have a height map that is half RGB(255,255,255)-white and half RGB(0,0,0)-black:
If the Z-scale is 100 then the white part will be llifted to 256 meters, the black part will be lowered to -256 meters.
If the Z-scale is 200 then the white part will be llifted to 512 meters, the black part will be lowered to -512 meters.
You see how UE 4 interprets the heights different despite using the same colors for the height map, just because we changed the scale?
So if you use World Machine to build a 10km high mountain but only use Z scale of 100 then UE4 will interpret that and will set that mountain to only be 256 meters tall.
In order to allow the mountain to be 10km high you’d need to set the scale accordingly (i think someting like ~3900 for the Z scale would allow 10km high mountains).
Please keep in mind though that increasing the Z scale to allow higher heights, since there are only 256 value possibilities in a height map pixel, increases the “step amount” per grey scale pixel.
For example the terrain difference between a RGB(0,0,0)-pixel and a RGB(1,1,1)-pixel on the heightmap might only mean 10 cm difference with a Z scale of 100 (not sure about the exact values, this is just an example), with a Z scale of 200 the difference would be 20 cm, so there is a tradeoff between how high you can build and how precise the height differences can be.
Stefan, holy cow! Thank you so much for that very in-depth explanation. You went through a lot of trouble to put that all down and I really appreciate it, and it was very helpful! It took me a couple times reading through to really digest it, but it was very helpful. Thanks again
This is wrong by concept.
heightmap use 16bit int so you have 65535 possible steps, not 256.
difference between black and white or 0 and 65535 is also most certainly not 10cm with a scale value of 1. Let alone a scale value of 100.
As of a few months ago, you can actually consult the official documentation, which was updated with examples and correct ratio values to use for height scaling.
