| Time |
Nick |
Message |
| 00:01 |
|
liceDibrarian joined #minetest |
| 00:29 |
MTDiscord |
<mistere_123> fun thing: https://www.desmos.com/3d/556b8f0bf7 |
| 00:53 |
|
v-rob joined #minetest |
| 01:24 |
|
smk joined #minetest |
| 01:45 |
|
lemonzest joined #minetest |
| 02:26 |
|
lemonzest joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 05:01 |
|
est31 joined #minetest |
| 05:15 |
|
est31 joined #minetest |
| 05:39 |
|
est31 joined #minetest |
| 05:55 |
|
YuGiOhJCJ joined #minetest |
| 05:59 |
|
calcul0n joined #minetest |
| 07:01 |
|
gxt joined #minetest |
| 07:13 |
|
gregon joined #minetest |
| 07:22 |
|
Alnotz joined #minetest |
| 07:43 |
|
TomTom joined #minetest |
| 08:38 |
|
mrkubax10 joined #minetest |
| 08:44 |
|
dridron joined #minetest |
| 08:48 |
|
dridron joined #minetest |
| 09:33 |
|
qqq joined #minetest |
| 09:42 |
|
gxt joined #minetest |
| 09:43 |
|
Guest74 joined #minetest |
| 09:50 |
|
e1z0 joined #minetest |
| 10:32 |
|
sys4 joined #minetest |
| 10:45 |
|
appguru joined #minetest |
| 11:09 |
|
s20 joined #minetest |
| 11:17 |
|
turtleman joined #minetest |
| 11:19 |
|
calcul0n joined #minetest |
| 12:36 |
|
gxt joined #minetest |
| 12:42 |
|
Oksanaa joined #minetest |
| 12:50 |
|
s20 joined #minetest |
| 13:04 |
|
e1z0 joined #minetest |
| 13:18 |
erle |
celeron55 do you know what the motive is behind “oh your hardware is so bad, it must not work” when it works? like, i had assumed it is some gamer thing, because in hacker circles i rarely encounter it. case in point: if someone runs doom on a potato computer, people are rather impressed there. |
| 13:19 |
erle |
i mean you obv can't read minds, but i doubt AFCMS is going to tell me about the finer points of gamer culture |
| 13:20 |
erle |
and i doubt it has anything to do with technical skill (i.e. people still make fun of those who have “worse” hardware even when they know it is wrong) |
| 13:20 |
erle |
i encountered it first in mineclone2 btw, it was much worse there |
| 13:20 |
celeron55 |
i don't know. i personally take pride in MT working on the old thing, but i am terrified of the potential amount of resources that could end up being taken from more productive work into supporting hardware only a few people have |
| 13:20 |
erle |
but that's the joke, it does not take any resources. it just works. |
| 13:20 |
celeron55 |
the focus must be in the future |
| 13:21 |
celeron55 |
otherwise the project will stagnate, people will lose interest, and the project will die |
| 13:21 |
erle |
well i have interest in improving it, as you can see from my recent PRs (some even got accepted :P) |
| 13:21 |
erle |
so ig i will tackle the shadow issue as soon as i have understood what changed in irrlichtmt |
| 13:22 |
celeron55 |
we have had this discussion ten times already and that's 9 times too many |
| 13:22 |
celeron55 |
you already know what i think and what the dynamic there is |
| 13:22 |
erle |
i do. i just wondered, because for *you* and the other devs i get it – i don't get it for some ordinary gamer though. |
| 13:22 |
erle |
they have no concept of maintenance burden |
| 13:23 |
erle |
yet it is very important if a GPU gets you 200 or 300 fps |
| 13:24 |
celeron55 |
i don't think i've stumbled upon “oh your hardware is so bad, it must not work” in any serious way from ordinary people. but i guess they're thinking based on their own experiences, maybe they had to upgrade their hardware |
| 13:24 |
erle |
hmm, yes that tracks with AFCMS (“i was not able to run minetest on a 4 year old laptop, how can you run it on an older one?”) |
| 13:24 |
erle |
i'll ask those ppl if they extrapolate from their own experiences then |
| 13:24 |
erle |
but for imperceptible differences it still makes no sense |
| 13:25 |
erle |
in old gaming magazines ca. 1999 we had this category for how well games work on hardware |
| 13:25 |
erle |
there was a rating ”ruckelt, aber spielbar” (movement stutters, but playable) based on resolution or so |
| 13:26 |
erle |
which i find funny |
| 13:26 |
erle |
like if it stutters, it always irritates me to no end |
| 13:26 |
|
xBarkDog joined #minetest |
| 13:26 |
erle |
even if it is some pixelated scene like xcom or so (these games have vastly higher hardware needs nowadays because they used some palette tricks that are AFAIK no longer done in hardware, so they are slow) |
| 13:28 |
erle |
for my hardware, i was pretty much told that my driver is EOL … but there is a newer driver, that is faster :D |
| 13:28 |
erle |
the only downside being that it does not support at all stuff that the old driver supported with a framerate of like 0.1fps or so |
| 13:29 |
erle |
because it does not even try |
| 13:42 |
|
Sobinec joined #minetest |
| 13:53 |
|
definitelya joined #minetest |
| 14:15 |
|
Desour joined #minetest |
| 14:18 |
|
appguru joined #minetest |
| 14:18 |
muurkha |
now movement stutters in every app all the time |
| 14:21 |
|
appguru joined #minetest |
| 14:44 |
sfan5 |
since when? |
| 14:52 |
erle |
i think it happens if people run like half a dozen electron apps. or if they run mac os :P |
| 14:53 |
erle |
(application startup is slower and it has animations everywhere, both of which contributes to a *feeling* of slowness, even if the computer is fast) |
| 14:56 |
MTDiscord |
<warr1024> Can confirm, Mac OS feels really sluggish to use. Smooth, but lazy. You can't turn off the animations. Turning off all animations on e.g. Android via developer options mitigates transition lag quite a lot, wish they allowed it on mac. |
| 15:05 |
erle |
though i recently talked with some coworkers and it turns out some people don't have this effect |
| 15:05 |
erle |
like, apps don't feel slow if the animation is <0.3s or so |
| 15:44 |
celeron55 |
0.3 is incredibly slow for me. i want zero UI animations |
| 15:44 |
celeron55 |
my time is too short for UI animations |
| 15:44 |
celeron55 |
i mean, my life is too short |
| 15:46 |
muurkha |
sfan5: mostly since the first iPhone, I think |
| 15:47 |
celeron55 |
if i press a key or click a button, i consider the computer's utmost priority to be process anything related to it and show me the finished result as fast as possible. any animations are an absolutely silly, actually ridiculous, distraction from that goal |
| 15:47 |
celeron55 |
+to |
| 15:47 |
MTDiscord |
<luatic> No animations can feel somewhat janky |
| 15:47 |
Oblomov |
that flamegraph with vector.length eating up all the time … |
| 15:48 |
celeron55 |
it doesn't when you are the one commanding a thing to happen. and if you didn't command it to happen, it shouldn't happen |
| 15:48 |
MTDiscord |
<luatic> still an animation can make it feel smoother |
| 15:48 |
MTDiscord |
<luatic> for example in a chess game, if the pieces just teleport that's not very smooth |
| 15:48 |
celeron55 |
i don't want my screen wallowing around without my input. i press a button, thing happens instantly, and then the computer waits for me to ask me to do another thing |
| 15:49 |
celeron55 |
ask it* |
| 15:49 |
MTDiscord |
<luatic> of course the animation should be reasonably quick, and it should be finished as soon as the next command is received |
| 15:49 |
rubenwardy |
Most people find that animations make something feel more polished and fun to use, as long as it's a quick one |
| 15:49 |
celeron55 |
i hate fun |
| 15:50 |
jonadab |
Animations make a demo look more polished the first time you ever see it. |
| 15:50 |
MTDiscord |
<luatic> "i hate fun" - celeron55, 2023 |
| 15:50 |
jonadab |
But after you've seen the same animation a few thousand times, it gets _old_ |
| 15:50 |
MTDiscord |
<luatic> this explains minetest /s |
| 15:51 |
|
jaca122 joined #minetest |
| 15:51 |
celeron55 |
jonadab: 100% agree |
| 15:51 |
celeron55 |
i'm fine with animations, as long as they happen only once and i don't need to see them ever again |
| 15:52 |
jonadab |
I think it's fine to have them on by default, if the user can turn them off when they get tired of them. |
| 15:52 |
jonadab |
Then people who don't want to turn them off, can just... not do that. |
| 15:52 |
celeron55 |
the computer's job is to be an efficient extension of me, not to manipulate me to be happy or feel more things happen than actually does happen, or to make input given by me to cause more processing than is needed |
| 15:53 |
jonadab |
celeron55: Have you ever played Zork? |
| 15:54 |
celeron55 |
in other words, the job is very clearly defined, and animation does not help in reaching the goal |
| 15:54 |
celeron55 |
unless the animation is specifically designed to aid in visualizing something i want and need to have visualized |
| 15:54 |
jonadab |
(Zork has no graphics of any kind. And yet, it works.) |
| 15:56 |
celeron55 |
no i haven't played zork, but the concept is nice |
| 16:01 |
celeron55 |
luatic: chess is a good example of animation being a helpful visualization method. without animating the move, it is literally difficult to see what is happening if you're playing against an AI or a remote player. their hand isn't there moving the piece so you need to visualize the move. of course, you can visualize a move without animation. just draw an arrow from the old location to the new location |
| 16:02 |
celeron55 |
- i think i'd probably like that more than animation as you can look at it as long as you want to |
| 16:02 |
celeron55 |
and you don't need to wait for it to happen in order to see what happens. you can instantly see it fully |
| 16:29 |
erle |
i agree with celeron55, everything that stands in the way of computer doing the job is useless |
| 16:29 |
erle |
related https://en.wikipedia.org/wiki/Ornament_and_Crime |
| 16:30 |
rubenwardy |
to give some examples of animations I add - I add a slight transition on hover effects on buttons and such. I also add short fade in/out for modals. The former is non-blocking, the latter delays interaction I guess |
| 16:30 |
erle |
these fades always frustrate me |
| 16:30 |
erle |
and you are spot-on, the “non-blocking” kinda mitigates it |
| 16:32 |
erle |
there's a reason most users are not using compiz or commit linear algebra crimes on unsuspecting application windows |
| 16:32 |
erle |
(“i can see my terminals backside” type of crimes) |
| 16:32 |
|
LizzyFleck joined #minetest |
| 16:33 |
muurkha |
aren't most users using the moral equivalent of compiz these days? |
| 16:33 |
muurkha |
on Android, iOS, macOS, Microsoft Windows, and GNU/Linux |
| 16:34 |
erle |
i'm not sure. i mean compositing is one thing, but like, windows that fold up like airplanes or burn or so? |
| 16:34 |
erle |
definitely not aiding anything |
| 16:34 |
erle |
the genie-back-into-the-bottle animation on OS X at least shows you where the app went |
| 16:34 |
muurkha |
macOS has been doing that in every release for like 20 years I think? |
| 16:34 |
muurkha |
they also use it for "exposé" |
| 16:35 |
erle |
on android, you can turn it off. on ios … nope. for debugging your own app apparently you can! |
| 16:35 |
erle |
i have automated android app stuff (through appium) and the first time i tried it failed because i assumed computers are fast. but animations are not! |
| 16:36 |
erle |
and everything likes to be uselessly faded in/out or slide from some side (regardless of if it actually gives a usable spatial hint) |
| 16:36 |
erle |
to me it appears almost like people saw these spatial hints and were like “yeah but what if we do only the effect, without the meaning?” |
| 16:36 |
celeron55 |
the fact that you need to give a spatial hint means the UI is kind of screwed. i don't want to need to know where something "went" |
| 16:37 |
|
gregon joined #minetest |
| 16:37 |
celeron55 |
i want it to go where i want it to go, so i then automatically remember where i put it |
| 16:38 |
erle |
yeah, me too. but i read the reason why the windows button was named START is because they figured out if someone is given the task to do something that makes it more likely |
| 16:38 |
erle |
and assuming not all animations were useless all the time, i *guess* showing where a minimized window went is useful for some? |
| 16:38 |
erle |
(not for me, i have i3) |
| 16:39 |
muurkha |
celeron55: I have an easier time remembering positions than recognizing images, so it's helpful for me to see where things go |
| 16:40 |
erle |
something minetest-related btw. this bug report does not follow the template and is thus pretty useless to me (see my comment). anyone knows the correct inputs and outputs? https://github.com/minetest/minetest/issues/13946 |
| 16:40 |
muurkha |
(I have an easier time still with names, though) |
| 16:40 |
celeron55 |
the classic start menu or the modern equivalent which is an app gallery or launcher screen is pretty useful for beginners, but i don't like them in the long term. in the long term i set up direct keyboard shortcuts or start the application using the literal binary name. it's important for a software engineer to know the binary names of things. you end up in trouble if you don't. i do get it why normal |
| 16:40 |
celeron55 |
people like app galleries and launchers |
| 16:40 |
celeron55 |
but that doesn't have anything to do with animations. it's just yet another thing |
| 16:41 |
erle |
celeron55 btw what do you use? everyone i know ends up at i3 or sway or so on (which is pretty funny bc those are almost never preinstalled) |
| 16:41 |
celeron55 |
muurkha: recognizing images? what? |
| 16:42 |
celeron55 |
erle: i'd probably use i3 if i didn't get used to icewm a long, long time ago. icewm made me get used to a set of keyboard shortcuts that are completely incompatible with i3's ones and i'm very efficient with it so i have no need to change |
| 16:42 |
muurkha |
celeron55: hmm, I was thinking about alternative to putting things in places, but left out that link from my utterances |
| 16:42 |
|
rod_tout_court joined #minetest |
| 16:42 |
muurkha |
icewm has a great set of keyboard shortcuts |
| 16:43 |
erle |
celeron55 well that's fine ig |
| 16:43 |
celeron55 |
when i start a thing, i put it on one of my 12 workspaces, and i remember the workspace number |
| 16:43 |
erle |
i have fewer workspaces and they have names. like 3:chat |
| 16:43 |
muurkha |
I'm terrible at remembering numbers |
| 16:43 |
celeron55 |
and my workspace shortcuts are win+1234qwerasdf |
| 16:43 |
erle |
and when i start a thing they get put on that workspace |
| 16:43 |
celeron55 |
this is also the exact thing what disallows me from using i3 |
| 16:43 |
erle |
because you'd have to redefine all the keys? |
| 16:43 |
celeron55 |
i can browse through the workspaces in about 1.5 seconds if i don't remember what's where |
| 16:43 |
muurkha |
but workspaces on particular keys seems reasonable |
| 16:44 |
|
gregon left #minetest |
| 16:44 |
celeron55 |
because the shortcuts are optimally placed on the keyboard for the left hand |
| 16:44 |
erle |
i see, i should maybe adopt that |
| 16:44 |
celeron55 |
yeah i don't really remember the numbers i guess |
| 16:44 |
celeron55 |
i remember the workspaces by the shortcuts |
| 16:44 |
celeron55 |
finger positions |
| 16:44 |
erle |
i end up using fewer workspaces because 67890 are so far right |
| 16:44 |
erle |
now that you say it |
| 16:45 |
celeron55 |
i don't usually use all 12, i have 5 spare right now which is a good amount of spares |
| 16:45 |
* muurkha |
makes a joke about AfD |
| 16:45 |
celeron55 |
and 12 is enough, the need for more occurs super rarely |
| 16:45 |
celeron55 |
at that point i always can close something to free up both the computer's and my brain's resources |
| 16:46 |
erle |
celeron55 this is maybe related and cute: https://www.davidrevoy.com/article989/how-to-customise-a-usb-numeric-keypad-under-gnulinux |
| 16:48 |
celeron55 |
i think the world needs a modern implementation of icewm. maybe as a curated set of configs on top of another wm, or maybe as a fork of something, or maybe as a completely new thing. the focus would be on predictable classic behavior and snappy keyboard shortcuts. i tried MATE lately on one system but it's super clunky, it feels like a museum |
| 16:48 |
celeron55 |
a spiced up gnome shell is better than MATE |
| 16:48 |
celeron55 |
very resource hungry and kind of silly, but better anyway |
| 16:48 |
celeron55 |
gnome shell without some specific config changes and extensions is near useless though |
| 16:49 |
|
rod_tout_court joined #minetest |
| 16:49 |
erle |
gnome shell breaks extensions all the time though |
| 16:49 |
celeron55 |
i found one gnome shell extension that froze the entire system |
| 16:49 |
erle |
LOL |
| 16:49 |
celeron55 |
ridiculous, i know |
| 16:49 |
erle |
as jwz said: once is coincidence, twice is sabotage, three times is official GNOME policy |
| 16:50 |
celeron55 |
when icewm crashes (a rare occurence, but anything can happen), it just restarts and is like "huh, whatever" |
| 16:50 |
celeron55 |
or you get kicked out of X and back to tty or the dm |
| 16:50 |
celeron55 |
as for DMs, i hate all of them and just login on tty and type startx |
| 16:51 |
celeron55 |
my latest gried with DMs was with trying to set the dpi setting on my 4K display |
| 16:51 |
muurkha |
ugh |
| 16:51 |
celeron55 |
it was impossible to do in a way that would satisfy all WMs and applications |
| 16:51 |
celeron55 |
on the other hand with startx and xinitrc you can do things super controllably |
| 16:53 |
celeron55 |
gnome shell of course is able to force the dpi setting for everything using whatever magic, and it plays nice with gdm. but that's like saying apple's products are compatible with apple's products |
| 16:54 |
muurkha |
what's your preferred Wayland setup? |
| 16:55 |
celeron55 |
the only way i've used wayland is with gdm and gnome shell. and on my sailfish phone. so i guess those |
| 17:04 |
|
fluxionary joined #minetest |
| 17:14 |
celeron55 |
i should post my recommended gnome shell setup. it's always difficult to find everything that it needs |
| 17:16 |
celeron55 |
but that would mean deleting my current gnome shell settings, extensions, extension configs and miscellaneous gsettings options and redoing them all over |
| 17:16 |
celeron55 |
sounds like torture |
| 17:16 |
celeron55 |
maybe if i'd make a new user and diff all the config files |
| 17:17 |
jonadab |
That does sound easier. |
| 17:17 |
jonadab |
If you wanted to torture yourself, you'd be using Windows 10. |
| 17:17 |
celeron55 |
i still remember the time when linux people used to laugh at windows registry |
| 17:17 |
celeron55 |
these days... the windows people laugh at all the linux registries |
| 17:18 |
jonadab |
Eh, I stopped using Gnome a long time ago, for a whole lot of reasons. |
| 17:18 |
jonadab |
And the registry was never one of my main problems with Windows. |
| 17:19 |
celeron55 |
frankly i'm kind of impressed that you can set up gnome shell to be tolerable on a secondary computer. my expectation was it would be awful no matter what |
| 17:20 |
|
v-rob joined #minetest |
| 17:26 |
erle |
i think if the gnome people would stop removing things they personally don't like (e.g. theming) and would be backwards compatible their users would be much less upset. |
| 17:26 |
erle |
i mean GNOME managed to have both MATE and cinnamon fork off them, that's kinda impressive |
| 17:26 |
erle |
GNOME 4 fork when |
| 17:26 |
celeron55 |
here's one thing i don't understand in gnome shell: why don't they include a slider to adjust the sizes of window title bars |
| 17:27 |
celeron55 |
i get it that themes have their own sizes for them, but it's pretty common that i like a theme but the title bars are just the wrong size |
| 17:27 |
celeron55 |
i suppose their ideology is that title bars shouldn't exist to begin with |
| 17:28 |
erle |
aren't title bars rendered by the applications in current GNOME? |
| 17:28 |
celeron55 |
but why does that mean they need to be so big |
| 17:29 |
celeron55 |
i guess some are, as they include extra content in them |
| 17:29 |
erle |
if you want to theme anything, you are obviously soooo last-century: https://stopthemingmy.app/ |
| 17:29 |
celeron55 |
but e.g. think of something like gnome terminal |
| 17:29 |
erle |
> GTK Stylesheets can make applications look broken, and even unusable. |
| 17:30 |
erle |
:D |
| 17:30 |
celeron55 |
nobody uses the title bar buttons regularly to warrant them being so big |
| 17:30 |
celeron55 |
regularly enough* |
| 17:30 |
celeron55 |
the content is in the big black part, the title or the buttons there are almost meaningless |
| 17:31 |
celeron55 |
and take multiple lines of space |
| 17:31 |
celeron55 |
yeah of course what also happened is that gnome has bad options for dpi scaling |
| 17:31 |
celeron55 |
you can choose 1x or 2x |
| 17:32 |
celeron55 |
1x makes everything way too small, 2x makes everything slightly too big |
| 17:32 |
celeron55 |
on the 4k display |
| 17:32 |
celeron55 |
why is there no 1.75x or something, i don't get it |
| 17:33 |
celeron55 |
then there's an "extra large fonts" accessibility option which turns fonts from slightly too small to slightly too big |
| 17:33 |
celeron55 |
why not a slider or something |
| 17:33 |
celeron55 |
i love the high contrast accessibility option though, and the disable animations one also |
| 17:33 |
erle |
do they still have high contrast inverse? |
| 17:33 |
erle |
that one was really useful for me |
| 17:33 |
celeron55 |
dunno. what i used was the dark mode with the high contrast option |
| 17:34 |
celeron55 |
the high contrast option turhs the dark mode from smushy to crisp |
| 17:34 |
celeron55 |
turns* |
| 17:34 |
erle |
they should let desour handle their scaling obviously :D |
| 17:36 |
|
mrkubax10 joined #minetest |
| 17:51 |
|
Talkless joined #minetest |
| 17:51 |
|
fling joined #minetest |
| 17:52 |
|
v-rob joined #minetest |
| 18:22 |
copygirl |
I'm curious, how realistic is having multipart / microblock nodes that can be made out of different parts, such as panels, stairs, post, each potentially made of a different material? |
| 18:24 |
erle |
copygirl want to cobble together some entities or what? |
| 18:25 |
copygirl |
I think I was being clear about wanting nodes. Unless you're talking about block/node/tile entities? |
| 18:26 |
erle |
copygirl if i would want to do something, i'd probably do it like voxelmodel https://content.minetest.net/packages/Noodlemire/voxelmodel/ |
| 18:27 |
erle |
and yes, i'd associate the entity with the node. this is not available statically from the engine, but mineclon* echests for example are like that IIRC |
| 18:29 |
copygirl |
I would like different collission shape combinations as well but it might be possible to generate those programmatically, and reduce the amount of unique nodes registered that way. Though I doubt I'll be able to programmatically make textures for new unique combinations of microblocks as they're used. |
| 18:29 |
copygirl |
Then again I can't have dynamic textures for just basic nodes. I would need entities, after all. |
| 18:34 |
celeron55 |
the reason why nodes are performant and don't take lots of ram and disk space is because they are simple. adding complexity like that to them would slow down everything and use up multiple times the memory even if you don't use the features. it's the tradeoff an engine like this has to make. a compromise could be some kind of indirection layer that dynamically allocates and generates nodes based on |
| 18:34 |
celeron55 |
more complex data structures but that would require quite a lot of development work |
| 18:35 |
copygirl |
I've delved into voxel development and the lack of a per-chunk-palette limits the amount of stuff you can do such as dynamic node registration. That would really help in this particular case. |
| 18:35 |
copygirl |
bloxel game development* I should say |
| 18:36 |
erle |
can't you just make the player bigger or so |
| 18:36 |
celeron55 |
another option would be to make nodes dynamically sized, but that would require a dynamic node memory space in each mapblock which would have to be managed, and you'd get an extra layer of indirection and memory allocation overhead, so it would be slower |
| 18:36 |
copygirl |
Either way I was hoping to learn about something that is currently possible. |
| 18:36 |
celeron55 |
dynamically sized in memory, i mean |
| 18:36 |
copygirl |
Why? |
| 18:36 |
celeron55 |
not dynamically sized as in in-world physical size |
| 18:37 |
celeron55 |
and every node would then have size information which would in itself increase their size even on that basic level to begin with |
| 18:38 |
copygirl |
If you need more data you can either represent it as a new dynamically created node, or if it's common enough, as a new layer of data layered on top of existing data. |
| 18:38 |
celeron55 |
in order to have large generated worlds the most common case of simple nodes would have to be made fast and easy on memory, and then the system would have to be able to expand from that using a dynamic system of some sort. that's the basic idea and constraint |
| 18:38 |
celeron55 |
copygirl: yes what i said: that would require a dynamic node memory space in each mapblock which would have to be managed, and you'd get an extra layer of indirection and memory allocation overhead |
| 18:38 |
copygirl |
Node type could be one layer, block light another, sky light a third. And just the same, you could add any additional layer to a chunk, on demand, that holds custom information about blocks. |
| 18:39 |
celeron55 |
currently no allocation is needed, no indirection is needed, no memory management is needed |
| 18:39 |
copygirl |
Nodes themselves don't need to be dynamically sized in any of my suggestions. |
| 18:39 |
celeron55 |
it makes everything very fast and reliable |
| 18:40 |
copygirl |
With a palette based system, nodes are mapped to ids which depending on the number of unique blocks, those are dynamically sized, yes. But it has too many benefits to avoid using, in comparison to a fixed ID space. |
| 18:40 |
celeron55 |
layers like that are possible for sure, if you're ok with allocating a layer for all nodes in a mapblock even if only one node needs it and others don't. i personally like the idea of layers |
| 18:40 |
celeron55 |
i almost started a proof of concept of simple layers like that |
| 18:40 |
copygirl |
Palette based storage is very reliable and don't tell me about performance in a Lua modded game. |
| 18:41 |
celeron55 |
each was 8 bits per node, and i intended them to be dynamic all the way to Lua, each layer having a name |
| 18:41 |
copygirl |
Actually, unsure if it would even be slower. |
| 18:41 |
MTDiscord |
<greenxenith> What does lua have to do with engine performance |
| 18:41 |
muurkha |
copygirl: I benchmarked LuaJIT against Haskell's GHC this morning and it turned out to be orders of magnitude faster |
| 18:41 |
celeron55 |
performance matters a lot. you don't appreciate it until you see something that doesn't perform, and believe me, i saw a lot of that when i developed the core of minetest |
| 18:41 |
copygirl |
You either have a global hardcoded id => block lookup, or you have a palette id => block lookup. Same speed. |
| 18:42 |
muurkha |
[but that was because my benchmark was flawed] |
| 18:42 |
muurkha |
I was just testing function fib(n) if n < 2 then return 1 else return fib(n-1) + fib(n-2) end end |
| 18:42 |
muurkha |
which in retrospect is a stupid benchmark for a tracing JIT |
| 18:43 |
muurkha |
because tracing JIT will always inline the function-call operations and probably constant-fold away most of the arithmetic, so it's really just testing how deeply it traces |
| 18:44 |
celeron55 |
copygirl: i don't understand what you're trying to say. layers would obviously represent attributes of nodes, and rendering of nodes would then have to accomodate for the added attributes (or ignore them, for layers that are only meant to be used server-side, for example for physics or whatever) |
| 18:44 |
muurkha |
but I've seen lots of real problems where naive code in LuaJIT will outperform naive code in C++ or Haskell. just, not by orders of magnitude |
| 18:44 |
copygirl |
I was advocating for per-chunk palette based block storage here. |
| 18:44 |
copygirl |
I felt like you were questioning the speed of that. |
| 18:45 |
celeron55 |
palette means nothing to me |
| 18:46 |
copygirl |
Thing of an image. Instead of assigning each pixel a full RGBA color (32 bits) you could assign each existing color an index (for example 0=red, 1=blue, 2=transparent) and if that's all the colors you use in your image, now you can represent a pixel with just 2 bits. |
| 18:46 |
celeron55 |
anyway. if you have strong ideas, i recommend making a proof of concept |
| 18:47 |
celeron55 |
it's hard to 1) prove that you're serious, 2) prove that an idea can work, and 3) communicate how exactly it should even work, without a proof of concept |
| 18:47 |
copygirl |
The proof of concept is Minecraft. They use palette-based storage. Though you probably mean in Minetest itself? I really don't want to touch C++ code. |
| 18:48 |
celeron55 |
i don't see how what you describe would help, or even what problem it intends to fix |
| 18:48 |
copygirl |
The cool thing with a bloxel game is that you can have theoretically infinite different block types, because only the ones that exist within a chunk need to be references and mapped to a much smaller id. |
| 18:48 |
celeron55 |
oh you mean not having a game instance global id space but instead a block global id space |
| 18:49 |
celeron55 |
that makes sense |
| 18:49 |
copygirl |
Not sure what you mean. |
| 18:49 |
MTDiscord |
<mistere_123> Well, we already have both near-infinite mapgen and near-infinite content ids :trollface: |
| 18:51 |
copygirl |
Instead of having a single global id <=> block type mapping you would have an per-chunk id <=> block type mapping. |
| 18:52 |
celeron55 |
node ids are 16-bit in mapblocks, and that's enough to make every node in the mapblock have a different id, and it's compact as it should be. but currently globally node ids are also 16 bit. it would be possible to have 16-bit node ids in mapblocks mapped to 32-bit global node ids. the mapping would consume space and it would have to be maintained as nodes are removed and added to the mapblock though |
| 18:52 |
copygirl |
Why even have global ids? Map them to a name when saving, and to a block instance at runtime? |
| 18:52 |
celeron55 |
they already are mapped when saving |
| 18:53 |
celeron55 |
but a node is never represented by the name in memory. it's always represented by the id. thus, the need for global ids |
| 18:53 |
celeron55 |
the global id mapping is generated on world load time to contain all the registered node names |
| 18:54 |
copygirl |
Why is the mapping to a global ID necessary? |
| 18:54 |
celeron55 |
at the same time as the parameters of each node are set up |
| 18:54 |
celeron55 |
because names are more expensive than ids |
| 18:55 |
celeron55 |
and don't start about Lua. most processing in minetest happens in the engine for a good reason. it gets enormous speedup by dealing with ids |
| 18:55 |
MTDiscord |
<jordan4ibanez> Because if you do not do that and you changeout your mod loadout, all of a sudden certain IDs aren't mapped properly so water could be a bunch of fire |
| 18:55 |
copygirl |
Can't you refer to a block by the reference to the block instance? |
| 18:55 |
muurkha |
an index into a table of pointers to name strings (hashed or otherwise) is effectively a global id |
| 18:55 |
celeron55 |
refer where? minetest is full of world-global algorithms that go through a fast abstraction layer to mapblocks |
| 18:55 |
celeron55 |
you don't deal with mapblocks in algorithms |
| 18:56 |
copygirl |
jordan: I'm suggesting that in-world mapping is done with per-chunk palette. |
| 18:56 |
celeron55 |
the per chunk palette is dynamic |
| 18:56 |
celeron55 |
you can't use it to refer to stuff in the global interfaces |
| 18:56 |
rubenwardy |
plus makes it harder to compare between 'chunks' |
| 18:57 |
celeron55 |
at the instant you add a new type of node to a mapblock, or remove the last one of one type, the per-mapblock id space would be altered and you would have to adjust everywhere |
| 18:57 |
erle |
copygirl what is the case that you actually want to optimize for with your suggestion? |
| 18:57 |
celeron55 |
if you have an indirection layer per-mapblock to 32-bit global ids, then that's what you'd alter and everything else would stay the same |
| 18:58 |
celeron55 |
but then there's the argument whether it would be better to just have 32-bit node ids stored in each node |
| 18:58 |
copygirl |
This is the gist of it if you want to read it up: https://www.reddit.com/r/VoxelGameDev/comments/9yu8qy/palettebased_compression_for_chunked_discrete/ |
| 18:58 |
celeron55 |
it would probably be simpler and faster |
| 18:58 |
MTDiscord |
<mistere_123> I think the purpose is to remove the maximum number of content ids limit |
| 18:58 |
celeron55 |
than the extra mapping nonsense |
| 18:58 |
copygirl |
I think the code is not complete, and not implemented in the best way possible, but it outlines the idea, anyway. |
| 18:58 |
celeron55 |
stored in each mapblock* |
| 18:59 |
erle |
copygirl beautiful code is nothing without a problem to solve |
| 18:59 |
erle |
so what's the problem |
| 18:59 |
copygirl |
Palette-based storage would be a good first step to not having to worry about reaching any sort of maximum block types limit, and open the way to dynamic node registration at runtime. (For example for multipart blocks.) |
| 19:00 |
muurkha |
it would be simpler, celeron55, but it seems like it would use twice as much space |
| 19:00 |
copygirl |
It could also reduce the size of chunks on-disk and over the network, depends on if / how they get compressed at the moment. |
| 19:00 |
celeron55 |
copygirl: yeah that palette code there that you linked is pretty expensive computationally and memory wise |
| 19:00 |
muurkha |
so it might be faster or slower |
| 19:00 |
celeron55 |
it's not a very wise choice |
| 19:00 |
celeron55 |
i'd rather have 32-bit global node ids |
| 19:01 |
copygirl |
Woah you determined that by looking at it for .. less than a minute? |
| 19:01 |
copygirl |
Not even considering optimizations that could be done. |
| 19:01 |
celeron55 |
of course if you'd design a new engine or a fork of minetest solely based on the idea of that sort of palette, you could do things that are impossible with minetest's registered nodes system |
| 19:01 |
celeron55 |
but it's out of scope for us |
| 19:02 |
copygirl |
Yeah this conversation went a bit off-track and I apologize, but I was being questioned about a thing and I answered. |
| 19:02 |
celeron55 |
it would be a different type of engine on a fundamental level |
| 19:02 |
copygirl |
(And got defensive at times.) |
| 19:02 |
celeron55 |
i'd like to see it of course |
| 19:02 |
celeron55 |
so please go write the proof of concept |
| 19:02 |
copygirl |
(To be fair, I want to make it, so ...) |
| 19:03 |
copygirl |
I do want to point out that, again, Minecraft is technically the proof of the concept. |
| 19:03 |
erle |
why what can it do? |
| 19:03 |
celeron55 |
i don't see minecraft doing any of the actually interesting things the system would allow. they seem to be absolutely wasting it if they actually do have it |
| 19:04 |
copygirl |
Yeah, registrations of blocks are limited to startup time. |
| 19:04 |
celeron55 |
that system should allow essentially having a separate node registration table per mapblock (or in minecraft terms, chunk) |
| 19:04 |
celeron55 |
i don't believe they have that |
| 19:04 |
erle |
oof |
| 19:05 |
erle |
that sounds not like ”solution fits in head” |
| 19:05 |
copygirl |
But the palette-based storage is working fine for them. And I don't think there's a concernable performance loss due to it. Speedup is done by not using high-level access for things such as world gen and high-performance modifying of chunks using stuff like worldedit. |
| 19:05 |
celeron55 |
minetest uses a form of palette-based storage on disk. it fits the purpose very well. but the colors there are simply registered node names |
| 19:06 |
copygirl |
You can telle the palette to give you the ids of blocks that might or might not exist in the chunk, then commit all the changes you'd like to do (more) directly to the buffer. No need to risk multiple resizes. |
| 19:06 |
copygirl |
That would be a global palette, right? |
| 19:07 |
celeron55 |
once the server has started the server and clients talk about nodes by the global ids that the server assigns to node names at startup. it's the system minetest is build on, and it's fast and reliable and i'm pretty sure minetest will roll with it long into the future |
| 19:07 |
copygirl |
(TIL "mapblock" = "chunk", that sure was the cause of some confusion in this conversation.) |
| 19:08 |
celeron55 |
oh yes, that's the terminology here. i specifically use "mapblock" instead of "block" to avoid confusion |
| 19:09 |
celeron55 |
the first being the actual literal name of the data type in MT |
| 19:13 |
copygirl |
So I am to assume that it's not feasible to do a multipart block node in Minetest? While I doubt I want to use an entity per node in-world, what rendering capabilities do node-based entities have in MT? |
| 19:15 |
celeron55 |
MT doesn't have a good system for having masses of multipart nodes, anything you do will probably be pretty disappointing unless you begin by looking at developing the engine first in some fairly tricky ways (like some of the stuff i talked about initially) |
| 19:16 |
celeron55 |
entities are for actively moving or changing things that are few and far between in the world, and nodes are for masses of persistent things aligned with the grid |
| 19:16 |
celeron55 |
the thing in between doesn't really exist |
| 19:17 |
celeron55 |
and obviously is the more challenging thing to design and implement |
| 19:18 |
copygirl |
Well you can have per-node meta data storage. |
| 19:18 |
copygirl |
Just no custom rendering based on that. |
| 19:18 |
celeron55 |
yes, well node metadata based rendering has been fiddled with in the past... i made a proof of concept at some point |
| 19:19 |
celeron55 |
it was years and years ago |
| 19:19 |
celeron55 |
i modified the node definition to be storeable inside metadata, in which case you could assign any custom definition to any node in the world and modify it dynamically just for that node |
| 19:20 |
celeron55 |
the branch is probably in my repo on github |
| 19:20 |
celeron55 |
https://github.com/celeron55/minetest/tree/meta_set_nodedef |
| 19:22 |
celeron55 |
frankly it's a pretty interesting PoC, that's why i've saved it |
| 19:23 |
celeron55 |
it's from 2012 though, i don't remember whether we even had nodeboxes back then |
| 19:23 |
celeron55 |
with what today's node definitions can do, or even combining dynamic media with node meshes, it could get wild |
| 19:30 |
erle |
i have the feeling there is this specific threshold of simplicity that is somewhere |
| 19:30 |
erle |
and i do not know if it is on the other side or not |
| 19:30 |
erle |
btw, neat: https://garrit.xyz/posts/2023-11-01-tracking-sqlite-database-changes-in-git |
| 19:34 |
|
sparky4 joined #minetest |
| 19:50 |
|
fling joined #minetest |
| 19:50 |
copygirl |
Are node IDs 16 bit? So you can have 65000-ish of them? |
| 19:52 |
MTDiscord |
<wsor4035> half that |
| 19:52 |
MTDiscord |
<wsor4035> the other half is reserved for unknowns |
| 19:52 |
copygirl |
Unknowns? |
| 19:52 |
MTDiscord |
<wsor4035> when you remove a mod, whats left behind |
| 19:53 |
|
Sobinec joined #minetest |
| 19:56 |
erle |
these are known unknowns, things we know we don't know |
| 19:56 |
erle |
copygirl so what is your funny mod that generates lots of nodes? |
| 19:56 |
erle |
i am disappoint i can not make a node for each unicode character hahahahaha |
| 19:57 |
erle |
(i will not do that though) |
| 19:57 |
erle |
(inventory rendering would heat my computer into plasma) |
| 19:57 |
copygirl |
A multipart / microblock mod. |
| 19:58 |
|
appguru joined #minetest |
| 19:58 |
erle |
how small are the microblocks though |
| 19:59 |
copygirl |
Slabs, panels, posts, ... more like RedPower 2 if anyone remembers that, rather than, say, chisel and bits. |
| 20:00 |
copygirl |
If I was able to, I would love to pour concrete inside a block enclosed with panels for example, but I'll likely limit things to 1 material per node. |
| 20:02 |
copygirl |
Is Minetest's lighting propagation per-side? |
| 20:02 |
copygirl |
So can a slab let light through horizontally, but block it vertically (depending on whether it's a top or bottom slab). |
| 20:05 |
sfan5 |
it can't |
| 20:07 |
erle |
> limit things to 1 material per node |
| 20:07 |
erle |
how far can you fake this hehe |
| 20:44 |
|
fluxionary joined #minetest |
| 20:49 |
|
lemonzest joined #minetest |
| 21:30 |
|
v-rob joined #minetest |
| 21:34 |
|
fluxionary joined #minetest |
| 22:00 |
|
fluxionary joined #minetest |
| 23:29 |
|
sparky4 joined #minetest |
| 23:34 |
|
panwolfram joined #minetest |
