Skip to main content ↑ ↓
Topic: NEW CLIMATES MODEL (was: The Equatorial Wind) (Read 36978 times) previous topic - next topic

NEW CLIMATES MODEL (was: The Equatorial Wind)

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 ****ume 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

Re: The Equatorial Wind

Reply #2 –
These, together with latitude dependent darkening are on the eternal todolist.

Re: The Equatorial Wind

Reply #3 –
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...

Re: The Equatorial Wind

Reply #4 –
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.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #5 –
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 ****ume) 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.

Re: The Equatorial Wind

Reply #6 –
Quote from: Roads – on
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.

Quote from: Roads – on
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.

Quote from: Roads – on
I am clueless what you mean by "digging"
Digging - when you raise or lower land.

Quote from: Roads – on
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 ****ume) 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 m****ive 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?

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #7 –
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 m**** 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 m****ive 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. :(

Re: The Equatorial Wind

Reply #8 –
Quote from: Roads – on
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 ...

Re: The Equatorial Wind

Reply #9 –
Simutrans is slowly evolving to Matrix.    ::)

Re: The Equatorial Wind

Reply #11 –
Quote
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.

Re: The Equatorial Wind

Reply #12 –
Great ideas!!!!

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

Re: The Equatorial Wind

Reply #13 –
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?

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #14 –
yes.  ;)

Re: The Equatorial Wind

Reply #15 –
Oh! Then the simulation should be rather precise.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #16 –
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.


 

Re: The Equatorial Wind

Reply #17 –
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 :D 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 :)

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #18 –
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.

Re: The Equatorial Wind

Reply #19 –
So something like this?

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #20 –
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.

Re: The Equatorial Wind

Reply #21 –
Did I forget? Maybe not. And I learned what I am after should not be called moisture map, but precipitation... shame on me ;D

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 p****ing 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]
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 p****ing 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


My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #22 –
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?

Re: The Equatorial Wind

Reply #23 –
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...

Quote
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.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #24 –
wow, this looks really promising :)

Re: The Equatorial Wind

Reply #25 –
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?

Re: The Equatorial Wind

Reply #26 –
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 8) 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.)

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #27 –
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.

Re: The Equatorial Wind

Reply #28 –
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...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #29 –
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.

Re: The Equatorial Wind

Reply #30 –
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 cl****ifying 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!

Cl****es:

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 cl**** O(n^2) while dct has O(N log N).

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #31 –
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*

Re: The Equatorial Wind

Reply #32 –
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...


My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: The Equatorial Wind

Reply #33 –
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Re: The Equatorial Wind

Reply #34 –
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. :)