Minetest logo

IRC log for #minetest-dev, 2021-03-22

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
02:32 ivanbu joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
04:12 Edgy1 joined #minetest-dev
07:55 rubenwardy joined #minetest-dev
07:59 ivanbu joined #minetest-dev
08:00 ShadowNinja joined #minetest-dev
08:06 olliy joined #minetest-dev
09:21 hlqkj joined #minetest-dev
09:42 appguru joined #minetest-dev
09:43 absurb joined #minetest-dev
10:45 Fixer joined #minetest-dev
11:03 hlqkj_ joined #minetest-dev
11:08 calcul0n_ joined #minetest-dev
11:13 proller joined #minetest-dev
11:14 hlqkj joined #minetest-dev
11:32 appguru joined #minetest-dev
11:43 calcul0n__ joined #minetest-dev
11:46 Dyedefra joined #minetest-dev
12:08 tech_exorcist joined #minetest-dev
12:44 turtleman joined #minetest-dev
13:00 appguru joined #minetest-dev
13:12 olliy joined #minetest-dev
13:14 hlqkj joined #minetest-dev
13:15 Lunatrius joined #minetest-dev
13:17 hlqkj joined #minetest-dev
13:48 Wuzzy joined #minetest-dev
14:15 hlqkj_ joined #minetest-dev
15:14 Fixer_ joined #minetest-dev
15:23 tech_exorcist joined #minetest-dev
15:26 Wuzzy Is using table.copy a big performance issue and should it be avoided in builtin?
15:27 Wuzzy for example, is it OK to use table.copy to deep-copy a node table?
15:27 Wuzzy or should i copy it "by hand" with {name="foo:bar", param1=0, param2=45}?
15:27 sfan5 I think by hand is preferable there
15:27 Wuzzy why?
15:27 Wuzzy can we trust node tables to stay the same forever?
15:30 celeron55_ they're part of the api so... yes?
15:31 celeron55_ maybe there should be a function for making a copy of a node table though
15:31 Wuzzy ok thanks
15:32 Wuzzy eh, i dont think such a functtion is that important, i was just askin bout conventions 🙂
15:35 MTDiscord <Warr1024> The easiest way to ensure that param3 eventually gets added to the node tables is to hard-code the table copy all over the place to ensure that it would be maximally inconvenient to add support for it...
15:36 Lunatrius joined #minetest-dev
15:40 celeron55_ this all of course depends on details that were not explained
15:40 celeron55_ but in builtin a simple grep will give us every line that needs to be changed if the engine is changed in some way, that's not a problem in any case
15:42 celeron55_ mods might end up with some compatibility problems, that's for sure
15:43 celeron55_ so if you were asking that exact question for a mod that deals with copied node tables, you may have reasons to do it differently
15:56 appguru joined #minetest-dev
16:24 Taoki joined #minetest-dev
16:46 Wuzzy Reminder to all core devs: builtin is translatable now, remember to enclose your player-facing server messages in S()
16:49 nerzhul nobody cares about my proposal about a irrlicht header retribution to the lib ? :(
16:58 absurb joined #minetest-dev
17:05 MTDiscord <appguru> We should abolish the entire copy-thing IMO.
17:08 MTDiscord <appguru> For compatibility reasons we can't do that for old callbacks, but we should do it for newly added ones.
17:14 pgimeno FWIW I don't think it matters whether a deepcopy is inlined or not, performance wise. The copy itself of the nodes table is expected to make the function call overhead negligible.
17:18 MTDiscord <appguru> I'm saying we should deprecate call-by-value yesterday and have all new callbacks not do it anymore
17:21 pgimeno I may be misunderstanding the use case
17:22 pgimeno certainly, avoiding pairs() has potential for speeding up things because it prevents JIT compilation, so if the alternative does not involve pairs(), it may be better
17:55 rubenwardy nerzhul: I can't see any such proposal
18:07 nerzhul 1 PR on each repo and talked about it this weekend
18:08 nerzhul rubenwardy ^
18:17 DS-minetest joined #minetest-dev
18:39 proller joined #minetest-dev
19:22 Fixer joined #minetest-dev
20:23 MTDiscord joined #minetest-dev
20:35 MTDiscord joined #minetest-dev
21:18 troller joined #minetest-dev
21:30 v-rob joined #minetest-dev
21:32 appguru joined #minetest-dev
21:33 v-rob I had another (not fully developed) idea about extending node possibilities beyond param2, and I want to run it by some other people to see any problems with it
21:34 v-rob The Minetest world, in general, is fairly homogenous. Most of the world is air, stone, or things that are identical to each other
21:35 v-rob So, instead of storing MapNodes in MapBlock, store pointers to MapNodes and put all the MapNodes in a separate list. Memory usage would increase initially since pointers are at least the same size as MapNodes, but later it might be more efficient memory-wise if more is added to MapNode
21:36 v-rob Only one MapNode would need to be stored for all air nodes, stone nodes, etc
21:37 DS-minetest isn't this basically the content id?
21:37 sfan5 it's another lay of indirection on top
21:37 sfan5 layer*
21:37 v-rob Right, but it also includes param2
21:37 v-rob I don't know if performance would suffer or not
21:38 DS-minetest ah. so, would the MapBlock lists be stored per block or per whole world?
21:38 celeron55_ you're going to have to imagine and write down quite a list of benefits for a system like that to be created
21:38 celeron55_ it would be a *lot* slower
21:39 celeron55_ as in, quite fast, but not blazing fast like the current simple system
21:39 celeron55_ 128 bit nodes would be faster than that
21:39 v-rob Yes, that's why I'm running it past everyone first :)
21:39 celeron55_ maybe even 256
21:40 celeron55_ or larger
21:40 v-rob However, memory usage would be quite smaller than 256 MapNodes, though
21:41 v-rob 128... maybe not
21:41 celeron55_ what are the usecases for larger nodes that fit between current nodes and node metadata
21:41 v-rob I guess it depends on whether the world is mostly homogenous or not
21:41 celeron55_ and how much data they need
21:41 celeron55_ that's the question
21:42 v-rob Isn't node metadata too slow to be used in rendering?
21:43 celeron55_ no?
21:43 v-rob Thought it was, but I don't think anyone would consider storing param2 in metadata for every node
21:44 celeron55_ well what you just proposed was basically more tightly packed node metadata
21:44 celeron55_ it would have the same characteristics, just somewhat smaller
21:44 v-rob But would be quite a bit cheaper memory-wise than metadata
21:44 celeron55_ that is, still can't bloat up every node with extra stuff
21:45 DS-minetest btw. why aren't param0, param1 and param2 each stored separately? this would make it easier to allow special (but very common) mapblocks with 8 bit param0; and with SIMD operations one could more easily find nodes of a specific id faster; isn't it pretty common to only look at the content id for most nodes?
21:46 troller joined #minetest-dev
21:46 celeron55_ DS-minetest: it's also very common to fetch many or all of them for a single node
21:47 celeron55_ i guess the main reason is because this way allows a normal class structure for nodes
21:48 v-rob Variable-length structures in an array are difficult
21:48 DS-minetest well yes, but isn't that mostly because of the lua api that only has the get_node and no get_nodename or similar?
21:48 celeron55_ if you do separate arrays in C++, the optimization ends up messing up code readability really bad
21:49 v-rob An adaption on my idea: Store param2 in metadata, but in an optimized form. So, minetest.get_meta():set_param(value), implemented without string-based lookup internally for RAM and performance benefits
21:50 v-rob Also frees up former param2 space in MapNode for e.g. param1 to extend to colored lighting
21:51 v-rob Yeah, that idea sounds better than the original one, but maybe not perfect still
21:51 celeron55_ i don't recommend wasting the time to make that just to benchmark it being bad
21:51 celeron55_ is the most polite way for me to put this
21:52 sfan5 you have to consider that mesh making right now can avoid touching metadata at all
21:52 sfan5 bringing metadata into it will make it slow
21:52 v-rob Don't worry about politeness, I want my ideas to be torn apart if they're bad
21:53 celeron55_ there are so many ways to "improve" the node storage, all of them being bad, and i don't want to explain the badness of each individually
21:54 celeron55_ anyway i'll let you discuss 8) of course there can be one good one among a hundred bad ones that i'm not willing to look into
21:55 celeron55_ i'd like to underline what i said previously:
21:55 celeron55_ if there's a need for more fast bulk data per node, we, or i, will figure it out
21:56 pgimeno <v-rob> Isn't node metadata too slow to be used in rendering?
21:56 pgimeno <celeron55_> no?
21:56 pgimeno wait, what? is that for real? if that's true, that would open a whole new world of possibilities
21:57 v-rob Well, there was a PR a while ago about storing a whole nodedef in metadata that worked at some point
21:57 celeron55_ until there's a strong need for it with lots of benefits that justify the performance downgrade that people want to start using, the nodes won't be extended just for the sake of extending them
21:57 celeron55_ v-rob: ...i think i made that, right?
21:58 v-rob Oh, did you? I didn't know
21:58 celeron55_ it created the option to make a node look completely different just by defining a custom node in metadata
21:58 celeron55_ or something like that
21:58 celeron55_ actually i don't remember, i'd have to look it up
21:59 celeron55_ and not by node id but literally a complete node definition
21:59 sfan5 https://github.com/celeron55/minetest/tree/meta_set_nodedef
21:59 celeron55_ there are probably updated versions of that by others
22:00 pgimeno I think that using metadata for rendering would be a revolution
22:00 DS-minetest #5919
22:00 ShadowBot https://github.com/minetest/minetest/issues/5919 -- [WIP] Meta-set nodedef: Part 4 by Thomas--S
22:01 Taoki joined #minetest-dev
22:02 celeron55_ looks like credit to me was lost at some point 8)
22:03 pgimeno imagine, being able to define textures independently per face, even mixing half-height nodes with different textures that the user can change for the top and the bottom
22:04 celeron55_ well, yeah, and then someone makes an entire world out of those and wonders why is it 100x slower to load than normal
22:05 celeron55_ of course the fact that someone will always abuse whatever is done isn't a reason not to do it
22:05 celeron55_ i don't remember why that branch remained as an experiment for me
22:05 v-rob I think the biggest problem aside from RAM/performance is that node definitions can easily become outdated, requiring cumbersome LBMs for compat
22:06 celeron55_ well of course
22:06 celeron55_ those should be kept for active nodes that will change their appearance from time to time anyway
22:06 pgimeno imagine a house made of 1 node walls and ceilings, with the floors different to the ceilings, with the inner walls different to the outer ones... these are the immediate examples that come to mind, and I'm not a creative person
22:07 celeron55_ altough, if you're happy with the appearance, how does it make sense to want it to update at any point in the future?
22:07 v-rob Well, #10801 + SSCSM + per-node textures would be awesome, but unlikely
22:07 ShadowBot https://github.com/minetest/minetest/issues/10801 -- Add CSM 2D Drawing API by v-rob
22:09 v-rob Inner/outer walls could easily be done with one content ID with #9193
22:09 ShadowBot https://github.com/minetest/minetest/issues/9193 -- Add paramtype2 for node texture variants
22:12 sfan5 while fully "dynamic" node appearance would obviously be very cool I think adding paramtype or metadata for specific parts of the nodedef is the most useful tradeoff
22:12 sfan5 just like that issue you linked
22:13 v-rob Nodes should be semi-dynamic-ish, not entities
22:14 pgimeno no, param2 doesn't give nearly the same flexibility with just 8 bits
22:15 v-rob That's kind of the reason why I started the whole discussion, since I think larger param2 would be useful
22:15 sfan5 ("or metadata")
22:45 Dyedefra left #minetest-dev
23:51 Wuzzy #11110
23:51 ShadowBot https://github.com/minetest/minetest/issues/11110 -- Fix number of tool uses being off by 1..32767 by Wuzzy2
23:52 Wuzzy This PR has 2 days of work behind it.
23:58 Seirdy joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext