Time Nick Message 05:29 MTDiscord I can't comment on whether they're a disaster, but without them, mipmapping is a disaster 05:30 MTDiscord Unless anything has changed, my screenshots showing the terrible moire effects when everything is disabled, and the blurring and harsh depth boundaries with only mipmapping, still stand. 09:37 [MatrxMT] celeron55: we need you to rename these rooms into #luanti and the like (don't know if he's online) 09:45 celeron55 i'll try to rise that higher up on the to-do list 10:58 sfan5 Warr1024: i believe the mipmapping issue is adressed by https://github.com/minetest/minetest/pull/15603/commits/83764574b0b335bbdff09475625d53c81c5f508d 10:59 sfan5 there is no direct relation to bilinear/trilinear *except* for the fact that texture_min_size is not applied if you enable only mipmapping 15:21 mark-wiemer sfan5: Hope I'm not being too much of a bother. Anything I can do to help get #15510 merged? 15:21 ShadowBot https://github.com/minetest/minetest/issues/15510 -- Add vcpkg.json and related files for building on Windows by mark-wiemer 15:37 MTDiscord sfan5, I'll have to take a look at it and see if I can get some screenshots 15:43 [MatrxMT] celeron55: thank you. It'd be nice to have all the renaming stuff done before FOSDEM (January 31) so not to confuse new hypothetical contributors. I'm talking also about the organisation on GitHub 15:43 [MatrxMT] We're currently at 30 out of 39 16:58 sfan5 ~tell mark-wiemer fastest way would be to find someone else of the core developers to review it, sorry 16:58 ShadowBot sfan5: OK. 16:58 MTDiscord @mark.wiemer ๐Ÿ‘† 17:23 grorp merging #15602 in 5 17:23 ShadowBot https://github.com/minetest/minetest/issues/15602 -- TouchControls: More methods instead of static functions by grorp 18:02 Krock grorp: 5 what? 18:03 sfan5 banana 18:03 grorp 7-minute-blocks 18:10 Krock banana'd 18:10 sfan5 grorp: you are using the nvidia proprietary driver on Linux, right? 18:11 Krock (FYI if there's something to test on an NVIDIA Pascal card, I could try too) 18:23 grorp sfan5: yes, I am 19:24 sfan5 Warr1024: I found out my changes are rubbish so you can skip testing them. do you still stand with this opinion? https://github.com/minetest/minetest/issues/14007#issuecomment-1817199368 19:27 MTDiscord Yes, that sums up my opinion on the subject, at least until improvements come around that don't turn out to be rubbish :-) 19:29 sfan5 I am proposing limiting *linear filtering to high-res textures (e.g. >256px) in the engine so users don't turn their MTG into a blurfest when checking all boxes in settings. 19:29 MTDiscord What I really ideally want is "crisp" upscaling (nearest neighbor with antialiasing along texel boundaries at least) and anisotropic downscaling (no moire effects, no blur, and no visible mip-level transitions). Our existing options make the downscaling option possible, to the limit of the hardware's accuracy. The upscaling option is currently not truly possible, but enough VRAM + trilinear + texture_min_size fakes it up to a certain 19:29 MTDiscord limit. 19:30 MTDiscord Limiting filtering to "large enough" textures would work fine with the texture_min_size hack. I wouldn't hard-code it, but it's fine to have a pretty high default. 19:31 MTDiscord (as long as you base it on the post-texture_min_size-scaled textures, I assume) 19:31 sfan5 texture_min_size would be removed. there is no need to fake high-res to avoid blurring if you disable the linear scaling in the first place. 19:32 sfan5 so if you use the theoretical future state + aniso I think it should get you close to what you want 19:32 MTDiscord Like I just said above, it's necessary to get intratexture antialiasing with our current pipeline. 19:33 MTDiscord I don't think you should remove it until the engine has the capability to reach the level of visual quality possible with it, without tanking framerate. 19:33 sfan5 I don't know what exactly you mean but do you use any antialiasing mode in your settings? 19:34 MTDiscord I've played around with them, but either they don't do anything (or not enough at least) or they cause painful framerate loss. Texture filtering is pretty close to "free" though. 19:35 Desour IIRC, on some hardware you can't turn on anisotropic filtering without automatically also enabling bilinear filter in both mag an mini. so we'd still need texture min size for nice anisotropic rendering 19:35 MTDiscord If you look at any of my screenshots on CDB, pretty much any "anti-aliasing" you're seeing on there is actually from texture filtering. 19:36 sfan5 Desour: so far the "some hardware" report we had is erle on with opengl 1.4 19:36 MTDiscord oh, yeah, I forgot that if we lose aniso because we're not allowed to use linear filtering, that will screw things up too. 19:36 Desour sfan5: huh, I thought it was also you 19:36 MTDiscord No, that'd be me 19:36 Desour also happens mesa llvmpipe, fyi 19:37 MTDiscord I've never seen a system that allows using aniso with nearest. Must be only newer systems or something. 19:37 Desour my amd vega 8 (bought 2018) can do it 19:37 MTDiscord sorry for interrupting the discussion, but new poc just dropped: #15606 19:37 ShadowBot https://github.com/minetest/minetest/issues/15606 -- Allow overriding fonts via media files (PoC) by appgurueu 19:38 sfan5 works fine on my RX 6600 19:38 sfan5 on grorp's nvidia setup too 19:38 MTDiscord It's already painful enough telling people "you have to manually fix the gamma", I'd hate to have to tell people "if you want the game to look as good as the screenshots, you have to use this 256px texturepack" 19:39 Desour apropos gamma, we should use srgb texture types, so textures don't look darker if you look anisotropicly on them 19:39 MTDiscord If we made a dedicated GPU a requirement, how much of our audience would we lose though? 19:39 MTDiscord Desour: since you're here, can we go ahead and merge docs#115? 19:40 MTDiscord ah dangit 19:40 Desour @warr my gpu is an itegrated, fyi 19:40 MTDiscord https://github.com/minetest/dev.luanti.org/pull/115 19:40 MTDiscord (Lua code style guidelines dev.luanti.org PR) 19:41 Desour luatic: ah yes, sure 19:41 MTDiscord alright, thanks 19:42 MTDiscord I don't think it's possible to get rid of linear filtering (and correspondingly, the texture_min_size hack) without abandoning support for fixed-function rendering pipelines, because the whole "must linear before you can aniso" shit seems to be a quirk of some common implementations of that pipeline, at least. 19:43 sfan5 "without abandoning support for fixed-function rendering pipelines" I have good news for you 19:43 MTDiscord If we're moving to a pure-shader-based pipeline where we can do things like software-defined filtering, that sounds good to me (assuming we can make it perform like non-ass) 19:44 sfan5 if you want to do the filtering on your own the gpu is the right place for it 19:44 Desour "must linear before you can aniso" <- if the texture says it's linear, the gpu should mix it linearly, obviously 19:45 Desour eww, don't do texture filtering in the shader 19:45 Desour the gpu has extra hardware so we get filtering for free 19:45 Desour basically free 19:46 MTDiscord There exist apparently-decent algorithms for "crisp" pixel rendering in 3D (i.e. without the blurring of linear, and without the jagged edges of nearest) which we could probably do with a shader-defined pipeline, and I'd be really interested to see in the real world. 19:46 Desour and if you want to do anisotropic filtering, you'd even have to sample several times 19:46 sfan5 Desour: I mean filtering which the gpu does not have built in 19:47 MTDiscord Yes, the point here is NOT to get filtering, that's what we want to get rid of, because naively it blurs pixels that we want to stay crisp. 19:47 sfan5 for example like this https://github.com/minetest/minetest/blob/27c3aade5dc689db3e4eaa9c7273584bee6527ee/client/shaders/nodes_shader/opengl_fragment.glsl#L310-L313 19:48 MTDiscord The problem with just going with nearest sampling is that we get jagged texel edges in upscaling, and we get moire effects from downscaling. 19:48 MTDiscord otherwise this would all be really easy :-D 19:50 Desour sfan5: but do we want such a filtering for normal textures? I don't think so 19:51 Desour @warr1024: the jagged edges should probably be mitigated with more antialiasing options. temporal aa maybe? 19:52 MTDiscord AA options themselves won't help; what we need is the right AA option that fixes the problem, AND doesn't significantly increase the rendering cost. 19:52 MTDiscord What is even temporal AA? Sounds like motion blur or something... 19:53 sfan5 Warr1024: any complaints with this screenshot? https://0x0.st/8slR.jpg 19:55 MTDiscord Ouch, please include a Content Warning when you're going to post moire effects like that ๐Ÿ˜„ 19:55 Desour @warr: https://en.wikipedia.org/wiki/Temporal_anti-aliasing?useskin=vector (yes, it can cause blurriness) 19:55 MTDiscord I had to make sure it wasn't my client causing the effect but it actually got worse when I expanded it to full size. 19:56 MTDiscord So temporal AA sounds like it hides jaggies by just jiggling the camera by some tiny subpixel amount, so that you use the viewer's own brain to combine the samples ... ๐Ÿค” 19:56 Desour sfan5: do you notice how the bricks are more red and less white in the upper corner? 19:56 MTDiscord Well, that won't work when the fps drops down to like 8 anyway 19:56 sfan5 Desour: yes. I know it's gamma incorrect 19:57 Desour :) 19:58 MTDiscord I'm less concerned about the change in brightness at different angles of incidence, as I am about that weird line running diagonally through the pattern with the starburst effects around the middle, like ringing artifacts. 19:58 sfan5 so what you want is this, right? https://0x0.st/8sl7.jpg 19:59 MTDiscord Yeah, second screenshot is immediately notably better. 20:00 sfan5 that's only doable with the texture_min_size hack as it is 20:00 MTDiscord Had to check the rail and the stone, but I didn't see any notable difference there. The brick however is immediately noticeabl. 20:00 sfan5 the stone is a bit blurrier if you look closely 20:01 MTDiscord I thought it might be "blurrier" but I think it's more like random highlight pixels aren't leaking through the downscale. I don't we're losing contrast in the filtered version so much as we're exaggerating contrast in the unfiltered one. 20:01 sfan5 anyway the the first one mipmap, aniso, FSAA @ 4. second is that plus bilinear and min_size=256 20:02 sfan5 compared to stock settings the moire is already much reduced in the first one and personally I'd rather have that than blurry textures 20:02 Desour sfan5: oh, maybe your gpu doesn't do aniso properly if you don't enable bilinear 20:02 MTDiscord For me, mipmap + aniso is just mipmap unless filtering is enabled, and FSAA @4 means 2fps. 20:02 sfan5 it does 20:04 sfan5 well I can't judge "properly" but it does have an effect on its own 20:04 MTDiscord It sounds kind of like there was some common aniso implementation that was commonly used across GPU vendors (I've seen it from intel, matrox, ATI, STB, I think early nVidias) but some higher end makers started supporting aniso w/o filtering, and others just didn't bother because for most use-cases, texture resolution was increasing fast enough that most users wouldn't notice, or something. 20:05 MTDiscord I play with trilinear, aniso, texture_min_size 256, and no AA. I have to tolerate jaggies on geometry, but at least on large surfaces there's nothing that stands out like that, and importantly, certain stuff like glass renders correctly at a distance. 20:06 MTDiscord I think my only AA options are FSAA, which kills framerate, and one of those early "clever" AA options that doesn't actually work. 20:06 Desour oh, tested, I noticed I also get more artifacts with nearest + aniso than with trilinear (or bilinear) + aniso 20:06 Desour like in sfan's screenshots 20:08 sfan5 Warr1024: this is "trilinear, aniso, texture_min_size 256". I double checked https://0x0.st/8sUs.jpg 20:08 Desour btw., do we currently set a lod bias or something similar? 20:08 MTDiscord it really looks like your trilinear is broken, let alone aniso, with those moire effects... 20:08 sfan5 we don't. I proposed it in #15603 but dropped it when I found out that "mipmap + aniso" is the perfect combo already 20:08 ShadowBot https://github.com/minetest/minetest/issues/15603 -- [no squash] Rendering tweaks/improvements/debug features by sfan5 20:09 MTDiscord many why the hell do GPU-specific interpretations of the exact same options differ so damn much? 20:09 Desour I see, thx 20:10 Desour warr: because the standard doesn't specify it I guess x) 20:10 MTDiscord lol, it's gotta specify whether aniso implies doing aniso or not XD 20:11 MTDiscord Like, that last screenshot from sfan looks like it's just pure nearest downscaling. 20:11 sfan5 https://0x0.st/8sU-.jpg <- what mesa's software renderer makes of the same options 20:11 MTDiscord haha, amazing 20:11 Desour well, you can only set a *max* aniso factor, so the driver may also just take 1 instead 20:12 MTDiscord Yeah, I'm kind of inclined to trust the reference renderer as reference :-) 20:12 sfan5 I believe the standard says the max_samples must be at least 2, Desour 20:12 Krock Mesa looks very smooth here, though. 20:13 Krock (by which I mean that I'd prefer that over the other) 20:14 MTDiscord Mesa looks very close to what I see in hardware with those options. At least artifact-wise, that's what I expect, and what I personally think the default look of MT should be (as unblurry as possible, but no moire artifacts first) 20:14 Desour https://registry.khronos.org/OpenGL/extensions/EXT/EXT_texture_filter_anisotropic.txt <- you set a maximum degree, is what I meant 20:14 sfan5 yes but 20:14 sfan5 What should the minimum value for MAX_TEXTURE_MAX_ANISOTROPY_EXT be? 20:14 sfan5 RESOLUTION: 2.0. To support this extension, at least 2 to 1 20:14 sfan5 anisotropy should be supported. 20:15 MTDiscord Hmm, so hardware can't pretend it supports aniso if it only supports single-sample, but maybe it can allow single-sample to be chosen in options? 20:16 Krock driver bugs may exist too 20:16 sfan5 I'm not sure what mesa is doing but enabling ansio changes from ~70 fps to like 1-5 fps 20:17 sfan5 (the sofware renderer I mean) 20:17 MTDiscord Driver bugs MAY exist but I'm unwilling to blame the weirdness of sfan's results on that quite yet :-) 20:17 MTDiscord yeah, CPU software renderers are kinda trash 20:17 sfan5 "Implementations are also permitted to ignore the minification or magnification filter and implement the highest quality of anisotropic filtering possible." 20:17 sfan5 seems sus 20:17 MTDiscord It's possible that it just defaults to an insanely high number of samples, too 20:17 sfan5 well yes, MT asks for 255 samples 20:17 MTDiscord haha 20:18 MTDiscord I guess that's reasonable if you want to offer a checkbox and assume no vendor would offer such a high sample count that it would make their FPS look bad. 20:18 MTDiscord we COULD make that an integer setting instead ๐Ÿค” though I'm not sure it's worth it...? 20:18 Desour oh, you mean software renderer *supports* 255 samples? O_o 20:18 sfan5 hmm i dont think that's it. changing it to 16 does not change the result or performance 20:19 MTDiscord It's a software renderer, and, I suspect, intended to be a "reference" renderer of sorts, so I wouldn't be surprised if there's effectively no cap on certain operations. You might be able to enable 1024x FSAA or something and check back next month to see if your frame is finished. 20:20 Krock and it's not doing SSAA by any chance? 20:20 MTDiscord I have to say "CPU software renderer" sometimes because there are people who call shader renderers "software" that's running on the GPU. I guess some people just weren't alive yet at a time when "software renderer" got its original meaning ๐Ÿค” 20:21 Desour aniso in software rendere might also just be slow because it's slow to implement in software 20:23 MTDiscord If we could improve software rendering performance somehow, that might be a nice bonus, but I'm not sure how much we're actually using it in practice, so utilizing available hardware rendering performance to meet at least minimum default quality goals is probably more important :-) 20:24 MTDiscord tbh I'm running some livestreams out of docker containers and I'm uncertain what level of acceleration they're getting from the iGPUs built into the CPUs they're running on. They perform ... okay, though, I suppose. 20:26 Desour what LIBGL_ALWAYS_SOFTWARE=1 with aniso, tex min size=64(default), mipmap, nearest looks like for me: https://0x0.st/8sU1.jpg 20:27 sfan5 "what level of acceleration they're getting from the iGPUs built into the CPUs" by default none, you need to expose some devices nodes into the container to allow gpu access 20:28 sfan5 my takeaway is that texture_min_size is the magic moire-removal knob for some people so we can't get rid of it just yet 20:28 sfan5 also means the only way to achieve my goal is if we set a high minimum on texture_min_size to prevent people from turning their game into blur 20:30 Desour ideally, we should also consider using a different min size depending on the uv mapping 20:31 sfan5 that would be hard 20:31 Desour as said, ideally 20:33 Desour but for a mesh, one could assume a scale of 1 (or BS 1, so 10?), and look through the triangles, to see which is the biggest (or smallest?) one in terms of uv/world. and then on meshgen, choose a texture modifier accordingly or so 20:43 Krock What's the goal of these filters in the first place? In which cases is blur desirable? 20:44 Krock if it's solely to get rid of sharp edges, then antialiasing on its own should be the better solution. 20:45 sfan5 i dont think anyone wants blur 20:46 sfan5 unrelated: getTextureAverageColor is criminally inefficient 20:47 Krock and valgrind reports some UB in there but I couldn't find the source 20:47 Krock getPixel() apparently accesses data outside what's been initialized in IImage 20:48 Krock * Conditional jump or move depends on uninitialised value(s) 20:50 Krock the affected texture must be of type ECF_A8R8G8B8, which is accessed by pointer casting to u32 in CImage::getPixel. And yet. Everything appears to be in bounds. 20:51 Desour Krock: if you look at a texture from far away, you get spacial aliasing (meaning you sample at a lower resolution than the texture (i.e. you skip texels)). to get rid of that there's mipmapping, but it doesn't work right if you look from the side (anisotropicly), which is why there is anisotropic filtering. bilinear filter is so that you get a blurry texture, which is for high resolution textures usually preferable over seeing the texels (not for 20:51 Desour luanti usually though). if you scale up the textures, you can get rid of jaggies () while also seeing the square texels 20:51 Desour I probably forgot to mention something important 20:52 Krock Desour: ah yes. That does make sense. 20:53 Desour oh, and on some hardware anisotropic filtering automatically enables bilinear 20:54 Krock sfan5: https://pastebin.com/raw/pHcZaVgm if you're curious. CImage.cpp and imagesource.cpp selectively compiled with -g, a few days ago. 20:55 sfan5 ๐Ÿคท 20:55 Krock :) 21:03 Krock strange how it tries to find the average color on a CGUITTGlyphPage 21:10 sfan5 https://0x0.st/8sUd.png what are we doing here 21:12 Desour limit the cost 21:13 sfan5 what about comparing y to width 21:13 Desour ooh 21:23 MTDiscord "set a high minimum on texture_min_size" <- if you mean "high default", then yes, that make sense. I wouldn't force a minimum though. 21:23 MTDiscord The best default tbh might just be based on a heuristic looking at RAM or VRAM or something. 21:27 sfan5 the best default is what doesn't cause blur 21:29 MTDiscord I'm on a "low end but not totally unreasonably so" system (ThinkPad T430s from 2012) and 256 gives pretty good visuals and doesn't seem to murder performance. 21:30 MTDiscord There's a risk trade-off there because higher values increase memory usage, and some servers and games just have enough textures to trash memory. 21:30 MTDiscord Granted, there are some (IIRC the VanessaE ones were mostly like that for me) that just wouldn't work at all, even with no upscaling at all... 21:31 MTDiscord If you want to find a value that ensures there's no perceptible blurring, you'd have to calculate that from something like screen resolution, FOV, the near clipping plane, and the assumption that these textures will be used on 1-node sized geometry or smaller, or something. 21:32 MTDiscord You could probably come up with a static default assuming default FOV, 1080p fullscreen resolution, etc defaults 21:33 sfan5 (that's 192 or 256 imo) 21:35 MTDiscord Oh, if 256 is high enough, I say go for it. 21:35 sfan5 i mean you can obviously see the blur if you get closer to nodes and stuff 21:35 sfan5 but it's no longer in the territory where you immediately notice that "wait why is everything so blurry"ยง 21:35 sfan5 (IMO) 21:36 MTDiscord I assume we'll still ship the engine with filtering turned off by default, and texture_min_size doesn't kick in until filtering is enabled, so like 80%+ of users won't be affected no matter what we set it to. Users who enable filtering thinking "I want better visuals and my machine can handle it) will be more likely to be the same ones who won't bat an eye at the VRAM cos. 21:36 MTDiscord cost* 21:39 sfan5 12us per run to 0.5us per run 21:39 sfan5 now that's a success 21:40 MTDiscord Kind of makes me wonder who are the main voices in the community pushing for low-end hardware support? I know erle was big into that. I seem to be one too, though to a bit less of an extreme. How many other people are there out there who are very performance-sensitive even at rather modest quality settings and low minimum framerates? 21:41 sfan5 ancient hardware != low-end 21:42 MTDiscord I suppose that's true. My computer was considered high-end for the time, and I suppose that means it will age a bit more gently than others might. 21:43 MTDiscord At least, it's a solidly well balanced rig, so it doesn't suddenly start developing severe bottlenecks so easily. 21:47 sfan5 we dropped a big chunk of the ancient part by requiring opengl 2.0 (so with shaders) now 21:48 sfan5 since graphics programming changed a lot with time optimizing for ancient hardware can actually conflict with optimizing for low-end hardware 21:49 MTDiscord It looks like I can go as high as 4.2 here. 21:51 sfan5 we can definitely make better of modern opengl 21:55 sfan5 +use 22:00 MTDiscord There was an era where javascript on websites needed to be "unobtrusive" and "not required" because it was common to disable JS, and inconsistent standards across browsers made it often just not work. Then, after an era of shims, polyfills, and compatibility hacks, we ended up in an era where JS is mostly pretty consistent, and many sites are basically all client-side code written in JS that interacts with a remote API rather than 22:00 MTDiscord loading remote markup. It sounds like GLSL has gone through a similar revolution, and we're still in the "javascript on the web circa 2000" side of it. 22:02 MTDiscord If we ever get a shader-based pipeline and there's any question of "okay now what should we do that we couldn't before" then I vote for order independent transparency :-) 22:04 sfan5 there's an issue for that 22:09 MTDiscord "I don't think anyone wants blur" fwiw (and this may not be the best time), texture filtering should partly be up to mods/games, because I may on fact want blur to make lower res textures appear higher res (a la ps2 graphics) 22:15 MTDiscord (s/on/in) 22:16 [ both in the case of javascript and shaders, requiring them is a bad thing 22:17 MTDiscord Indeed it depends on the intended art style. I've got lots of textures in NodeCore where I expect crisp square pixels ... and I've got a few where I actually want blur, like the breath HUD, and the resolution of the textures is lower for resource conservation reasons. 22:36 sfan5 [: you are welcome to make your javascript free fork 22:38 [ don't you mean shader-free? 22:38 MTDiscord of Luanti? Sounds easy. Of the web? Maybe a bit less easy. 22:38 [ or rather works-without-shaders 22:39 MTDiscord I believe our image handling code could be more efficient & simpler if we standardized images to ARGB8 22:39 MTDiscord note that textures will still need different formats e.g. for depth buffers 22:39 sfan5 all our textures are ARGB8 but we don't capitalize on it 22:40 rubenwardy comparing shaders to web js is a false equivelance