News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Smoother large maps

Started by jamespetts, June 07, 2009, 12:31:27 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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

gerw

You just have to allow smaller values of roughness:

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

gerw

Then maybe something like this works:

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

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.

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!

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.

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!

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.
Links+Tutorial: Make heightmap of any part of world !
http://forum.simutrans.com/index.php?topic=2210.0

gerw

Quote from: dantedarkstar on June 10, 2009, 11:35:53 AM
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 %).

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!

gerw

Quote from: VS on June 10, 2009, 12:52:52 PM
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?

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!

gerw

No. The frequencies are fixed and the amplitude depends on the map roughness:
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 :(

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!

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 :D

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.

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!

gerw

Quote from: VS on June 13, 2009, 05:59:36 PM
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.
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.

VS

I am still away...

(Oops, the original message regarding "away" was only visible to very few people, wasn't 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!

jamespetts

I didn't see it... but it's good to know that this hasn't been abandoned, just delayed due to your absence :-)
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.

jamespetts

Have people forgotten about this one? This enhancement would be most invaluable if it were ever included...
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.