Understanding the map_heights to battle map conversion limits

[danny X]

This is more research than tutorial.

This will be messy for abit until i sort the information into a coherent manner!

My research started with a conversation i had with Gigantus earlier into how battle maps are formed.

Post 1

Spoiler Alert, click show to read: 

Hi gigantus i've been doing some testing on the map_heights conversion to how in game battle maps are produced.

Nothing substantial unfortunately, but its lead me to believe that accessible map_heights tiles ideally shouldn't go above somewhere between 80 80 80 and 90 90 90. This is most noticeable on the battle maps radar map, it losses detail, goes black.

Im also starting to believe that at a certain rgb value, at about 140 140 140, detail in the battle maps background may be lost too, e.g there should be mountains in the distance, but there are none. I think such battle maps could also default to being completely flat also.

Sorry my research is sporadic at best, but i thought you might like to know and i will try to go in more detail if you want.

Also thinking have you researched or noticed anything similar?

Gigantus's reply:

Spoiler Alert, click show to read: 

The turning black of the radar map and disappearance of the far background at greater height is known. It is very very prominent in TATW in the long stretch of the misty mountains.
So far no one has determined when exactly it happens, so your results will be of interest.

So i decided to delve abit deeper:
Post 2

Spoiler Alert, click show to read: 

Ah yes, i believe it was a TATW thread which led me to test a fantasy map i just started. The battle map radar map is fine at 80 80 80, but at 90 90 90 its black, so somewhere between 81 81 81 and 90 90 90 it turns black, i'll confirm this later, i'll run another series of tests. The maps completely flat at the moment, so it wont take long.

Post 3

Spoiler Alert, click show to read: 

This was my testing ground, they run top row, left to right 81 81 81, to 85 85 85, the second row, from left to right 86 86 86, to 90 90 90, with 140 140 140 on the bottom row. They are all 7x7 squares in map_heights, starting on an odd,odd tile and finishing on an odd,odd tile in map_heights.

Spoiler Alert, click show to read: 

At 84 84 84, the radar map was completely fine, at 85 85 85 however some black starts:

Spoiler Alert, click show to read: 

The radar map at 88 88 88, actual battle arena completely black.

Spoiler Alert, click show to read: 

The radar map at 90 90 90, i was expecting this to be completely black, but the left and bottom edges are the rapid decline of the square in map_heights. They were in the position of my first picture.

Spoiler Alert, click show to read: 

Post 4

Spoiler Alert, click show to read: 

Using a similar method as before, it appears the battle map defaults to completely flat at 102 102 102, here's a pic at 102 102 102:

Spoiler Alert, click show to read: 

What's interesting, is here is a battle fought on 220 220 220, the mounds in the background are 255 255 255 and 250 250 250, they haven't disappeared:

Spoiler Alert, click show to read: 

And here is a battle fought on the 255 255 255 block facing (i think) the 220 220 220 block:

Spoiler Alert, click show to read: 

I guess they haven't disappeared due to the gaps between the mounds, which was 15 15 15.

I'll test without gaps soon.

It might be worth advising mappers not to use above 100 100 100 on accessible tiles, what do you reckon?

All these tests used wilderness in map_ground_types and light temperate forest in map_climates.

[danny X]

This is where i've changed all the 15 15 15 from map_heights, they've all been changed to 98 98 98.

The below is a battle fought next to a backdrop of 255 255 255 tiles using the previous methods.

Spoiler Alert, click show to read: 

The below is a picture of the generated battle map, as you can there is no huge mound in the background! It may be worth noting the two contour lines that run across the top of the radar map, 99 99 99, 100 100 100? perhaps?

Spoiler Alert, click show to read: 

The below is the battle fought on top of the 255 255 255 mound.

Spoiler Alert, click show to read: 

We should be facing a massive dip here, but unlike the 15 15 15 tiles, there is nothing, not even a single contour line, its completely flat as far as the eye can see.

Spoiler Alert, click show to read: 

[danny X]

Here is where i've started giving the 7x7 mounds abit more variation in map_heights.

In the below picture, i,ve kept the surrounding tiles at 98 98 98, but on the 7x7 mound, the left side of the mound is a vertical strip of 100 100 100, then to right i work my across in multiples of 10, 110 110 110, 120 120 120, 130 130 130, 140 140 140, 150 150 150 and 160 160 160, so the battle map should be slanted.

Spoiler Alert, click show to read: 

As you can see below, the battle map is completely flat.

Spoiler Alert, click show to read: 

The next test i simply changed the 98 98 98 surrounding tiles to 20 20 20, but i kept the mound exactly the same.

Spoiler Alert, click show to read: 

Again the battle map is completely flat, although contour lines have appeared in the distance, due to lower rgb values creeping in, from making the surrounding tiles 20 20 20.

Spoiler Alert, click show to read: 

The next test i kept the surrounding tiles 20 20 20, but i changed the value of the tiles on the mound. I did a vertical of 70 70 70 starting on the left and worked my way to the right of the mound again increasing in values of 10. 80 80 80, 90 90 90, 100 100 100, 110 110 110, 120 120 120 and 130 130 130. The battle below should roughly be fought on the 100 100 100 tiles.

Spoiler Alert, click show to read: 

As you can see in the picture below on the radar map, at some point between 90 90 90 and 100 100 100, roughly the middle of the battle map, the map has defaulted to being completely flat.

Spoiler Alert, click show to read: 

[danny X]

The summary:

I think I should conclude that at a map_heights value of 100 100 100 and above, the battle map that is generated, is generated completely flat. Also some surrounding detail in the distance, the mountains, stops at 100 100 100 too. This is most noticeable in my opening post, under the header Post 4, if you notice all the mounds in the background, they are all the same height. They shouldn't be, but they are! Unfortunately at the time, i hadn't quite noticed this and still believed i was looking at values above 100 100 100.

My values in descr_terrain, apart from width and height, are the same as vanilla's and probably the same values that most mods use. I haven't and am unlikely to do any research into the effects of changing these values on my above research!

Spoiler Alert, click show to read: 

dimensions
{
    width  500
    height  400
}
heights
{
    min_sea_height  -3406.782
    max_land_height  7511.272
}
roughness
{
    min  50.000
    max  200.000
}
fractal
{
    multiplier  0.500
}
lattitude
{
    min  22.000
    max  56.000
}

My conclusions:

The battle map's radar map starts going black at 85 85 85 and is completely black at 90 90 90, within the battle square.

The battle map and surrounding detail defaults to completely flat at 100 100 100.

I would advise mappers not to use above 80 80 80 on accessible tiles in map_heights, with inaccessible tiles being dense forest, impassable, mountains high and mountains low in map_ground_types.

[Glaygon of Holland]

A most interesting and valuable study for the modding community I'd say and with a clear conclusion:
While RGB 100, 100, 100 + generates fine on the campaign map, RGB 100, 100, 100 is the height cap for the battle map. Any changes done to map_heights above RGB 100, 100, 100 does not take effect in the battle map.

+rep for a well executed study .

[wilddog]

A most interesting and valuable study for the modding community I'd say and with a clear conclusion:
While RGB 100, 100, 100 + generates fine on the campaign map, RGB 100, 100, 100 is the height cap for the battle map. Any changes done to map_heights above RGB 100, 100, 100 does not take effect in the battle map.

unless you also change the geography.db strat map to heights scale.....

Or you Just need to ensure the Battlemap heigh calculations remain within the cap of (approx)

3000 (cap) < strat TGA value / 255 * max_land_height * strat to battle scale

Sorry I never got around to checking this until now (actually asked Mak to do it) as I was pretty sure this was likely to be the case.

[BM309K58SMERCH]

unless you also change the geography.db strat map to heights scale.....

Or you Just need to ensure the Battlemap heigh calculations remain within the cap of (approx)

3000 (cap) < strat TGA value / 255 * max_land_height * strat to battle scale

Sorry I never got around to checking this until now (actually asked Mak to do it) as I was pretty sure this was likely to be the case.

Sorry, but can you explain this a bit more? And how about the mountains in the backgrounds? They appear 10 times larger than Everest most of the time. I want to make large mountains in the campaign map, but small-to-normal-sized mountains in the battle map. Also not to mention the point that the generation of the mountains make steep impassable cliffs and a black radar map.

[wilddog]

@ BM309K58SMERCH
People are hitting different issues and assuming everyone is talking the same thing.

Mostly I'm talking about

I think I should conclude that at a map_heights value of 100 100 100 and above, the battle map that is generated, is generated completely flat.

.

In our experiments the values were around 103 BUT it all depends on the various parameters used within the geography.DB file.

3000 (cap) < strat TGA value / 255 * max_land_height * strat to battle scale

The cap value seems to be around the value 3000 , meaning if this is exceeded you get no more 'increased' height variation. I am guessing but I think this is due to the 6 classifications of soil types used by geography.DB and so in turn may be individual values of 500.

The first part ie the 'strat TGA value' comes from the TGA value the strat map (assuming TGA is used and not the .hgt file which is probably a true float). As this is greyscale positive only values it can only have values from 0 to 255. the exact fraction of the maximum height is therefore the strat TGA pixel value divided by its maximum (255 hence the calculation shows strat TGA value / 255

The maximum height is the value in the file data/world/maps/base/descr_terrain.txt eg max_land_height 7511.272

Anyone doing strat mapping changes should be aware of the above.

now taking our value of complete flatness we had 103 / 255 = 0.403922 and if you multiply by 7511.272 you get 3033.965 which is why I said the value is approx 3000.

The last value ie the only one in geography.db has a preset value of 1.0 so no effect.

This value is in the text file called height scale I think. In IWTE I copied a name but its the parameter called 'River - height scale' this was a mistake as I was copying the 'river bit from the names I used above it. It will be called 'Strat to battle - height_scale' in the next version. Anyway if you were to change that to say 0.5 the above calculation would return a value of 1516.982 which would show the hills but obviously all the data coming from the strat map is now halved. To counter that you can then increase the tga to 206 to get the same flat appearance. Understand?

The black bits on the radar map seem to start lower but that may be more to do with the parameters variation in the geography.db file that generates the battlemap. Those parameters add upwards/downwards slopes to what otherwise may be completely flat battlefield.

A few of other things to note.
1)The geography.DB parameter has NO effect on the terrain heights set in a .world file it only affects the 'original' battlemap heights.
2) If you change the max height parameter in the descr_terrain file its probably a good idea to change the minimum sea value by the same ratio to prevent changes to the land/sea triangles and variations on the coastal smoothing.
3) as far as I can see the battle map is really dependent on the types associated with the strat map pixels rather than a pure height basis. So there doesn't seem to be a concept of a tree line (above which you don't get trees) its more tied to concepts around 'relative heights' and the type of vegetation/climate mix the mapper used as presumably the mapper took that into account when making the map.
4) The strat map views will be dependent only on the TGA (or .hgt) and the descr_terrain heights (ie doubt there is any cap there).

Hope that helps you understand.

[danny X]

As Steam decided to delete all my pics, you can now find them in the attachment:

They should line up with my posts by the pictures time stamp ( yeah I didn't understand that either)

[nadalio]

Hi Danny, I don't understand how to put the pictures in the right place.