Time Nick Message 00:00 srifqi done 00:00 srifqi by the way, when should we update the translations again? release candidate has been published 00:01 MTDiscord What needs to be updated? 00:02 srifqi i meant running the updatepo.sh script 00:02 MTDiscord Perhaps it would be wise to do that even if there are only slight changes since the feature freeze is in play 00:03 erle translation is not a feature anyway 00:03 erle so it can be easily done wherever 00:08 srifqi i asked that in case there are PRs with string updates that will be merged soon, so that we don't update translations too often 00:14 MTDiscord No such thing, pump those commit numbers up 00:15 MTDiscord If java has taught me anything, it's that you can be verbose as can be and still have a community backing 00:17 srifqi ( .-.) 00:17 srifqi so, MC also does that? 00:18 MTDiscord Well we have no idea of telling because it's closed source, but I'm just going to say maybe 00:20 srifqi from Crowdin activity log, it seems like they are doing it almost weekly 00:21 MTDiscord Then I suppose you'll have to fire the translation cannon 01:24 rubenwardy feature freeze also means string freeze, but we can update date them as long as there's a week to go (which there is) 01:24 rubenwardy especially as it's missing strings not changed ones 01:30 srifqi the sooner the better, i guess 01:31 MTDiscord https://tenor.com/view/speedball-cannon-gif-18004290 01:32 srifqi i found no PR with Bugfix label that changes strings 09:53 sfan5 I might have time to do string updates in a few hours 13:49 MTDiscord sfan5, I accidentally copied the old results by mistake when I replied to your question on #13976. I edited my reply so it is now accurate. 13:49 ShadowBot https://github.com/minetest/minetest/issues/13976 -- Fix UB in modulo360f (bugfix for #13960) by superfloh247 14:00 MTDiscord That was my first time using Catch's benchmark feature. I was thrilled at how little setup was required. 14:00 MTDiscord Previously when I experimented with timing, I wrote the timing code by hand and it was a pain and probably not nearly this accurate. 15:43 grorp Ideally to be merged before the next string update: #13984 15:43 ShadowBot https://github.com/minetest/minetest/issues/13984 -- Get rid of hidden settings in settings_translation_file.cpp by grorp 18:46 erle rubenwardy celeron55 since both of you are online right now, would anyone of you be willing to test and support the test nodes? (it would make some bug report i want to file easier) 18:46 erle https://github.com/minetest/minetest/pull/13955 18:46 erle these ones 18:47 erle also i'll try to figure out now if unfucking the bilinear filtering regression is as easy as i thought 19:31 [MTMatrix] We're in feature freeze, that's a feature (as in "something new to add") 19:37 erle it's not a feature, it's a test. but fine, then i'll just fix the regression. 19:37 erle unless feature freeze means rendering errors also don't get fixed lol 19:38 erle btw, maybe devtest should be unbundled too 19:38 erle like it's not even in the release 19:38 jonadab Normally, for most projects, when there's a feature freeze, it's on a branch that is leading up to release, and new-feature work can still be checked in on the trunk. 19:39 jonadab Although some of the devs may want to focus on the release and thus may not be available to review/merge/etc. said new feature work. 19:39 erle anyway, i don't care much when it gets merged. i care about the regression and that one is WAY easier to see with those test nodes (it is how i noticed it and it prob would not have occured if they were there earlier, but i did not make them earlier). 19:39 erle as i said i will fix it 19:39 erle i have some time right now 19:41 erle you can also see it with 7px texture pack btw, which is why i will reference that then ig 19:44 erle TL;DR: thinking that the “texture gets upscaled before filtering” is purely a workaround for textures otherwise being blurry was a mistake, aesthetically it is important so that the looks of the base texture pack, generated textures and whatever else players are using in world does not clash. also it lead to some specfic rendering style of lowres textures that felt comfy and apparently accidentally got removed. and then th 19:44 erle ere is this bug which makes anisotropic filtering turn on bilinear filtering, but bilinear filtering alone dose not do it now. 19:44 erle that was almost too long itself, i'll be silent on this here ig 20:30 grorp In hindsight, I would not be opposed to re-adding that option 20:30 grorp as long as you can still disable bilinear filtering on upscaling (that's the new thing brought by the cleanup PR) 20:33 erle i am pretty sure that if a refactoring yields one minor new thing but causes several non-minor regressions, reverting it is the first course of action. figuring out how to add the new thing without breaking the old one is secondary (i am sure it is possible, but feature freeze and all that). 20:34 erle i mean an option ”do not upscale textures” (the default needs to be upscaling to keep the look for existing texture packs) would be possible. then again, couldn't you just set min_texture size to 0 or so to always achieve that? 20:34 erle i am going to research it 20:34 erle because if that's the case, the code would not have to be removed at all 20:42 erle grorp am i correct that setting min texture size to 0 would have the effect you wanted? 20:42 erle i ask because if that is the case the regression can prob be cleanly reverted 20:43 grorp so, going item by item... 20:43 erle i.e. you can keep that look without breaking it for everyone who used filtering with 7px texture packs 20:43 grorp "but causes several non-minor regressions": I think that's a misrepresentation. 20:44 erle well you have seen how anisotropic filtering looks on my hardware now i assume. that's one thing i mean with non-minor. and i do not know if that is an engine bug or something else, but it is a regression. 20:44 grorp "do not upscale textures" (min_texture_size = 0) was always possible and is still possible 20:44 grorp but that's not what this is about 20:44 erle hmm tell then 20:44 erle what is it? 20:45 grorp well, the engine would always set bilinear filtering on upscaling previously 20:45 erle bc as i see it, the change broke visual consistency between things with different detail level if filtered, which may not be big for you, right? 20:45 erle yes and now it *never* sets bilinear filtering if i check the option 20:45 erle only if i also check anisotropic filtering, but then it is useless 20:45 grorp so min_texture_size = 0 would result in maximum blurred textured 20:46 erle oh, so what i am experiencing right now ig 20:46 erle i see how i got it wrong then 20:46 grorp *textures 20:46 erle so how to get it right then? 20:47 grorp either a. revert the pr and set a high min_texture_size value b. have hardware with working (non-blurry) anisotropic filtering 20:48 erle okay, i'll open an issue. otherwise this will be another wall of text here. 20:48 erle it can not be either-or, because i *want* the behaviour as before (as, judging from screenshots, others might want too) 20:49 erle like even if my hardware is totally faulty this thing is still a break that makes stuff look weird if filtering is on but your textures do not all have the same resolution (or you like the style that minetest had for a long time) 20:49 erle so i want to know what the minimum change is that would satisfy us both 20:49 grorp well, I can see how you can find texture_min_size + bilinear mag filter look good 20:50 erle ah, good. try it with 7px texture pack if you have some time to waste :) 20:50 erle it looks very comfy 20:50 erle btw previosly i think anisotroopic filtering could not be activated without bilinear filtering 20:51 erle so it is definitely the change that introduced a regression, because both was on at the same time before 20:51 erle like either you got bilinear filtering or bilinear + anisotropic 20:51 erle but never anisotropic alone 20:51 erle which is now an option, but does not seem to work properly (at least here) 20:52 erle i am checking docs now on this 20:53 Desour enabling anisotropic filter without bilinear filter has worked before, iirc. I've used that combination of settings 20:53 grorp I'm quite sure anisotropic filtering alone was already possible before 20:53 erle in the interface? 20:54 erle i am pretty sure i never saw that option 20:54 erle but i am willing to retract my assertions and state the opposite if you say so 20:55 erle okay so apparently it really DOES depend on the hardware what anisotropic filtering does and sometimes it forces bilinear, sometimes it forces trilinear. 20:55 erle basically, a LOT of GPU drivers cheat 20:56 erle i think this would probably need an actual rendering test suite 20:57 MTDiscord aniso without bilinear is I'm pretty sure a hardware-dependent kind of thing. I've seen it work on higher-end stuff, but not on most of the iGPUs I run 20:57 grorp erle: probably you didn't see the effects of that previously because of texture_min_size 20:58 erle i guess so, but that's kinda a “no one could see the difference then”, right? 20:58 erle uh, i may have seen 6 months old reports of aniso without bilinear being fucky on recent intel GPUs 20:58 erle is this a vendor thing? 21:03 erle grorp what do you think of “revert the change that removes the scaling (thus preserving both existing rendering style for low-res texture packs and side-stepping having to deal with anisotropic filtering GPU differences) and figure out the finer details after release” as the way forward? 21:04 erle i mean given that this breakage was not noticed i doubt any of us can come up with something that is surely not breaking anything more 21:05 erle https://github.com/KhronosGroup/Vulkan-Docs/issues/1361 21:05 erle > using NEAREST with aniso is probably not going to give consistent behavior across implementations, ever 21:05 erle lol there you have it 21:06 erle and there is a comment from 2023 claiming intel HW just can't do aniso + nearest 21:06 erle which explains my experience (various thinkpads with intel igpus) 21:07 erle ok i guess i know enough now, thanks grorp Desour 21:07 erle and warr1024 21:08 MTDiscord As long as I can get mip+aniso for downscaling (which I assume I can because we still use linear down, right?) I don't mind that much if I don't get it for upscaling. 21:10 grorp erle: If the "remove texture_min_size" part of #13683 is reverted, I think the "disable bilinear filtering on magnification" part should be reverted too. Otherwise, texture_min_size is hardly useful. 21:10 ShadowBot https://github.com/minetest/minetest/issues/13683 -- Clean up texture filtering settings by grorp 21:10 grorp regarding the "finer details after release" part: I certainly won't spend any more time on this. 21:11 erle oh so you don't even use that feature? or you think it is too hairy? 21:11 grorp I do use these settings 21:12 erle then i think ”upscale things” should be a simple true/false (but it needs to be true by default to not break existing visual style that relies on this ig) 21:13 grorp Warr1024: yes, you can still get that 21:15 Desour grorp: disabling bilinear for magnification is still good 21:16 Desour e.g. if you have a mesh with a not so small texture, but big texels mapped to a big surface, upscaling to a min size wont work 21:16 erle Desour yes but having a simple setting would cut it right? 21:16 Desour there are only simple settings right now, erle 21:16 erle i mean a boolean 21:16 Desour bilinear mag is always off iirc 21:16 Desour (if not by aniso) 21:16 grorp yes 21:17 erle btw, anyone of you two wants to support the test nodes i made? (i just care about approvals, not when it gets merged) 21:18 erle these https://github.com/minetest/minetest/pull/13955