[Mod][Merged] Valleys Mapgen [valleys_mapgen]
-
- Member
- Posts: 1233
- Joined: Tue Oct 23, 2012 12:59
- GitHub: Dragonop
- IRC: Dragonop
- In-game: Dragonop
- Location: Argentina
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
This needs to be ported and merged on the minetest engine, this mapgen is just amazing.
- philipbenr
- Member
- Posts: 1897
- Joined: Fri Jun 14, 2013 01:56
- GitHub: philipbenr
- IRC: philipbenr
- In-game: robinspi
- Location: United States
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
So much update too little time. I love this magpen please keep up progress.
-
- Member
- Posts: 121
- Joined: Fri Aug 28, 2015 13:55
- GitHub: Minerz
- IRC: Minerz
- In-game: MinerMan
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
Wow, Gael de Sailly. What a mod!
-Minerz
-Minerz
- Napiophelios
- Member
- Posts: 1035
- Joined: Mon Jul 07, 2014 01:14
- GitHub: Napiophelios
- IRC: Nappi
- In-game: Nappi
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
I hope not, its slower than christmas.Dragonop wrote:This needs to be ported and merged on the minetest engine, this mapgen is just amazing.
-
- Member
- Posts: 121
- Joined: Fri Aug 28, 2015 13:55
- GitHub: Minerz
- IRC: Minerz
- In-game: MinerMan
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
Wait... does this mod have VILLAGES?!
- Napiophelios
- Member
- Posts: 1035
- Joined: Mon Jul 07, 2014 01:14
- GitHub: Napiophelios
- IRC: Nappi
- In-game: Nappi
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
No.Minerz wrote:Wait... does this mod have VILLAGES?!
try https://github.com/Ekdohibs/mg by nore
or
https://github.com/Sokomine/mg_villages fork by Sokomine
-
- Member
- Posts: 115
- Joined: Sun Feb 22, 2015 07:11
- GitHub: melzua
- IRC: melzua
- In-game: melzua
- Location: Catalonia
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
Did you tried the lua mod or the minetest engine's duane fork? The last one isn't slower than christmas, and anyway this would be a new mapgen option like v5, v6, v7 or singlenode, not a default mapgen for all.Napiophelios wrote:I hope not, its slower than christmas.Dragonop wrote:This needs to be ported and merged on the minetest engine, this mapgen is just amazing.
- Gael de Sailly
- Member
- Posts: 845
- Joined: Sun Jan 26, 2014 17:01
- GitHub: gaelysam
- IRC: Gael-de-Sailly
- In-game: Gael-de-Sailly gaelysam
- Location: Voiron, France
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
I don't know much about licenses. What's different in fact between the licenses ?duane wrote:Gael de Sailly would have to relicense it. The minetest license isn't compatible with gpl3, as I understand it.Ivà wrote:This mapgen should be merged into the main engine as the fifth option, really.
Just realize how bored we would be if the world was perfect.
- duane
- Member
- Posts: 1715
- Joined: Wed Aug 19, 2015 19:11
- GitHub: duane-r
- Location: Oklahoma City
- Contact:
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
viewtopic.php?f=11&t=1271Gael de Sailly wrote:I don't know much about licenses. What's different in fact between the licenses ?
If a mod is to be included in the main game, it's code needs to be relicensable under LGPLv2.1+, and textures/sounds under CC BY-SA 3.0 Unported, as the main game is released under those licenses. Notably, WTFPL (for anything), BSD (for code) are perfectly compatible with this. Notably, LGPLv3+ and GPLv3+ for code is not compatible with this.
Believe in people and you don't need to believe anything else.
- Napiophelios
- Member
- Posts: 1035
- Joined: Mon Jul 07, 2014 01:14
- GitHub: Napiophelios
- IRC: Nappi
- In-game: Nappi
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
No I last tried the mapgen when version 2.0 came out, I think.Ivà wrote:Did you tried the lua mod or the minetest engine's duane fork? The last one isn't slower than christmas, and anyway this would be a new mapgen option like v5, v6, v7 or singlenode, not a default mapgen for all.Napiophelios wrote:I hope not, its slower than christmas.Dragonop wrote:This needs to be ported and merged on the minetest engine, this mapgen is just amazing.
I am a big fan of Gael de Sailly's awesome forests,
so I will definitely try the fork by Duane.
-
- Member
- Posts: 115
- Joined: Sun Feb 22, 2015 07:11
- GitHub: melzua
- IRC: melzua
- In-game: melzua
- Location: Catalonia
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
Do you know why I'm getting transparent nodes? They are default:stone, and it happens with the last git client and server.
Spoiler
- Attachments
-
- screenshot_20150920_075821.png (762.95 KiB) Viewed 1705 times
- paramat
- Developer
- Posts: 3700
- Joined: Sun Oct 28, 2012 00:05
- GitHub: paramat
- IRC: paramat
- Location: UK
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
Lua or C++ version? Sure it's default:stone? stone seems visible in the river banks. Try digging the riverbed node to see what it is. This usually happens in a core mapgen when a node is left undefined.
If this is the C++ version this may be because the biome generation code needs editing in a river mapgen, see my changes to 'generate biomes' in my own core river mapgen https://github.com/paramat/minetest/com ... ae3e43R445 lines 464 481 505 526 duane you will need these changes to trigger biome calculation and to work with river water.
If this is the C++ version this may be because the biome generation code needs editing in a river mapgen, see my changes to 'generate biomes' in my own core river mapgen https://github.com/paramat/minetest/com ... ae3e43R445 lines 464 481 505 526 duane you will need these changes to trigger biome calculation and to work with river water.
-
- Member
- Posts: 115
- Joined: Sun Feb 22, 2015 07:11
- GitHub: melzua
- IRC: melzua
- In-game: melzua
- Location: Catalonia
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
C++ version, I've found default:stone and default:dirt. I have a server with the latest git version, so you can see it for yourself if you want: mtdig.zapto.org:3000paramat wrote:Lua or C++ version? Sure it's default:stone? stone seems visible in the river banks. Try digging the riverbed node to see what it is. This usually happens in a core mapgen when a node is left undefined.
- duane
- Member
- Posts: 1715
- Joined: Wed Aug 19, 2015 19:11
- GitHub: duane-r
- Location: Oklahoma City
- Contact:
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
That's probably because I used a new node for the river bottoms -- river mud. It's there because I couldn't think of a clever way to keep non-water plants (trees) from spawning in the rivers. One or two might be ok, but they were everywhere.Ivà wrote:C++ version, I've found default:stone and default:dirt. I have a server with the latest git version, so you can see it for yourself if you want: mtdig.zapto.org:3000
The changes to games/minetest_game/mods/default/nodes.lua are in the mapgen on git (where they don't belong), just to keep things simpler for now. They're probably not overwriting your copy of the game file out of a sensible desire by git to avoid clobbering another project.
Edit: I just added a check for the new nodes and sensible defaults, but of course you'll get trees in your rivers without them.
Last edited by duane on Mon Sep 21, 2015 08:57, edited 1 time in total.
Believe in people and you don't need to believe anything else.
- duane
- Member
- Posts: 1715
- Joined: Wed Aug 19, 2015 19:11
- GitHub: duane-r
- Location: Oklahoma City
- Contact:
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
The c++ version of vmg is now feature-complete, at least as far as I'm concerned. It creates terrain according to the original algorithm, carves and fills rivers, generates caves, water, and lava underground, generates v7 dungeons, chooses biomes and populates areas based on them, and places ore and decorations (plants). It does not use different types of dirt, or create vmg-style trees -- features which properly belong to biomes or mods.
It has numerous options for adjusting temperature, humidity, river, and underground features. All noise maps can be customized in the configuration file. Biomes are fully supported. You can choose to use v7 caves instead of vmg's. You can also skip several computationally expensive functions by specifying the "fast" flag, which makes it run... faster anyway.
It already requires a few changes to the default game mod, to support a few new nodes. These were compromises to avoid problems with the existing biome code, and I'm still trying to think of good ways around them. However, I'm going to create a mod to go with it to try to adapt the default biomes. There's no way that I know to make them all work exactly the same, other than using voxelmanip to do it all -- which is definitely an option, but bear in mind that my goal is compatibility, not fidelity.
In the future, I'll be debugging and (hopefully) optimizing the code, and trying to get the last features added as lua. The code is here, if you want to compile it and try it out:
https://github.com/duane-r/minetest
Edit: Thanks to paramat, I've removed one of the new nodes. I might move the stalagmites and stalactites out of the mapgen -- it looks just as easy to do them in lua. That will obviate any need to change the default game.
It has numerous options for adjusting temperature, humidity, river, and underground features. All noise maps can be customized in the configuration file. Biomes are fully supported. You can choose to use v7 caves instead of vmg's. You can also skip several computationally expensive functions by specifying the "fast" flag, which makes it run... faster anyway.
It already requires a few changes to the default game mod, to support a few new nodes. These were compromises to avoid problems with the existing biome code, and I'm still trying to think of good ways around them. However, I'm going to create a mod to go with it to try to adapt the default biomes. There's no way that I know to make them all work exactly the same, other than using voxelmanip to do it all -- which is definitely an option, but bear in mind that my goal is compatibility, not fidelity.
In the future, I'll be debugging and (hopefully) optimizing the code, and trying to get the last features added as lua. The code is here, if you want to compile it and try it out:
https://github.com/duane-r/minetest
Edit: Thanks to paramat, I've removed one of the new nodes. I might move the stalagmites and stalactites out of the mapgen -- it looks just as easy to do them in lua. That will obviate any need to change the default game.
Last edited by duane on Mon Sep 21, 2015 13:22, edited 1 time in total.
Believe in people and you don't need to believe anything else.
-
- Member
- Posts: 115
- Joined: Sun Feb 22, 2015 07:11
- GitHub: melzua
- IRC: melzua
- In-game: melzua
- Location: Catalonia
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
It now runs the latest git version with the nodes.lua from your git repo and it seems ok (I'm on my mobile and can not test it properly). I used the default mgdjr_spflags to generate the map.duane wrote:That's probably because I used a new node for the river bottoms -- river mud. It's there because I couldn't think of a clever way to keep non-water plants (trees) from spawning in the rivers. One or two might be ok, but they were everywhere.Ivà wrote:C++ version, I've found default:stone and default:dirt. I have a server with the latest git version, so you can see it for yourself if you want: mtdig.zapto.org:3000
Thanks for your work!
- duane
- Member
- Posts: 1715
- Joined: Wed Aug 19, 2015 19:11
- GitHub: duane-r
- Location: Oklahoma City
- Contact:
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
Ah! Sand. That solves the problem much more neatly, and I put your changes in as well, thanks.paramat wrote:If this is the C++ version this may be because the biome generation code needs editing in a river mapgen, see my changes to 'generate biomes' in my own core river mapgen https://github.com/paramat/minetest/com ... ae3e43R445 lines 464 481 505 526 duane you will need these changes to trigger biome calculation and to work with river water.
Believe in people and you don't need to believe anything else.
- duane
- Member
- Posts: 1715
- Joined: Wed Aug 19, 2015 19:11
- GitHub: duane-r
- Location: Oklahoma City
- Contact:
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
These trees were generated entirely from four schematics. I think they look as good as any created with voxelmanip, and they're faster (though not as fast as the stock trees). Plus the decoration system does all the work of planting them.
Spoiler
Believe in people and you don't need to believe anything else.
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
The trees look nice.
Many of my mods are now a part of Minetest-mods. A place where you know they are maintained!
A list of my mods can be found here
A list of my mods can be found here
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
This is awesome! I've added support for it to Lord of the Test, and here are some screenshots of the result: https://imgrush.com/c8680d1c6ef5 and https://imgrush.com/1OF2M95rfjWa.png
- kaadmy
- Member
- Posts: 706
- Joined: Thu Aug 27, 2015 23:07
- GitHub: kaadmy
- IRC: KaadmY
- In-game: KaadmY kaadmy NeD
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
Agreed! The mapgen in Lua is too slow to play normally, and making it C++ would be great.Ivà wrote:This mapgen should be merged into the main engine as the fifth option, really. It provides a realistic terrain that is a lot more interesting than v6 and less fantasious than v5 or v7, for those who prefer that style of land.
Keep up the good work!
- kaadmy
- Member
- Posts: 706
- Joined: Thu Aug 27, 2015 23:07
- GitHub: kaadmy
- IRC: KaadmY
- In-game: KaadmY kaadmy NeD
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
Wow. I downloaded/compiled and it looks great!
One thing I noticed though, is that it won't start a singleplayer(Or multiplayer?) world if the setting keymap_autorun is not set. Is that required in default, or just this branch>
One thing I noticed though, is that it won't start a singleplayer(Or multiplayer?) world if the setting keymap_autorun is not set. Is that required in default, or just this branch>
- duane
- Member
- Posts: 1715
- Joined: Wed Aug 19, 2015 19:11
- GitHub: duane-r
- Location: Oklahoma City
- Contact:
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
Whoops. That's my autorun code, ala world of warcraft. I hate having to hold the forward key all the time. I'll have to fix that since it's causing problems.kaadmy wrote:Wow. I downloaded/compiled and it looks great!
One thing I noticed though, is that it won't start a singleplayer(Or multiplayer?) world if the setting keymap_autorun is not set. Is that required in default, or just this branch>
Edit: Done. It has a default now -- the F key.
Believe in people and you don't need to believe anything else.
- duane
- Member
- Posts: 1715
- Joined: Wed Aug 19, 2015 19:11
- GitHub: duane-r
- Location: Oklahoma City
- Contact:
Valleys Mapgen Support
I've uploaded my working support files to github. This project is intended to add the features of vmg that don't belong in C++ to the C++ project.
Here you'll find a file called traditional.lua, which is basically a skeleton for doing voxelmanip changes after the c++ mapgen has created the world. It loads the heightmap, heatmap, and humiditymap created in C++, verifies the correct ground level (heightmap seems to change randomly, possibly because it hasn't actually been completed before control is handed to lua -- I'm not sure), and calls a function which could handle decorations.
I don't like this file, because my goal for this side project was to be compatible, and going back to placing everything directly is counter to that aim. It would be better if we use the biome and decoration managers whenever possible. Of course, there are drawbacks to that.
I intend to drop all of the vmg tree generation in the final product. I've already proved to my satisfaction that schematics can do the job as well or better. In the deco.lua file, I've put code to create schematics programmatically. All the lua processing is done before the first voxel of the world is created, then the C code in the game does the actual handling of the trees, more quickly than you could manage with lua.
I've copied a lot of the decoration and biome data from the default mods, because I had trouble making changes to them without everything spawning everywhere at once, as though there weren't any biomes. I suspect there's a way around that, and we'll be able to remove that code eventually.
Here you'll find a file called traditional.lua, which is basically a skeleton for doing voxelmanip changes after the c++ mapgen has created the world. It loads the heightmap, heatmap, and humiditymap created in C++, verifies the correct ground level (heightmap seems to change randomly, possibly because it hasn't actually been completed before control is handed to lua -- I'm not sure), and calls a function which could handle decorations.
I don't like this file, because my goal for this side project was to be compatible, and going back to placing everything directly is counter to that aim. It would be better if we use the biome and decoration managers whenever possible. Of course, there are drawbacks to that.
I intend to drop all of the vmg tree generation in the final product. I've already proved to my satisfaction that schematics can do the job as well or better. In the deco.lua file, I've put code to create schematics programmatically. All the lua processing is done before the first voxel of the world is created, then the C code in the game does the actual handling of the trees, more quickly than you could manage with lua.
I've copied a lot of the decoration and biome data from the default mods, because I had trouble making changes to them without everything spawning everywhere at once, as though there weren't any biomes. I suspect there's a way around that, and we'll be able to remove that code eventually.
Last edited by duane on Sun Oct 04, 2015 06:28, edited 3 times in total.
Believe in people and you don't need to believe anything else.
- duane
- Member
- Posts: 1715
- Joined: Wed Aug 19, 2015 19:11
- GitHub: duane-r
- Location: Oklahoma City
- Contact:
Re: [Mod][WIP] Valleys Mapgen [valleys_mapgen]
For those of you who are looking for speed in the C++ version of valleys, I have some good news. The short of it is, use the v7 caves (v7caves flag).
I did some simple profiling. Almost all of the mapgen's functions are called from makeChunk, the heart of the code which actually generates the terrain. I put some cpu time checks through it and got results like this:
T1: 2279078.0181818 calculate_noise (Yike!)
T2: 24672.563636364
T3: 3223.7909090909
T4: 36025.409090909
T5: 51817.645454545
T6: 6307.8272727273
T7: 5776.9636363636
T8: 27691.436363636
T9: 8536.3727272727
T10: 759692.98181818 update liquids and light maps
Notice that calculate_noise is using two orders of magnitude more time than anything else except liquid and light handling (which I can't do much about). So that's our problem area. I immediately did the same thing for that function:
T1: 1524947.6870229 actual perlinMap calls
T2: 310.32061068702
T3: 10171.938931298 all the fancy math
That opened my eyes. I thought the math was going to be a problem, but it's all the perlin noise maps that are killing us. Here's the entirety of the code involved.
The 3D maps are taking the bulk of the time since all the maps have the same dimensions, and those are exclusively involved in cave generation. So I ran a quick check with mg_flags = nocaves set. Time spent generating map chunks dropped by a factor of more than a hundred. Setting mgdjr_spflags = v7caves was just about as fast. Maybe verson 7's noise maps are more efficient.
The bad news is that liquid and light handling are taking more than ten times as much time as anything else after that. So, there's probably not much to be done to speed everything up past the cave issue.
I did some simple profiling. Almost all of the mapgen's functions are called from makeChunk, the heart of the code which actually generates the terrain. I put some cpu time checks through it and got results like this:
T1: 2279078.0181818 calculate_noise (Yike!)
T2: 24672.563636364
T3: 3223.7909090909
T4: 36025.409090909
T5: 51817.645454545
T6: 6307.8272727273
T7: 5776.9636363636
T8: 27691.436363636
T9: 8536.3727272727
T10: 759692.98181818 update liquids and light maps
Notice that calculate_noise is using two orders of magnitude more time than anything else except liquid and light handling (which I can't do much about). So that's our problem area. I immediately did the same thing for that function:
T1: 1524947.6870229 actual perlinMap calls
T2: 310.32061068702
T3: 10171.938931298 all the fancy math
That opened my eyes. I thought the math was going to be a problem, but it's all the perlin noise maps that are killing us. Here's the entirety of the code involved.
Code: Select all
noise_filler_depth->perlinMap2D(x, z);
noise_heat->perlinMap2D(x, z);
noise_humidity->perlinMap2D(x, z);
noise_heat_blend->perlinMap2D(x, z);
noise_humidity_blend->perlinMap2D(x, z);
// vmg noises
noise_terrain_height->perlinMap2D(x, z);
noise_rivers->perlinMap2D(x, z);
noise_valley_depth->perlinMap2D(x, z);
noise_valley_profile->perlinMap2D(x, z);
noise_inter_valley_slope->perlinMap2D(x, z);
if (flags & MG_CAVES) {
if (spflags & MGDJR_V7_CAVES) {
noise_v7_caves_1->perlinMap3D(x, y, z);
noise_v7_caves_2->perlinMap3D(x, y, z);
} else {
noise_caves_1->perlinMap3D(x, y, z);
noise_caves_2->perlinMap3D(x, y, z);
noise_caves_3->perlinMap3D(x, y, z);
noise_caves_4->perlinMap3D(x, y, z);
noise_stala->perlinMap3D(x, y, z);
}
if (spflags & MGDJR_LAVA) {
noise_lava_1->perlinMap2D(x, z);
noise_lava_2->perlinMap3D(x, y, z);
}
if (spflags & MGDJR_GROUND_WATER) {
noise_water_1->perlinMap2D(x, z);
noise_water_2->perlinMap3D(x, y, z);
}
}
The bad news is that liquid and light handling are taking more than ten times as much time as anything else after that. So, there's probably not much to be done to speed everything up past the cave issue.
Believe in people and you don't need to believe anything else.
Who is online
Users browsing this forum: Ahrefs [Bot], Google [Bot] and 29 guests