NEW CLIMATES MODEL (was: The Equatorial Wind)

[Roads]

Just so y'all know, I think the maps are absolutely beautiful.  The concept of climate based on altitude is solid.  IMHO however, the maps lack a sense of predictability from user choices and also sometimes present spotty patches of terrain that do not seem to match its neighbor.  Let's suppose that every map that is created has some relationship to the equator.  Now let's assume that the farther the map is from the equator, the colder the climate is and that is enhanced by the altitude of the land.  Conversely the warmth of the equator would mitigate the colder temps for high altitudes.  This alone would allow the user to create different climates simply by choosing how far the center of the map should be from the equatorial line or indeed on it.  Naturally the map could be either north or south of the line.

Now let's add a global wind that travels around the earth on the equator.  When it travels over the ocean it picks up moisture.  Let's say the user placed his map on the equator and it has a mountain range running north and south on it across the equator.  The wind is going to drop a lot of moisture on the right side of the mountain range (creating a jungle) and  on the left side of the range a desert.  No mountain ranges?  Then the land would receive a consistent, if heavy amount of rainfall.  The map is directly under the equatorial wind, right?

Well we are all fixed up for maps centered on the equator.  Now to address the ones that are not.  The equatorial winds should carry the greatest moisture at its center and gradually decrease with distance from the center.  Of course this would mean maps north or south would be pretty dry.  What we need to do is add spurs off the equatorial wind.  These could be both random distances apart and random lengths.  Also they need not be and probably should not be all perpendicular to the equatorial wind.  The spurs would have the same effect of dropping moisture when they encounter mountains.

I have no idea if this would be more trouble than it is worth but it would present a systematic approach to climate and could have far reaching implications for later development.  For example if you wanted to have droughts, you could simply shift the spurs for a time.  If you really wanted to screw up the climate, you could shift the equatorial wind which of course would also shift all the spurs.

The idea would also allow for crops having very good and not so good growing locations since you would know the exact amount of rainfall each square received.  For example cotton needs a rather dry climate while corn needs more water.  Coffee needs high altitudes.  Rice, well you know, there's lots of possibilities.  

EDIT: title changed

[gauthier]

I support 

[prissi]

These, together with latitude dependent darkening are on the eternal todolist.

[Roads]

I'm going to begin readng on how to help with programming.  I've had very little experience with C++ and I'm afraid the code will scare me when I see it but it is better to light one candle than curse the darkness.  This was illustrated to me once again Thursday night when we had a power outage...

[VS]

This is really interesting, as I have kept thinking about something similar for years, first just as a dream, later more and more from programmer's viewpoint, and finally as a painter, too. Well, it was something different, simulating geological history and thus determining resource deposits, hand in hand with rivers which in turn affect forests and so on... let's forget that for now, as it requires a completely different approach. At least to me, your suggestion sounds far less... detached from reality? In the end, it adds only one factor/number, humidity, which is easier to cope with than complete representation of resource types as my idea would require.

It is possible, just as everything and anything is possible, only the amount of resources needed might be too much, depending on how far it goes.

Just how would that work? Some thoughts...

1)
If there is just one single wind direction or the whole map, things are simple. In fact, if you disregard the fact that the moisture disappears after some distance, the whole problem is reduced to a simple formula independent on map, only for the tile in question and its neighbours: "slope steepness in direction of wind vector". One great advantage of this approach is simplicity and transparency - a few calculations and you get the number.

2)
A step further is simulating that the moisture is after a while dropped completely - in other words, the wind carries only so much of it. IMO that calls for something akin to raytracing, which is an order of magnitude more complicated. So, shoot "rays of wind" and depending on the previous formula, subtract amount of carried moisture from counter and transfer to tiles. As soon as the counter is zero, you can stop... However, since you have to actually follow the "ray", the moisture map must be calculated either completely, or at least in "stripes" reaching to the tile in question. If it is needed complete, then the disadvantage is not so big. However, terrain at some place affects results at another place, so for every change (when you dig), some part of moisture map has to be recalculated. At this point there is still only one constant direction of wind, so the affected part can be determined easily.

3)
This scheme can be easily improved by allowing arbitrary ray directions and origins, only then the deterministic factor disappears -> digging = bad stuff, forces recalculation of the whole map.

4)
Finally, what if winds stop on obstacles such as mountains? You have to calculate new direction for every encountered tile. Gradient of tile+neighbours to decide new direction. Then, moisture does not get to some places, so it is even closer to reality.


Perhaps I am wrong and there is some other way... but imho the first way is easiest.

[Roads]

VS, I believe we are singing from the same hymnal.  If I had my "wants" I would very much like to see a simulation of all the things you talked about.  A baby has to crawl before it can walk.  My idea was not only to enhance the capabilities of the current map but to establish a basis for other things that can be done in years to come without having to redo the climate.  Hopefully it will do that.  If not, maybe someone else has a better idea or this one can be refined.

I'm going to re-read your last post to make sure I understand what you are saying but one thing I did note - about the wind giving up all its moisture when it encounters a mountain.  It might be better for it to give up its moisture on a random (with high probability basis) rather than always.  That way it would sometimes, but rarely rain in the desert.
EDIT:  As I understand it in most cases, wind does not stop when it encounters a mountain, it simply drops most or all of its moisture as it travels over it.

Two other things about the wind giving up its moisture.  One is that if you had a gradually increasing height in the terrain, it seems the wind should drop more of its moisture than if the terrain was flat.  Second, I want to think that as the temperature of the terrain decreases, the wind would drop more moisture.  This idea causes difficulty though because it would leave the very cold areas dry as a bone.
EDIT:  Now that I've thought about this some more, perhaps the cold temp could cause the wind to drop its moisture.  Since only the spurs would be affected, the coldest areas would get the last of the moisture.  This should allow very cold areas to have some areas with snowfall and some very dry depending on the terrain preceding it.


EDIT:  I am clueless what you mean by "digging" but if I understand what you said about one tile affecting other tiles, couldn't you just not worry about what has gone before but simply apply the moisture to a tile based on the moisture content of the wind above that tile?  Of course the previous tiles would affect the moisture content of the wind but their effect would already be calculated and subtracted.  What I'm saying is couldn't all this be calculated when the map is drawn and stored like (I assume) the value of the altitude?

I apologize if I've jumped into water way above my head and just rattling about something that is far more simplistic than what you are talking about.

[VS]

Two other things about the wind giving up its moisture.  One is that if you had a gradually increasing height in the terrain, it seems the wind should drop more of its moisture than if the terrain was flat.  Second, I want to think that as the temperature of the terrain decreases, the wind would drop more moisture.  This idea causes difficulty though because it would leave the very cold areas dry as a bone.
EDIT:  Now that I've thought about this some more, perhaps the cold temp could cause the wind to drop its moisture.  Since only the spurs would be affected, the coldest areas would get the last of the moisture.  This should allow very cold areas to have some areas with snowfall and some very dry depending on the terrain preceding it.

Right! I considered only the effect of elevation changes - that is, while writing all that I thought:
"If the wind has to "go up", water drops more; if down, it's less."

I totally agree that this is not the only factor, temperature is also important. However I tried to keep the main "thought stream" (?) as simple as possible to avoid even more confusion. Adding temperature would be relatively easy, simply multiply by some value somewhere



I tackled this more from the programming side, so I mainly theorize about ways to turn the "idea" into "recipe" and what sacrifices can be made, with what effect.

one thing I did note - about the wind giving up all its moisture when it encounters a mountain.  It might be better for it to give up its moisture on a random (with high probability basis) rather than always.  That way it would sometimes, but rarely rain in the desert.
EDIT:  As I understand it in most cases, wind does not stop when it encounters a mountain, it simply drops most or all of its moisture as it travels over it.

Something I omitted completely is season of year. If the aim is to receive only one number, it should be more efficient to simply take an average - or so I hope. And randomization in this case falls into the same category. Or... yes, if it was a place-random but time-constant coefficient of raining probability for a given tile, then it fits into the algorithm just as you suggested.

By the way, the parallel of casting photon rays in this case translates seamlessly to blowing clouds around. I should have thought about that earlier.

I am clueless what you mean by "digging"

Digging - when you raise or lower land.

but if I understand what you said about one tile affecting other tiles, couldn't you just not worry about what has gone before but simply apply the moisture to a tile based on the moisture content of the wind above that tile?  Of course the previous tiles would affect the moisture content of the wind but their effect would already be calculated and subtracted.  What I'm saying is couldn't all this be calculated when the map is drawn and stored like (I assume) the value of the altitude?

Agreed, a moisture map is what I am thinking about. The difference is in the way to "fill it in" with numbers. If height of tile affects the outcome somewhere else, change in height map (which change is self-contained so to say) requires also change in the moisture map. Then if the algorithm is such that a small change (one tile) triggers massive response (change on many other tiles), every change requires recalculation of moisture map, either some part when it can be determined which, or the whole of it - that is of course unwelcome...

What evaded you in the reasoning above is that if the moisture map keeps changing, the process leading to it must be repeated, while it is desirable to never repeat it. It is another work to do while the game runs, or said differently, "eats" some of the time dedicated to keep the thingies on screen moving fluently, not jerkily.

One pitfall of my argument is that it might not actually be demanding enough to matter - if the increase is 2% of previous workload, why even care? That is also the reason why I suggested four solutions, progressing from simplest to most abstract and at the same time increasing in resource demand intensity.



One of the things I learned is that when thinking about programming, one has to take into account a lot of things that are not immediately understandable for uninitiated, simply because they think computers are clever - whereas they are totally stupid, just glorified calculators. Thus descriptions in this domain require high amount of detail - which scares other people as redundant. I apologize if all this text was hardly comprehensible or relevant to what you wished to talk about. I was really eager to discuss how to get this into the game, maybe not so much the details surrounding it...

Also, English is not my native language, and while I would normally say I'm quite fluent when writing, this text stretched it to limits. So, please forgive the abuse of "I" and other defects.

Now that I think about it, perhaps I am envisioning quite different path to the same result... or not even that? To make it clearer: How big is the map, relatively to the globe? How many wind directions are there? Which of the ones in picture is most similar to your idea?

[Roads]

It should not matter how big the map is relative to the globe.  The idea is that the equatorial wind travels around the globe.  So, there is only one main wind.  Also it should not matter if there is one land mass or several.  The main wind (equatorial wind), picks up water when it is over water and drops water when it is on land.  The spurs, (there could be several and this is where the idea differs slightly from your pic) get their moisture from the equatorial wind.  Thus I believe "C" (the top one) in your pics is closest to my idea.

I had forgotten about seasons as well.  My first idea (which is usually not the best), is to redraw the moisture map whenever the seasons change.  That is if you want the moisture content of the tiles to change with the season and I'm guessing you do.

Yes I had forgotten about players making changes in the height of tiles.  Realistically though, it would take massive changes to affect the weather.  Since that is still a possibility, would it be difficult to put a check in that when a player makes greater than x number of changes you throw a window up saying something like "The changes you have made will cause a change in the weather.  Please wait for the new world weather pattern" and redraw the moisture map?  I'm thinking we would need this anyway because if, at some later point, the output of crops is based on the moisture content of the tiles it occupies, then that output would need to be recalculated.

I would never have guessed English is not your native language.  I think your response was excellent.  To some extent and I'm sure not as extensively as you, because I don't have the in-depth programming knowledge that you have, that every detail of a proposed programming change must be explored.  I realize without doing that you can write numerous lines of code, then realize you forgot some detail which likely could cause all that code to need a rework.

Oh geez VS, no one abuses "I"'s like I do.  Try as I will, that is something very difficult for me to improve. :(

[jbode]

I had forgotten about seasons as well.  My first idea (which is usually not the best), is to redraw the moisture map whenever the seasons change.  That is if you want the moisture content of the tiles to change with the season and I'm guessing you do.

Maybe simplify that way:
- to have the wind just blowing west to east
- recalculate the moisture map per season (can take the sun elevation of prissi's eternal wishlist into account)
- cities also warm up locally so they can be changing the moisture map too (including skyscrapers influencing the airflow)

To recalculate on every building activity (landscape forming, bridgebuilding, planting trees, ...) might be of too low relevance justifying the additional CPU time. When the needed workload is really small it could go to a monthly recalculation.

The argument its "just 2% more" is in my regard dangerous. There is such an amount of little wishes "with just 2% more workload" that its possible to add up to too much We have already the overtaking of vehicles included and numerous more ...

[isidoro]

Simutrans is slowly evolving to Matrix.    :

[IgorEliezer]

Can I be the Architect?



I promise I will be kind with Simu-Matrix-citizens.  :

[Roads]

Can I be the Architect?

WOW!  I don't know who will make that decision but I'm one happy camper right now.

Certainly I'm doing as much as my ability will allow and that is offering ideas.

[Fabio]

Great ideas!!!!

One day i'll open the forum and i'll found it done, i know this...

[VS]

Now I slept a bit and see where is the difference:

I understood humidity as a rather invisible parameter - it would affect only industry placement and maybe trees, too.

What you all are suggesting is to actually let it affect "climates" (-> also ground graphics) which are now only dependent on height.

Correct?

[Roads]

yes. 

[VS]

Oh! Then the simulation should be rather precise.

[Roads]

VS, I am not sure where your head is on this.  If you are talking about tiles ending up with exorbitant amounts of rainfall or never getting rainfall, then it is true that can happen unless the amount of water carried by the wind is carefully explored.

That said, it might not matter, in fact you might even have a slider for the user to determine the amount of water content of the equatorial wind.  If the map comes up and the land is all wet, move the slider back and regenerate.  This could be a frustrating though where you could end up with a situation where only a tiny area of the slider presented a usable map.  For example, many maps could be generated where every tile recieved in excess of say, 500 inches of rain or huge areas devoid of rainfall.

Possibly the first thing to consider is the size of the map.  If different size maps are possible, then the base amount of water the equatorial wind carries should be determined by the size of the map.

Another thing to consider is how many spurs the equatorial wind can have.  I believe it would simplify the concept if that number were set per map size or at least have a min/max number.  The concept would work regardless of what it done here as well but again you could have a sloppy situation where a usable map was hard to generate.

One thing of note is that it may prove very difficult to come up with a formula to reliably produce maps that never have tiles with excessive rainfall.  This might not be a problem.  If this is the case, then those tiles could be indicated as lakes.  Tiles such as this adjacent to each other would naturally form rivers.

[VS]

Ah, nope. Of the two parts to the whole thing,
1) create the moisture map,
2) put it to some use,
right now I don't care that much about the latter, since there is a large pool of people that can come up with ideas concerning these "visible" aspects, which the player directly sees or feels their impact on game.

I rather focus on (1) as it is a prerequisite There is a lot of mechanisms involved, too, so lots of space for discussion as well. If I'm not completely off, that was what we (mostly) discussed so far. My goal with this is to find the formulas and so on, find out what effect can be included and which not, to get finally to something that would take as input a heightmap and produce an acceptable moisture map, in all cases.

On an unrelated note: excessive rainfall... hm, swamps? As of now, lakes aren't possible, since water in Simutrans is just on the sea level. Same for rivers, although these can be represented by canals.



I tried to create something similar to what I earlier described as first alternative. It was an epic fail In the end, I just discovered that all the vector calculations lead to a result identical with "emboss" operation - except I did it in a horribly complicated way, generalized for any direction. Well, more experience points for me...

In other words: Variant #1 moisture map is equal to embossed terrain profile!

That is good news, as emboss is calculated using convolution matrix - something I can relate to well

Another discovery is a bit disheartening; given how tiles in Simutrans work, terrain actually isn't smooth, but forms something best described as "stairs" - there are level tiles, and sloped tiles, and there is always more of the former kind. Since all of the methods I considered need some sort of gradient to be non-zero to get a result, the moisture maps would look mostly "flat", without any notable varying areas.

So I guess it won't be as straightforward as I thought first.

Now on to the second variant, maybe I'll find some time in a few days.

PS: I didn't do this in Simutrans! Only a proof of concept matlab script, working on a heightmap loaded from map files commonly used for Simutrans, nothing more. There is still a very long way to go. So don't hold your breath

[Roads]

This may be just another post that will not be helpful to you but here goes.  I know almost nothing about heightmaps.  I do know that the water level is always zero but that's for a later discussion.

I think you would first need to determine with your algorithm where the x,y on the edge of map is for the main wind.  This tile and everyone adjacent to it would receive the greatest and equal rainfall.  That is every tile along this line is flat.  If any tile along this line is inclined, then that tile and (to be determined number) of previous tiles should receive an additional amount of rainfall.  Each of those preceding tiles should receive succeedingly less of that additional amount.  Ugh, I bet that does not make sense.  If I need to phrase that differently, please say so.

We now have the main wind dropping rain on the map one tile wide.  Not only that but it also drops more rain on inclined and adjacent to inclined areas.  This is only true if the inclined tile is leaning in the direction of the wind!  The exact opposite would be true for a tile leaning opposite to the wind.  It and a succeeding number of tiles would receive less rain.

Now for the tiles adjacent to the main line.  They sould follow the exact same method only receive minutely less rain than the main line.  Rinse and repeat until you get to the edge of the map top and bottom.

That should do it for the simplest of patterns.  However it obviously leaves the top and bottom of the map very dry.  This is why you need spurs coming off the main line.  They could be treated exactly like the main line as far as dropping moisture but in the north/south direction instead of the east/west direction of the main line.

Is this something that will help or work?

EDIT:  One thing I had not considered is that all the tiles on the map would be covered by the main wind.  Since this is true then the spurs could not be done exactly the same as the equatorial wind.  Instead the moisture content of the tile would have to be added to the spur amount.

[VS]

So something like this?

[Roads]

The top left pic is what I'm thinking with perhaps, a few less spurs.  Anything more than a single east/west (horizontal) line could get very complicated.  But for the sake of map coverage, you can think of that line as a "band."  The width of this band should extend very far north and south and could extend to the edge of the map.  In fact if it doesn't extend to the edge of the map, the extreme north/south areas would receive no moisture from the equatorial wind.

The moisture there would have to come from the spurs.  Their width could be quite wide as well and their length extend to the edge of the map.

If this pattern proves to be unworkable, that is if the tiles at the center of the equatorial wind receive way too much moisture and those near the edge of it way too little, then the wind with its spurs could be duplicated somewhere in the top 1/2 of the map and also somewhere at the lower 1/2 of the map.  These secondary main winds could also (as you indicated in the other pics) travel in a diagonal direction.  That is if the main lines were single, not two or three as shown in the pics.

VS, I know you have much more technical ways of doing this but I'm thinking it could be done with "for" loops.  It looks to me like you could count the number of tiles across the map, setup your for loop, then begin dropping moisture on the tiles beginning at the point of entry.  Each tile, as I said in the previous post would receive an equal amount of moisture as long as the tile is flat.  Of course when you encounter a leaning tile (in the direction of the wind), you would have to drop back and add additional moisture to those tiles affected.  This pattern would have to be repeated for every tile in the east/west direction until you reach the edge of the wind or band.

When you start a spur off the main wind the exact same procedure could be followed except that you would have to include the moisture dropped by the equatorial wind.

I'm thinking the moisture map could be done after everything is completed on the map, maybe prior to adding the buildings...you wouldn't want any buildings to be under water.

This is why I am thinking that it wouldn't matter if heightmaps will only let you have water at altitude zero.  You could simply lay water tiles down the same way you do buildings only wherever the quantity of rainfall dictates.  No doubt there would need to be some refinements once you saw what the map looked like but the concept does allow it.

[VS]

Did I forget? Maybe not. And I learned what I am after should not be called moisture map, but precipitation... shame on me

It works, but creating a feasible... something... requires some ocean around, or the method hopelessly fails. Some more tweaking of parameters could reveal a setup which works for both coastal and inland maps. Or so I hope.

How it works, in short - first create a heightfield like inside Simutrans, then apply gaussian blur (radius 25, uff) to get rid of stairs-like nature, run over with direction operator, and this is gradient. Second, go in stripes (1 tile wide) over the map in direction of wind and do the raining thing. That is - when passing over water, gather it, otherwise first gather small fixed amount, drop small fixed amount, plus drop amount depending on gradient of tile. Attached below is the full code.

Currently the configuration part looks like this.

Code Select Expand


imgfile = 'Tasmania_637x595.ppm';
% what to load

dirop = [...
    1  1  1 ;...
    0 -3  0 ;...
    0  0  0 ];
% the direction where the ones are "bluntly aimed to" in respect to -3 is
% where wind comes from

water_starting     =  200; % enter map on edge with this amount
water_drop_base    =   20; % multiplied by slope gradient
water_drop_always  =    5; % always dropped
water_add_always   =    6; % always added (these two do clash a bit)
water_add_ocean    =  100; % added when passing over water
water_max_capacity =  inf; % maximum the wind can carry


Britain, wind from north-west



Britain, wind from south-west



Panama, wind from north-east



Switzerland, wind from north



Tasmania, wind from north

[Roads]

VS, I've had a bit of trouble lately both with replying and getting to the site or I would have posted before now.  I have not lost interest!

First off, congratulations are in order for coming up with something that is workable.  Well done!  No doubt there will be lots of things to work out but it is something to work from.

I'm thinking it might not be a great idea to have the wind carry an unlimited amount of water.  Would it be possible to have a saturation point at which it starts raining regardless of the terrain?  It could even rain over the ocean.  Also I think if the wind started the map at saturation point it would allow rain on maps with no ocean.

One thing worries me a bit and that is I think this will create maps which will have much larger "same type" areas than the maps that are currently generated.  For me that is a good thing.  If true, do you think that will be generally accepted by the players?

[VS]

Thanks! I don't think I will lose interest either This is too interesting to let go, especially when I have progressed a bit.

There is still a number of possibilities I have not tried. For instance, I kind of forgot about evaporation Tiles with high rainfall should also return far more moisture into air. That could cure the problem with sea needed...

One thing worries me a bit and that is I think this will create maps which will have much larger "same type" areas than the maps that are currently generated.  For me that is a good thing.  If true, do you think that will be generally accepted by the players?

What is this new information used for is something I'll worry about only when it works reliably.

[robofish]

wow, this looks really promising

[Roads]

I think so too robofish.

VS, I'm not sure I can see where you are going with evaporation.  It seems that would be more of a secondary effect rather than part of the solution to the initial precipitation.

As for "all land" or "land and sea" maps, I can see difficulties in trying to make one formula fit two entirely different situations.  Perhaps you could use a dif formula depending on the map type?

[VS]

Oh, but then it is a question of detecting somehow if it is coastal or inland map, no? Again the same question... how? Always more questions than answers - reality check I think I got it to work with both kinds anyway.

If it is of any use, after trying the few select heightfields from our maps site I learned empirically that the 0-1 scale can be divided with two thresholds: 0.25 and 0.5. The lowest values are most common, and the highest rather rare. Well, generating maps exactly like Simutrans does and testing with them is presumably next step.

Computing this for maps of size ~1000+ takes about two to three times as long as generating them it in Simutrans. Matlab is interpreted, but on the other hand, it uses SSE, so no idea what it says about performance after rewriting to C++.

One thing seems clear to me, this is too resource-costly to run even yearly or so. Calculate once per map at start and that's it. (Needs three copies of map and two smoothing convolutions with large radius.)

[Roads]

VS, it sounds like you have put a huge amount of time in on this.  Saying thank you sounds weak at best.  I guess the satisfaction of creating something really awesome is the only real reward.  If you need anyone to test what you are doing, I'll be glad to do that.

For me, I don't care and am not surprised that it will take longer to generate the maps.  If you were thinking you could use the precipitation map to actually display rain or snow during game play then I can see why you sound a bit disappointed.  I'm just guessing at that because I can't see any reason why you would need to regenerate after the initial map is created.

[VS]

Ahh Roads, don't flatter me so. The time was not by any measure huge, and so far it was only proof of concept, where I fleshed out the "recipe" in an environment I am familiar with.

A bigger challenge will be recreating this inside Simutrans, really.



Calculation time is needed mostly for smoothing the data, so this is probably the direction to search for further improvements...

[Roads]

As far as I'm concerned a little flattery is a good thing when it is well deserved.  And please don't tell me it is not in this case.

To those of us looking ahead and thinking about playing in years to come, it is comforting to know there are people who can and are working on enhancements that can very possibly lead to new challenges instead of penalities as well as more realistic and exciting maps.

[VS]

Well, the recipe is ready, I would say.

In the end, I decided to drop the side winds completely before trying them; the difficulties with a single stream are enough. Making them attach smoothly to the main wind would be problematic and could raise resource usage. If not made very carefully, it could introduce artefacts in form of straight line borders... which is not desirable at all.

Following observation of the results, it seems that classifying the values into three steps is about right. I would propose this scheme, dependent on both precipitation and height:

(Temperature is still equivalent to elevation, identically as before - the higher, the colder.)
The top row of climates should be completely forested...



As an example, map of Southern America with wind from north-west. I am really pleased with the result - the three types of areas are distributed roughly equally to provide all types of terrain, and the main features as the Amazonian forests and deserts behind Andes are there!

Classes:

Data:

Process:




Now on to optimization - so far I smoothed the data using plain convolution with a huge gaussian. A promising technique could be filtering in DCT domain, perhaps... theoretically convolution has class O(n^2) while dct has O(N log N).

[Roads]

The map has a natural, realistic look - exactly what I was hoping for.  You have already done an incredible job on this.  Using the single wind looks like it has worked out well.

The terrain types are great as well.  I'm wondering if within these types we will have varying precipitation amounts?  I don't mean that this would require different colors for the variations but simply an annual rainfall amount when queried.  If not, no worries, you have already accomplished the main objective.

Again, I want to say the maps look great, great, great! *cheer*

[VS]

Ahh, nope - there are the three levels of moisture: low, normal, high. These are then combined with four height levels, so the resulting climate zone is combination of height (temperature) and moisture. The table shows it...

[jamespetts]

This really looks very interesting, I have to say - and looks as though it has been an enormous amount of work! I shall look forward to seeing it in Simutrans.

[Roads]

Now that I've thought about it more, variations in terrain type might add little, if anything to the game.  With what you've done we could have terrain based crops.  That is, crops that would grow on more than one type of terrain but would grow better on one rather than both, three, etc.  I'm with JamesPetts, I look forward to seeing it in the game.

The only suggestion I could offer at this point is for the terrain at the equator to be warmer and gradually cool both north and south.  This would give us coffee.  If the Simutranians are anything like me that would make them very happy.

[VS]

Oh... now that's an idea! For some reason I always thought that climates must be fixed with height, but obviously that is a very false assumption. It suddenly seems so easy - all it needs is that all height limits are decreased towards sides of map.

You know, this could really work... Except I still have to find how to get this into Simutrans Yay for coffee... and tea, chocolate, sugar and all the other goodies.

[IgorEliezer]

Little off-topic:

Again, I want to say the maps look great, great, great! *cheer*

Someone here lives at SE part of that map.

[jamespetts]

Oh... now that's an idea! For some reason I always thought that climates must be fixed with height, but obviously that is a very false assumption. It suddenly seems so easy - all it needs is that all height limits are decreased towards sides of map.

You know, this could really work... Except I still have to find how to get this into Simutrans Yay for coffee... and tea, chocolate, sugar and all the other goodies.

Ahh, might I make one suggestion? Might it be best not to assume that the equator runs through the middle of the map every time, so that different overall climates could be simulated? All that that would require is an equator offset value, with 0 being the middle of the map, negative numbers being further South, and positive numbers being further North. Furthermore, there could be another "range" value, which would vary with the scale of the map: for example, with the "range" at the highest setting and offset at 0, the middle of the map would be equatorial, and the top and bottom polar, whereas with the offset at 0 and the range setting very low, the whole map would be more or less equatorial. This should enable a wide range of map scales and overall climates to be simulated, hopefully with fairly minimal additional coding effort. After all, not everyone will want a Simutrans map the size of the whole world...

[kierongreen]

Climates changing independently of height is a little tricky in terms of graphics... Means you need n^4 * 15 graphics tiles to be calculated - that could work out to be 20k tiles or so with 5 climates and snow...

[jamespetts]

Kieron - not necessarily, since many of the tile types could be used at different heights, depending on the climate. It would be a bit silly if all low-lying land was desert, even if one is supposed to be simulating, for example, Polish transport...

[VS]

Uff - one by one.

First, there isn't any C++ code yet. I haven't even started to think about it (I definitively want though).

Second, about the equator and "moving" height levels. It could simply work by having three sliders for something like climate height offset. Attached is a sample of the ui part. If that is not enough, a fourth scrollbar in the bottom could move the middle one...



Third, number of transitions. That could be a bad problem... It would be probably better to render transitions on the fly from more images, as multiple layers. Then you need the base tile of climate in 11 versions for all slopes. Transitions are two, since you're going to want transitions only in "one" direction (two orthogonal), not bilateral. Multiply transitions by 3 for all kinds of slopes (no irregular slopes, phew...). So that gives 11+2*3=17 tiles per climate.

Given there are 12 cells but only ten climates (irregularity - good? bad?) and one can be identified with snow, which is special, you need 9 regular climates. 9*17=153.

Next comes water, which is special; only bottom-up transitions, but from all sides. That makes (11-1)*climates=10*9=90; 90+153=243. Water with depths is aside as it can not go upwards or downwards - err, some 7 images? 243+7=250. Still not thousands

Finally snow. Can be next to anything, generally, but the good message is that it can't go from below. This saves one transition. No. of transitions is therefore only 5; 5*9=45; 250+45=295. Still good... maybe.

The one thing I can see is that corners could become uglier. That could require special transitions for them then.

Sorry if the numbers make no sense to you - just draw the situation and see for yourself.

I'll think more about this tomorrow, and try to come up with some estimation as it looks when transitions between height levels

[attachment deleted by admin]

[Fabio]

Second, about the equator and "moving" height levels. It could simply work by having three sliders for something like climate height offset. Attached is a sample of the ui part. If that is not enough, a fourth scrollbar in the bottom could move the middle one...

This is a great idea and, besides, much more intuitive than the present system.

Am i asking too much to see a preview of climates in the minimap in create new world? maybe there could be two minimaps: one for heights and one for climate...

[Roads]

This seems to be really coming together now.  I am absolutely delighted that you saw a way of incorporating colder temps as you move farther from the equator.  The idea that the equator can be moved on the map is great too.  It looks like we will have the ability to create a wide range of maps - from those that have every terrain type to really warm and really cold ones.

I guess it remains to be seen how robust the possibilities that this offers is included into the game but it certainly allows including more than a complex transportation system.  It adds the ability to challenge the player to find ways of transporting far-away crops and getting foodstuffs out of difficult and rugged terrain.

[Fabio]

An easy way to affect gameplay, would be a multiplier/divider for construction and maintainance according to the climate.

e.g.
0.75 for mediterranean and temperate
1.25 for jungle
1.50 for desert and tundra
1.75 for rocky
2.00 for arctic

an additional multiplier would be
1.00 areas below the winter snowline
1.25 areas above the winter snowline

[prissi]

THere is some rework needed before different climates on the same heightlevel are supported within the game. ALso you would need to beldn between the same climate horizontally, which is also not in yet.

You can forget about multipliers. Each tile must have a single climate, because the search function need to be fast. Doing bitwise and is fast, and real numbers is really slow.

[Fabio]

the multipliers would just affect waybuilder and maintainance (which is monthly, IIRC).

and they could be int as well (maintainance: 1x on temperate and mediterranean, 2x on jungle and tundra, 3x on desert or rocky, 6x on arctic... this would even be more realistic than 1.5 )

[VS]

Why keep things simple... and so on.

[kierongreen]

As prissi says - without rework different climates at the same height is not possible.

As for number of image tiles:
If climates can be at any elevation then for each tile any of the corners can be any climate.
This means that there are 7 x 7 x 7 x 7 (=2401) possible climate combinations for a given tile, and 15 tiles (with slopes). That alone gives 30000 possible tiles without snow. Now restricting it so that climates have to always be in sequence reduces this a bit, but you are still talking about considerably more tiles than are calculated at present (currently at most 7 x 15 x 2 x 2 = 420 tiles give or take) - since transitions between climates could be on any slope.
Of course you could go for just rendering the tiles as you go along, but this would be much slower than the current system.

[VS]

I think I know that it is not possible without rework

Now I see where you got that "15". That's as it is now, but evidently transitions do not to have be in the middle of tile. What I want to do is make every tile have its "base" climate and make the other climates "poke" slightly into it - but not much.

Rendering tiles as they are encountered was that you first draw base, then the overlapping parts as needed (picture worth far less than thousand words):

[attachment deleted by admin]

[Roads]

For the simplest of reasons, I like fabio's idea of terrain based maintenance because it adds another level of decision making into the game.  Would it be better to go for the added expense and distance of building a road around a desert or directly across it?

Also if, and at some point, a way and/or the approval of adding resources into the game is conceived, it could provide a difficulty for obtaining that resource, e.g. salt is found in the desert isn't it?  Oh and please, please, please could we just think about a camel caravan to get that salt out of the desert?  I think in some places they still do that...but I, uh, probably just dropped off the deep end with that one...   

[emaxectranspoorte]

For the simplest of reasons, I like fabio's idea of terrain based maintenance because it adds another level of decision making into the game.  Would it be better to go for the added expense and distance of building a road around a desert or directly across it?

It depends on the circumstance provided... (in real life, IMHO).

[Roads]

It depends on the circumstance provided...

emax, I meant this merely as a rhetorical question but you have further illustrated the decision requirement.

[Fabio]

updates:

VS -- how are they going, the efforts to create a new climate system not based on height?

Not going at all. I have a finished, deterministic recipe for one part of that, the humidity, which is (imho) the hardest part wrt. planning and testing. Making this into actual Simutrans code would require some serious number crunching with Fourier transform... I am not really sure how hard that would be. In the concept demo I used plain convolution which is of course easier to do... but infinitely slower.

Even once that is in place... I can't remember outright, but the other parts were also temperature, a GUI to control these parameters, and finally combining these two into new climates, which requires changes to drawing terrain.

well, that's a pity there is no progress, i was really *looking forward* to this feature. it' would be awesome!
is there any chance to simplify the model, at the cost of losing some precision?

When I read the thread regarding this, I already wanted to ask whether (or why) you (plural) want to make ST a climate simulator.
It might be easier to first prepare the actual new implementation of climates, and later introduce additional methods of simulating their natural distribution on the map.

[Andyh]

I know that this is old topic, but i wondered whether there had been any developments?  Of all the items on the perennial Simutrans wish list this (i.e. making climates dependent on factors other than just height) is closest to my heart.

I'm impressed by some of the complex and sophisticated ideas presented in this thread, but I've had an idea buzzing around my head for some time which is a lot simpler and cruder (and therefore, I think, easier to implement).

It's based on the old geographers' concept of a relationship between elevation and latitude.  In other words if the elevation increases at a given latitude the climate changes in much the same way as it does as you travel towards the poles. The relationship between elevation and climate is already represented in the game.  The relationship between latitude and climate could be represented by creating a function which would make more northerly tiles (in the northern hemisphere) behave as if they were at higher elevations for the purpose of defining their climate.

Latitude is represented in the game by the y coordinate of a tile.  I would propose a single new variable (call it 'climate_modifier' for example) which would represent the impact of latitude on climate, ON TOP OF any impact of height on climate.  climate_modifier would be calculated for each tile as something like:

climate_modifier = int(y/k)

(actually this probably needs to be modified slightly for Northern hemisphere maps because the Simutrans origin is top-left rather than bottom-left)

where k is a user defined constant that could be defined either in the simuconf.tab file or in the new map climate dialog.  A large value for k would lead to small climate variability due to latitude and a small value of k would lead to a relatively large number of climates across the map from North to South.  For example, take a largish map with a North-South dimension of 1000 tiles, a value for k of 1000 would lead to no climate variability due to latitude (but there could still be climate variability due to height), whereas a value for k of 100 would mean the climate variability due to latitude would be the equivalent of about 10 tile heights.  If each climate zone is defined as being 2-3 heights apart then there would be around 3-5 climate zones across the map from North to South even if the map were completely flat.

The climate_modifier variable would simply be added to the height of a tile for the purpose of defining its climate.  Therefore a tile at the very bottom of a map (assuming Northern hemisphere) would (typically) have a climate_modifier of zero and its climate would only be defined by its height.  As one moves up the map towards the top the climate_modifer would get larger (at a rate defined by k) and the tiles will tend to move into relatively colder climate zones, in addition to any effect that height might have.  For example, a tile at the bottom of the map with a height of 2 might have a tropical climate, whilst a tile at the top of the map with the same height and a climate_modifier value of (say) 9 might have a tundra or alpine climate, and a mountain in the middle of the map with a height of 6 and a climate_modifier of 5 would have the same tundra or alpine climate on the top.

I think the advantage of this approach is ease of computation and, most importantly, it doesn't change the sequence of climates, so i don't believe there would be any need to change the tileset.

Hope this makes sense, would be very interested in anyone's comments/questions.

I would love to try and create a little mod to do this.  Could any of you programmers out there give me some guidance/hints as to how I might get started on doing this?

[Ashley]

http://simblob.blogspot.com/2010/01/simple-map-generation.html

This blog article is relevant to this discussion

It's something I'm working on for my own game project, using wind/rainfall to model terrain is a very simple and effective idea. You can also take it a step further, and use that rainfall to produce rivers...

On the subject of the many many tiles problem, why not just dynamically generate them and cache the results? In reality there will only be a small subset of the tiles "in play" at any one time. With the amount of RAM available nowadays this is potentially a perfectly good solution... I've got code which demonstrates rendering a tile from scratch, and I'm working on dynamic caching of the results, it's very possible (even with two-steepness terrain, enhanced tileset and multiple terrain type graphics...)

[prissi]

Simutrans currently only uses 65534 different images. Extending that is possible; another solution would be a different image class only for landscape.

For most computers this may not be an issue; but if simutrans should run on small devices, then the tiles might become an issue.

[kierongreen]

When I originally coded the texture tile system initially tiles were generated on the fly, however speed was not quick enough to use in game (it managed about 2 frames a second). That might have changed admittedly, however it would still be a major performance hit, and I'd imagine other things would have a priority in terms of cpu time than changing something which basically works fine...

[Andyh]

My original post was focused specifically on the climate model as opposed to the way tiles are rendered in a broader sense.  I think the current rendering method does work fine; you can move around large maps with ease.  The current climate model also works fine on its own terms; but if one is trying to create maps on a continental scale the ability to vary climate according to latitude (as well as height) would be a huge plus.

I would be interested in what people think to my idea above of having climate affected by a simple relationship between latitude (as represented by the y coordinate of a tile) and the climate type.  In essence I'm saying: make the climate of a tile dependent on its y and z coordinates as opposed to just the z coordinate as at present.  I think I'm right in saying that doing this would not require any expansion in the current tile set.

[jamespetts]

There is some merit in what Andyh is saying - this idea was actually discussed further back in the thread, with the idea of an "equator offset". Unless I am missing something, it would be a simple and effective way to add considerably more realism to the game.

[prissi]

Also the link above shows a very interesting system to generate climates; one that would be easily applicable to simutrans and might generate much nicer maps than now.

[Andyh]

The climate generation system shown in the link is based on the concept of moisture being blown across a relief map creating areas of relief rainfall (damp climates), and rain shadow (drier climates).  It does not take latitude into account.  This method would be very good for generating climates on a small-medium sized map; say one where the North-South dimension being modelled is no more than a few hundred kilometers.  However, by itself, it would be less good on the continental scale where climate variation is more heavily influenced by latitude.  To illustrate: differences in climate within Washington State can easily be explained by looking at moisture, wind patterns and topography (i.e. where the mountains are), but the difference in climate between Alberta and Louisiana has more to do with the fact that Alberta is a lot closer to the North Pole.

Ideally, of course we would include all these factors (i.e. latitude, elevation and wind/moisture) in a Simutrans climate model.  I'm very new to the forum, although I've been playing Simutrans for years; how can I get involved so as to move this initiative forward?  I have little to no programming skills, but I think that I could come up with some mathematical models, and perhaps provide some insights on the geographical side of things.

[jamespetts]

One other thing that would have to be considered is the scale of the map.

[prissi]

@Andyh:
Unfourtunately ideas are not lacking; programming time on the other hand is.

[Spike]

Ideally, of course we would include all these factors (i.e. latitude, elevation and wind/moisture) in a Simutrans climate model.  I'm very new to the forum, although I've been playing Simutrans for years; how can I get involved so as to move this initiative forward?  I have little to no programming skills, but I think that I could come up with some mathematical models, and perhaps provide some insights on the geographical side of things.

Then you need to find someone who shares your interest in these ideas and who can program them for you. Currently there are about three people actively coding for Simutrans, and they are all busy with other tasks, i think.

As Prissi said, ideas are plenty around Simutrans, but there are only few people who (can) do the work.

[kierongreen]

Any changes to the current model would require more tiles. The computer generated maps in the link do look nice. However I think technically it will be too tricky to implement. If you are going that far you might as well put a simple weather system in so that areas would get snow on and off through the winter, maybe have images for it raining and snowing, variable amounts of snow on the ground. It would all be great eye candy but really not much more than that.

[Andyh]

.

Any changes to the current model would require more tiles.

I don't think that this is necessarily the case.  As explained in my original post, unless I'm missing something I don't believe that a simple latitude-based climate modification of the type I describe WOULD require more tiles (because it uses the same climates and the same climate sequence as at present).

Here's what I would suggest: I've downloaded the Simutrans source code.  Would someone mind giving me a few general hints as to how to go about building a little mod?  Specifically: which files/lines contain the code which defines the climate associated with a tile?  I'll then noodle around a bit myself and see whether I can come up with something.

Thanks a lot for everyone's help and advice

[prissi]

THis is simple:

The climate is given by simworld::get_climate, found in simworld.h line 609 or so.

Code Select Expand


/**
* returns the current climate for a given height
* uses as private lookup table for speed
* @author prissi
*/
climate get_climate(sint16 height) const
{
const sint16 h=(height-grundwasser)/Z_TILE_STEP;
if(h<0) {
return water_climate;
} else if(h>=32) {
return arctic_climate;
}
return (climate)height_to_climate[h];
}


Unfourtunately for non-height dependent climate, you need to change all calls to this function (And probably  make climate instead a property of the ground).

[kierongreen]

Even a latitude based offset to climate would require more tiles. Admittedly not as many as some other systems but still 4 * 7 * 2 potentially taking into account all the climate transitions and snow. Another problem is that the new map configuration window would become more confusing as you would have to set several latitude options.

[jamespetts]

Another problem is that the new map configuration window would become more confusing as you would have to set several latitude options.

If the UI is made clear, it would not add much in the way of confusion. Additional options in the "climates" window would be a price very much worth paying for this improvement.

[TurfIt]

Mega bump... but the time is close. 


Was there any progress beyond rain4.m?

(and note: there's still a long long way to go before such maps are fully usable in Simutrans)

[kierongreen]

Interesting... I'd still keep the existing beach code myself...

[TurfIt]

The beach code is untouched. I stuck the rain4 algorithm between the "set climates in new area and old map near seam" and "bays have wide beaches" sections of karte_t::enlarge_map().

[kierongreen]

Ok just couldn't see them that far zoomed out!

[VS]

I think there wasn't any progress... I abandoned the project, as I realized that inland maps get very little water. That, of course, requires something different. I think one of Hajo's insights buried somewhere was that modelling the result of some processes does not need understanding and modelling the actual mechanics. (Essentially mechanistic vs empirical model.) So, right now, I might try some other approaches, some that ensure that the map gets enough water (as a primary goal) and then tries to distribute that in a convincing fashion. That would mean one could set amount of moisture on a map separately from terrain shape... The main method of blurred heightmaps' gradients would remain, of course.

Actually, I don't even know any more if separating temperature and moisture is the right way to go, but it still feels like the right way to do it.

Anyway, I am glad that the tinkering back then actually helped someone

There is also that inspirational page...

(heavily edited)

[TurfIt]

At first, I was also thinking inland maps vs islands were an issue, but doesn't it end up the same if you simply give the inland map a higher water_starting amount?

I've seen that page linked before. It is interesting but would only give best results imho if the whole terrain generation in simutrans was replaced. The rain algorithm was has advantage of being a simple overlay.

Attached is my crude test implementation of rain4.m. The parameters can be adjusted in the climate dialog. The enlarge map dialog has a button to open the climate settings too, and a button to rerun the rain without needing to create a new map. Note: the mediterranean, temperate, and tundra height numbers from the old system control the boundaries for the 4 height categories in the new.

The parameters seem extremely finicky. I'm rather doubting any set of sensible defaults for all maps can be obtained, but it would sure be nice if someone could find one...
I'm only using the existing 7 climates. My mapping from rain/height to these 7 doesn't seem very good. 10 climates were used above in matlab, 14 climates at the polygon map linked site. It would also be nice if someone could determine how many we really need...
Latitude/temperature is not implemented. Probably needs to be for larger maps.

Any feedback on the viability of this would be great....

[kierongreen]

I seem to get graphical errors with water transitions almost all missing? The climate distribution for the default parameters seemed ok to me, although map generation was significantly slower than before.

As for more climates - choices are really either 7 existing or 15 or 31 (not that all of those would have to be used). It wouldn't be a simple change though as a few bitfields would have to be extended from uint8s to uint16/32s.

If you actually start thinking about climate/ground types across the world you do have quite a few though...

No Vegetation: Beach, Dune, Rocky pavement, rock (maybe several types/colours)
Grassland: Tundra, Montane, Prairie/Stepp, Savannah
Scrubland: Moorland, heath, mediterranean, desert
Forest: boreal, coniferous, broadleaf,
Humid forest: cloud forest, rain forest
Wetlands: Bog, Marsh, Swamp, Mudflats

Keeping in mind that before humans came along all of a particular climate would be filled with similar vegetation, hence the need for several climates for each temperature range. That would suggest if you really wanted to go overboard on climates you should transition to 31 straight away.

[IgorEliezer]

What if climates were "coded" like a pakset object?

Something like:

Code Select Expand

obj=Climate
name=Tundra
ground=<obj_name>
vegetation[0]=<tree_name1>
vegetation[1]=<tree_name2>
ground_obj[0]=<obj_name>
terrain_roughness=<int>
...

It would allow people to define the look of the climates for their paksets, for example: kind of trees, size of forests, density, % coverage, if it has winter graphics, winter period length, terrain roughness, mean altitude...

... umm, or it's better to let people go wild?

[kierongreen]

Quick note that when I try generating maps from (large) heightmaps I get a crash in karte_t::rain4 (simworld.cc:2227). Seems to be related to deleting some variable...

[prissi]

Meanwhile OpenTTD has implemented something even more sophisticated. Including a pdf of the basics: http://www.tt-forums.net/viewtopic.php?f=33&t=71970

With the water climate, indeed rivers are not needed any more, as channels could be made from all water.

[Vladki]

Wow that's nice stuff - specially for real world height maps - it seems to generate rivers on the right place where they should be...

[Sarlock]

Interesting!  I wonder how easily that method could be ported to Simutrans...

[Isaac Eiland-Hall]

Wow, that is really amazing.