More height levels (in trunk since r27010)

[Ben_Robbins_]

I can't at this second play the game, so this is going on what I noticed a while ago, so might not be 100% correct, and may not be up to date. I created a scenario from a height map. The height map was 2 shades. a black area and a white area. The image was small, and I tried it on a range of map sizes. On a 2048-2048 map, the mountains in the centre rose up to 63 levels (?) in height but no higher, and was flat thereafter. I could manually raise this. Why did it stop at this height? It was no longer restrained by the given space inside the area above sea level, but just by the random height value of 63 (i think..need to check). Basically how do I get max heights from a height map?

[ChillCore]

...
the mountains in the centre rose up to 63 levels (?) in height but no higher
...
Basically how do I get max heights from a height map?

This is hardcoded in the patch to still be able to use the currently available heightmaps.

Find this code in the heightmap.cpp,

Code: Select all

/* Colour scales from 0 to 255, OpenTTD height scales from 0 to 15.
* Heightlevelspatch scales from 0 to 63. */
if (AllowMoreHeightlevels()) {
	SetTileHeight(tile, map[img_row * img_width + img_col] / 4);
} else {
	SetTileHeight(tile, map[img_row * img_width + img_col] / 16);
}

change the if statement to read:

Code: Select all

	SetTileHeight(tile, map[img_row * img_width + img_col]);

and recompile.
That's all you need to do.
It has been suggested to make the maximum height when loading heightmaps configurable but I did not get to doing so yet.

[Ben_Robbins_]

Would changing it just exaggerate the available height maps so they no longer appear as intended, or would the ground be restrained by it's own variation? i.e. it requires x tiles wide to rise y in height because of the available gradients, so if a hill appears among hills, it can only be as big as the space allows.

This leads to me to wondering. Does it simply look at the pixel value and directly change this into a height value, and raise the land to as-closer value to that as it can? If so, would comparing values to the neighbouring pixels help? Small hills on a height map would retain there prominence, rather than get de-solved into the face of a bigger peak. The biggest peak would only be as big as the space allowed, rather than consuming all else just to secure the max height. The original height maps would only be exaggerated so much as the space allowed.

Slightly confused also why it can handle up to 63, where as the original is 16? Is it a case of finding the middle ground?

Also congratulations, and thanks, on fixing the big airport placement issue you said about! horrah!

[ChillCore]

To keep it simple ...
The original code reads the heightmap colours and converts it to a 256 greyscale pallete, no matter how many colours there are in the picture as long as OpenTTD can read the format. (.png or .bmp)
Level 63 works because OpenTTD generates a heightmap starting from a 256 palette. Level 255 in your code works also without modification. The deviding by 16 is original code behaviour.

So why have I put the level 63 in the patch if 255 works also?

First reason,
because of the waterlevel.
Looking at the png, before conversion, black is the darkest colour and white the brightest.
After conversion: Shade 1 is black(*) and shade 256 is white.
The rest of the explanation is continuing from the grayscale pallete after internal conversion.
With the original code shade 16 becomes level 0 (water), with the patch as is shade 4 becomes level 0, and with the your code shade 1 becomes level 0.
To make a good heightmap you have to cheat to make your heightmap have shade 16 as water, shade 32 as level 1 and so on.
When generating a heightmap optimised for level 16 it will have its waterlevel messed up when loading it at level 255 -> Way lower then as intended by the creator.
Just try a heigtmap and load it with the patch disabled then try the same map with the patch enabled. You will notice the difference ...

Second reason,
while a map of size 2048 * 2048 can easily support level 255 a smaller map say 512 * 512 can not, unless you want to build a pyramide.
If I hardcode level 255 small maps will also be forced to level 255 and will not look good. Again just try a few with your changed code.

As for the future codechange ...
I could make the generated height depend on the mapsize, as we do with normal mapgeneration, or have it configurable but how would we have to handle the changing waterlevel assignment? (See first reason.)

So to conclude, level 63 is a reasonable compromise. It is still to high though for maps of size 64 * 64 and 128 *128.
I hope you are not having a headache by now.

(*)
When creating a heightmap you have to keep in mind that level 16 becomes water(original trunk code). It was my experience that if you make a png to serve as heightmap and you pick pure black(rgb #000000) as lowest colour the waterlevel will not be correct ! Instead you want to pick #000100.
I have posted two examples a few pages back. This one is optimised for level 255 made with microdem: http://www.tt-forums.net/viewtopic.php? ... &start=340 and a few posts lower there is an example of a png heightmap I have made with gimp to test.
Another tool you can use is GeoGen <- See CommanderZ's signature for that program. It is very, very cool and you can make your own nuts to generate heightmaps. I have to run the console version but there is also a gui-version for windows users.

[Ben_Robbins_]

Took a few reads, but I think I understand, I need to experiment, that would make it all clear. Thanks!

When I get to my computer I'll have a mess about again, and put explanation into practice/game, currently I'm just picturing things in my head.

For the potential future code change, could the value which you said to remove in the if-then bit of the code (4) be manually variable, just as smoothness is currently when making a map? Could leave it up to the user to avoid rubbish land formations, or certain options could fade out in relation to certain map sizes being selected. I need to mess about before I can safely say 'I grasp the water level issue', but is it a possibility to have levels 16+ at 1 value per level, but level 16 and below levels values meaning level1? (offset values -16, and anything below 1 treat as 1).

Really I'm just thinking out loud, I'm sure if I'm thinking it, it's been thought of!

Anyway I don't want to add anything to the todo list! I'm beating round the bush here really, this is minor, and nothing is stopping me manually creating the highest peaks in the scenario on top of the automated main section.

[ChillCore]

You've got it.
Shade 17 to 32 is level 1.(normal trunk)

I have been thinking a bit about how to solve it too a while ago, as have many people before you and me.
I was thinking maybe have shade 1 as waterlevel and devide the remaining 255 shades by 17 per heightlevel? For the orignal trunk code that would work as 1 + 15 * 17 = 256 shades. But how do I scale that towards the moreheightlevels patch? Keeping things as they are is the simplest and the best thing to do for the patch.

Having the "/ 4" configurable in the load heightmap gui is exactly what I intended to do when I feel like messing with the gui again.
Create textbox widget, create buttons, define tooltips, blabla, * 2 for -> scenario editor also, not now but soonish ...

Do keep thinking out loud.
If you have ideas on making the patch better extending the Todo list is not always a bad thing.

[CommanderZ]

What about 0 - water; 1 - 31 = 1; 32 - 47 = 2... (just add nonzero values that would go to zero level to the 1 level)

[ChillCore]

That is also an option CommanderZ.

1 = water; 2 - 32 = 1; 33 - 48 = 2 ...
With the patch enabled.
1 = water; 2 - 8 = 1; 9 - 13 = 2 ...

For a far as I know the grey_palette starts at 1, not zero like normal arrays.

Code: Select all

byte gray_palette[256];

If it would start at 0 it would no longer fit in the byte?

[CommanderZ]

For a far as I know the grey_palette starts at 1, not zero like normal arrays.

Now i don't understand. You mean in OTTD? I was not referring exactly specifically to OTTD. Everywhere (almost) in computing world grayscale color 0 = black.

byte gray_palette[256];

This is supposed to be a C++ array definition?

Then it is an byte array having 256 elements with valid indexes 0 - 255. Try to read from the index 256...you will get Access violation error (if you are lucky).

And byte is usually an unsigned variable type capable of holding 256 different values in total...once again, 0 - 255.

[ChillCore]

Okay we were talking different things.
I agree in general black is 0.

I was talking OpenTTD. See heightmap.cpp.
We did not change that part of the code. That is why I think it starts at 1 to fit in the byte ...

[Ben_Robbins_]

So the values of 4 and 16. If they are variable, would this need to vary on a curve? i.e. a 64x64 map /16 and a 2048x2048 /1 and an exponential curve between?

Also would it take the smaller of the 2 values (x an y), or average the value? i.e. a 64x2048 map /2 (now possible with land along the map edges). If it was average then just swap MIN for AVG and the figures would be usable.

Anyway, 1 way of getting a helpful value is:

=ROUND((2048/(SQRT(((MIN(X:Y))^2)+12000))),0)

(X and Y are cell values containing 64-2048) From small to big map sizes the values are 16, 12, 7, 4, 2, 1.

A better set of figures comes from:

=(16/(((MIN(X:Y))/2048)*16))-(ROUND((((16/(((MIN(X:Y))/2048)*16))^1.4)/8),0))

From small to big map sizes the values are, 16, 10, 6, 3, 2, 1.

I stuck no thought into the water issue you said about though. It's just to get a resonable number for the section of code you said to change.

[CommanderZ]

I was talking OpenTTD. See heightmap.cpp.
We did not change that part of the code. That is why I think it starts at 1 to fit in the byte ...

Could you please specify a line which suggests this?

I think these lines suggests it is simple mapping [0,255]->[0,15].

Lines 335 and 346 in heigtmap.cpp:

Code: Select all

/* Colour scales from 0 to 255, OpenTTD height scales from 0 to 15 */
SetTileHeight(tile, map[img_row * img_width + img_col] / 16);

[ChillCore]

So the values of 4 and 16. If they are variable, would this need to vary on a curve? i.e. a 64x64 map /16 and a 2048x2048 /1 and an exponential curve between?

The function I posted before will read something like this in the end.

Code: Select all

if (AllowMoreHeightlevels()) { 
	... / get value    // Set by player in the gui.
} else { 
	... / 16           // Not changeable. Patch off behaviour.
}

All the rest would be in done in the gui.
Using two buttons I was thinking of having values 16, 8, 4, 2 and 1 selectable to generate at heightlevel 15, 31, 63, 127 and 255, even if the result does not look good. It is player's choice.

Also would it take the smaller of the 2 values (x an y), or average the value? i.e. a 64x2048 map /2 (now possible with land along the map edges). If it was average then just swap MIN for AVG and the figures would be usable.

We could add an auto setting also which then scales according to mapsize.
This could also be configurable with a two more buttons to select if the player wants to scale according to the minimum, the maximum or the average of the two sides, while taking into account the bordersettings. 6 settings non visible except displaying min, max or avg. This would take some testing to get it right as the player has no indication of generated height here.

I have not yet tested if values 12, 10, 7, 6 and 3 can be used without causing problems. You know where to change what if you feel like testing.

Could you please specify a line which suggests this?
I think these lines suggests it is simple mapping [0,255]->[0,15].

You could be right. I will need to browse the code a bit more to see what I can find. I just find it strange that that a byte can have value 256 without causing problems.
The lines you quoted are the ones that are modified to generate the terrain higher.

[CommanderZ]

I just find it strange that that a byte can have value 256 without causing problems.

Why do you think so? Saving 256 into byte results in 0 (it won't crash, there just will be 0 in the variable).

[ChillCore]

Oh boy ... offcourse you are right.
And I even fixed the running ticks overflow in my patchpack just a few days ago, I hope.
I do not know why I expected that to crash ...
Time to pull my head out of the source and play a little game.

[ChillCore]

Two patches this time...

v25_4 is just a bump to trunk.
As by miracle you can now generate artic heightmaps with a snowline higher than 13.
I do not know exactly since what version this is possible but one of the last remaining bugs is fixed.
One of the few remaining bugs is that when generating a heightmap from the main menu there is no warning when resizing the heightmap to much causing the game to exit with a segmentation fault. When loading a heightmap in the scenario editor the warning does show. hmm, something to chew on.

The heightmap_test version allows to select the generated height when creating a game from a heightmap.
It is a seperate version for now as I am not yet sure if I will keep the implementation the way it is now.
I will return to having one version if this is tested some more and when I have taken the time to review the gui codechange a bit more.

I have reused the Fallen -> Alpinist dropdown but not the code that is behind it as that part of the code is not reusable for creating heightmaps.
Instead I have created a seperated array in heightmap.cpp.
The array is called _max_heightmap_height[7] if you feel like tuning. If you need more options in the dropdown just let me know.
Also the create heightmap gui is re-arranged but some alignment is left to be done.

[ChillCore]

Hello,
I have a little question for the Devs.

I was going to start on extending the height colour legend in the smallmap.
I am a little confused.
On page 3 of this thread PhilSophus said:

The height levels are said to be 50m, so 64 levels are 3150m. Seems to be enough for most purposes.

However looking at the actaul code in smallmap gui they seem to be 25 meters.
What should I do, go for 50 meters and write a little patch to correct clean trunk or go with 25 meters to follow the code as it is now?
Writing the little patch for trunk is rather trivial but changing the patch afterwards if the code would be rectified in clean trunk would take quite longer.

[Ben_Robbins_]

I'm not sure if this is known of, and I'm using the version synced with 18288, but I believe I have a bug.

If you don't have enough money to level/lower/raise the land, it still destroys everything on the selected area, included water at no cost. You can then raise the sea out of water at the same price as regular land/soil. It still displays the message with the correct price stating that it can't be done. No file attached as it is easily done.

[ChillCore]

Thank you Ben_Robbins_.

No, I was not aware of this.
Indeed if the command fails because of lack of money the land is cleared at no cost while terraforming fails as it should.
Nice spotting.

I have always tested with something in the way (Towns, transmitters, etc.) it seems. In that case the command fails and no land is cleared.
There is some code marked to be done in terraform_cmd and maybe the bug you have just reported will be fixed at the same time.
Great another todo.

[Alberth]

On page 3 of this thread PhilSophus said:

The height levels are said to be 50m, so 64 levels are 3150m. Seems to be enough for most purposes.

However looking at the actaul code in smallmap gui they seem to be 25 meters.
What should I do, go for 50 meters and write a little patch to correct clean trunk or go with 25 meters to follow the code as it is now?

Is there a better reason to change trunk? PhilSophus saying a number different from the one we have now doesn't sound too convincing.

Each value seems equally arbitrary (except that current trunk values are already translated). Also, each value seems equally controversial. Some will say it is too much, others will consider it too big.