| Time |
Nick |
Message |
| 00:53 |
|
v-rob joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:55 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:59 |
|
calcul0n joined #minetest-dev |
| 08:36 |
pgimeno |
"Inventory rendering shows weird patterns depending on texture size. Could this be improved?" -> That looks like moiré. Do you want to include anisotropic filtering to the inventory rendering, just for this use case? |
| 08:38 |
pgimeno |
"The artifact in this screenshot is probably Minetest's fault. These kind of things just happen:" -> Moiré again. I believe activating mip mapping should do something about that. |
| 08:42 |
pgimeno |
Moiré happens even in commercial games, by the way. |
| 08:45 |
erle |
pgimeno yeah the thing is i tried combinations of mipmapping and anisotropic filtering and all it did was make textures mushy |
| 08:46 |
pgimeno |
of course... you can't expect "correct" rendering of that because it does not exist |
| 08:46 |
pgimeno |
the screeen simply does not have enough resolution |
| 08:47 |
pgimeno |
make a giant checkerboard texture in gimp and zoom it out - see what happens |
| 08:49 |
pgimeno |
there's even a checkerboard rendering filter in gimp if you want to try |
| 08:54 |
erle |
pgimeno well the weird banding thing looks definitely workse than whatever is to the left and right of it |
| 08:54 |
pgimeno |
at that distance maybe - I'm pretty sure it will vary with distance |
| 08:55 |
erle |
hmm, so i wonder if ultimately it has to do with the filtering being done in the wrong space |
| 08:56 |
pgimeno |
ultimately it has to do with the fact that the screen is made of pixels. It happens even in photography: https://i.ytimg.com/vi/ZFteoCptzvM/maxresdefault.jpg |
| 08:57 |
erle |
hmm, gimp does not have the kind of issues i see in minetest |
| 08:57 |
erle |
i wonder if it is because of better filtering or because the viewing angle is constant |
| 08:57 |
pgimeno |
gimp has anisotropic filtering for the scalings |
| 08:58 |
pgimeno |
not for the zoom out though |
| 09:00 |
erle |
pgimeno should i maybe focus on different patterns or increase the size of the checkerboard pixels if i want this to mainly address the fact that devtest is mostly 16×16? |
| 09:01 |
pgimeno |
maybe you just should stop asking for something impossible. Have you tried the same in Minecraft? |
| 09:02 |
erle |
i think you misunderstand me. this is not a feature request. there *are* issues with some texture sizes. like that (supposedly) driver issue i noticed on the edges of 2×2 and 4×4 and 6×6 nodes. non-16×16 texture sizes are simply not represented much in devtest. |
| 09:02 |
erle |
(and just because that one is a driver issue does not mean minetest does not have bugs related to it) |
| 09:03 |
pgimeno |
the issues on the edges are precision problems, again not something minetest can do anything about |
| 09:04 |
erle |
so do you think devtest should not have nodes for testing other texture sizes? i mean i can't think of a better thing to figure out the effects of various scaling and filtering issues rn, but that does not mean there isn't one. |
| 09:04 |
pgimeno |
if you want to test different texture sizes, a checkerboard pattern is not the best way |
| 09:04 |
erle |
then what would you suggest? |
| 09:05 |
erle |
i mean the more complicated patterns i can suggest all expose gamma-related rendering issues hehe |
| 09:05 |
pgimeno |
something that doesn't have these high-frequency high-amplitude issues; a softer texture |
| 09:06 |
erle |
uh, but pixel art is about exactly that? |
| 09:06 |
erle |
wait, let me look at my other test textures |
| 09:06 |
erle |
the one i made for tga_encoder |
| 09:08 |
pgimeno |
<pgimeno> the issues on the edges are precision problems, again not something minetest can do anything about <-- these are normally called "texture bleeding" in case you want to look it up |
| 09:09 |
erle |
pgimeno any of those better? https://mister-muffin.de/p/-408.png |
| 09:10 |
pgimeno |
probably, yeah |
| 09:10 |
erle |
then how would you parametrize them? |
| 09:10 |
pgimeno |
*shrug* |
| 09:11 |
erle |
so in what ways do you think they are better at helping diagnose issues? |
| 09:11 |
erle |
for example, the two orthogonal color gradients and a solid square, what does it help with? |
| 09:12 |
pgimeno |
they are better in that they have softer light intensity changes and lower frequencies where missing one pixel because it can't be rendered is not disastrous |
| 09:13 |
pgimeno |
in a checkerboard pattern, if you have black-white-black and the white pixel isn't rendered, you get two blacks and that causes moiré |
| 09:13 |
erle |
wouldn't adjusting the checkerboard with node size also help here? |
| 09:14 |
erle |
to keep the frequency constant |
| 09:14 |
pgimeno |
even at a distance? |
| 09:14 |
erle |
or almost |
| 09:14 |
erle |
well at some distances everything is going to be mushy |
| 09:14 |
pgimeno |
exactly |
| 09:14 |
erle |
but that's exactly the thing i want to test. |
| 09:14 |
erle |
like, “does anisotropic filtering help with viewing angle changes”? |
| 09:15 |
erle |
if you don't engineer tests to actually hit the painful edge cases, they aren't that useful to me. unless you don't want to hit those edge cases at all, but i do want to do it, to figure out issues. |
| 09:15 |
erle |
btw, again, any gradient exposes gamma handling issues (or am i wrong on this?) |
| 09:16 |
erle |
and it was agreed that gamma-correct rendering is not something minetest wants when i proposed gamma test nodes in the first place |
| 09:16 |
erle |
(it is also not *that* important for a pixel art game imo) |
| 09:17 |
pgimeno |
well, test it for yourself, convince yourself, and if you want to divulge your results, go ahead - but it's a fact that a chequerboard pattern is going to cause issues as long as the chequers are too small to fit in one pixel (and even earlier) |
| 09:18 |
pgimeno |
if you want to test different texture sizes, you can ignore any gamma issues |
| 09:20 |
erle |
pgimeno i'll think about it more, thank you |
| 09:24 |
erle |
pgimeno i have linked the conversation in the issue. what is your github username though? |
| 09:24 |
pgimeno |
it used to be pgimeno before I deleted my account when MS acquired it |
| 09:24 |
erle |
i see |
| 09:27 |
erle |
so no conversation on github then |
| 09:27 |
erle |
pgimeno what about a test pattern that has a single white pixel and a single black pixel in opposing corners and is otherwise a monochrome gradient? |
| 09:28 |
pgimeno |
the bleeding issues won't disappear; other than that, check by yourself whether that helps with moiré problems |
| 09:29 |
erle |
well the bleeding issues are just one problem that i quickly diagnosed using these things. figuring out minetest is not at fault is a good result, it means mesa is :P |
| 09:30 |
erle |
someone told me yesterday that mesa pretty much trades off accuracy for rendering speed nowadays |
| 09:31 |
pgimeno |
every GPU does that |
| 09:32 |
erle |
as i understand it, older mesa drivers in particular would fallback to slow software rendering if the GPU could not handle something – and nowadays they prefer fast, but as-accurate-as-the-GPU allows |
| 09:33 |
erle |
(mesa software rendering will render minetest on potato GPU with opengl 3.1, but it's obviously not going to be fast, just very accurate) |
| 09:34 |
pgimeno |
even if the accuracy was perfect (by that I mean respecting the ISO/IEC-559 standard), there's just so much you can obtain with single precision floats, and texture bleeding is just a natural thing to happen when using these. Maybe with doubles things would improve, but I'm not too convinced of that either; there's always edge cases where rounding problems surface. |
| 09:34 |
erle |
i have asked cheapie to investigate this (they have some hardware laying around already used to test rendering issues) and await the outcome if they do it |
| 09:35 |
erle |
yeah obviously accuracy is always a problem, but you can fake yourself through something. z-fighting issues with shadows/overlays? just step away from the wall a tiny bit before rendering hehe. |
| 09:37 |
erle |
i wonder why the bleeding happens only for small texture sizes though |
| 09:38 |
erle |
(i mean, the obvious answer is because no one uses these, so no one cares, but maybe one could sidestep that whole problem entirely somehow? no idea) |
| 09:39 |
erle |
anyways, i'[l try some other test patterns later. thank you! |
| 09:42 |
erle |
pgimeno btw, i don't think minetest is like other games in this regard. many other games do not want to preserve the pixel art appearance – or if they do, they use weird upscaling algorithms like hq2x and hq3x and so on. |
| 09:42 |
erle |
pgimeno what do you think of this proposal? https://jorenjoestar.github.io/post/pixel_art_filtering/ |
| 09:42 |
erle |
> apply neighbour/nearest filter on pixels that are fully inside a texel, and use bilinear with custom weights at the edges! |
| 09:46 |
pgimeno |
that's basically what I proposed in the love2d forum for 2D rendering; I don't think it's viable for 3D rendering |
| 09:48 |
pgimeno |
my exact proposal was to do a pixel-perfect scaling to the closest integer multiple of the target zoom factor (rounding down), then a filtered upscale of the result to the desired zoom factor, which achieves the same effect |
| 09:59 |
pgimeno |
found it, https://love2d.org/forums/viewtopic.php?p=243473#p243473 |
| 10:05 |
erle |
pgimeno why would it not be viable for 3d rendering? i mean it looks like it's a solution to not blur pixel art as much as it is blurred right now |
| 10:05 |
erle |
with any kind of filtering i can turn on in minetest right now that mitigates the moire issues, the small checkerboard starts looking like it got painted with watercolors on wet paper |
| 10:06 |
erle |
if it were upscaled before filtering, that would not happen, right? |
| 10:45 |
|
appguru joined #minetest-dev |
| 10:55 |
pgimeno |
that method is only applicable to a 2D texture rendered to the screen, it will be useless if applied to a texture which is then 3D-rendered. It might be doable with a shader, but I somehow doubt it to be practical. |
| 10:56 |
pgimeno |
The method is only useful for upscaling, not for downscaling. |
| 11:04 |
pgimeno |
A shader would need to sample the pixel to the left and right of the current one, determine whether they belong to adjacent pixels, and if so determine a weight for each of the pixels and apply a linear interpolation based on that weight. Same in the vertical direction. Costly. |
| 11:07 |
pgimeno |
And the algorithm for calculating the weight gets complex when the texture is not axis-aligned like in the 2D case. |
| 11:08 |
pgimeno |
It's difficult enough for rotated textures, but even more so if it's 3D-projected. |
| 11:10 |
pgimeno |
I wouldn't even want to begin to try to write an implementation, but be my guest if you think otherwise. |
| 11:12 |
erle |
pgimeno well as you can see in the last screenshot here, upscaling issues are a thing https://github.com/minetest/minetest/pull/13949 |
| 11:14 |
erle |
pgimeno “upscale with an integer factor and THEN scale with filtering” would reduce artifacts here somewhat, right? |
| 11:16 |
pgimeno |
in this case it would, the question is whether it's so common as to be worth even being concerned about it |
| 11:17 |
erle |
well i HAVE seen complaints about shitty node looks going years back, even with 16×16 |
| 11:17 |
pgimeno |
I'd say those who try using them, if they see the result is not satisfactory, will give up, and that's perfectly fine for such a niche use case |
| 11:17 |
|
turtleman joined #minetest-dev |
| 11:18 |
erle |
again, you misunderstand the issue here |
| 11:18 |
erle |
these things happen with 16×16 textures as well |
| 11:18 |
erle |
i am just pointing out where they happen MORE |
| 11:19 |
|
calcul0n joined #minetest-dev |
| 11:19 |
pgimeno |
I'd just call it a limitation of the engine and move on |
| 11:19 |
erle |
also i don't think “turn off filtering” is good advice if you can reduce the artifacts it produces |
| 11:19 |
erle |
come on |
| 11:20 |
erle |
”limitation of the engine” when a simple solution exists means “improve rendering” is entirely worthless as a roadmap goal. |
| 11:20 |
pgimeno |
if it were simple, maybe you should be able to implement it? |
| 11:20 |
erle |
i believe in TDD. a failing test case is the first step. |
| 11:21 |
erle |
only then i can figure out how to approach it – and you already gave me a good idea. |
| 11:21 |
erle |
btw, i think i should have both high-frequency and low-frequency things on the texture |
| 11:22 |
erle |
or maybe just make some checkerboards that are always 2 white and 2 black pixels, but at different resolutions |
| 11:22 |
erle |
to figure out where exactly scaling hurts |
| 11:24 |
pgimeno |
if you upscale a 16x16 texture, you're going to use more GPU memory - that's bad |
| 11:25 |
erle |
yeah but if i upscale a 8×8 texture to 16×16 to get less blurry rendering that is good right? |
| 11:25 |
erle |
also this could be adjustable anyway |
| 11:25 |
erle |
like all advanced rendering options are |
| 11:25 |
erle |
one moment, i am going to make improved checkerboard textures |
| 11:27 |
pgimeno |
you can easily apply the method I suggested in the forum post I linked before, with gimp |
| 11:29 |
pgimeno |
make a 3x3 texture with a 3x3 chequerboard pattern, then upscale it to 15x15 (5X zoom) with nearest neighbour, and then to 16x16 with linear filtering |
| 11:44 |
erle |
pgimeno left is nearest neighbour, middle is linear filtering, right is combined. looks good! https://mister-muffin.de/p/uvHE.png |
| 12:15 |
rubenwardy |
I wish IRC had threads so I could just not open this |
| 12:18 |
celeron55 |
let's make the bot kick everyone who doesn't start their message with a thread tag (let's say [foobar]) and then everyone can script their clients to handle that |
| 12:22 |
celeron55 |
(i'm half serious. it could work and make irc permanently a better place) |
| 12:25 |
erle |
i'd rather have had this discussion on github actually, but pgimeno is not there and it yielded an interesting idea (the one about texture scaling that preserves pixel art style) |
| 12:25 |
erle |
what about mailing lists |
| 12:25 |
erle |
(i am only half-joking) |
| 12:26 |
erle |
on-topic, what do you two think about “upscale by an integer amount and then filter” as an option? i think it could definitely fix some of the more annoying tradeoffs |
| 12:27 |
[MTMatrix] |
<Zughy> or you could have that discussion in private on IRC |
| 12:27 |
rubenwardy |
erle: that's already an option |
| 12:27 |
erle |
rubenwardy oh, i did not know! what do i need to do? |
| 12:29 |
rubenwardy |
texture_min_size = 32 |
| 12:29 |
rubenwardy |
documentation seems off |
| 12:30 |
rubenwardy |
ahh, this PR changed the docs #13683 |
| 12:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/13683 -- Clean up texture filtering settings by grorp |
| 12:31 |
rubenwardy |
that setting used to be more than just world-aligned textures |
| 12:31 |
rubenwardy |
yeah looks like that PR removes this option |
| 12:32 |
erle |
that is unfortunate |
| 12:37 |
celeron55 |
i think upscaling and then filtering would be a good feature |
| 12:39 |
celeron55 |
Desour claims in the original issue #13108 that doing that is ridiculous, but it kind of isn't when rendering is designed for high-res textures and the high-res version of pixel art is upscaled pixel art. you could of course render the entire screen at a higher resolution and then filter. i belive that's supported, right? |
| 12:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/13108 -- Remove/redo bilinear filter settings |
| 12:40 |
celeron55 |
believe* |
| 12:40 |
celeron55 |
but i don't think it's necessarily as effective, especially when considering performance |
| 12:44 |
celeron55 |
the thing about textures ending up mushy which erle claims anisotropic filtering does can be the correct thing to happen. if you scale a grid of black and white squares down far enough, what you should get is plain gray |
| 12:44 |
celeron55 |
if you get something else, it's illogical and probably noisy on movement |
| 12:47 |
celeron55 |
anyway, i believe upscaling and filtering does get a bit more detail out of a low screen resolution |
| 12:49 |
erle |
celeron55 but i am *upscaling* things |
| 12:49 |
erle |
i mean downscaling is expected to flatten everything eventually and minetest is known buggy there bcause gamma-related things, but the help text in the interface even says it is not gamma-correct |
| 12:49 |
celeron55 |
and yes, i admit there was too much text to read on this channel and i just responded to the latest lines |
| 12:50 |
celeron55 |
don't assume i read anything |
| 12:50 |
celeron55 |
or that i will continue to read anything... |
| 12:50 |
erle |
if you arrived at “i think upscaling and then filtering would be a good feature” you are at the point where i am and i read everything, so … ^_^ |
| 12:56 |
erle |
btw, i think the most annoying scaling artifacts occur with scaling of game icons in the main menu. i just checked and that seems to be still true. |
| 12:56 |
rubenwardy |
the issue says that upscaling was removed in favour of using GL_NEAREST |
| 12:56 |
rubenwardy |
which is quite an assumption, Minetest shouldn't always have to be pixel art |
| 13:00 |
pgimeno |
I don't think the setting did what should be done to get rid of the blurriness, anyway, namely upscale with GL_NEAREST to the next integer factor, then with GL_LINEAR to the final resolution |
| 13:01 |
pgimeno |
anyway, I doubt it helps in any circumstance other than with the aniso filter |
| 13:03 |
celeron55 |
yeah that filter is how the thing intended to be run (at least now) |
| 13:03 |
celeron55 |
whether erle's laptop can support the aniso filter is another question... |
| 13:05 |
pgimeno |
I still think that supporting this use case is overkill, and considering lack of support for that scenario a limitation of the engine is the right thing to do |
| 13:08 |
celeron55 |
probably so. i mean, there are more important things to consider |
| 13:10 |
erle |
celeron55 i think “making fun of me based on random ideas about what my hardware can do” is the first thing i'll suggest if there ever is a code of conduct :P |
| 13:12 |
erle |
(in fact, my computer seems to be *much* more limited by world generation than rendering) |
| 13:13 |
celeron55 |
i will insist on adding on the code of conduct that one is allowed to make fun of 15 year old hardware being used to run modern software |
| 13:13 |
erle |
well it got modern drivers |
| 13:15 |
rubenwardy |
not sure I'd call Minetest modern software yet :) |
| 13:16 |
[MTMatrix] |
<localhost> is just normal software, no old, no modern |
| 13:17 |
erle |
anyways, again: i have like 30fps with view range 100 in minetest_game, 45fps on fullscreen es2gears, firefox can play videos … it's not like software *has* to become slower as hardware gets faster. |
| 14:15 |
|
Desour joined #minetest-dev |
| 14:18 |
|
appguru joined #minetest-dev |
| 14:21 |
|
appguru joined #minetest-dev |
| 14:29 |
Desour |
re blurriness and anisotropic filter: something that I didn't know back when I opened #13108 is, that some platforms don't support setting anisotropic filtering and bilinear upscaling independently. if anisotropic filtering makes your textures blurry, consider changing your settings. the blurriness of bilinear upscaling is usually, afaik, wanted, so you'd not want to get rid of it again by nearest neighbor upscaling all textures. as said in the issue, |
| 14:29 |
Desour |
ideally modders should decide whether the texture should be upscaled via bilinear filter (i.e. if they didn't use pixel art). |
| 14:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/13108 -- Remove/redo bilinear filter settings |
| 14:38 |
MTDiscord |
<warr1024> The purpose of trilinear filtering in downscaling is to achieve the things that mipmapping set out to achieve, i.e. to eliminate moire effects, but without the jarring transition between mip levels that plain mipmapping has. The purpose of bilinear/trilinear in upscaling is to eliminate stairstep effects in non-screen-axis-aligned texel boundaries, i.e. poor man's antialiasing. |
| 14:40 |
MTDiscord |
<warr1024> If I could enable aniso without linear, I would, but given the choice between a little blurring vs the 1990 software renderer look, I'd rather look for mitigation for the blurring than have to crank my view distance way down just so the distant terrain doesn't make me dizzy. |
| 14:49 |
erle |
i can indeed confirm that enabling anisotropic filtering blurs literally everything (using the 7x7 texture set). and i don't think the minimum texture size thing even helps there (or i did something wrong when setting it to 256). |
| 14:50 |
erle |
Desour you say “ideally modders should decide whether the texture should be upscaled via bilinear filter”, but … they can already do that themselves. by providing upscaled textures? |
| 14:51 |
erle |
cursed idea: just let the texture pack supply the mipmaps so you can make houses that are invisible from some distance :P |
| 14:52 |
MTDiscord |
<warr1024> Minimum texture size at 256 used to be a pretty good mitigation for me unless I went and shoved my face in some nodes (which I don't usually do) but obviously it hasn't been working quite as well since the feature was removed... |
| 14:53 |
erle |
no anisotropic filtering for me then ig |
| 14:54 |
Desour |
whether bilinear upscaling is done for a tile depends on the settings and not on tiledef. upscaling textures doesn't change this. and always enabling bilinear filter, and forcing modders to upscale their textures to work around the blurriness sounds horrible |
| 14:54 |
MTDiscord |
<warr1024> It would be nice if we had something like CSS's image rendering with a "crisp pixels" option. But CSS crisp pixels actually still antialiases, which I would like to be able to do without having to turn on FSAA... |
| 14:54 |
erle |
though i can't pinpoint exactly where the regression is, since i don't have these filters turned on usually (to prevent the kind of 1990s renderer look) |
| 14:54 |
MTDiscord |
<warr1024> Yeah, I'd rather not have to ship larger textures with duplicate pixels, only to force players to eat up more VRAM. |
| 14:55 |
erle |
guess i should simply make some checkerboard test nodes with a 2×2 pattern (but like 4×4, 8×8, 16×16, 32×32) to figure out filter effects. i'll be doing that now. |
| 15:02 |
Desour |
what regression? |
| 15:03 |
erle |
well, maybe i misunderstood it. but smaller textures used to be upscaled to min texture size before being filtered? or am i wrong here? |
| 15:04 |
erle |
(i man, this preserves the pixel art look with filters and was at least what pgimeno suggested) |
| 15:11 |
pgimeno |
ruben said that the texture_min_size setting was for that purpose but I doubt it was applied that way |
| 15:12 |
erle |
and yet desour called it a workaround, hmm. Desour have a test case that shows the before-after for the refactoring of the filtering thing? |
| 15:12 |
Desour |
have you actually read through all the relevant PRs and issues linked before? I don't want to explain to you what was changed and why if it's already described issue descriptions |
| 15:12 |
erle |
like a devtest node i can place or some small mod or texture set |
| 15:13 |
erle |
(or simply a screenshot and means to reproduce that scene) |
| 15:17 |
pgimeno |
# |
| 15:17 |
pgimeno |
oops |
| 15:23 |
pgimeno |
thinking twice about it, if texture_min_size just did nearest neighbour upscaling, it would work well in most situations |
| 15:25 |
erle |
nearest neighbour upscaling is so damn ugly (look at the game icons in the main menu, some funny people make like 103×103 icons or so) |
| 15:27 |
pgimeno |
it works perfect for powers-of-two sized textures when texture_min_size is itself a power of two, and it works well for textures with a size much smaller than texture_min_size; the problem is e.g. if texture_min_size=32 and the texture size is 24 |
| 15:28 |
pgimeno |
that's not very common ig |
| 15:28 |
jonadab |
Do people make textures that aren't a power-of-two size? WHY would people do that? |
| 15:30 |
erle |
yes, they do. the reason is pixel art aesthetics, as far as i can tell. there is a 7×7 texture pack on cdb and a friend worked on a 5×5 texture pack some time pack. |
| 15:31 |
erle |
at these low sizes, there is no feasible way to upscale these to powers-of-two-sizes and keep the crisp edges unless you go like *really* high. |
| 15:31 |
rubenwardy |
erle: try texture min size on 5.7.0 |
| 15:31 |
[MTMatrix] |
<Zughy> In pixel art sometimes 16x16 is not enough and 32x32 is too big I guess (so you go 24x24). But take it with a grain of salt jonadab, I've worked very little with 3D projects |
| 15:32 |
pgimeno |
erle: try upscaling a 7x7 texture to 32x32 with nearest neighbour |
| 15:32 |
* erle |
coughs and whispers “minetest-icon-24x24.png” |
| 15:32 |
erle |
exactly the case zughy mentioned btw |
| 15:47 |
|
Oblomov joined #minetest-dev |
| 15:48 |
jonadab |
7x7, now I've heard everything. |
| 16:32 |
|
LizzyFleck joined #minetest-dev |
| 17:04 |
|
fluxionary joined #minetest-dev |
| 17:20 |
|
v-rob joined #minetest-dev |
| 17:52 |
|
v-rob joined #minetest-dev |
| 19:58 |
|
appguru joined #minetest-dev |
| 20:44 |
|
fluxionary joined #minetest-dev |
| 21:30 |
|
v-rob joined #minetest-dev |
| 21:34 |
|
fluxionary joined #minetest-dev |
| 22:00 |
|
fluxionary joined #minetest-dev |
| 23:34 |
|
panwolfram joined #minetest-dev |
