[0.4.8] LuaVoxelManipulator

leetelate
Member
 
Posts: 205
Joined: Thu Aug 29, 2013 18:07

by leetelate » Mon Nov 18, 2013 01:59

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:
Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
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
Image

and here is the noise:
Image

and le map:
Image

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!
Last edited by leetelate on Mon Nov 18, 2013 15:08, edited 1 time in total.
MT IS MC'S SMARTER BROTHER
minetest 0.4.8 compiled from latest git on linux mint 15 with qjoypad and wired 360 controller
freeminer, pilztest, buildcraft and next are the idea factories
my minetest page is http://1337318.zymichost.com if zymic isn't down - meh, it is free...
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

by paramat » Tue Nov 19, 2013 12:07

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."
Last edited by paramat on Tue Nov 19, 2013 12:08, edited 1 time in total.
I rely on donations to help provide an income https://forum.minetest.net/viewtopic.php?f=3&t=14935
 

leetelate
Member
 
Posts: 205
Joined: Thu Aug 29, 2013 18:07

by leetelate » Tue Nov 19, 2013 23:14

paramat wrote: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:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
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)

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
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 -
Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
 vm:set_data(data)
 vm:set_lighting({day=5,night=10})
 vm:calc_lighting()


gives a server error:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
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
Image
Attachments
lighting_nolight.tar.gz
(892 Bytes) Downloaded 171 times
lighting.tar.gz
(812 Bytes) Downloaded 197 times
Last edited by leetelate on Wed Nov 20, 2013 01:07, edited 1 time in total.
MT IS MC'S SMARTER BROTHER
minetest 0.4.8 compiled from latest git on linux mint 15 with qjoypad and wired 360 controller
freeminer, pilztest, buildcraft and next are the idea factories
my minetest page is http://1337318.zymichost.com if zymic isn't down - meh, it is free...
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

by paramat » Wed Nov 20, 2013 13:29

mauvebic's having lighting problems with asteroid mod LVM version https://forum.minetest.net/viewtopic.php?pid=118925#p118925
I rely on donations to help provide an income https://forum.minetest.net/viewtopic.php?f=3&t=14935
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

by paramat » Thu Nov 21, 2013 05:24

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"
I rely on donations to help provide an income https://forum.minetest.net/viewtopic.php?f=3&t=14935
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

by paramat » Thu Nov 21, 2013 06:20

hmmmm has now fixed set_lighting, commit http://git.io/nesCkQ
I rely on donations to help provide an income https://forum.minetest.net/viewtopic.php?f=3&t=14935
 

leetelate
Member
 
Posts: 205
Joined: Thu Aug 29, 2013 18:07

by leetelate » Fri Dec 13, 2013 22:37

thank you!
MT IS MC'S SMARTER BROTHER
minetest 0.4.8 compiled from latest git on linux mint 15 with qjoypad and wired 360 controller
freeminer, pilztest, buildcraft and next are the idea factories
my minetest page is http://1337318.zymichost.com if zymic isn't down - meh, it is free...
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

by paramat » Fri Dec 13, 2013 23:31

Also i have discovered it is essential to have 'set lighting' included like this to avoid lighting bugs:
Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
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.
Last edited by paramat on Tue Feb 04, 2014 05:43, edited 1 time in total.
I rely on donations to help provide an income https://forum.minetest.net/viewtopic.php?f=3&t=14935
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

by paramat » Tue Feb 04, 2014 05:46

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.
I rely on donations to help provide an income https://forum.minetest.net/viewtopic.php?f=3&t=14935
 

Mineiro
New member
 
Posts: 1
Joined: Fri Apr 11, 2014 17:54

by Mineiro » Fri Apr 11, 2014 18:00

someone explain to me how to register this game
 

User avatar
Evergreen
Member
 
Posts: 2131
Joined: Sun Jan 06, 2013 01:22
GitHub: 4Evergreen4
IRC: EvergreenTree
In-game: Evergreen

by Evergreen » Fri Apr 11, 2014 19:00

Mineiro wrote: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.
"Help! I searched for a mod but I couldn't find it!"
http://krock-works.16mb.com/MTstuff/modSearch.php
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

by paramat » Fri Apr 11, 2014 22:28

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."
Last edited by paramat on Fri Apr 11, 2014 22:28, edited 1 time in total.
I rely on donations to help provide an income https://forum.minetest.net/viewtopic.php?f=3&t=14935
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

Re: [0.4.8] LuaVoxelManipulator

by paramat » Fri Jul 18, 2014 22:17

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
Member
 
Posts: 1178
Joined: Tue Oct 23, 2012 12:59
GitHub: Dragonop
IRC: Dragonop
In-game: Dragonop

Re: [0.4.8] LuaVoxelManipulator

by Dragonop » Fri Jul 25, 2014 03:14

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

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

Re: [0.4.8] LuaVoxelManipulator

by paramat » Fri Sep 19, 2014 01:19

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)
Last edited by paramat on Sun Nov 09, 2014 09:20, edited 1 time in total.
 

User avatar
Inocudom
Member
 
Posts: 2889
Joined: Sat Sep 29, 2012 01:14
IRC: Inocudom
In-game: Inocudom

Re: [0.4.8] LuaVoxelManipulator

by Inocudom » Mon Oct 13, 2014 18:37

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
4aiman, post: 1724, member: 49 wrote: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
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

Re: [0.4.8] LuaVoxelManipulator

by paramat » Mon Oct 13, 2014 22:17

> 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.
Last edited by paramat on Wed Oct 15, 2014 03:33, edited 2 times in total.
 

User avatar
Inocudom
Member
 
Posts: 2889
Joined: Sat Sep 29, 2012 01:14
IRC: Inocudom
In-game: Inocudom

Re: [0.4.8] LuaVoxelManipulator

by Inocudom » Tue Oct 14, 2014 00:26

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?
 

User avatar
philipbenr
Member
 
Posts: 1665
Joined: Fri Jun 14, 2013 01:56
GitHub: philipbenr
IRC: philipbenr
In-game: WisdomFire or philipbenr

Re: [0.4.8] LuaVoxelManipulator

by philipbenr » Tue Oct 14, 2014 01:53

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

Judging by the above topic.
 

4aiman
Member
 
Posts: 1208
Joined: Mon Jul 30, 2012 05:47

Re: [0.4.8] LuaVoxelManipulator

by 4aiman » Tue Oct 14, 2014 16:04

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.
 

User avatar
Inocudom
Member
 
Posts: 2889
Joined: Sat Sep 29, 2012 01:14
IRC: Inocudom
In-game: Inocudom

Re: [0.4.8] LuaVoxelManipulator

by Inocudom » Tue Oct 14, 2014 17:12

I need to destroy my pride completely and entirely:
Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
20<Inocudom>30    proller: http://forum.freeminer.org/threads/again-a-lua-mapgen-yappy.171/#post-1711 We have a big problem here.
T 1413130428 20<Inocudom>30    LuaVoxelManip is malfunctioning again for unknown reasons.
T 1413131387 24*    zat has quit (Quit: Leaving.)
T 1413133105 18<proller18>    because its shit ?
T 1413133284 24*    proller has quit (Quit: Leaving)
T 1413133295 20<Inocudom>30    proller: Would you be able to make a post in that topic then? And if not LuaVoxelManip, what then?
T 1413133376 23*    zat (~ale@179.57.205.11323) has joined
T 1413133385 23*    proller (~p@80.240.216.6923) has joined
T 1413135183 23*    iqualfragile (~iqualfrag@unaffiliated/iqualfragile23) has joined
T 1413135600 20<Inocudom>30    proller: But without LuaVoxelManip, how else would people be able to make Lua mapgens efficiently? Something would have to take its place, unless the goal is to make such omni-impossible.
T 1413140515 18<proller18>   Lua mapgens cant be  efficiently
T 1413140815 20<Inocudom>30   proller: Then it is as I said: omni-impossible?
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

Re: [0.4.8] LuaVoxelManipulator

by paramat » Fri Jan 02, 2015 03:13

Recently hmmmm realised his voxelmanip mapgen example, posted in the first post of this thread http://pastebin.com/x0DFYXQD has an error, the 'noise object' minetest.get_perlin_map() should not be created multiple times, only :get3dMap_flat() should be per mapchunk.
My code below, taken from 'levels' mod https://forum.minetest.net/viewtopic.php?f=11&t=10888, shows the correct way to create the noise object once only during the generation of the first mapchunk. This method will make your mapgen a little faster.

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
-- Initialize noise objects to nil

local nobj_terrain = nil

-- On generated function

minetest.register_on_generated(function(minp, maxp, seed)

   local x1 = maxp.x
   local y1 = maxp.y
   local z1 = maxp.z
   local x0 = minp.x
   local y0 = minp.y
   local z0 = minp.z
   
   print ("chunk minp ("..x0.." "..y0.." "..z0..")")
   
   local vm, emin, emax = minetest.get_mapgen_object("voxelmanip")
   local area = VoxelArea:new{MinEdge=emin, MaxEdge=emax}
   local data = vm:get_data()
   
   local c_stone = minetest.get_content_id("default:stone")
   local c_water = minetest.get_content_id("default:water_source")
   local c_lava  = minetest.get_content_id("default:lava_source")
   
   local sidelen = x1 - x0 + 1
   local chulens3d = {x=sidelen, y=sidelen, z=sidelen}
   local minpos3d = {x=x0, y=y0, z=z0}
   
   nobj_terrain = nobj_terrain or minetest.get_perlin_map(np_terrain, chulens3d)
   
   local nvals_terrain = nobj_terrain:get3dMap_flat(minpos3d)

   local ni3d = 1
   for z = z0, z1 do
      for y = y0, y1 do
         local vi = area:index(x0, y, z)
         for x = x0, x1 do
            local n_terrain = nvals_terrain[ni3d]
..
..
Last edited by paramat on Thu Jan 08, 2015 13:04, edited 1 time in total.
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

Re: [0.4.8] LuaVoxelManipulator

by paramat » Sat Jan 03, 2015 09:00

Post deleted.
Last edited by paramat on Tue Jan 06, 2015 06:58, edited 4 times in total.
 

hmmmm
Member
 
Posts: 47
Joined: Tue Apr 02, 2013 04:04

Re: [0.4.8] LuaVoxelManipulator

by hmmmm » Sat Jan 03, 2015 16:13

I was wrong when I said that, you were always able to omit z from chulens. Nothing special needs to be coded for that.
Also as of the 0.4.11 release, the size parameters a noisemap object was created with has no bearing on the rest of the parameters.
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

Re: [0.4.8] LuaVoxelManipulator

by paramat » Mon Jan 05, 2015 07:20

Thanks hmmmm, posts edited.
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

Re: [0.4.8] LuaVoxelManipulator

by paramat » Tue Jan 06, 2015 06:59

I just discovered that the z component of 2D perlinmaps must be 'z=1' to avoid crashes. Chatting to hmmmm he realised his post above was actually not correct. This may be fixed soon but since players will be using your mods in 0.4.11 stable 'z=1' should be included.
See my latest lua mapgen 'levels' as an example of correct lua mapgen coding https://github.com/paramat/levels
Last edited by paramat on Thu Jan 08, 2015 13:33, edited 1 time in total.
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

Re: [0.4.8] LuaVoxelManipulator

by paramat » Thu Jan 08, 2015 13:21

Levels mod had a bug, now fixed in version 0.2.6. I had restated the noise objects as locals within the on-generated function. This caused the noise objects to be re-created per mapchunk instead of only once.
Last edited by paramat on Sat Feb 14, 2015 09:27, edited 1 time in total.
 

paramat
Member
 
Posts: 2662
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat

Re: [0.4.8] LuaVoxelManipulator

by paramat » Sat Jan 10, 2015 06:05

Here's another improvement to my lua mapgen coding, realised when bugfixing with hmmmm.
Until now my mapgens have ended with these lines:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
   vm:set_data(data)
   vm:set_lighting({day=0, night=0})
   vm:calc_lighting()
   vm:write_to_map(data)
   vm:update_liquids()


Any light values pre-existing in the mapchunk were cleared with 'set_lighting' before re-calculating light.
It is actually more efficient to set the mapgen parameters to have no light right from the start and calculate it once only after the voxelmanip has added content.
So now near the beginning of your code add this for a singlenode mapgen:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
minetest.register_on_mapgen_init(function(mgparams)
   minetest.set_mapgen_params({mgname="singlenode", flags="nolight"})
end)


Or this for core mapgens:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
minetest.register_on_mapgen_init(function(mgparams)
   minetest.set_mapgen_params({flags="nolight"})
end)


Then after the mapgen loop there is no need for 'set_lighting', the end code look should be:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
   vm:set_data(data)
   vm:calc_lighting()
   vm:write_to_map(data)
   vm:update_liquids()
 

Sokomine
Member
 
Posts: 2980
Joined: Sun Sep 09, 2012 17:31

Re: [0.4.8] LuaVoxelManipulator

by Sokomine » Thu Jan 22, 2015 04:26

I'd be glad if you could take a look at the recent version of mg_villages. Most of the code is pretty fast, but some of those recent optimizations might help as well, especially regarding the calculation of noise?
A list of my mods can be found here.
 

User avatar
neko259
Member
 
Posts: 769
Joined: Sun Jun 19, 2011 06:51

Re: [0.4.8] LuaVoxelManipulator

by neko259 » Sun Mar 22, 2015 17:36

1. Can I rotate node with VoxelManip? I tried to use it to speedup moving many nodes at once, but it just forgets the facedir.

2. Why is it implemented as a completely different interface? Was it harder to implement just a way to get the node area and work inside it with the old set_node and get_node? What I mean is some kind of a transaction that would speed-up working with a set of nodes instead of getting and setting them one by one. But VoxelManip is something with a completely different interface, not sure what it was designed for.
 

PreviousNext

Return to Minetest News

Who is online

Users browsing this forum: No registered users and 7 guests

cron