Bridge Command Forum

Support => Bridge Command General Support => Topic started by: rellufdarb on April 22, 2024, 01:59:18 PM

Title: TerrainHeightMapSize
Post by: rellufdarb on April 22, 2024, 01:59:18 PM
In the Terrain.ini files I see this-----TerrainHeightMapSize----but it is not listed in the relevant documentation. At least I cant find it.
Where is this defined please?
Title: Re: TerrainHeightMapSize
Post by: forum_admin on April 22, 2024, 10:22:28 PM
Hi, TerrainHeightMapSize is no longer required, so will now be ignored.

In earlier versions, it was previously required to specify the size of a square image defining the heightmap, but because this can be found directly from the image dimensions, it is not required any more.

If you are using a binary heightmap (a list of 32 bit floating point values), TerrainHeightMapRows and TerrainHeightMapColumns are now used instead, as non-square heightmaps are allowed.
Title: Re: TerrainHeightMapSize
Post by: rellufdarb on April 23, 2024, 12:18:16 AM
Hello Admin,

OK, makes sense.

I am just starting with Bridge Command. So far I have been trying to use (simple) greyscale .png files for height. I am having difficulty getting realistic shorelines--getting the slope right is hard and I usually end up with cliffs because I have the greyscale gradient too steep. To manually edit a large map has consumed many hours late at night already.

One question, for an 8 bit 256 level greyscale, is zero (water level) represented by 127 or half way between Max Height and deepest depth in the terrain.ini file?
Title: Re: TerrainHeightMapSize
Post by: forum_admin on April 23, 2024, 08:57:58 AM
Hi, with a normal greyscale image, 0 represents -1*SeaMaxDepth, and 255 represents TerrainMaxHeight, with linear interpolation in between. This actually means that the 'half way' between max height and max depth is between 127 and 128 greyscale values.

I made a simple calculator at https://www.bridgecommand.co.uk/data/_uploaded/file/Height%20conversions_255.xlsx which might be useful.

The relatively small number of steps available in a greyscale image is why there is also the 'RGB' encoding (height in metres is set by (red * 256 + green + blue / 256) - 32768), or raw 32 bit floating point format available, which both allow a much finer elevation step.