| 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 |
<jordan4ibanez> What needs to be updated? |
| 00:02 |
srifqi |
i meant running the updatepo.sh script |
| 00:02 |
MTDiscord |
<jordan4ibanez> 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 |
<jordan4ibanez> No such thing, pump those commit numbers up |
| 00:15 |
MTDiscord |
<jordan4ibanez> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> Then I suppose you'll have to fire the translation cannon |
| 00:29 |
|
ShadowBot joined #minetest-dev |
| 00:30 |
|
appguru joined #minetest-dev |
| 00:37 |
|
ShadowBot joined #minetest-dev |
| 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 |
<jordan4ibanez> https://tenor.com/view/speedball-cannon-gif-18004290 |
| 01:32 |
srifqi |
i found no PR with Bugfix label that changes strings |
| 02:32 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:55 |
|
celeron55 joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 07:07 |
|
calcul0n joined #minetest-dev |
| 08:48 |
|
beanzilla joined #minetest-dev |
| 09:10 |
|
beanzilla joined #minetest-dev |
| 09:36 |
|
Swift110-mobile joined #minetest-dev |
| 09:48 |
|
beanzilla joined #minetest-dev |
| 09:53 |
sfan5 |
I might have time to do string updates in a few hours |
| 11:37 |
|
luk3yx joined #minetest-dev |
| 12:30 |
|
beanzilla joined #minetest-dev |
| 12:49 |
|
appguru joined #minetest-dev |
| 13:16 |
|
Wuzzy joined #minetest-dev |
| 13:47 |
|
imi joined #minetest-dev |
| 13:49 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> That was my first time using Catch's benchmark feature. I was thrilled at how little setup was required. |
| 14:00 |
MTDiscord |
<josiah_wi> Previously when I experimented with timing, I wrote the timing code by hand and it was a pain and probably not nearly this accurate. |
| 14:01 |
|
dv^_^ joined #minetest-dev |
| 14:29 |
|
grorp joined #minetest-dev |
| 15:39 |
|
Desour joined #minetest-dev |
| 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:02 |
|
Desour joined #minetest-dev |
| 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] |
<Zughy> 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 |
| 19:45 |
|
dzho joined #minetest-dev |
| 20:26 |
|
grorp joined #minetest-dev |
| 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:39 |
|
grorp joined #minetest-dev |
| 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 |
<warr1024> 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 |
<warr1024> 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 |
| 22:51 |
|
Fleckenstein joined #minetest-dev |
| 23:22 |
|
appguru joined #minetest-dev |
| 23:33 |
|
panwolfram joined #minetest-dev |
| 23:38 |
|
YuGiOhJCJ joined #minetest-dev |
