Smoother large maps

Topic: Smoother large maps (Read 11504 times) previous topic - next topic

Smoother large maps

June 07, 2009, 12:31:27 pm

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?

Re: Smoother large maps

Reply #1 – June 07, 2009, 01:19:39 pm

You just have to allow smaller values of roughness:

Code: [Select]

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

Re: Smoother large maps

Reply #2 – June 07, 2009, 01:23:55 pm

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?

Re: Smoother large maps

Reply #3 – June 07, 2009, 01:41:04 pm

Then maybe something like this works:

Code: [Select]

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;

Re: Smoother large maps

Reply #4 – June 07, 2009, 02:50:34 pm

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?

Re: Smoother large maps

Reply #5 – June 07, 2009, 03:36:56 pm

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

Re: Smoother large maps

Reply #6 – June 07, 2009, 09:26:18 pm

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

Re: Smoother large maps

Reply #7 – June 07, 2009, 09:33:24 pm

(without looking at code) The problem is that the generator creates the same level of co****ness 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.

Re: Smoother large maps

Reply #8 – June 08, 2009, 08:05:27 am

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

Re: Smoother large maps

Reply #9 – June 08, 2009, 08:51:51 am

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.

Re: Smoother large maps

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

Re: Smoother large maps

Reply #11 – June 10, 2009, 12:01:53 pm

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.

Re: Smoother large maps

Reply #12 – June 10, 2009, 12:52:52 pm

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 %).

Re: Smoother large maps

Reply #13 – June 10, 2009, 02:53:19 pm

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.

Re: Smoother large maps

Reply #14 – June 10, 2009, 03:07:53 pm

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

Re: Smoother large maps

Reply #15 – June 11, 2009, 08:56:40 am

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

Code: [Select]

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

Re: Smoother large maps

Reply #16 – June 11, 2009, 10:27:42 am

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

Re: Smoother large maps

Reply #17 – June 13, 2009, 05:59:36 pm

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 p****ed 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.

Re: Smoother large maps

Reply #18 – June 14, 2009, 09:17:00 pm

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

Re: Smoother large maps

Reply #19 – July 20, 2009, 11:58:04 pm

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.

Re: Smoother large maps

Reply #20 – July 31, 2009, 02:21:24 pm

I am still away...

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

Re: Smoother large maps

Reply #21 – July 31, 2009, 09:38:35 pm

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

Re: Smoother large maps

Reply #22 – May 02, 2010, 09:16:07 am

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