File Output in Terragen file format - broken ALTW chunk?

Bug Reports
1

Hello all,

using WM 1.25 Standard Edition, I’m currently trying to load files that are created by the File Output device into Terragen.
Using Terragens own file format *.ter, this generally works very well, except for the fact that it gets the terrains heights (altitudes) incorrectly scaled.

In World-Machine, I’ve set a world size of 1024*1024 pixels, scaled to 10.86 km^2. The “Terrain Height Scale” is set to 2040m.
(However, the actual elevation data that I eventually feed to the File Output device ranges only from about 80m to 500m.)

Then I started to examine the .ter file that the File Output device generated by hand:

It seems to get all chunks right, except for the beginning of the ALTW chunk (see http://www.planetside.co.uk/terragen/dev/tgterrain.html for details):
The ALTW chunk header is followed by the hex byte sequence 80 01 00 00 77 89 (signed, 2-byte ints in Intel byte order), which translates to
HeightScale = 384,
BaseHeight = 0,
Elevation of first point = -30345.

Now, when I put these numbers into the equation BaseHeight + Elevation * HeightScale / 65536 as given by the spec, I obtain in fact and as expected the same numbers that I see in Terragen in the Landscape View.
(0 + -30345*384/65536 = -177.803, and taking this from pixels to meters yields -177.803 * 10860 / 1024 = -1885.7, the result that I can also read in the Terragen Landscape View.)

So it seems that Terragen is correctly reading the file, while it has been incorrectly created by World-Machine.

Here is what I had expected WM to put into the .ter file:
First, determine the min. terrain elevation at 80m, the max. elevation at 500m.
The difference is 420m, the average height is at 290m.
These two numbers must be taken from the real world units “meters” to per-pixel units. As we have 10.86 km per 1024 pixels, we get 420m / 10860m * 1024 pixels = 39.6 pixels, and 290m / 10860m * 1024 pixels = 27.3 pixels.
Reasonably rounding these numbers to integers (always(??) upwards, ceil()), we find the complete equation that translates a ALTW height value to meters as
(28 + 40*x/65536 ) * 10860/1024 = h. (h is the height in meters.)

That is, WM should have set HeightScale to 40, BaseHeight to 28, and find the height values by solving the above equation for x… (which must expect 16-bit integer overflows as a consequence from the previous rounding step, I didn’t fully think this out…)

:arrow: A bug?? Or did I overlook something?
I’d be very happy for any help here, as it is very important for me to get these things correctly loaded into Terragen…

Oh, and this issue could easily be worked-around if WM showed the true min/max elevation heights (I’ve just “guessed” the above 80 and 500m from my knowledge about how the terrain was built…).

Thank you very much in advance!!

2

Hi Carsten,

it’s actually simpler to fix than that; World Machine previously (and will again) map a height of 0 to height 0 and a height of 1 (the max in World Machine) to whatever you set the Vertical Scale slider to. A heightfield that doesn’t span the maximal 0…1 region will live in some smaller subregion within that range.

Terragen .ter output has been adjusted for the next version to span 0…VHeight elevation in Terragen as might more intuitively be expected, rather than the centered height span currently used.

(In adding the extra 1 bit of accuracy, TG interprets as the sign bit to allow negative terrains. Consequently, to achieve sensical results the individual data chunks were adjusted to sit between -32767 and 32767. This caused a positive Base Offset to need to be added)

BTW, in terms of true min/max elevations, you can always be assured that the true terrain height can be no lower than 0 and no higher than 1. The “meters” terrain height is obtained by scaling this by a height factor. If you hook up a Clamp device before your file output, and check “Normalize Input”, it will ensure that the file going to ouput will always span that maximal range (in WM and TG). If you click the “Find Extents” button the sliders will adjust to the elevations of the top and bottom-most points of the terrain as well, which gives you a feedback for exactly what those points are.

3

Hi Remnant,

the range 0 to 1 is certainly the most natural to store terrain heights, possibly scaling it by VHeight, the “Vertical Scale” slider setting to obtain real-world physical units “meters”.

Unfortunately, Terragen seems overly complicated here, especially because it scales heights by the horizontal meters per pixel distance (that was the 10860m / 1pixel in my post above).

I’m not sure though if I understood you properly: After your explanations, for best precision, I still think that you have to set
BaseHeight = 1/2 * VHeight / mpp and
HeightScale = VHeight / mpp
where mpp is the above mentioned “meters per pixel” setting that is also mentioned in WMs “World Size & Positioning” dialog (10,605m/pixel for a terrain of 10.86km at 1024 pixels).
(So BaseHeight and HeightScale are measured in the units “pixels”, unfortunately, and their spacing is given by the SCAL chunk…)

A lot easier, of course, is probably to have BaseHeight always at 0, and ignore the sign-bit, so that only 15 bits of precision are used. :wink:

Anyways, thanks for your hint about the Clamp device, I think that’ll help.
Any idea when the next release will be ready?

4

yes; the actual vertical scale is adjusted by the map horizontal detail level as you say.

Essentially, dimensions and Pixel Spacing reported in WM should be preserved when it enters TG.

And yes, ignoring the sign bit would certainly be easier :wink:

The next release is probably a ways out. I’m currently working on the Pro edition, which will include many changes that will also filter down to the Standard and Basic editions. Once Pro is out, then other versions will follow soon thereafter, but alot of stuff for Pro has to be done first.

You can check out the Dev Blog to follow progress :wink: (http://www.world-machine.com/blog)