Height Ranges

Bug Reports
#1

Hi, i am trying to take height values from WM that are expressed as a Minimum and Maximum height range in the WM Project settings, and translate this in to a value i can use in our game engine for the Height value of our terrain tiles.

However the heights and terrain do not look like i expect once i get them in to our game engine (Unigine).

This is the process i am following:
-Generate a series of tiles in WM and check the base elevation and Maximum elevation in the general setup screen - for example base = -150 + Max = 300. this gives me a height range of 150+300=450 height range. (We are using a 1m detail scale in both WM and our game engine)
-Modify a height corridor through the terrain using 3d splines in the layout view (These splines define a railway corridor where out train tracks in Unigine should sit on - i am using a falloff of 2km
-Generate my Tiles in our engine, inputting the height range for each tiles generation at 450
-Because our engines terrain heights start at zero and cannot be negative, i offset the tiles down in the Z Direction by -150 (Our WM base height)

When i then look at the result, our terrain does not match up to our tracks in most places being too low, and in others too high.

So a couple of questions:
1, Does the Base and Max elevation represent the ACTUAL height extents, or just a possible min and max? - If it is not the actual, then is there a way to find out the actual height min and max for our tiles in WM so we can calculate the range accurately?

  1. Would adding a clamp device with normalise on it ensure that our min and max values are always met?

  2. in the layout view when using 3d splines, what does the height value do here? is it relevent or not? (I thought the height should be read from the splines file itself, but when i import the splines it gives them the MAX value in the height field in the edit dialog box)

I hope this was not so Much of a confusing explanation, and any help anyone can offer regarding height ranges in WM would be much appreciated.

#2

I am particularly interested in this topic, too.

As far as I know, the output gray scale image gets interpreted by a game engine and will have the same width/height ratio, but not necessarily the same size.

In my case I finetune a 75km x 75km x 6km terrain in WM in 8k (~10m resolution) and use it in the UDK.

But in there, the size is relative to the UDK “Units”. The maximum world extent ranges from lower left (-261152, -261152) to top right (261152, 261152) units. I am using a xyz scale of 64 for the terrain to fit in there completely, but I have no idea how big this actually is in meters or kilometers.

I would like to know a way, how to stay true to the real-world-size. Perhaps we will find solutions for various engines (I will use UDK and also try CryEngine SDK -although all I saw so far tells me that 8k resolution is not gonna work in the latter)

Cheers, Bodo

#3

Any answer on this one? I’m seeing the same issue. All my heights are off in engine.
If the heightfield export (r16 format) isn’t expressed relative to the base and max heights, how do I find the real min/max of the data being written to the file?

#4

Hi there,

Sorry, I missed this thread the first time around.

  1. The base and max elevations you setup in the General Setup represent possible min and max, not the actual ones. To find your actual min and max, there are several methods:

a) You can find a pretty good value for your actual min and max by adding a clamp device right before your export device and then selecting “Find Extents” within it. There’s currently a minor UI bug fixed for the next edition where it only reports the heights after you close and re-open the dialog, but after you do this the elevations reported in the clamp are your worlds min and max. You can then delete or bypass the clamp.

b) Alternatively, after exporting your files, simple open them up in a new File Input device in the same world. The file input device will report the actual elevation range in the file in bottom right area.

  1. Yep! Or if you are going to do a Tiled build, I recommend using the “Find Extents” method above as it is compatible with tiled building.

  2. If you are import DXF splines, they should receive the actual elevation values from your input data. The import dialog will print a warning if the elevations in the data are all above or all below the current worlds’ elevations, and let you re-scale them into a correct range (or you can change your world’s min and max to match – your choice)

#5

Thanks. One step further, though I’m still a bit stumped.
What values are being writtin to the RAW16 file? Are they normalized to the min/max of the heightfield so they use the full range of the raw16?

For instance, this is what I’m seeing:
Project Base/Max Elevations: -500/2500m
Output from Clamp device: -499/376.5m
Min/Max uint16 values in engine: 0/18157

In the past, using l3dt, this code handled the raw loading fine (where hfMax and hfMin were the true min/max elevations of the terrain):
float height = (float)rawheight / 65535.0f * (hfMax - hfMin) + hfMin;

Am I just missing something obvious here?
Thanks.

#6

Output files are not normalized before export – this would cause all kinds of trouble when exporting different sections of terrain. You can manually normalize before export with a clamp device if you wish however!

Your code will work as long as the min and max are the project base and max:

ie if the terrain has a max uint16 value of 18157 / 65535 = 0.277 in normalized units.

that translates to 0.277 * (2500m - -500m) - 500m = 331m, which is close to what the clamp reports. The clamp is slightly inaccurate as it uses the preview only to determine min and max heights (which incidently, I’ve actually already changed for 2.3.3 so that it will use the final build if that is available). I suspect if you used the “load the file back in” method it would match up exactly.

Long story short, when the output is not normalized all you need to do is use the base/max elevations for the scaling and everything should just work. (If the file was normalized, you would need to use the ‘true’ pre-export min/max elevations).

#7

Ahh. OK, I think I found the issue then. When I was adjusting the project’s base elevation to get the look right, it was still saying the water level was at 0 in the UX, even though it was actually relative to the base level still (and now actually at -200), so what I thought looked right in WM, was way off in engine. Reloading WM or adjusting the water level again seemed to fix the issue.
I’m back on track. Thanks!

#8