Smoother large maps

[jamespetts]

I notice that, when very large maps (>1024 in either direction) are generated, the landscape becomes quite inconsistent, with large numbers of comparatively small lakes and islands. The overall effect is quite haphazard. Conversely, when smaller maps are generated (<768 tiles), the overall shape of the land is much smoother.

Would it be possible to have landscapes of the shapes generated by smaller map sizes in larger sizes by altering the scale of the sizing calculations somewhere?

[gerw]

You just have to allow smaller values of roughness:

Code Select Expand

Index: gui/climates.cc
===================================================================
--- gui/climates.cc     (revision 2506)
+++ gui/climates.cc     (working copy)
@@ -72,7 +72,7 @@
        mountain_roughness.set_pos(koord(LEFT_ARROW,intTopOfButton) );
        mountain_roughness.set_groesse(koord(RIGHT_ARROW-LEFT_ARROW+10, 12));
#ifndef DOUBLE_GROUNDS
-       mountain_roughness.set_limits( 0, 7 );
+       mountain_roughness.set_limits( -7, 7 );
#else
        mountain_roughness.set_limits( 0, 10 );
#endif


[jamespetts]

Gerw,

thank you for that suggestion, which I have tried. It helps a small amount, but still gives (I was testing with 2048 x 2048) a blotchy finish, with lots of small bodies of water, rather than a smaller number of larger seas/oceans. Would there be any way of addressing that issue?

[gerw]

Then maybe something like this works:

Code Select Expand

Index: simtools.cc
===================================================================
--- simtools.cc (revision 2506)
+++ simtools.cc (working copy)
@@ -188,8 +188,8 @@
        const double frequency = (double)(1 << i);
        const double amplitude = pow(p, (double)i);

-       total += interpolated_noise((x * frequency) / 64.0,
-                                    (y * frequency) / 64.0) * amplitude;
+       total += interpolated_noise((x * frequency) / 64.0 / 4.,
+                                    (y * frequency) / 64.0 / 4.) * amplitude;
     }

     return total;


[jamespetts]

Gerw,

thank you for your further patch. Unfortunately, this one works a little too well, and makes smaller maps very plain. Do you think that it'd be possible to vary this effect by size of map?

[gerw]

I think it's possible, if you pass another parameter to this function.

[Isaac Eiland-Hall]

Here's a vote for allowing players to set this somewhere - I've always wanted my smaller maps to look like the larger maps, and it takes me a loooong time to find good map values

[VS]

(without looking at code) The problem is that the generator creates the same level of coarseness on absolute scale. The level of detail related to tile is still same. But when you use a larger map, it gets repeated so many times it stops looking like plausible terrain.

[The Hood]

Would a simple solution be to add height to the central parts of the map on top of the roughness generated?  If the map domes in the middle, there is less chance of the little splodgy lakes in the middle of large maps...

[VS]

Hmmmm... I prefer two continents separated by sea, to give some chance to ships It's rather that spatial frequencies should scale with (longer?) map side.

[dantedarkstar]

Or perhaps use self-similar structures for landscape ? Meaning to generate the landscape as a fractal. This way it will look still plausible on very large scale, while retaining fine structures.
Otherwise I get the feeling that just scaling spatial density by map size would create extremely smooth large maps - on small scale they would be featureless.

[gerw]

Or perhaps use self-similar structures for landscape ? Meaning to generate the landscape as a fractal. This way it will look still plausible on very large scale, while retaining fine structures.

This is the current behaviour.

[VS]

IIRC maps are currently generated with perlin noise, which is multiresolution and so should yield a roughly fractal-like structure (...I believe).

You are in principle right with the smoothness remark, but I meant something else. Allow me to clarify - perhaps I should have expressed that a bit better.

We obviously need the low frequencies to be most important as they will shape the landscape most. If you look at spectrogramm of almost anything, the energy is mostly hurdled around DC component and decreases from there. By low I mean (heh, rather guess) the ones with period in range, say, to 1/4 of map size.

We get spectrum that for some reason has high/low ratio not good. Of course that's oversimplification, shape is more important then reducing the whole spectrum to one number. But it describes the problem in a very compact way. So there are basically two options to improve this empirical ratio. Boost low or mute high. Now, we don't need to reduce the higher frequencies, only make the low ones prominent. And that only for big maps. So obviously there are hardcoded some values that don't fit well all cases.

The catch is, if frequencies are set as distances [absolutely mapped] on tile scale, with map size shifts the whole spectrum. Or to say it in another way, with larger map size the spectrum [part that still matters] expands into lower frequencies.

I suspect that there simply aren't generated low enough frequencies for big maps - only a number of fixed ones with values that used to fit the map sizes when Simutrans was still young and Pentium 300something was the epitome of speed, with 32 MB RAM. That works for smaller maps but with bigger ones the ultra-low frequencies are needed. (I remember having to play on long strips to have some distance but keep it playable.)

This is only a "table top analysis" without even a look at code - still trying to get my normal computer to work. But it should be in principle correct, as long as the code is what I think it could be. The #1 question is whether frequencies in our perlin noise are absolute (in tiles) or relative (map %).

[gerw]

The #1 question is whether frequencies in our perlin noise are absolute (in tiles) or relative (map %).

They are absolute.

[VS]

And are they fixed? I mean, do the numbers change with map size?

[gerw]

No. The frequencies are fixed and the amplitude depends on the map roughness:

Code Select Expand

double perlin_noise_2D(const double x, const double y, const double p)
{
double total = 0.0;
int i;
for(i=0; i<6; i++) {
const double frequency = (double)(1 << i);
const double amplitude = pow(p, (double)i);
total += interpolated_noise((x * frequency) / 64.0,
(y * frequency) / 64.0) * amplitude;
}
return total;
}

(x,y) are the coordinates of a point and p = 'map roughness + 8'.

[VS]

Ah, good. I will try looking at the code asap, which might be in two days. Still sorting out the dead disk... instead of fun with Simutrans :(

[VS]

It seems that there is no way to find a good set of values that would enable creation of nice big maps and not break the small ones. That is, they end up either all water or all land - and starting map seems to favour the watery variant

So, somehow the map size must be passed down the whole stack...

Gerw, I don't want to break map enlarging, so - what exactly happens when you enlarge a map? Am I reading it right that most of the code simply generates more perlin noise with same seed so that it fits - or continues the map edge if loaded from heightfield? What confuses me is that you don't have any special case for creating the map from scratch.

[gerw]

Gerw, I don't want to break map enlarging, so - what exactly happens when you enlarge a map? Am I reading it right that most of the code simply generates more perlin noise with same seed so that it fits - or continues the map edge if loaded from heightfield? What confuses me is that you don't have any special case for creating the map from scratch.

If you enlarge the map, simutrans will calculate new heights with the same seed. The result of both "creating 64x64 and enlarge to 128x128" and "create 128x128" is the same - neglecting some differences at the old border. And creating a new map is just the special case: "enlarge from 0x0 to 64x64".

[jamespetts]

Has any progress been made on this issue recently? The problem that VS described could easily be solved, I imagine, by setting the values by reference to the actual size of map that the user wishes to generate. If you could give me some of the numbers that you find work well for larger maps, I can try to plumb them into a system of checking desired map size.

[VS]

I am still away...

(Oops, the original message regarding "away" was only visible to very few people, wasn't it?)

[jamespetts]

I didn't see it... but it's good to know that this hasn't been abandoned, just delayed due to your absence :-)

[jamespetts]

Have people forgotten about this one? This enhancement would be most invaluable if it were ever included...