More height levels (in trunk since r27010)

[ChillCore]

Nice to know that you like the values that are present already.
I know what you mean by the line-like structures, they are rather hard to get rid off, not completely impossible but rather hard still. Picking primes and creating valeys and peaks with plateaus in between helps a bit, but then some seeds will make them appear again so ...

I will give your patch a quick look but I think I am going to call it quits for today after that.
We made some good progress and I am glad we got rid of that nasty crashing, let's hope it does not come back somehow.

[Rubidium]

Regarding v37, 181_Variety.patch: what's the intention of this change?
game_creation.variety is always positive, so that change doesn't make a difference.
game_creation.landscape is always LG_TERRAGENISIS; GenerateTerrainPerlin is the only entry point, and from landscape.cpp it is guarded by a LG_TERRAGENISIS guard.
Although... landscape != land_generator, so this is a landscape == LT_TEMPERATE check, which makes me really wonder... why no variety in temperate?

I guess the only remaining major thing is getting nice sets of amplitudes, or are the current ones already right?

This is roughly the behaviour of the old amplitudes on an underlying sine wave, though I guess it gives one some kind of clue about the roughness. Having said that, the current implementation doesn't use a sine wave, but random at intervals and then interpolating in between. In the big picture that'll behave somewhat like a sine wave.

smooth_old.png (66.72 KiB) Viewed 4096 times

This shows the behaviours of the new smoothness. To me they are significantly smoother than they were before, though that is likely due to the longer wavelengths that are taken into account now.

smooth_new.png (64.33 KiB) Viewed 4096 times

And I guess those longer wavelengths are a (partial) problem. With higher height differences you want larger mountains and thus there need for longer wavelengths and as a result shallower relative angles since those angles with get a lot steeper when going to heightlevel 100 than when staying at heightlevel 16.

As such I keep thinking that we need different sets of 'smoothness' amplitudes for different ranges of maximum heightlevel. After all, at 16 height levels having a 512x512 area that is between level 8 and 16 for very rough doesn't feel like it. At 170 heightlevels it becomes a significantly larger range. I'm not really sure where the boundaries should be for the different sets of amplitudes.

[ic111]

Regarding v37, 181_Variety.patch: what's the intention of this change?
game_creation.variety is always positive, so that change doesn't make a difference.
game_creation.landscape is always LG_TERRAGENISIS; GenerateTerrainPerlin is the only entry point, and from landscape.cpp it is guarded by a LG_TERRAGENISIS guard.
Although... landscape != land_generator, so this is a landscape == LT_TEMPERATE check, which makes me really wonder... why no variety in temperate?

Seems like I didn´t look close enough on that one when splitting the old patch 180 up.(I probably mixed up landscape and land_generator in my mind when I dealt with it). I currently don´t see a reason for that change either, so I guess you are right and we can leave it out.

I guess the only remaining major thing is getting nice sets of amplitudes, or are the current ones already right?

Well, I didn´t yet find a map where it is really failing to do something senseful, so I guess they are at least a good state for now. But, I didn´t test each and any combination either.

And I guess those longer wavelengths are a (partial) problem. With higher height differences you want larger mountains and thus there need for longer wavelengths and as a result shallower relative angles since those angles with get a lot steeper when going to heightlevel 100 than when staying at heightlevel 16.

I see your point. When I generate a 1024x1024 / Alpinist / Very Rough / Max heightlevel 200 map, I get very steep mountains (this is IMHO ok, since this is the steepest setting available, if one objects about that then something like Hilly is the way to go), with some not-too-good-looking structures, e.g. some inverted-pyramid-like structures. I assume that they are a symptom of exactly the problem you describe.

My personal opinion is that I regard that particular topic of the story not too important since I made quite good experiences with heightmaps in the past. I have seen and played e.g. quite realistic looking heightmaps of the Austrian and Swiss mountains with the mhl-patch enabled, and they generate landscape of a quality where tgp cannot compete anyway, regardless of any fine-tuning one can do. So, probably building up some repository of heightmaps of mountainious areas that are known to work well with mhl is a good idea for the future.

As such I keep thinking that we need different sets of 'smoothness' amplitudes for different ranges of maximum heightlevel. After all, at 16 height levels having a 512x512 area that is between level 8 and 16 for very rough doesn't feel like it. At 170 heightlevels it becomes a significantly larger range. I'm not really sure where the boundaries should be for the different sets of amplitudes.

IMHO this is a valid argumentation, however I don´t feel like I´m the best person for implementing that (i.e. for actually choosing values for those amplitudes). What do other people think about this, are there volunteers?

[Kogut]

Is it hard for people involved in mhl to produce version that would allow tuning of relevant parameters without compilation and later recompilation (via config file or GUI)? I would happily test it (on Win7 or Lubuntu 14.04), maybe also somebody else.

[Wahazar]

I would like to suggest following addition to landscape generation: carving a riverbeds.
Just reuse existing FlowRiver procedure, but instead of placing river, decrease 1 level tile height.
Such riverbed procedure should be run before rivers generation.
As an result, not only we would obtain natural-looking landscape with valleys, but also most of the rivers will choose riverbeds
instead of flat areas - which allow to use eye-candy bridges without annoying bumps (especially for weak engines!).

Here is example, how it works (valleys are carved based on real world hydrographic data, but above mentioned algorithm should work similar):


Of course some rivers would still flow widespread, but most of them would be embanked.
Some riverbeds would be dry, but it looks natural also.
BTW, riverbeds repetition should be equal to amount_of_rivers = 3 parameter, you always have erosion, but in dry climate you have wadi instead of rivers.

There is no need to store riverbed source position. Just run carving procedures and if finished, independently flow river procedures.

[ic111]

Is it hard for people involved in mhl to produce version that would allow tuning of relevant parameters without compilation and later recompilation (via config file or GUI)? I would happily test it (on Win7 or Lubuntu 14.04), maybe also somebody else.

You won´t be able to change the settings without a recompile. But what you can do is starting games with different settings and have a look wether they produce what you expect. Should be easy now, as ...


.... More Heightlevels are in trunk since r27010.

Thanks to Rubidium for the review and various code fixes and adjustments, to ChillCore and CommanderZ for further implementation work and to all testers. It was a long way, 5 years, 10 months and 7 days since I opened this thread to be exactly

[romazoon]

A big round of applause to all the people involved

and you deserve all my respect for not giving up over such a long and generous project

[Pyoro]

Yepp, congratulations and thanks for the hard work

On my subjective note this is probably more game-changing than CargoDist, and that was pretty big already

[Digitalfox]

Great work

Would this work also help in the future to have levels below water?

[Gigigonzalez]

Great work! Personally I dont see the added value "yet?", also how does this work with heightmaps? I dont hope they are all screwed up now! Also I dont hope this adds another desync saga.

Sorry I dont want to be pessimistic, Im just a bit worried.


/offtopic
I think after this project its time someone starts working on the extended heightmap format!

[Eddi]

Great work

Would this work also help in the future to have levels below water?

only in the sense that it's now easier to scratch off some height levels from the top to add some at the bottom of the sea. there's loads of other things to consider that were not even touched by this patch.

Great work! Personally I dont see the added value "yet?", also how does this work with heightmaps? I dont hope they are all screwed up now!

heightmaps that are optimized for 16 heightlevels can still be used for 16 heightlevels. other heightmaps can also be scaled up for more heightlevels.

Also I dont hope this adds another desync saga.

Sorry I dont want to be pessimistic, Im just a bit worried.

the chances for desyncs in this part of the code are pretty low.

[Nappe1]

Truly amazing!
Six years is long time to maintain any patch, not to mention getting it eventually in shape that it gets included in trunk.
Awesome work from the all involved, big thanks.

Can't wait for the 1.5.0 release, which is probably the first official release include this?
(I will use nightlies for single player, so I will test the "trunked" version soon enough, but for multiplayer official builds are much easier.)

[Pingaware]

Congratulations ic111, ChillCore and CommanderZ! It's always nice to see the big features finally hitting trunk.

[Kogut]

Thanks! I just introduced OpenTTD as game for my sister and she was sad that it is impossible to create proper mountains.

EDIT: She is really happy about this change

[Ogre]

All praises and as many thanks as possible to both the patch authors and the developers of OpenTTD for making the much wanted additional height levels possible. Chistmas is quite early this year... but who's complaining about that? *thumbs up*

[Tafidis]

Thank you! This is BIG. Great to see OpenTTD being developed so actively for so long. I mean WOW, this changes (enhances) the game SO much! Thanks again!

[Gigigonzalez]

So how will this work with heightmaps (ie. how does it read heightmap pngs), can they be seamlessly converted ?

did you simply add more grayscale steps in between ?

[peter1138]

Er, previously heightmaps were simply scaled from 0 to 15. Now they are simply scaled from 0 to whatever you set as the maximum height.

[kamnet]

It should read heightmaps with a greyscale range of 0-255, but typically the ones generated from sources like USGS, NASA, etc. are going to be 0-15. I've created custom heighmaps using the wider scale, though.

[ChillCore]

It seems to me that r27008 was the missing piece of the puzzle to finish (*) MHL.

Congratulations ic111 and thank you everyone else for the continued support and feedback over the past years.

Is it hard for people involved in mhl to produce version that would allow tuning of relevant parameters without compilation and later recompilation (via config file or GUI)? I would happily test it (on Win7 or Lubuntu 14.04), maybe also somebody else.

I am working on my custom smoothness settings patch, It has a gui to mess about with the parameters without the need for re-compilation.
I could post what I have so far if you're interested in messing about and helping me improve usability.
Note that this may be a crude experience still as there are options missing, you will have 2 guis open at times. Also I noticed that with some combinations of noise parameters the mapgeneration tends to freeze for a bit and I do not want to fry everyone's CPUs ...

So how will this work with heightmaps (ie. how does it read heightmap pngs), can they be seamlessly converted ?

did you simply add more grayscale steps in between ?

As Petern explained things should work pretty good in regards of heightmaps.
Ofcourse when importing the heightmap, just as with re-sizing , you will get less than optimal results if you scale height too much up or down.
Also scaling down will generally work better than scaling up as we do not magically insert colours into the greyscale if they are not there to begin with (read: when you start with a heighmap that has less than 255 colours in it) ...

Attached a few teasers of what you will be able to generate yourself.
The number indicates the max_height setting I had when exporting the heightmap , which happens to be the ideal maxheight you select when loading it back in.



(*)
Finish the end of the beginning that is.