[0.4.8] LuaVoxelManipulator

[leetelate]

the water should flow downward at the joins, make rivers, and where there is no water is a desert

bah, i got side-tracked with the idea of mapping on-the-fly (which is almost solved, btw - a super-simple routine creates an overhead map via the noise and is built as the chunks are generated - sweet, though the output is only in pgm format at the moment - waiting for 0.4.8)

shupagen is coming along nicely:

Code: Select all

 for x=minp.x, maxp.x, 1 do
  for z=minp.z, maxp.z, 1 do
    local n = noise:get2d({x=x,y=z})
    local q = math.abs(math.floor(n*128))
    local c=q+128
    for y=minp.y, maxp.y, 1 do
    ...  build it based on the height data from the 2d noise


seed=679072 octaves=9 persistance=0.9 scale=100 gives a rpg-friendly terrain of: (white = mountains, black = ravines, gray = flat)
now i just need to clamp c to a decent value, then smooth it out a bit with a fft (bigger hammer)

[paramat]

Looks like crazy terrain :)
Some advice on your use of perlin noise:
The first octave creates detail roughly on the scale of 'scale' = 100 nodes, each extra octave creates detail on a scale half as big, so 100 50 25 12.5 6.25 nodes ...
Any detail with a scale smaller than roughly 4-8 nodes is lost in the 'blockiness' of the individual nodes. So you dont need 9 octaves only 5, this will greatly reduce processing and speed up mapgen.
Also, having the largest scale of terrain as 100 nodes will create terrain with no variation larger than 100 nodes, i recommend at least 250 nodes, which is the value used in default MT mapgen.
I use 2^n numbers for scale because they always divide by 2, so an MT scale mapgen would be scale = 256, octaves 6, creating detail on these scales: 256 128 64 32 16 8 nodes. Personally i always stop at 8 nodes and dont go to 4 because the detail is lost.
Persistence is roughness of terrain, a 'medium' / noise-industry standard value for this is 0.5.
MT default is 0.6 = fairly detailed, 0.4 = smooth, 0.7 = crazy.
0.9 means the small scale variation is too strong and drowns-out the large scale noise, i suggest 0.4-0.7 for most uses.

[leetelate]

oh, i see what you mean - making it porcupine then having to smooth back again it wastes the horses eh? - thanks a lot for the data, it will help - and my mapscale is obviously wrong too - i was thinking it was a big distance but the flat areas between the mountains and ravines are tiny lol - it is always something we don't know about causing the error! - early days - i will go back and look at the octaves/scale again in a bit - i really like that contiguous terrain with mountains->flats->ravines, which is basically why i was using 9/100 as 'fill' instead of doing it myself - sharpness of the mountains was a plus too - yeah i see what you mean now about the scale and it getting lost
5,0.4,256 gives the first map file
5,0.6,256 gives the first map file
and the mapper code (makes a pgm 500*500 overhead map from a 2d noise specified by the values)

[Neon]

Some advice on your use of perlin noise......

This information should totally be added to the wiki

[leetelate]

yes it should - also there are some things that cannot (as far as i can figure out) be used with lvm

chests - forget about param2, there is no meta data, so chests no work when you use it - have to dig it up and place it again to put the metadata

furnaces - crashes mintest with some error about "fuel" - i didn't care at that point and changed it to a stone block - metadata again

torches, signs (anything wallmounted?) - floats harry potter style until disturbed then falls as a lua object lol

everything else seems to work great - i think the lvm is wonderful!

shupagen is finished (no on-the-fly) and working in 500*500 with a pop-up map - very sweet - one more cleanup then i will put it up, probably as a christmas rpg mod


note: for those that didn't see the thread, on-the-fly mapping from the noise during the mapgen now works but is useless! as there is no way to push the map texture to the client. i got drunk the day i found that out. Very sad.

[leetelate]

HA! I knew there had to be some way to do it - well, if i'm going to set the meta after the build, why not just put them in normally after the build? - i will think about it

i'm putting up the shupa christmas mod with the shupagen and map - it is a 1000 * 1000 test-size previously-generated noise terrain, overhead-view mapped, then map-gen in the game to be the same as the original noise! - unfortunately you can't just use the same noise params and mapgen for real in-game because of the world seed being different, so i used a pgm file- the full-size varsion would have to use tiled pgm's - muhwahhahaha cough cough but it works so pffffft

the noisegen and overhead mapper is simply:

Code: Select all

     local noise = minetest.get_perlin(zseed, zoctaves, zpersistance*.10, zscale)
     for x=1,1000,1 do
      for z=1,1000,1 do
        local n = noise:get2d({x=x-500,y=z-500})
        local q = math.abs(math.floor(n*zmh))
        local c=q+zgh
       --c is the terrain
       local d = c
                   if c <= zwater then
                    --water area
                      d = 50
                   elseif c <= zjungle then
                    --jungle area
                      d = 100
                   elseif c <= zgrassland then
                    --grassland area
                      d = 120
                   elseif c <= zgrass then
                    --grassy area
                      d = 180
                   elseif c >=zsnow then
                    --snow area
                      d = 210
                   end --if s
         --biomes is d


i got my walkable ridgelines! and some serious parcour terrain that i needed for the christmas mod


and here is the noise:


and le map:


experience so far: the mapgen in the game is really fast since you don't really generate terrain, biomes, etc - generating from the noise was done before hand and in-game you just mapgen from the noise image - world is limited by the size of the image, but those could easily be tiled, as would be the overhead map, and you get to tweak the noise image before - all in all it is a lot more trouble, but i love the overhead map so much!

[paramat]

Some useful advice on lighting from the creator of luavoxelmanip copied from IRC chat ...

"The lua documentation doesn't mention the minp and maxp parameters to calc_lighting because they're not existing any longer. i removed them because the lua modder would never need that sort of power and it'd only serve to screw up the lighting, i'm not sure if a modder can use it a way other than i originally had it that'd work as intended.

Set_lighting sets lighting in the voxelmanip exactly to the light you specify, does not calculate.

The nolight flag is a mapgen parameter that disables all lighting computations, which is very helpful for when you're doing a total mapgen replacement in lua.

In order to not get lighting glitches, you have to either set the nolight flag or call vmanip:set_lighting({day=0, night=0}) before calling vmanip:calc_lighting() in order to get correct lighting results."

[leetelate]

Set_lighting sets lighting in the voxelmanip exactly to the light you specify, does not calculate.

and

The nolight flag is a mapgen parameter that disables all lighting computations, which is very helpful for when you're doing a total mapgen replacement in lua.

more incredibly useful data, thanks! - explains why the lava area in grandfather's house is dark, while the rest of the house is lit up bright - until you throw a torch up and it sets something somewhere

In order to not get lighting glitches, you have to either set the nolight flag or call vmanip:set_lighting({day=0, night=0}) before calling vmanip:calc_lighting() in order to get correct lighting results.

vm:set_lighting({day=0, night=0}) is sadly meaningless to me - day=1 or night=1

from the latest lua.doc on github:

set_lighting(light): Set the lighting within the VoxelManip
^ light is a table, {day=<0...15>, night=<0...15>}

nah, still senseless - why is it day AND night? - oh way,is this saying that the particular node gets x lighting in the DAY and x lighting in the NIGHT? - so a street lamp that is off in the day and on at night would be day=0,night=15?

or i could just use the no_light flag and everything would all stay dark?

or is it not even node based but for the whole area of the vm?

anyway, so my:

Code: Select all

minetest.register_on_mapgen_init(function(mgparams)
        minetest.set_mapgen_params({mgname="singlenode"})
end)


should be: (stolen from paragen.lua with much love)

Code: Select all

 minetest.register_on_mapgen_init(function(mgparams)
    minetest.set_mapgen_params({mgname="singlenode", flags="nolight", flagmask="nolight"})
end)


i'll try some things in a bit

um, nope i won't -

Code: Select all

 vm:set_data(data)
 vm:set_lighting({day=5,night=10})
 vm:calc_lighting()


gives a server error:

Code: Select all

18:50:37: ACTION[main]: Server for gameid="minetest" listening on port 52076.
creative inventory size: 176
spawning at:(0,55,0)
on_newplayer
18:50:38: ACTION[ServerThread]: singleplayer [127.0.0.1] joins game. List of players: singleplayer
Could not open file of texture: character.png
Loaded mesh: character.x
Font size: 8 15
generating    (-32,-32,-32)    (47,47,47)
18:50:42: ERROR[EmergeThread0]: ERROR: An unhandled exception occurred: LuaError: error: attempt to index a nil value
18:50:42: ERROR[EmergeThread0]: stack traceback:

In thread ad8bfb40:
/home/emachine/minetest/src/emerge.cpp:567: virtual void* EmergeThread::Thread(): Assertion '0' failed.
Debug stacks:
DEBUG STACK FOR THREAD ad8bfb40:
#0  virtual void* EmergeThread::Thread()
(Leftover data: #1  virtual MapBlock* ServerMap::emergeBlock(v3s16, bool): p=(3,3,3), create_blank=0)
(Leftover data: #2  ServerMapSector* ServerMap::createSector(v2s16): p2d=(3,3))
DEBUG STACK FOR THREAD ae2a8b40:
#0  virtual void* MeshUpdateThread::Thread()
DEBUG STACK FOR THREAD b4f51b40:
#0  virtual void* ServerThread::Thread()
#1  void Server::Receive()
(Leftover data: #2  virtual void ServerEnvironment::step(float))
(Leftover data: #3  void RemoteClient::GetNextBlocks(Server*, float, std::vector<PrioritySortedBlockTransfer>&))
(Leftover data: #4  void ItemStack::serialize(std::ostream&) const)
DEBUG STACK FOR THREAD b69f6700:
#0  int main(int, char**)
(Leftover data: #1  void Client::step(float))
(Leftover data: #2  virtual void ClientEnvironment::step(float))
(Leftover data: #3  void Client::Receive())
(Leftover data: #4  void Client::ProcessData(irr::u8*, irr::u32, irr::u16))
(Leftover data: #5  void ItemStack::deSerialize(std::istream&, IItemDefManager*))
[1]+  Killed                  ./minetest
Aborted

the same code with "no_light" mgparam and no set_lighting looks great! - i dug a hole, it turns dark as it should - i'll just use this - clay is great for testing lighting! - creator code below - i wanted to compare the no-light to set_lighting with the same code but nope

[paramat]

mauvebic's having lighting problems with asteroid mod LVM version https://forum.minetest.net/viewtopic.php?pid=118925#p118925

[paramat]

I directed hmmmm to this thread and mauvebic's post, this was his response on IRC:

"oh dear, set_lighting does indeed cause a crash, and it's a really obvious stupid error too. shows how often it gets used, huh
as for the other two, you're using it the wrong way
you set the nolight flag so that the mapgen you're using does not do any lighting calculations of its own
with the nolight flag, you run calc_lighting after setting all your nodes to the vmanip and then write it back to the map
so that should be:
1). you make sure the nolight flag was set in on_mapgen_init
2). in on_generate, you set your nodes in the vmanip
3). you write those nodes back to the vmanip with set_data()
so now at this point the vmanip object has the nodes you wrote in its internal memory, so you can calculate the lighting by calling calc_lighting()
THEN you write it back to the map
nolight is necessary because if you don't do that, the lighting values that will already be there will be the old ones from the terrain that the core mapgen calculated
which causes buggy lighting
the reason why I mentioned set_lighting to 0 was because that's another way to clear the lighting
either way you do it, either by setting it to 0 with set_lighting, or by specifying nolight so it's never calculated in the first place, you need to start out with a clean slate before you run calc_lighting or else you'll get buggy looking lighting, plain and simple
thank you for bringing set_lighting's problem to my attention, I'll be sure to fix that up right away"

[paramat]

hmmmm has now fixed set_lighting, commit http://git.io/nesCkQ

[leetelate]

thank you!

[paramat]

Also i have discovered it is essential to have 'set lighting' included like this to avoid lighting bugs:

Code: Select all

vm:set_data(data)
vm:set_lighting({day=0, night=0})
vm:calc_lighting()
vm:write_to_map(data)

Why i don't know, it seems redundant to set lighting to zero just before calculating it, but it seems to help.

[paramat]

Here's my own simple lua mapgen to serve as another example of how to use the voxelmanip.
https://forum.minetest.net/viewtopic.php?id=8483

In other news ... hmmmm has added per node getting and setting of param1 (which is usually light level) and param2.

[Mineiro]

someone explain to me how to register this game

[Evergreen]

someone explain to me how to register this game

First: You posted this in the wrong topic. Second: You do not have to register to play the game. Third: You would have figured that out if you had tried.

[paramat]

Another voxelmanip mapgen example/tutorial https://forum.minetest.net/viewtopic.php?id=8628

"This mapgen is a framework for developing mapgens, and a simplified example/tutorial of how to use the new lua voxel manipulator and use both 2D and 3D perlin noises in the LVM-optimum ZYX order mapgen loop.

While 3D noise is excellent for many uses and essential for primary terrain generation it is also processing heavy, 2D noise should be used instead for many tasks, for example varying across X and Z to select biomes per vertical column. So when creating mapgens it is almost inevitable you will need to combine the 2."

[paramat]

Here's celeron55's blog post explaining the 3D noise mapgen of mgv5 http://c55.me/random/2011-07/noisestuff/ this was my starting point for learning mapgen. Hmmmm's example mapgen in the first post is a very simple version of 3D noise mapgen. This is essentially creating a 'density field' by mixing density noise with a density gradient, then the surface is defined by density = 0, solid terrain is defined by positive density.

[Dragonop]

Cool i love it; i hope 3D noise in future builds!!!

[paramat]

The incompatibility between snow and plantlife/moretrees is fixed thanks to hmmm's commit https://github.com/minetest/minetest/commit/9e4e7072da8f565eef37da7558053a436b9cbba3 it works even without setting dependancies, however mapgen will run much faster if snow mod is chosen to run first.

We had misunderstood the mapgen object voxelmanip, it had been erasing changes made by other mods use of 'add node'.
On-generated functions are run in the order they were registered, which is the order mods are loaded, this order is controlled by dependancies, or if no dependancies are set some currently unknown order.
The mapgen object voxelmanip is so fast because it is just an extension of the core mapgen voxelmanip, so it always reads the map as it was immediately after core mapgen. When it writes back to the map it could erase any changes made by earlier-run on-generated functions.

Hmmm's recent solution is for 'add node' to update the voxelmanip.

(Post duplicated from splizard's snow mod thread)

[Inocudom]

Everyone, this post from 4aiman in the Freeminer forums is very important:
http://forum.freeminer.org/threads/again-a-lua-mapgen-yappy.171/#post-1724

Inocudom, dude... your pessimism literally killing me...
Just stop wining for a sec. Please, be a man and DO something to fix LVM or WAIT.
Proller has all kinds of ground NOT to fix LVM.
He really "speed-upped" set_node() to provide SOME way to fix LVM issues.
The reason LVM is broken is that nobody cares about it. Hmmmm had started the whole business and just drop it after time. Some people who wanted to work on LVM and mapgenv7 were coldly rejected before it had happened, though. But where did those people had gone? IDK.
But I do know something about the present days. Nobody cares. Still. Krock even don't want to use FM... Pardon my impudence, but what on earth were you thinking while posting yappy here, Krock? AFAIK yappy isn't dead or anything, so why did you bring a project that you can't maintain because of... what exactly?
And all that Inocudom does is making complaints. Do you really think the rush-in-and-tell-everyone-about-the-issue is the best way to act? Do you really think that after the first problems with LVM devs didn't get the overall picture of it? Do you really think that Lua can be as fast as C?
Go to #freeminer and ask for help in making something better. Proller is quite sociable and has answered all my stupid questions about biomes, LVM and stuff. The only thing you need to do is to ask for particular info only a core dev may tell you about. Complaining is a bad way and will lead you to nowhere.
Believe it or not, but I AM sorry to speak to you, guys, like this, but I'm too confused/puzzled with your behaviour to be calm and/or quiet.
To change the subject:
I've seen no code that tries to stay within chunksize and generate thing only within minp<->mapx.
The key word is "seen", 'cause I didn't look into every Lua mapgen and yappy as a matter of fact. So don't get over-exited by my statements and pardon me if I'm wrong - I just CAN'T test any mapgen till November.
But what I COULD'VE DONE do was to use LVM. And I did. LVM worked just fine if one does not expect it to create a map from scratch. Use mapgenv7 or propose your own mapgens re-coded into C.
I doubt anyone would be against new mapgen. Yappy is ideal for testing, so it stands a better chance against other mapgens.
What would be cool is a plugin system. A plugin that have a set of functions needed by the engine to create and manage a map.
Alternative? Use set_node(). It's rather stable.
On a side note:
How can one talk about the latest FM when the whole dozen of latest pulls can't pass a travis build? I've tried to compile FM the other day and that's when I found out that it's impossible w/o changes.

There needs to be serious discussion on this.

[paramat]

> Proller has all kinds of ground NOT to fix LVM.
He really "speed-upped" set_node() to provide SOME way to fix LVM issues.
The reason LVM is broken is that nobody cares about it. Hmmmm had started the whole business and just drop it after time.

Erm ... even if you quadruple the speed of 'add node' it will still be many times slower than voxelmanip.
We fixed the incompatibility between voxelmanip and 'add node' mods, see post above. I found a lighting bug with dark water on chunk edges, not yet fixed. Voxmanips isn't broken, many people care about it, hmmmm hasn't dropped it at all.

> I've seen no code that tries to stay within chunksize and generate thing only within minp<->mapx.

That mapblock deep shell around the mapchunk is essential for avoiding chunk edge glitches, amazingly it actually contains more nodes than the mapchunk.

> LVM worked just fine if one does not expect it to create a map from scratch.

That's it's strength, see my mapgens, only a few patches of dark water, but we get lighting bugs anyway.

EDIT
Working with a mapchunk of nodes as an array makes good sense, you can make multiple passes of the data without having to directly access the map 512000 times per mapchunk.

[Inocudom]

I did inform 4aiman of this post that you made, paramat. Of course, if you can make posts in the forums of Freeminer yourself, that would be greatly appreciated. I would ask if you yourself could test that fork of Minetest, but that greatly depends on what operating system you are using. Speaking of which, what operating system are you using?

[philipbenr]

I'm pretty sure it is linux of sorts: viewtopic.php?f=17&t=9432

Judging by the above topic.

[4aiman]

FM didn't remove LVM.

But due to changes made to mapgen and a separate thread for mapgen, LVM became buggy.
Also, while set_node() can't be compared with LVM in terms of speed, it's better than nothing.
But thanks to those changes FM doesn't stop the game itself because of mapgen load. So one can safely wait for new chunk while fighting mobs, collecting some stuff etc.

What Inocudom didn't tell everyone here, was his conversation with proller @ #freeminer.
Inocudom, as usual, didn't ask. He just stated that LVM in FM is omni-impossible and then added a question mark to his statement.

The only thing proller said was that a Lua mapgen can't be efficient, but Inocudom has started to panic once again. It seems, he didn't want to receive help or information, but to state that LVM's fate lies within oblivion.

But what I meant by "creating from scratch", however sad, is true. LVM works just great when in comes to small patches of terrain. I did many small enough things using LVM (different structures). But large LVM-only generated worlds aren't smth that should be expected to be stable in FM ATM.

If anyone wants reasons against LVM in FM, then here's one of 1000T in weight:
- there should be only 1 LVM, cause different LVM's does NOT respect each other. They (LVMs) just COPY terrain and then write it back with little to no regard of another instance of LVM running. Due to multiple threads, there can be weird results with one chunk generated by the 1st LVM and the other by the second.

It would be better to have a server-side mapgen-plugin system. *.dll or *.so files written in C would be much more efficient. Implement such a system and forget about inbuilt mapgens. It's not so hard to translate Lua mapgen into C one. Then a server will generate a map and send it to clients the way it does it every time. The only thing that will be different is a mapgen backend.