[Mod][Merged] Valleys Mapgen [valleys_mapgen]

[blert2112]

Regarding the tcave values of '1.00000' that I am/was getting. For some reason I am now getting correct values. No clue what has happened other than I deleted the old world and started a new one. I am going to clean out my build folder and start fresh just in case. Having to run cmake again is a bear, guess I should make a script instead of doing it through the gui.

[duane]

Yes this.
Beyond the y values the cave noise threshold is smoothly increased to taper the caves down to nothing.
So the threshold will be mostly 0.6, but near the top and base limits it will increase.

Why is the lower limit 33000? I thought the map limit was 31000.

[duane]

Regarding the tcave values of '1.00000' that I am/was getting. For some reason I am now getting correct values. No clue what has happened other than I deleted the old world and started a new one. I am going to clean out my build folder and start fresh just in case. Having to run cmake again is a bear, guess I should make a script instead of doing it through the gui.

Strange....

All I ever do with cmake is "make clean; cmake . -DRUN_IN_PLACE=TRUE". I didn't know it had a gui.

[blert2112]

... I didn't know it had a gui.

"cmake-gui" - It is pulled in with QT so will have to install that.

I don't think that the lower limit should be hardcoded into the massive caves code...

Code: Select all

#define MASSIVE_CAVE_YBLMIN    -32808  // -33000 + MASSIVE_CAVE_BLEND * 1.5

... because it can be changed in minetest.conf...

Code: Select all

#    Where the map generator stops.
#    Please note:
#    -    Limited to 31000 (setting above has no effect)
#    -    The map generator works in groups of 80x80x80 nodes (5x5x5 MapBlocks).
#    -    Those groups have an offset of -32, -32 nodes from the origin.
#    -    Only groups which are within the map_generation_limit are generated
#    type: int min: 0 max: 31000
# map_generation_limit = 31000

... If I set map_generation_limit = 10000, for a small world, the cave generation will be thrown off when you get to the bottom of the world.

[duane]

Here's a fun place to start. You only have a few trees, but there's lots of sparkling water, colorful reefs, several deep caves, and goblins playing in the surf. Watch out for the crocodiles!

map seed: 7708629960368984241

[duane]

I don't think that the lower limit should be hardcoded into the massive caves code...

Ok, how about this?

Code: Select all

diff --git a/src/mapgen_valleys.cpp b/src/mapgen_valleys.cpp
index 85df4cc..c29cc35 100644
--- a/src/mapgen_valleys.cpp
+++ b/src/mapgen_valleys.cpp
@@ -75,6 +75,10 @@ MapgenValleys::MapgenValleys(int mapgenid, MapgenParams *params, EmergeManager *
        this->heatmap   = NULL;
        this->humidmap  = NULL;
 
+       this->map_gen_limit = MYMIN(MAX_MAP_GENERATION_LIMIT,
+                       g_settings->getU16("map_generation_limit"));
+       printf("mgl: %f\n", this->map_gen_limit);
+
        MapgenValleysParams *sp = (MapgenValleysParams *)params->sparams;
        this->spflags = sp->spflags;
 
@@ -842,7 +846,7 @@ void MapgenValleys::generateCaves(s16 max_stone_y)
 
        v3s16 em = vm->m_area.getExtent();
 
-       float yblmin = MASSIVE_CAVE_YBLMIN;
+       float yblmin = -map_gen_limit + MASSIVE_CAVE_BLEND * 1.5f;
        float yblmax = massive_cave_depth - MASSIVE_CAVE_BLEND * 1.5f;
        bool made_a_big_one = false;
        float tcave_cache[csize.Y + 2];
@@ -864,11 +868,11 @@ void MapgenValleys::generateCaves(s16 max_stone_y)
        // This allows random lava spawns to be less common at the surface.
        s16 lava_chance = pow(lava_features, 3)
                * ceil((lava_max_height - node_min.Y + 1)
-                               * 10.f / MAX_MAP_GENERATION_LIMIT);
+                               * 10.f / map_gen_limit);
        // This allows random water spawns to be more common at the surface.
        s16 water_chance = pow(water_features, 3)
-               * ceil((MAX_MAP_GENERATION_LIMIT - abs(node_min.Y) + 1)
-                               * 10.f / MAX_MAP_GENERATION_LIMIT);
+               * ceil((map_gen_limit - abs(node_min.Y) + 1)
+                               * 10.f / map_gen_limit);
 
        u32 index_2d = 0;
        u32 index_3d = 0;
diff --git a/src/mapgen_valleys.h b/src/mapgen_valleys.h
index 7b338c7..fb3c0cd 100644
--- a/src/mapgen_valleys.h
+++ b/src/mapgen_valleys.h
@@ -36,7 +36,6 @@ with this program; if not, write to the Free Software Foundation, Inc.,
 
 // Cave blend distance near YMIN, YMAX
 #define MASSIVE_CAVE_BLEND     128.f
-#define MASSIVE_CAVE_YBLMIN    -32808  // -33000 + MASSIVE_CAVE_BLEND * 1.5
 
 class BiomeManager;
 
@@ -113,6 +112,8 @@ class MapgenValleys : public Mapgen {
        int ystride;
        int zstride;
 
+       float map_gen_limit;
+
        u32 spflags;
        bool humid_rivers;
        bool use_altitude_chill;

It doesn't seem to have any problems with a map_generation_limit of 2000. Below that, massive caves are really hard to locate.

[paramat]

Why is the lower limit 33000? I thought the map limit was 31000.

It is, maybe i set that in the mod to make the caves open to the base of the world instead of tapering. You may want to set it differently, probably a good idea to stop liquids collectng on the void of ignore at world base.

[duane]

Does anyone actually use the altitude_chill setting, separate from increasing or decreasing terrain size? I was considering ways to simplify the C++ mapgen settings, and it occurs to me that I've never had any interest in raising or lowering the snow line, so I thought it might make sense to adjust it automatically by the terrain noise.

Edit: Disregard. We've decided to keep it.

As a side-effect of looking for settings to remove, I think I've finally managed to get the humidity code right.

[duane]

Those who've been following Valleys, may have noticed with dismay that the "fast" option has been removed from the latest pull request. Never fear! I've started the fast branch to give you the ultimate in Valleys...ish speed.

At the moment, I'm generating chunks in about 18% the time it takes the valleys C++ mapgen to generate comparable terrain -- that's more than five times faster, and it still looks cool!*



Of course there are drawbacks. There are always drawbacks, are there not? In order to achieve these mind-bending speeds, I had to limit cave creation to well below the surface. You'll have to dig down about a hundred meters to find any, but once you get there, you'll find all of the V5 caves.

*YMMV

[duane]

Good news, everyone!

Pull request 83583aa is now part of the baseline code. This replaces valleys mapgen's simple caves with the standard V5 caves, including noise-based random caves, large caves with pools, and GIGANTO-CAVES. You have the option of enabling randomly placed water and lava in the settings or taking bare caves with lava and water appearing only as pools in large caves. The settings are (hopefully) simpler now in general.

Two understated but powerful improvements may not immediately catch your attention: The humidity handling is now much closer to the original Valleys Mapgen (and behaves more reasonably as a result). Also, cave noises aren't generated for chunks that don't need them, resulting in about a 15% speed increase at ground level (on my computer).

[Fixer]

- deleted (bug was fixed) -

[Fixer]

I'm playing latest GIT and I have strange feeling that RNG is forcing jungles on me, lots of jungles near rivers.
Examples:
https://i.imgur.com/c2thPXG.jpg (apples, aspen inside jungles o.O)
https://i.imgur.com/jONZNWX.jpg (jungles on river shores in ... savanna, actually I see it in your screenshot above too %))
https://i.imgur.com/9Nfh9c3.jpg

[duane]

I'm playing latest GIT and I have strange feeling that RNG is forcing jungles on me, lots of jungles near rivers.

That's very likely. The game picks the biome that has the closest combination of temperature and humidity, so it's going to pick jungles where both are high (low areas, near rivers or basins where the water table is high).

[duane]

I've put in a pull request to add two gennotify events for massive caves, which return two vectors outlining the smallest cube containing all of the massive cave within each chunk. That's about the most useful information I can give back to lua.

With that, you can guess about where the cave runs. For example, if the stated cube is above the bottom of the chunk, you're probably looking at a floor. I've already used the notify events just to tell me that a massive cave exists, so my valleys_c cave biomes don't get flooded by random water or lava.

Edit: I think we're going to go with just a notification that a massive cave exists, to save processing time.

Is this a secret goblin airfield? Enquiring minds want to know!

[Fixer]

Since last humidity changes my favourite place suffered some climate changes :) Yes, jungles yet again. This kind of jungle blend feels really strange and off balance. BTW, second screenshot features Filmic HDR PR (much better colours ingame).

Before:


After:


Also:

Here's a fun place to start. You only have a few trees, but there's lots of sparkling water, colorful reefs, several deep caves, and goblins playing in the surf. Watch out for the crocodiles!

Even more fun... since they are desert ones now... bare sand.

[duane]

Since last humidity changes my favourite place suffered some climate changes :) Yes, jungles yet again. This kind of jungle blend feels really strange and off balance. BTW, second screenshot features Filmic HDR PR (much better colours ingame).

It's definitely different, and I was concerned too, but I'm sure that the way I was doing things before was worse. For one thing, I'd completely screwed up the code for my version of river humidity so that it was always dominant. (In fact, I only had to put it in because I didn't translate the humidity code from lua to C++ correctly.) At the moment, the only theoretical differences between the lua version and the C++ version are:
(1) an increase in humidity near the ocean in the lua (which wouldn't help here, and would mess up the default game's beaches)
(2) lua code that decreases humidity for thinner soil (This is problematic using the v7 biomes and would only affect higher altitudes.)
(3) humidity changes based on soil type noises (I can't add anything like that in the C++)
(4) An offset of -20% to make the average closer to the noise
(5) the humidity noise.

Now, I've been running code to analyze the average humidity of all chunks that I generate, and they turn out a little higher than what the humidity noise is set to (about +8%). I wanted to err on that side since trees are so important, and it's easy to wipe them all out with a small change.

You also have to consider that if the temperature is high enough, you're going to get stuck with either savanna or jungle at low altitudes, and the rivers are usually lower than anything else in the region. The altitude chill code is also offset enough to make the average temperature about what the noise is set to, but of course, that means that lower is hotter.

What would you suggest needs to be done? Does bumping the noise offsets for humidity and temperature down help or does that just cause problems in the highlands?

Even more fun... since they are desert ones now... bare sand.

Yes, that was annoying, and quite the opposite of what I expected.

Here's the relevant code from C++:

Code: Select all

noise_humidity->result[index_2d] *= (1 + pow(0.5f, MYMAX((surface_max_y 	- noise_rivers->result[index_2d]) / 3.f, 0.f))) * humidity_offset;

and here from the lua:

Code: Select all

function vmg.get_humidity_raw(pos)
	local v13 = vmg.get_noise(pos, 13) -- Clayey soil : wetter
	local v15 = vmg.get_noise(pos, 15) -- Sandy soil : drier
	local v18 = vmg.get_noise(pos, 18) -- Humidity noise
	return 2 ^ (v13 - v15 + v18 * 2) -- Make sure that humidity is positive. Humidity is between 0.25 and 16.
end

function vmg.get_humidity(pos)
	local y = pos.y
	local flatpos = pos2d(pos)
	local hraw = vmg.get_humidity_raw(flatpos)

	-- Another influence on humidity: Dirt thickness, because when the dirt layer is very thin, the soil is drained.
	local v7 = vmg.get_noise(flatpos, 7)
	local thickness = math.max(v7 - math.sqrt(math.abs(y)) / dirt_reduction, 0) -- Positive
	local soil_humidity = hraw * (1 - math.exp(-thickness - 0.5)) -- Yes I love exponential-like functions. You can modelize whatever you want with exponentials !!!

	-- Get base ground level to know the river level that influences humidity
	local v1 = vmg.get_noise(flatpos, 1)
	local v3 = vmg.get_noise(flatpos, 3) ^ 2
	local base_ground = v1 + v3
	local sea_water = 0.5 ^ math.max((y - water_level) / 6, 0) -- At the sea level, sea_water is 1. Every 6 nodes height divide it by 2.
	local river_water = 0.5 ^ math.max((y - base_ground) / 3, 0) -- At the river level, river_water is 1. Every 3 nodes height divide it by 2.
	local water = sea_water + (1 - sea_water) * river_water -- A simple sum is not satisfactory, because it may be bigger than 1.
	return soil_humidity * (1 + water)
end

In this case, surface_max_y corresponds to pos.y and noise_rivers has base_ground stored in it (since base_ground models the water table). Some of the lua is necessary to get base_ground, but I threw a lot of it out because it's not practical in a C++ mapgen. Still, the missing code should have a small effect overall.

What I was doing previously was a botched version of the above balanced with an exponential function using the valley variable (equal to surface_max_y - noise_rivers) multiplied by the base humidity but limited by a magic number that had to be chosen for each game (ethereal required a different limit than the default game, for example). By mistake, the latter was always dominant. When paramat pointed out that the magic number was difficult to explain to players (and hard to justify anyway), I took another look at the code and realized how far off it still was from the original.

One thing that I've considered is trying to add the variation to base humidity rather than multiplying. Intuitively, that seems better to me, though I've no idea why. However, a simple version:

Code: Select all

			noise_humidity->result[index_2d] += 50 * (1 + pow(0.5f, MYMAX((surface_max_y - noise_rivers->result[index_2d]) / 3.f, 0.f))) * humidity_offset - 50;

gives me pretty much the same result in this case:

[TheReaperKing]

Congratulations on having your work added to the official version!!!

[Fixer]

Does bumping the noise offsets for humidity and temperature down help or does that just cause problems in the highlands?

Maybe adjusting those parameters will eliminate jungles at least in those alien biomes (also in deep forested valleys). Will be interesting to see what are side effects of that. Highlands seems good right now. Maybe that +8% humidity problem is a problem, dunno. Jungles like rivers a lot in a lot of biomes, it seems, I've walked yesterday in valleys for hours on different worlds, maybe it is impression from my experience, that in MT jungles are scarce, now it is super easy to find jungle tree, a lot of them (usually near rivers).

From "Look and Feel" standpoint it feels strange for sure, but that's only my impression and I can be wrong.
Just look from the above: https://i.imgur.com/TV3cse0.jpg Is this even realistic? %) It is every kind of tree in one place, and altitude difference is small and area is small. IIRC jungles are located in high humidity hot areas that exclude other kinds of trees, on the edges humidity goes down but hot remains, so there starts savannah... imo

Savannah sometimes have jungles in rivers, sometimes not, I'm good with that, but it feels like when savannah river has jungles, they are too dense, they are not scarce, but they should be (yes, it is more humid, but it is savannah!)

For me, main problem is river trees selection, it seems.

Found even more crazier place on your ocean island seed: https://i.imgur.com/ngchh5G.jpg

[duane]

Congratulations on having your work added to the official version!!!

Thanks from all of us involved.

Maybe adjusting those parameters will eliminate jungles at least in those alien biomes (also in deep forested valleys).

Try running this and tell me what you think:

Code: Select all

mg_valleys_spflags = noaltitude_chill,nohumid_rivers

[Gael de Sailly]

February 8th 2015, first line of VMG's code. A year on, already.

[duane]

February 8th 2015, first line of VMG's code. A year on, already.

Happy birthday, Valleys!

[duane]

After batting my head against the new plant api for weeks, I've made some changes that seems to give me better results.



I think the cover property is unnecessary (and complicating things). I've removed it and added a check for shade to keep trees from growing into each other (mostly). Now ground-cover can be set to high density and low priority, and show up everywhere. If anyone would like to try this (very experimental) change, please let me know what you think. You can download it here:

https://github.com/Gael-de-Sailly/valle ... plants.zip

As always, this works with either the all-lua or C++ Valleys.

[Fixer]

Code: Select all

mg_valleys_spflags = noaltitude_chill,nohumid_rivers

I think it is not good with those, also weird thought come to me: i can actually outrun the mapgen when fast fly is enabled, is it ok?

[duane]

Code: Select all

mg_valleys_spflags = noaltitude_chill,nohumid_rivers

I think it is not good with those, also weird thought come to me: i can actually outrun the mapgen when fast fly is enabled, is it ok?

Can you be more specific?

[Fixer]

noaltitude_chill adds jungles and savanna trees (and other things) to high altitude mountains, not good.
Hmm, I will look at nohumid_rivers alone.