More height levels (in trunk since r27010)

[ChillCore]

I don't think the "existing heightmaps are optimised for this level" argument is valid though, as even a change to 31 would require heightmaps to be remade for water edges to come out correctly. Even without adjustment though, the extra detail pulled out of the heightmaps looks great.

Indeed it is the water that needs retuning.
I attached a heightmap i optimised some time ago for myself.
It includes Belgium, Luxembourg,
parts of holland, Germany and France.
Please try with and without the patch.

Not so sure about extending the landscape indefinetely off the edge of the map though, thought that looks naff.

Those outside tiles are to be changed to black tiles later.

Thank you for testing the patch and your comments.

[ic111]

Loading heightmaps is now done at height 63.

Sensible I think, trying to load some of my heightmaps at 127 and the highest points weren't any higher than 80 anyway, as the mountains weren't wide enough. I tried recomplinig with 63 a couple of weeks ago and it seem like a better compromise. I need to try some more maps, particularly those that lots of land at a very high height, or with a large mountain peak somewhere.

I don't think the "existing heightmaps are optimised for this level" argument is valid though, as even a change to 31 would require heightmaps to be remade for water edges to come out correctly. Even without adjustment though, the extra detail pulled out of the heightmaps looks great. Not so sure about extending the landscape indefinetely off the edge of the map though, thought that looks naff.

How is the heightlevel information stored in a heightmap (in meters above sea level, in some other measure, etc.)? Maybe introducing a switch "scale to max. height x" would be an option? Then it would be up to the player to choose a max. heightlevel he wants. Of course, a heightmap author could give hints, e.g. "optimized for max. heightlevel 30".

[ChillCore]

When creating the heightmap, I used microdem, you set the desired heightrange by meters.
The game reads the colours of the heightmap,
and converts the result to a 255 colours grayscalemap in,
static inline byte RGBToGrayscale().

Then in,
static void GrayscaleToMapHeights(),
...
/* Colour scales from 0 to 255, OpenTTD height scales from 0 to 15.
* Heightlevelpatch 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);
... ,

the grayscalemap created before is optimized for the heightlevel we want.
this result is returned in tiles.

To make a map for trunk now you have to cheat because the first 16 colours are all water.
Level one is the seventeenth colour.
With the patch as it is now, level one is the fourth colour.
We could make it the first colour if we do this:

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

But as mentioned before this is no good with the slopes at mapedges.
IMHO, I think it is best to fix the heightmapgeneration at some level to be defined yet. The reason being that for every other level possible, there would be another optimised heightmap nessecary.

ps:
I played with this setting before and 128 is a limit (on big maps) unless we do something about them borders.

[Moriarty]

To make a map for trunk now you have to cheat because the first 16 colours are all water.

I consider this behaviour a bug and have reported it as such on flyspray. The devs copped-out and called it a "feature request", though it's still open.
For yours can you please assume that 0 is the only level that is water please.
All my heightmaps are 256 grayscale and only 0 is meant to be water. I'll be uploading a bunch in a few days when TrueBrain resets my bananas password (because I'm a cretin and forgot it )


As to map edges and water - why is that a problem? Surely with freeform edges the map edges should be at whatever height they need to be? I know this behaviour currently appears to be broken in trunk for heightmaps but it's my understanding this is the desired result though.

[Bob Smith]

As it stands, if you set the minimum height to be a tenth of the maximum height, before generating the greyscale heightmap in Microdem, the lowest land will be bright enough for OpenTTD not to allocate that tile to sea.

With sufficient height levels in game, we would want to generate maps in Microdem using fixed minimum and maximum heights, so that the highest point of a map is not always at the same height in game, but rather reflects the height of the real landscape the heightmap is based on. That minimum would depend on how many height levels the height map was being interpreted as, but if it was constant and we knew what value to use, then does it really matter?

Unless of course we get the option to choose how many height levels to interperet the heightmap as. Then it would be consistent to have 0 as sea, and scale the rest based on the number of height levels.

We can do this by changing this line:

Code: Select all

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

(where "numHeightLevels / 256" has been simplified to a constant)

to this:

Code: Select all

SetTileHeight(tile, (map[img_row * img_width + img_col] - 1) * (numHeightLevels - 1) / 255 + 1);

[Moriarty]

Unfortunately I'm not using MicroDEM and I don't want to do any fancy mathematical transforms for my heightmaps. I should just be able to supply 256 shade (and level!) heightmaps and have OTTD do something sensible. If I were to make the maps especially for 16 lvl ottd they'd have to be re-made should the devs ever fix the bug or a patch similar to this one be developed and deployed.

Unless of course we get the option to choose how many height levels to interperet the heightmap as. Then it would be consistent to have 0 as sea, and scale the rest based on the number of height levels.

My brain is in a fritz and maybe I'm mis-understanding, but shouldn't heightmaps only be interpretted as having 256 values where each value represents a different height? That's the simplest option. That way if someone wants an area as water they can set it to 0 (my suggestion, and the bug fix request) rather than have everyone else have to fudge their heightmaps so the land is only interpretted to start at 20 or so (current system).

[ChillCore]

My brain is in a fritz and maybe I'm mis-understanding, but shouldn't heightmaps only be interpretted as having 256 values where each value represents a different height?

You can use any picture with as many colours you want as heightmap.
The picture will always be reduced to 256 colours and then reduced again to fit the wanted height.

I attached a test heightmap to show you heightmaps do not have to be realistic.
Credits to Gimp filters on transparant background.
Black(water) is NOT #000000 but #000100 (html notation).

I tried two of your maps you recently uploaded (world-2048-2048 and west europe-1024*2048) at level 255 and sorry to say that did not look good.
I must add to this that i have not yet tested them in clean trunk or generated at other heightlevels. (Just to be clear: I am NOT saying they are no good)

I think you should take this darkest colour "flaw" into account when you make maps.
I read your flyspray report on that some time ago but did not come up with a solution.
I also think this is something different from changing heightlevels.
If solved this should be posted as a seperate patch.

Maybe ic111 can come up with something, or i might have a go it using the input from Bob Smith later, at the moment i am kinda focussed on coding style and terrain generation.

Talking about coding style.
r16000 is a nice round number for an update.
- No changes in funtionality.
- Coding style is coming nice and steady.
Unneeded changes to trunk gone. (most of them i think)

[Moriarty]

My brain is in a fritz and maybe I'm mis-understanding, but shouldn't heightmaps only be interpretted as having 256 values where each value represents a different height?

You can use any picture with as many colours you want as heightmap.
The picture will always be reduced to 256 colours and then reduced again to fit the wanted height.

That's what I said though, albeit not too clearly. It will always end up being reduced to 256 colours-greyscale. From there the game should (and does) scale them down to whatever height it needs.

I tried two of your maps you recently uploaded (world-2048-2048 and west europe-1024*2048) at level 255 and sorry to say that did not look good.
I must add to this that i have not yet tested them in clean trunk or generated at other heightlevels. (Just to be clear: I am NOT saying they are no good)

No need to apologise, I'm aware of this. But I can confirm they look just fine if 0 is the only level that is interpretted as water. This wasn't done in OTTD (as I lack the ability to fix the bug), but using a GIS application (ArcGIS).

I think you should take this darkest colour "flaw" into account when you make maps.

But then I'd be making technically flawed maps which would not load as well when someone got around to putting more than 16 levels into OTTD. The idea is that the maps are "future-proofed" up to 256 levels.

I read your flyspray report on that some time ago but did not come up with a solution.
I also think this is something different from changing heightlevels.
If solved this should be posted as a seperate patch.

Agreed it's best for another patch, I'm just bringing it up here in the hope you work under the assumption that 0 is the only one that should be sea-level. Otherwise (depending how they're made) current maps may or may not render properly on your new heightlevel stuff.

[ChillCore]

Changed:

- Max height generated on 2048 * 2048 maps is now level 96.
All other mapsizes are scaled accordingly.
This is a compromise untill i can extend the terrain type array.
I can do it visually but the array does not let me select all new options.(yet?)

- Smoothness parameters slightly retuned to reduce long slopes a bit.
This needs further evaluation ...
- ¿island creation?
- ¿Scale?

- Only four "comparison between signed and unsigned integer expressions"
warnings left.
Three in tgp.cpp, one in afterload.cpp
This needs reviewing. I left comments in tgp.cpp

- Some more coding style.
To be continued ... but slower now.
I feel: Lost in spaces. lol.

- Happy easter_egg finding.

Known bugs

- If smallest map-axis is 64 your map will be all water when choosing very flat and flat.

- rough, really rough, and cereally rough are unplayable when mapsize is 2048 * 2048 and mountainous
All other mapsizes seem playble.

Todo:

Update logfile.
Many bugs were fixed since the last posted and some parts of code in there are no longer valid.
Also the features section needs an update, and the todo section and ...

To test:

- Attached win32 binaries.

Agreed it's best for another patch, I'm just bringing it up here in the hope you work under the assumption that 0 is the only one that should be sea-level. Otherwise (depending how they're made) current maps may or may not render properly on your new heightlevel stuff.

This patch changes heightmap generation.
That is a valid reason to bring it up.


EDIT:
Binaries removed. Newer are available further in the thread.

[HackaLittleBit]

Keep on truckin ChillCore were all watching.

fix you one int warning
../src/saveload/afterload.cpp: In function `bool AfterLoadGame()':
../src/saveload/afterload.cpp:906: warning: comparison between signed and unsigned integer expressions

Code: Select all

		FOR_ALL_VEHICLES(v) {
			int z = GetSlopeZ(v->x_pos, v->y_pos);
			if (v->type != VEH_TRAIN && v->type != VEH_ROAD) continue;
			if (IsBridgeTile(v->tile)) {
				DiagDirection dir = GetTunnelBridgeDirection(v->tile);

				if (dir != DirToDiagDir(v->direction)) continue;
				switch (dir) {
					default: NOT_REACHED();
					case DIAGDIR_NE: if ((v->x_pos & 0xF) !=  0)            continue; break;
					case DIAGDIR_SE: if ((v->y_pos & 0xF) != TILE_SIZE - 1) continue; break;
					case DIAGDIR_SW: if ((v->x_pos & 0xF) != TILE_SIZE - 1) continue; break;
					case DIAGDIR_NW: if ((v->y_pos & 0xF) !=  0)            continue; break;
				}
			} else if (v->z_pos > z) {
				v->tile = GetNorthernBridgeEnd(v->tile);
			} else {
				continue;
			}

include

Code: Select all

int z = GetSlopeZ(v->x_pos, v->y_pos);

and change

Code: Select all

} else if (v->z_pos > GetSlopeZ(v->x_pos, v->y_pos)) {

to

Code: Select all

			} else if (v->z_pos > z) {

found you a bug (to keep you busy).
On see level without cash I can clear seawater without spending money.
see pic
Rubidium fixed small bug also.

Revision: 15895
Author: rubidium
Date: 9:59:26, segunda-feira, 30 de Março de 2009
Message:
-Fix (r15685): fixing the slopes was done a bit more often than intended making map generation with the original generator horribly slow
----
Modified : /trunk/src/landscape.cpp

Regards HackaLittleBit

[Haiya-Dragon]

Also, using shift to get a cost estimate for landscaping always returns 0 cost estimate.
It will return a cost estimate if you need foundations for rails for example.

[ChillCore]

Keep on truckin ChillCore were all watching.

fix you one int warning.

found you a bug (to keep you busy).

I am watching all off you too.

Thanks a Zillion.
Your code is in the patch now and will be included in the next posted.

Your bug report is in the logfile.
Thank you once again.

Also, using shift to get a cost estimate for landscaping always returns 0 cost estimate.
It will return a cost estimate if you need foundations for rails for example.

Your bugreport is also in the logfile.
Thank You so much for testing.
and taking the time to report bugs.

[ChillCore]

Updated patch.
I had a minor conflict while updating in viewport.cpp.

This version includes:
- Compiler warning fix by Hackalittlebit.(v10_01)
- Some more coding style.

No changes in funtionality.

You can use the last posted binaries for testing if you wish to do so.
I have not yet tested if the previous patch still Cleanly aplies.

Attached updated logfile.(WIP)
Read index first. I changed order of sections for ¿ easier ? reading.

[ic111]

Hello,

just a short notice from me: I am just moving from Germany to Austria, and I will not be able to do anything with this patch during the next weeks.

I know about the following to remaining problems:

The brown tiles outside map. Maybe someone familiar with the concept of graphics and actions in OpenTTD could introduce those black tiles posted some pages above into the game? Or maybe alternatively, could one add a palette with the following property: Applied to a (brown) tile, it makes it completely black. Anyway, you will have to change the painting method in - I think - dummy_land.cpp

The inability to raise/ lower freeform edges. In my new terraforming code, there is some test for the edge of map - I think you will find it if you search a bit and read the comments. At this place, it applies a bound of (0,0) to the edge of map. (0,0) means minimal allowed height of map edge is 0, maximal allowed height is 0. This special bound has to be removed.

Maybe you could try to solve those problems given those hints If you have questions, ask, maybe I answer, but I don't want to promise too much

[ChillCore]

Thank you for those hints ic111.
I will have a looksie in a bit. Maybe I can fix terrforming at borders.

Good luck with that move.

I changed the patch a bit.

- I found some more eastereggs. (Taking a break is good...)
- I retuned the smoothness array a bit more to reduce those long slopes.
Needs evaluating once again.
- Only one comparison int / uint left.
- Bump to trunk (Many changes , Thank you Devs.)

I have to learn once again something new.
Disabling widgets.
We have so many options now. It is time to think about disabling the unplayable ones. (Mapsize vs terraintype.)

[ChillCore]

Another small update to the smoothness parameters.

Still playing with them peaks. But i find the terrain becoming duller somewhat as slopes dissappear on smaller maps (512 *512 and smaller). (Fewer islands, valleys getting stretched out.)

Some combinations (smoothness - mapsize) still do not look good or are simply unplayable. Sorry for that.
Before disabling terraingeneration options, I want to try and tune as much as possible, to disable as little as possible in the end.

The unplayable options are for as far as i have tested:
- If smallest mapsize is 64, first four smoothness settings will result in watermaps.(scenario editor.)
When starting a new game the mapgeneration will abort complaining about not being able to place a town.

- If mapsize is 2048 * 2048 rough, very rough, cereally rough are unplayable.

Maybe there are some more settings that do not work very well, but there is just too much options to test them all at once.
7 terraintypes , 7 smoothness settings, 36 mapsizesettings, 16 waterborder settings ...

At the moment i am looking at some other patches to learn a few new things.
(disabling option not GLAND, and using the black tiles outside map.)


Edit: binaries removed. Newer are available further in the thread.

[2007Alain2007]

every time i try to add your patch i seem to get only level 15 max whats a bit odd when i should be getting more then that

[ChillCore]

I need a bit more info Alain.
Mapsize? Terraintype? Waterlevel? Mapgenerator? Did you enable the patch ?

Attached bump to trunk.
No change in functionality.

[2007Alain2007]

edit never mind i can live with it like that

what part of the code makes the brown tiles how can i change it to be black again please

[HackaLittleBit]

what part of the code makes the brown tiles how can i change it to be black again please

Read this!
and this