Time |
Nick |
Message |
00:14 |
|
Thermoriax_1 joined #minetest |
00:46 |
|
ShadowBot joined #minetest |
01:54 |
|
gh00p joined #minetest |
02:25 |
|
gh00p joined #minetest |
02:32 |
|
liceDibrarian joined #minetest |
02:37 |
|
sofar joined #minetest |
04:00 |
|
MTDiscord joined #minetest |
04:01 |
|
gregon joined #minetest |
05:26 |
|
gregon joined #minetest |
06:04 |
|
mdhughes joined #minetest |
06:59 |
|
gregon joined #minetest |
07:29 |
|
Glaedr joined #minetest |
07:53 |
|
bodiccea_ joined #minetest |
07:55 |
|
cheek_pain joined #minetest |
08:21 |
|
sys4 joined #minetest |
08:24 |
|
bodiccea_ joined #minetest |
08:28 |
|
gregon joined #minetest |
08:44 |
|
book` joined #minetest |
08:46 |
|
vampirefrog joined #minetest |
09:06 |
|
mrkubax10 joined #minetest |
09:45 |
|
fling joined #minetest |
10:02 |
|
YuGiOhJCJ joined #minetest |
10:08 |
|
fling joined #minetest |
10:31 |
|
AwesomeAdam54321 joined #minetest |
10:33 |
|
izzyb joined #minetest |
10:46 |
|
gregon joined #minetest |
10:54 |
|
ireallyhateirc joined #minetest |
11:42 |
|
gregon joined #minetest |
11:45 |
|
BuckarooBanzai joined #minetest |
11:54 |
ireallyhateirc |
what's the overhead for creating a voxel manip object? |
11:55 |
ireallyhateirc |
would creating multiple smaller VMs be much worse than one big of the same volume as the small combined? |
12:19 |
|
MinetestBot joined #minetest |
13:06 |
|
wiresoup joined #minetest |
13:16 |
|
silverwolf73828 joined #minetest |
13:21 |
MTDiscord |
<warr1024> I've heard that for a small 3x3x3 cube, get/set_node is supposed to be comparable. get/set_node is faster on smaller areas, and vmanips are faster on larger areas. I don't remember the source, so you might want to do some tests to confirm. |
13:22 |
MTDiscord |
<warr1024> I think there was also an assumption that you actually needed access to every node in that area. If many of them you will neither read nor modify, then you might still be paying the overhead costs for vmanips, so density might matter. |
13:23 |
MTDiscord |
<warr1024> I'd love to see some tests. PUC vs JIT probably matters. How optimal your access patterns are for vmanips certainly matters... |
13:25 |
celeron55 |
i guess somebody could do a benchmark and plot the result as a line, where one axis is the volume size, and the other is the amount of nodes inside the volume you'll be accessing, and then color the area where vmanip is slower |
13:25 |
celeron55 |
s/as a line/as an area/ |
13:27 |
celeron55 |
my rule of thumb would be something like: if you're accesing more than half the nodes in a volume larger than a mapblock, it always makes sense. less than that for either parameter and you start finding cases where it may not make sense |
13:29 |
celeron55 |
that's the use case it was designed for, anyway |
13:34 |
ireallyhateirc |
uh back, reading right now |
13:34 |
MTDiscord |
<exe_virus> I'd bet it's RAM vs CPU dependent |
13:36 |
ireallyhateirc |
>I've heard that for a small 3x3x3 cube |
13:37 |
ireallyhateirc |
that's what the modding book and API doc says, I'm speaking about bigger volumes - mapblocks and higher |
14:09 |
ireallyhateirc |
celeron55, by "it always makes sense" you mean creating a VM that's larger? |
14:10 |
ireallyhateirc |
As for the benchmark/plot is it possible to measure time/resources needed to create a VM object or does creating the VM object itself cost virtually nothing? |
14:11 |
ireallyhateirc |
I guess it only costs something when I get the flat array |
14:12 |
celeron55 |
well the vm is a copy of the node data. the data has to be copied |
14:13 |
celeron55 |
the idea is, a bulk copy is much cheaper than a single node access, on a per node basis |
14:14 |
ireallyhateirc |
Currently I'm loading VMs that are the size of a mapchunk |
14:14 |
celeron55 |
when accessing a single node, there's always the overhead of going through the dynamic map structure which is inherent to a dynamically sized, dynamically loaded world |
14:15 |
celeron55 |
ireallyhateirc: how many nodes do you access in it? |
14:15 |
ireallyhateirc |
but that's probably an overkill. My use case is for example changing spring soil (green grass) to winter soil (brown grass) |
14:15 |
celeron55 |
sounds like you're at least reading almost every node? |
14:15 |
celeron55 |
that makes it worth it |
14:16 |
ireallyhateirc |
for a volume the size of a mapchunk and assuming a flat map, I process 80 x 80 = 6400 nodes |
14:16 |
ireallyhateirc |
but the VM is 512000 nodes |
14:16 |
ireallyhateirc |
I made my mod with a silly assumption that map works using mapchunks, but it works on mapblocks after generation |
14:16 |
celeron55 |
how do you know which nodes you have to touch? |
14:17 |
ireallyhateirc |
I make a table of node ID replacements |
14:17 |
ireallyhateirc |
so a table keyed by node ID and having node ID as value |
14:17 |
celeron55 |
positions |
14:17 |
celeron55 |
we're talking of node access here |
14:18 |
celeron55 |
which nodes would you get_node and set_node if you didn't use the VM |
14:18 |
ireallyhateirc |
My mod is basically a bulk replacer/processor. The map is divided into mapchunks, each mapchunk gets labels upon generation like "has_trees", "has_soil", etc. |
14:19 |
ireallyhateirc |
what I do is simply brute-forcing the flat array |
14:19 |
ireallyhateirc |
iterating over the whole array and replacing whatever node it encounters |
14:20 |
ireallyhateirc |
so it's not aware of the positions, it only knows what to replace and if the nodes it wants are present in the mapchunk |
14:21 |
celeron55 |
well brute force iteration over everything is exact what vmanips are meant for |
14:21 |
celeron55 |
exactly* |
14:21 |
ireallyhateirc |
it's really fast, I get times between 5-30ms per mapchunk for tasks like soil replacing, snow placing, moisture movement |
14:22 |
ireallyhateirc |
though I'm looking for a way to make it faster, so I was thinking about processing mapblocks instead of mapchunks |
14:22 |
ireallyhateirc |
given the soil layer is usually no bigger than a single mapblock, I thought that using that instead could be faster |
14:23 |
celeron55 |
well, it could be worth a test |
14:23 |
celeron55 |
i mean, you'll have to store more metadata |
14:23 |
celeron55 |
but it will be a bit more focused |
14:23 |
ireallyhateirc |
on our Land of Bugs server the mod already runs, gimmie a sec and I will give you stats |
14:23 |
ireallyhateirc |
mod storage is about 80MBs as far as I remember |
14:24 |
ireallyhateirc |
the map is about 8GBs |
14:25 |
ireallyhateirc |
and currently the system stores 253245 mapchunks |
14:26 |
ireallyhateirc |
well I guess I have no reason not to try |
14:28 |
ireallyhateirc |
mod storage would probably get 125 times fatter given that there are 125 mapblocks in a mapchunk |
14:29 |
ireallyhateirc |
hmmm that would give ~10GB for a map of 8GB, that could be not worth it |
14:33 |
|
hlqkj joined #minetest |
14:34 |
|
gregon joined #minetest |
14:36 |
ireallyhateirc |
On the other hand disk storage is cheap-ish and a more focused approach could save CPU time that's a huge limitation |
14:42 |
|
jaca122 joined #minetest |
15:07 |
|
gregon joined #minetest |
15:19 |
|
SpaceMan1ac joined #minetest |
15:25 |
|
wiresoup joined #minetest |
15:27 |
|
bodiccea joined #minetest |
15:30 |
|
meldrian joined #minetest |
15:30 |
|
meldrian joined #minetest |
15:54 |
|
germ joined #minetest |
15:54 |
|
runxiyu joined #minetest |
15:54 |
|
ShadowBot joined #minetest |
15:54 |
|
TheCoffeMaker joined #minetest |
15:54 |
|
Trifton joined #minetest |
15:55 |
|
Cork joined #minetest |
16:12 |
|
Blockhead256 joined #minetest |
16:12 |
Blockhead256 |
Today I learned that you can have a game inside a world directory, not just worldmods https://github.com/minetest/minetest/blob/5.9.0/doc/lua_api.md#world-specific-games |
16:13 |
|
MiniontobyPI joined #minetest |
16:15 |
rubenwardy |
it's not very well supported by the main menu |
16:16 |
Blockhead256 |
oh yeah, can you even launch that within the GUI? Or do I need to CLI-launch the world? |
16:16 |
rubenwardy |
I believe you can only use the cli |
16:16 |
rubenwardy |
I'd recommend putting a world in a game instead |
16:16 |
rubenwardy |
~cdb modgen |
16:16 |
rubenwardy |
!cdb modgen |
16:16 |
Blockhead256 |
that's a more common approach yeah |
16:16 |
rubenwardy |
https://content.minetest.net/packages/BuckarooBanzay/modgen/ |
16:17 |
Blockhead256 |
I think this could be really handy for people like Walker though, who run multiple server processes on the same OS and separate them with worldmods |
16:19 |
BuckarooBanzai |
The `mapsync` mod works too for game contained worlds, it also has better separation of data and code ;) |
16:20 |
rubenwardy |
you should link to that from modgen |
16:25 |
BuckarooBanzai |
done 👍 |
16:27 |
BuckarooBanzai |
the game-inside-worldfolder is quite handy for servers: there's everything in one place, only missing piece i think would be full minetest.conf file support |
16:37 |
Krock |
servers can specify a custom minetest.conf location though |
16:37 |
Krock |
it's not as convenient, though. |
16:41 |
|
silverwolf73828 joined #minetest |
17:04 |
|
Talkless joined #minetest |
17:31 |
|
Warr1024 joined #minetest |
17:37 |
|
kamdard joined #minetest |
18:03 |
|
mrkubax10 joined #minetest |
18:24 |
MinetestBot |
[git] sfence -> minetest/minetest: Add possibility to easier override HP and breath engine logic by Lua … f2c66b9 https://github.com/minetest/minetest/commit/f2c66b9ceb4930dfd7b510c77037c235b161e603 (2024-08-21T18:24:43Z) |
18:26 |
MinetestBot |
[git] wrrrzr -> minetest/minetest: Refactor tool.cpp (#14873) 1bccb4e https://github.com/minetest/minetest/commit/1bccb4e48ce4db8851d3d6eb4a574e7f56a9f8fd (2024-08-21T18:24:59Z) |
18:26 |
MinetestBot |
[git] rubenwardy -> minetest/minetest: Generate Android versionCode from Major.Minor.Patch (#14963) 6cc0452 https://github.com/minetest/minetest/commit/6cc0452503fad764a9f64d30540b37737879eeea (2024-08-21T18:25:18Z) |
18:27 |
MinetestBot |
[git] zmv7 -> minetest/minetest: Sort clients in `minetest.get_server_status` and privs in `minetest.p… b2f6a65 https://github.com/minetest/minetest/commit/b2f6a65bc9d8b9af394c15db277db4cb6d2e8a55 (2024-08-21T18:25:41Z) |
18:27 |
MinetestBot |
[git] grorp -> minetest/minetest: Fix mods folder being read twice with RUN_IN_PLACE=1 (#15024) 66b3db3 https://github.com/minetest/minetest/commit/66b3db360115de5d46cc036b2387810bf1460bd5 (2024-08-21T18:25:58Z) |
19:03 |
MinetestBot |
[git] grorp -> minetest/minetest: Fix trailing whitespace from #14179 ab7af5d https://github.com/minetest/minetest/commit/ab7af5d15a8250c24628b283940401ccc3759c30 (2024-08-21T18:30:58Z) |
19:35 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Sanitize formspec fields server-side (#14878) c6ef5ab https://github.com/minetest/minetest/commit/c6ef5ab2595d55192e7952694c6b301f2b64f65c (2024-08-21T19:34:46Z) |
19:41 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Move network protocol implementation behind an interface 7968ab6 https://github.com/minetest/minetest/commit/7968ab69281103bb99280e70603e01a33df92c9a (2024-08-21T19:40:58Z) |
19:47 |
|
liceDibrarian joined #minetest |
20:03 |
|
mrkubax10 joined #minetest |
20:54 |
|
sys4 joined #minetest |
22:32 |
|
panwolfram joined #minetest |
23:05 |
|
Eragon joined #minetest |