| Time |
Nick |
Message |
| 00:26 |
|
turtleman joined #minetest-dev |
| 04:06 |
|
v-rob joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 07:15 |
|
nrz joined #minetest-dev |
| 07:43 |
|
v-rob joined #minetest-dev |
| 11:08 |
|
erle joined #minetest-dev |
| 11:17 |
|
appguru joined #minetest-dev |
| 12:55 |
|
Thomas-S_ joined #minetest-dev |
| 14:59 |
|
imi joined #minetest-dev |
| 16:22 |
|
fluxionary joined #minetest-dev |
| 17:01 |
|
v-rob joined #minetest-dev |
| 17:16 |
|
appguru joined #minetest-dev |
| 18:02 |
|
appguru joined #minetest-dev |
| 18:13 |
ROllerozxa |
is it a known issue that bi/trilinear filtering options are broken in 5.8.0-dev? |
| 18:13 |
sfan5 |
for upscaling or downscaling? |
| 18:16 |
erle |
ROllerozxa yes it is and i am going to figure it out right now and see if i can unbreak it. also, do you have an intel GPU? |
| 18:16 |
erle |
ROllerozxa maybe relevant https://github.com/KhronosGroup/Vulkan-Docs/issues/1361 |
| 18:19 |
erle |
ROllerozxa TL;DR in the course of a settings refactoring, the “scale all textures up before applying filters” was replaced by “don't filter lowres textures”, which leads to three things: 1. no filtering at all for lowres textures (you can see the difference with 7px texture pack) 2. inconsistent filtering look if not all textures have the same size 3. extreme blurryness with anisotropic filtering on intel GPUs |
| 18:19 |
erle |
i have several hours right now and am on it |
| 18:19 |
ROllerozxa |
ok erle |
| 18:20 |
ROllerozxa |
sfan5: unsure what you mean, basically what I would like the filtering to do is slightly blur the textures, like it used to do |
| 18:20 |
MTDiscord |
<rollerozxa> https://cdn.discordapp.com/attachments/747163566800633906/1173688940000198756/image.png?ex=6564de01&is=65526901&hm=65ba9f6e6aaa234a17291ad280501448eab700d8549bc5a6c5f5dd3e4baa6f1d& |
| 18:20 |
ROllerozxa |
left is 5.7, right is 5.8-dev |
| 18:21 |
erle |
ROllerozxa you can see the difference with my checkerboard test textures too. |
| 18:22 |
erle |
ROllerozxa filtering was only ever done for downscaling IIRC, it was only that the textures were upscaled to min_texture_size or how it is called before, to a) get a uniform look with differently-sized textures b) work around the driver detail that using NEAREST with aniso is probably not going to give consistent behavior across implementations, ever |
| 18:24 |
sfan5 |
so in formspec use |
| 18:24 |
sfan5 |
for what seems to be upscaling |
| 18:24 |
sfan5 |
wait no, that's nodes |
| 18:24 |
erle |
i was exclusively referring to nodes actually, no idea what the case with formspecs is |
| 18:25 |
erle |
same regression maybe? i'll find out. |
| 18:25 |
sfan5 |
anyway https://github.com/minetest/minetest/pull/13683 will have changed this |
| 18:26 |
erle |
ok then it's the same thing ig |
| 18:27 |
erle |
oh wow https://github.com/minetest/irrlicht/pull/227 |
| 18:35 |
MTDiscord |
<warr1024> I like the fact that the new look is now available as an option. I'm don't feel very strongly about the fact that the old look was removed as an option; it might be nice in principle to have options, but whether it's worth the complexity of supporting it I guess depends on how strongly others' need for it is. I would actually like to have the new look (being able to force nearest upscaling) as an option for skyboxes too. |
| 18:35 |
erle |
Warr1024 the new look was always available as an option? |
| 18:35 |
erle |
also, the ”new look” includes “intel GPU + anisotropic filtering is a mess” |
| 18:35 |
erle |
(and the fix for that is the old look) |
| 18:37 |
erle |
warr1024 there does not seem any big complexity in “supporting” the old look as far as i can tell. maybe i have not understood it correctly, what exactly do you mean? |
| 18:38 |
MTDiscord |
<warr1024> The new look was NEVER an option. If you wanted nearest-up you were forced to live with nearest-down. |
| 18:39 |
MTDiscord |
<warr1024> Really, if irrlicht/GL/whatever offers separate up/down scaling filter options, we should just let users configure their clients with the same options, instead of having some "translation layer" that constrains it to only bad compromises. |
| 18:42 |
erle |
i am pretty sure it is not too difficult to add a setting to makes the “new look” possible (would a toggle for upscaling textures before filtering do it alone? unsure, maybe you can work that out). but first order of business is fixing the regressions ig. |
| 18:43 |
erle |
the lesson here is probably “not all deleted code is debugged code” ;) |
| 18:45 |
MTDiscord |
<warr1024> No, I'm thinking that offering users one combined "filtering" option, and then translating it into separate up/down options on the backend, is just needlessly indirect. We should just offer separate upscaling (linear vs nearest) and downscaling (nearest, bilinear, trilinear) options. |
| 18:46 |
erle |
the issue with that is that this mental model does not actually work with the hardware, to quote from that vulkan issue: |
| 18:46 |
erle |
> This is a legacy of the early days of aniso filtering in GL, when filters and modes were abused (in different ways by different vendors) to serve as quality hints. |
| 18:47 |
MTDiscord |
<warr1024> Whether the hardware is capable or not of actually complying with the requested filtering options is irrelevant if we can't even allow the user to request the filtering options they actually want to try. |
| 18:48 |
erle |
i agree with you that stuff should be an option. i just don't want it to break existing setups needlessly. |
| 18:48 |
erle |
i'll be looking at the vulkan 1.3.249 spec update now |
| 18:49 |
MTDiscord |
<warr1024> The backwards-compatible way to not break existing setups would be just to deprecate but not remove the old settings, use new settings for these, and then generate the new setting values by translating the old ones if the new ones are absent; we should be able to offer a migration path. |
| 18:50 |
erle |
sorry i don't get what you mean. what are “old settings” and “new settings” in your example? |
| 18:50 |
sfan5 |
spacebar heating etc. |
| 18:51 |
MTDiscord |
<warr1024> All in all though I find it hard to imagine a workflow where a user notices that their graphic shit changed but can't just go back into the settings to fix them to their liking (and maybe experiment with the new options and find something even better). It might be different if it were a server-side setting and it had a subtle effect on gameplay, but this is really a visual setting, which users are generally very good at noticing |
| 18:51 |
MTDiscord |
and not at all shy about messing with. |
| 18:51 |
erle |
it's less spacebar heating and more “the existing way works everywhere and looks like a horrible hack, but you can either not filter at all (thus breaking setups) or just keep it” |
| 18:51 |
ROllerozxa |
what are you two talking about |
| 18:51 |
ROllerozxa |
currently the bi/trilinear filtering settings do not do anything anymore. this is compared to in 5.7 where it would do something, namely filtering textures giving them a smooth/blurry look. whether that works well depends on the textures and artstyle, obviously wouldn't work well with 16x textures but for photorealistic textures it would |
| 18:52 |
erle |
yes that is true |
| 18:52 |
erle |
but they were broken on purpose |
| 18:52 |
ROllerozxa |
I mean I don't want to automatically attribute malice |
| 18:52 |
MTDiscord |
<warr1024> Wait, bi/tri now don't do anything anymore? That's news to me, and I'm pretty sure I would have noticed if linear filtering were completely gone... |
| 18:53 |
erle |
they do something, but not what you usually want |
| 18:53 |
erle |
(or so i think) |
| 18:53 |
erle |
as i said ROllerozxa try with my checkerboard test nodes. |
| 18:54 |
ROllerozxa |
hm? |
| 18:54 |
erle |
ROllerozxa those: https://github.com/minetest/minetest/pull/13955 |
| 18:55 |
MTDiscord |
<warr1024> okay, yeah, apparently filtering IS broken, and I just didn't notice it because mipmapping was doing a good enough job on the real-world textures I was using. |
| 18:56 |
erle |
btw, you don't need to attribute malice. to me it looks like just regular “simplify code” refucktoring that literally all projects that don't have strict regression testing have. you can solve this by either requiring strict regression testing (infeasible) or requiring a “chesterton's fence” explanation. |
| 18:56 |
MTDiscord |
<warr1024> there are still the checkboxes in the config UI but only the mipmapping one does anything, and it's nearest-mip-nearest, not even nearest-mip-linear. |
| 18:56 |
erle |
(by “infeasible” i mean “infeasible in minetest in particular due to the people making those changes not being in favor of it, or they would do it”) |
| 18:58 |
erle |
Warr1024 but how big are your ”real-world” textures? |
| 18:58 |
MTDiscord |
<warr1024> 16px |
| 18:58 |
|
grorp joined #minetest-dev |
| 18:59 |
sfan5 |
did you all read the PR I linked? |
| 18:59 |
MTDiscord |
<warr1024> I gave it a simple checkerboard to test, and with mipmapping turned off, the moire effects are evident (which should be no surprised at least) |
| 18:59 |
MTDiscord |
<warr1024> https://cdn.discordapp.com/attachments/747163566800633906/1173698588593881158/screenshot_20231113_135729.png?ex=6564e6fd&is=655271fd&hm=d510568a8edb6880368cef8286ba34a552e49af9bfc390d95591d0045edce95b& |
| 18:59 |
grorp |
I'm quite sure they still do something, they just affect downscaling only now |
| 18:59 |
erle |
grorp good that you here. is there anything in #13683 that needs to be salvaged or is the best course of action to revert it? |
| 18:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/13683 -- Clean up texture filtering settings by grorp |
| 18:59 |
grorp |
Anway, just revert my PR, I really don't care |
| 18:59 |
erle |
okie dokie |
| 19:00 |
MTDiscord |
<warr1024> However, turning on mipmaps doesn't fix it, because there's now just this abrupt transition from the base texture to the first mip level, rather than the smooth blending that trilinear does. Aniso is also missing, which sucks ... but I guess I could live with that most of the time. |
| 19:00 |
MTDiscord |
<warr1024> https://cdn.discordapp.com/attachments/747163566800633906/1173698808736141383/screenshot_20231113_135758.png?ex=6564e732&is=65527232&hm=d9d8244aac1501de921f9766e66b50040db1a4c877d0072124165fb3deb2136b& |
| 19:00 |
erle |
Warr1024 if you have an intel GPU, turn on just anisotropic filtering and enjoy the blurrrrrr |
| 19:00 |
grorp |
I think the option suggested by warr (give users low-level control over texture filtering) would be the best for the future |
| 19:00 |
MTDiscord |
<warr1024> I never turned aniso off. |
| 19:01 |
erle |
i agree |
| 19:01 |
erle |
grorp Warr1024 i don't think giving fine-grained control is bad at all. i just think the state right now is borked. |
| 19:01 |
MTDiscord |
<warr1024> I don't know what my GPU would be willing to actually do given various options, but at least I'd like to try and find out, and then I can go blame Intel if things don't work out instead of blaming Minetest. |
| 19:02 |
erle |
no you can't blame intel, since the standards (e.g. opengl, vulkan) give the vendor a lot of leeway here and intel and AMD and nvidia seem to disagree for ilke 20+ years on what is the best to do in those kind of cases lol |
| 19:03 |
erle |
that does not mean it is a bad thing to give that kind of control |
| 19:03 |
erle |
i just think the default should be something that works everywhere (more or less) |
| 19:03 |
MTDiscord |
<warr1024> It seems like I don't notice this stuff much during normal gameplay because I'm getting a lot of frames and I can just sort of "temporally average" while I'm moving ... but if I stand still, it becomes really noticeable, and that will have a big impact on screenshots and such. |
| 19:04 |
erle |
same reason as why vp8 can get with 4:2:0 chroma subsampling and webp can't, motion! :P |
| 19:04 |
MTDiscord |
<warr1024> I absolutely can blame Intel if they fail to give me the quality settings I want, regardless of how loose the spec is. |
| 19:05 |
erle |
okay, you can, but it's not particularly likely to change anything in this case |
| 19:05 |
MTDiscord |
<warr1024> Indeed. Haha, even if I had fancy GPUs, I'd probably rather be playing with LLMs than GLSL with them 😄 |
| 19:06 |
erle |
i'll be compiling and testing if the revert works … |
| 19:09 |
grorp |
a straight git revert won't compile with the newest IrrlichtMt, you have to move setFiltersMinetest into Minetest because it was removed from Irrlicht |
| 19:09 |
erle |
i know |
| 19:09 |
erle |
but i am doing a writeup on this rn so it does not happen again |
| 19:09 |
grorp |
That function should never have been in Irrlicht at all |
| 19:10 |
MTDiscord |
<warr1024> I don't see much of a problem in moving a function with "minetest" in the name into minetest ... IIRC the entire existence of irrlichtMT as a separate thing was supposed to be sort of temporary, right? |
| 19:10 |
erle |
agreed |
| 19:10 |
erle |
Warr1024 nothing lasts as long as a temporary solution |
| 19:10 |
erle |
i am certainly not doing a refactoring of a botched refactoring and i ask everyone else to also not do that. there is enough time after the release to fix all of these things. |
| 19:10 |
MTDiscord |
<warr1024> After proton decay, nothing will be left of the universe except non-interacting photons, and the scraps of duct tape used to hold together all the temporary solutions. |
| 19:19 |
ROllerozxa |
erle: okay so I looked at your checkerboard texture nodes, um, what did it have to do with filtering |
| 19:20 |
erle |
ROllerozxa the checkerbox test nodes have the same checkerboard in different texture sizes, so you can see how filtering applies to each. |
| 19:21 |
erle |
IIRC all 2x2 checkerboards should look the same, but with the filtering refucktoring they don't |
| 19:21 |
erle |
you can see it in the screenshots |
| 19:21 |
|
grorp1 joined #minetest-dev |
| 19:21 |
erle |
anyway, as i said. i am on it. just wait a bit. |
| 19:22 |
erle |
i don't want to fuck up anything more (which just simply “git revert” without testing might do) |
| 19:22 |
ROllerozxa |
they all look the same... because there is no filtering |
| 19:22 |
ROllerozxa |
(like, every node with the same grid tiling looks the same) |
| 19:22 |
erle |
okay activate anisotropic filtering. still the same look? |
| 19:23 |
ROllerozxa |
(anisotropic filtering is already on) |
| 19:23 |
ROllerozxa |
do I need to disable it? |
| 19:23 |
erle |
i bet you don't have an intel GPU then :D |
| 19:24 |
erle |
disable aniso and enable bilinear ig |
| 19:24 |
ROllerozxa |
...yeah I have an AMD GPU (dedicated one, in particular) |
| 19:24 |
erle |
… and maybe look at non-powers-of-two checkerboards |
| 19:24 |
erle |
i think it should be more notable there |
| 19:28 |
ROllerozxa |
well if it doesn't occur on AMD then it would make sense that the NPOT sized textures look the same too, right? |
| 19:28 |
ROllerozxa |
(they still look the same) |
| 19:29 |
erle |
ROllerozxa please place all the checkerboard testnodes in a wall or so and enable bilinear filtering and make a screenshot of the wall. also disable mipmapping maybe? not sure. |
| 19:32 |
MTDiscord |
<warr1024> I have an Intel iGPU and the only option that makes any difference is mipmapping with the new "no filtering" thing; bilin, trilin and aniso are completely no-ops. |
| 19:33 |
erle |
Warr1024 i bet if you use a giant texture pack, they are not |
| 19:33 |
erle |
because then you are downscaling |
| 19:33 |
erle |
try it |
| 19:34 |
MTDiscord |
<rollerozxa> https://cdn.discordapp.com/attachments/747163566800633906/1173707452366200842/image.png?ex=6564ef3f&is=65527a3f&hm=5724db1238f6bb1b25a7ba3c4b2efe0e1a38de2bda06f682334deabafdd497ec& |
| 19:34 |
ROllerozxa |
they look like this no matter if I enable or disable anisotropic filtering, or enable or disable mipmaps |
| 19:35 |
erle |
ROllerozxa and if you enable bilinear/trilinear? |
| 19:35 |
erle |
are they no-ops? |
| 19:35 |
ROllerozxa |
bilinear and trilinear is already enabled |
| 19:35 |
erle |
oh lol |
| 19:35 |
erle |
okay i guess it is worse than i thought then |
| 19:41 |
MTDiscord |
<warr1024> When I want to test downscaling, I just look at some distant geometry. It's pretty easy to tell where that is because mipmapping DOES work, and it's definitely downscaling in the areas where mipmapping is happening. |
| 19:41 |
|
v-rob joined #minetest-dev |
| 19:41 |
erle |
Warr1024 btw did you check out hybrid dogs mipmap improvements? they seem pretty nice |
| 19:42 |
MTDiscord |
<warr1024> Right now, we just have nearest up and either nearest-mip-nearest or just nearest down. Basically all the "linear" and "anisotropic" options don't do shit on my hardware. |
| 19:42 |
MTDiscord |
<warr1024> I didn't look too closely at the mipmap improvements; mostly that stuff is too subtle for me, and I'd really rather have mipmapping in the context of also having trilinear. |
| 19:43 |
MTDiscord |
<warr1024> It seems weird that we wouldn't be able to achieve a level of graphical quality comparable to what I had in like 2002. |
| 19:43 |
erle |
it's not really subtle because it seems to be gamma-correct downscaling (i.e. mipmaps no longer make the textures darker than they should be) |
| 19:43 |
erle |
and the sharpness is very notable |
| 19:47 |
MTDiscord |
<warr1024> I play Minetest. I'm already thoroughly desensitized to gamma-incorrectness, including even scenarios where the same color used in different contexts ends up with a different final appearance. It's subtle to me. |
| 19:48 |
erle |
ig i thought because i have really bad contrast vision that it is even more jarring to others |
| 19:50 |
MTDiscord |
<warr1024> You might have like "perfect pitch" for colors or something too though. Like, even if your eyeballs have trouble processing the stimulus, you could still have heightened processing in the brain. I'm pretty sure my eyeballs send a ton of data to my brain but then the brain just throws almost all of it out, in my case. |
| 19:51 |
erle |
might be. i mean i immediately noticed the blurry CDB screenshots and apparently others did not? |
| 19:51 |
erle |
(did you?) |
| 20:02 |
MTDiscord |
<warr1024> I noticed that some thumbnails that were very blurry before (and even had JPEG ringing artifacts) are now a lot cleaner. |
| 20:05 |
erle |
now i wonder what was broken before lol (i was not able to make jpeg look worse at the same filesize than webp, despite trying). anyway, i would appreciate if people at least tested their rendering changes … regardless of in minetest or cdb. |
| 20:49 |
erle |
this whole irrlichtmt setup sucks. i can't even easily git revert, because someone converted all the line endings lol. seriously. |
| 20:50 |
erle |
anyone has a one-liner to coax git into magically not caring about line endings? |
| 20:59 |
pgimeno |
define "not care" |
| 21:03 |
erle |
i googled and thought a bit and figured out it is just easier to press backspace a bit and copy the code to the correct place |
| 21:04 |
erle |
now the remaining questions are: a) did i correctly unfuck it? b) can someone please explain how the original change was supposed to work at all? however i wrap my mind around it, i can find no way that the intended goal can *not* cause regressions. |
| 21:05 |
erle |
(and using GL_NEAREST in this case in particular is explicitly advised against by khronos group) |
| 21:06 |
erle |
i mean it does not materially change much, i just would like to have it all neatly wrapped up like in that case where the user forgot that numlock exists in their bug report. |
| 21:14 |
erle |
compiling … |
| 21:33 |
|
v-rob joined #minetest-dev |
| 22:11 |
MTDiscord |
<jordan4ibanez> If something being against what khronos recommends offends you, please, do not look at any opengl or vulkan drivers |
| 22:14 |
erle |
jordan4ibanez in this case in particular the recommendation is for API users, not vendors. and it is sound, no amount of testing is going to give you consistent results. |
| 22:41 |
|
loggingbot_ joined #minetest-dev |
| 22:41 |
|
Topic for #minetest-dev is now FEATURE FREEZE IN EFFECT | Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ https://irc.minetest.net/ https://github.com/minetest |
| 22:46 |
erle |
hmm, is this a known regression/upgrade/change in formspec rendering or was it always undefined? https://codeberg.org/mineclonia/mineclonia/pulls/708 |
| 22:47 |
erle |
(the formspec rendering different in 5.6 and 5.8-dev) |
| 22:48 |
erle |
reportedly the difference is in the main formspec of mcl_grindstone |
| 22:53 |
luk3yx |
erle: It looks like Dragonfire's GUIFormSpecMenu::parseImage function is from MT 5.5 and doesn't have support for 9-sliced images |
| 22:53 |
rubenwardy |
If there's been a formspec regression, the thing to do is to make a Minimum Reproducible Example and post it as an issue. It's a waste of our time to post random links here, from games with lots of custom code being used with people with custom clients |
| 22:54 |
luk3yx |
Since cora mentioned Dragonfire I assume they haven't tested it in an unmodified 5.6 |
| 23:33 |
|
panwolfram joined #minetest-dev |
