News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

climates based on humidity and temperature

Started by kierongreen, June 24, 2020, 02:24:54 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

kierongreen

Proof of concept stage currently. I don't see this as replacing prissi's new code for multiple climate distribution, or the need to read climate maps from files, but as a potential alternative which could be selected. Climate becomes dependent on temperature - which is related to height, and humidity, which is dependent on bodies of water and contours from the direction of the prevailing wind. Tree generation at map start also is dependent on humidity.

Known issues:
Westward edge of map has climates which don't necessarily reflect rest of map
Wind always blows from west
Areas around rivers don't match climate (think this might be shared with trunk).
Doesn't pay any attention to climate settings - fixed assumption that sea level has a temperature of 25.
Climate definitions are fixed (see sketch diagram in attachment)
Not tested enlargement of existing maps






Vladki

Interesting idea. Just a small note that wind in simutrans blows from north-east - planes land and take off against wind, smoke also moves to south-west = right to left.

prissi

Interesting. I think one still should be able to set "temperature" regions for climates, as well as making the apparent height scalable via a parameter, because the relative height of a mountain very much depends on the size of the map

kierongreen

Quote from: prissi on June 24, 2020, 02:42:38 PM
Interesting. I think one still should be able to set "temperature" regions for climates, as well as making the apparent height scalable via a parameter, because the relative height of a mountain very much depends on the size of the map
Indeed - I see a way forward as having a number of options related to map generation:
a) Heights - from file, from perlin, from other generators
b) Climates - from file, from heights (including your overlapping patches), from other generators (including this from humidity and temperature)

Other generators of height and climate will have a need for different parameters to be set - for humidity and temperature this would include wind direction for example. Scaling of temperature can probably be calculated in a global way based on sea level, summer snowline and winter snowline, but a common request is for temperature to increase toward the southern edge of the map (or north). It would be nice to change the temperatures and or humidities associated with different climates too. Have to start somewhere though!

prissi

#4
One thing which I find strange is the randomness followed by smoothing. I think both of them can go away ... Also I think lakes should contribute to humidity too, (and maybe rivers as well).

The wind can easily change to the four direction NSEW, as one would just iterate the map differently. A diagonal map iteration is not so straight forward.

Altogether this is already great and I would envision a combobox in the climate settings that then either show the current options or the temperature-height based climate options. I can take care of the gui.

I think one needs to set the temperature borders and the 65% and 75% humidity, the summer snowline and the wind direction, the "evaporation/resaturation" and the temperature gradient.

I think, it would make sense to add this also with the current climate options to the next version.

I also like the humidity dependent trees. Of course this asks for humudity dependent agriculture locations ...

kierongreen

Not got the code in front of me but lakes should contribute to humidity (any water tile will). Unless lakes are generated after climates but that can be swapped if desired. Rivers is trickier as they would be added later on in the map generation after climates had been made.


As an aside one idea I had was that rivers should be more likely to appear at higher humidities. To some extent trees, rivers and lakes would all have a two way interaction with climate - trees will cause humidity to rise and if you cut down a rainforest you're often left with desert, but equally there needs to be moisture in the air in the first place for trees to thrive. In desert climates rivers may (almost) disappear before they reach the ocean and lakes will evaporate to a lower level, sometimes even to a salt flat. I had thought whether to try and represent endorheic basins (e.g. the Dead Sea, Death Valley, Turpin Depression, Afar Triangle).


I do find the humidity based distribution of forests great when maps have a fair bit of elevation, but for flatter maps it can result in just a uniform spread which is a little boring. Hence maybe a combination which could be seen as acknowledging different soil types might work better, I might play around with that a bit more.


The randomness just adds a bit of variation - effectively trying to represent the factors that are too small scale to be otherwise visible. The smoothing is there to take away isolated climate tiles which otherwise look odd and is necessary regardless of randomness. I've also been looking at picking up some element of coastal humidity even if it's not in line with prevailing wind.


I've added a snow line based temperature calculation which seems to work well for giving adjustments on the temperature range across the map. Also there were a few errors in the original that have picked up on (such as isolated trees never being generated).


And yes, humidity dependent agriculture (and forestry) would seem to be logical. Storing the humidity map would allow for such things.


As you say, changing wind direction is trivial - even to diagonal isn't that difficult really - though would make it more necessary to handle the edges better. Having that, horizontal scaling and maybe some way to influence temperature and humidity boundaries in the gui would be good. Also another setting which I'd like to incorporate is a maximum lake height. That was set at groundwater plus 8 for a long time due to slow lake generation but that shouldn't be an issue now.

Mariculous

Quote from: kierongreen on June 25, 2020, 01:39:03 AMRivers is trickier as they would be added later on in the map generation after climates had been made.
It would be awesome if these started on hills, then searching a way without upward slopes until they meet another river, map borders or a large larke/the ocean.
Though, I guess that's a project on its own :(

In any case, this is a very interessting idea.

prissi

The rivers more or less work like that ...

The current code increases humidity only when hgt<groundwater, unless I overlooked something.

I can work a little on the GUI tonight or tomorrow.

kierongreen

As said didn't have code in front of me last night - it's an easy change anyway to include lakes.


In terms of code structure I'm reminded that Dwachs talked about wanting to separate out world generation from simworld - I had been thinking whether each generator could offer one or more from height generator, climate generator, tree generator, river generator, etc.


The defaults would be existing trunk - although a "from file" would be the first alternative covering not just height reader currently in trunk but also a new climate reader (plus in time others e.g. city locations?)? Users could then mix and match different elements to suit their desired map style.

freddyhayward

Quote from: Freahk on June 25, 2020, 07:01:56 AMIt would be awesome if these started on hills, then searching a way without upward slopes until they meet another river, map borders or a large larke/the ocean.
Quote from: prissi on June 25, 2020, 07:29:25 AM
The rivers more or less work like that ...
The problem on extended was that lakes acted as a black hole for rivers, so most rivers (except for a few coastal streams) never actually reached the ocean until lakes became disabled by default. Even a giant river system could end at a 1-tile lake. Does this still happen on standard? I remember reading this thread about using additional passes to create lake outflows: https://forum.simutrans.com/index.php/topic,13114.msg130518.html#msg130518

makie

#10
[google]In real life, water flows down a hill until it reaches a barrier. There it builds up and forms a lake. The level of the lake rises until the water exceeds the hurdle, then it flows further down the river to the sea. Lakes are formed by rivers and are created in hollows or depressions that are filled with water. If the dam is breached at the end of the lake, the lake runs empty. Lakes are created when water runs into a deepening.

[de]In echt fließt Wasser einen Hügel hinab bis es eine Barriere erreicht.  Dort staut es sich und bildet einen See. Der Pegel des Sees steigt bis das Wasser die Hürde übersteigt, dann fließt es als Fluss weiter talwärts bis zum Meer. Seen werden also von Flüssen gebildet und entstehen in Mulden oder Senken die mit Wasser aufgefüllt werden. Wird der Damm am Ende des Sees durchbrochen, dann läuft der See leer. Seen entstehen also dadurch, dass Wasser in eine Vertiefung läuft.

prissi

The problem is that not every corner of a map (especially smaller ones) has a sea. If every river must drain into the sea, then there will never be rivers and lakes in many areas of the smaller map.

And as some industries (like pak64 power stations) require rivers, those will then also spawn ess in those areas.

makie

If terrain lead the river to the card edge, then the river exit the map there.
Water follows always the steep way down. If the valley leave the map, the river do also.

freddyhayward

Quote from: prissi on June 25, 2020, 01:10:58 PMThe problem is that not every corner of a map (especially smaller ones) has a sea. If every river must drain into the sea, then there will never be rivers and lakes in many areas of the smaller map.
It's fine for rivers to end at lakes if there is no sea, or there is no reasonable route to it, but simulating outflows from lakes would be a good idea if feasible.

prissi

Please open a new thread discussing rivers and better spawning algorithms.

kierongreen

Updated patch to trunk and added a (most likely temporary) GUI to switch climate generation from height to temperature-rainfall based. Additionally if you have temperature-rainfall selected you can choose tree distribution to be none, random or rainfall based. This patch also incorporates the lake height GUI patch previously posted at https://forum.simutrans.com/index.php/topic,20119.0.html. I would advise applying the climate fix patch at https://forum.simutrans.com/index.php/topic,20117.msg189325.html#msg189325 for stability although this shouldn't be necessary as the two patches don't clash anywhere.

lake setting is now height above groundwater
no trees becomes tree and has value 0=non, 1=random, 2=rainfall
climate_generator has value 0=height, 1=temperature-rainfall

Known Issues:
GUI isn't the nicest looking - there probably needs to be a complete overhaul of the window (maybe incorporating tabs), would be preferable if this was able to support multiple climate generators. I also envisage this covering multiple terrain generators, including loading different elements (not just height but climate, rivers, cities etc) from files. Discussion about this aspect should probably be in a new thread.
GUI operation is quite clunky internally in terms of manually setting button states, might be more elegant ways of doing this (also see above).
GUI doesn't support setting parameters within temperature-rainfall, the only one that can be altered is the snowline which determines the spread of temperatures used. Adding this would need redesign of window (again, see first point)
In line with above there should be a code refactor so that (as suggested by Dwachs) generators are taken out of simworld.cc, either to a single separate generator file or to individual ones for each generator.
Saving of settings hasn't been updated yet - suggesting holding this off until have a clear implement version for trunk.

Incidentally patch also removes what I believe is a duplicate no_trees saving in the settings in trunk.

prissi

I have also worked on your initial patch and found several issues with smaller maps, so the drying/rehumidating coefficients needs to be setable as well. The temperatures are maybe best scaled not absulte but relative to artic height.

In the end there were so many diffrent parameters I started a tab based approach to GUI, because most coefficients are not shared between both. Still the GUI was not finished, so I did not post it yet.

kierongreen

Quote from: prissi on July 14, 2020, 02:57:37 PM
I have also worked on your initial patch and found several issues with smaller maps, so the drying/rehumidating coefficients needs to be setable as well. The temperatures are maybe best scaled not absulte but relative to artic height.

In the end there were so many diffrent parameters I started a tab based approach to GUI, because most coefficients are not shared between both. Still the GUI was not finished, so I did not post it yet.
That's ok I wouldn't want to duplicate work too much so will see what your approach looks like when it's able to be posted.

prissi

#18
Just an update of the current version. It is working quite well. You have to remember that the summer snowline is very important as it gives the temperature at sea level. Do not set it too high and almost everything is desert.

EDIT: Update to r9181

RealAmerican1776

How can I download this... and will it work with 256? On another note, I don't know if anyone has been to the Pacific Northwest for example Oregon (beautiful state by the way I highly recommend taking a trip there) but they get A LOT of rain, will it simulate a lot of rainfall?

prissi

That depends on your settings. If the snowline is close to water and the humiditz settings is high, you will get lots of trees and green lands.

I would like to test a pak256, but until now all of them did not release their source code and the binaries are only for extended. But it should work.

RealAmerican1776

Great, I'm willing to test it on my pak256.America. Where am I putting it? Is it just into the files? In Oregon and the rest of the Pacific Northwest, it does not see a lot of snow. I remember last Christmas I went up to a town called Grants Pass Oregon, and even though it was up in the mountains and not by the coast we did not get any snow, in fact it rained which was perfect because on Christmas Eve, a house on the opposite hill from my step grandparents exploded so it was able to stop the fire.

prissi

The new climate code is not submitted yet, as it is still a work in progress.

About 256 sized paks, this size has not been fully tested yet, so there might be some issues hidden in standard in transitions or transparencies.

prissi

This has now incorporated into standard.

With humidity based climates, the winter snowline becomes essential, as it defines the temperature at sea level. (Winter snomeline = 15C average temperature, desert and tropical only for T>25C!)

If you have a small map, maybe set the gradient to 2 or 3 instead 1.

Please enjoy and test it!

Dwachs

imho, the lines 773--775 in settings.cc should not be commented out.
Parsley, sage, rosemary, and maggikraut.

Dwachs

Also why are rivers created before the climate calculations? I get many warnings from weg.cc:415 from rivers that were put underwater by the climate calculations. We do not need to simulate global warming so precisely :D
Parsley, sage, rosemary, and maggikraut.

prissi

The water from the rivers affect the humidity, especially in desert. So you can get pasis etc with it. But for that we have to have rivers (and lakes) before.

prissi

The actually saving of tree is further down. But there should be a check for is_loading. Added in r9196. Thanks.

Andyh

I gave this a quick test drive just now.  Very interesting.  Thank you for putting it together.  A few thoughts:

1. I liked how trees were distributed... very realistic looking

2. Possible to provide an explanation of how the various parameters work: what is the impact of Moisture Land and Moisture Water?  What are Temperature Borders?  What do the 2 Humidities boxes control?

3. Still no latitude-based climate control?  Odd that the single largest determinant of real world climate can't be modeled.

4.  Odd random patches of arctic climate appear... they look out of place... a bug perhaps

5.   Possible to include the option of a East to West weather patterns?  I realize that this is not prototypical, but some players (well ok... me) may want to design maps with that climate model in mind.     

prissi

Different wind directions are possible, but need a little work (Other order of processing the tiles).

For the temperature / humidity borders, look at the diagram in the first post of this thread.

The code assumes that the humidity increases on a raising slope (up to 100%) and decreases on a decending slope by the land parameter. Over water (or rivers) the humidity will go up by the water step.

You got artic tiles with which settings? Artic is default, so tiles where the algorithm fails will stay artic.

Andyh

1. OK.  I think I got the temperature border/humidity thing, thanks.  Does it matter which order the border and humidity parameters are in? 

2. The "arctic artifacts" seem to occur next to water (sea and rivers)... and if memory serves me correctly when the humidity controllers were "inverted" (first larger than second).  I'm not at my own computer at present but can post screen shots of configuration and outcome later if it helps.

3. I got very excited when I saw this in an earlier post on this thread...

Quote from: prissi on June 24, 2020, 02:42:38 PMI think one still should be able to set "temperature" regions for climates, as well as making the apparent height scalable via a parameter, because the relative height of a mountain very much depends on the size of the map

... seemed like we were getting close to latitude based climate zones.  Is this still a possibility?



kierongreen

Quote from: Andyh on September 01, 2020, 08:24:05 PM
1. OK.  I think I got the temperature border/humidity thing, thanks.  Does it matter which order the border and humidity parameters are in? 

2. The "arctic artifacts" seem to occur next to water (sea and rivers)... and if memory serves me correctly when the humidity controllers were "inverted" (first larger than second).  I'm not at my own computer at present but can post screen shots of configuration and outcome later if it helps.

3. I got very excited when I saw this in an earlier post on this thread...

... seemed like we were getting close to latitude based climate zones.  Is this still a possibility?
On point 3 it is possible technically to have latitude based climates, and even relatively easy to add code for this. However a factor to consider is map size (and scale). For climate based on latitude to even start to become apparent in most places around the world you would be looking at as a minimum 500 to 1000km (equivalent to the length of the UK, New Zealand or California, or Florida to Washington DC).

Originally (nominally) in Simutrans the scale was a tile representing 1km in each direction, but for the last 10 years or so that's been shrinking to allow more detailed maps - in Extended for example it's 125m in each direction I think. As such it would only be the very largest maps where you would see this - or ones with an unusually small scale. Say for example a 10000x10000 map of Australia with a scale of 250m per tile.

Andyh

Quote from: kierongreen on September 22, 2020, 08:08:34 PMOriginally (nominally) in Simutrans the scale was a tile representing 1km in each direction, but for the last 10 years or so that's been shrinking to allow more detailed maps - in Extended for example it's 125m in each direction I think. As such it would only be the very largest maps where you would see this - or ones with an unusually small scale. Say for example a 10000x10000 map of Australia with a scale of 250m per tile.

Simultans has always had a different "micro scale" vs "macro scale" (and is non the worse for that).  And to a certain extent one is always obliged to suspend disbelief regarding these discontinuities of scale.  The 125 m (or the 1 km) scale should clearly not be taken too literally and extrapolated to every aspect of the game.  It seems pretty reasonable to model a 3000 - 5000 tile per side map as a continent, covering several latitudinal climate zones.    If the modification were coded with a suitable user-controlled scaling factor available then players could choose the extent to which they exploited this feature.

As I've said elsewhere, climate mapping may ultimately provide the most flexible solution, but I'm agnostic as to method.  I would just dearly love to see a better way of defining climates on continent-scale maps than spending hours painting them (which is what I to do currently).     

Mariculous

Quote from: kierongreen on September 22, 2020, 08:08:34 PMin Extended for example it's 125m in each direction I think.
It's a simuconf parameter that depends on the pak. Pak128.britain-ex chose 125 mpt.

Anyways, as Andyh said, there has always been a mico scale (graphics) and a macro scale (economy and physics) I don't see an issue in using a different climate scale.