| Time |
Nick |
Message |
| 00:02 |
|
hwpplayer1 joined #minetest-dev |
| 00:05 |
|
Eragon joined #minetest-dev |
| 01:22 |
|
YuGiOhJCJ joined #minetest-dev |
| 01:33 |
|
Thomas-S_ joined #minetest-dev |
| 04:54 |
|
Noisytoot joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:29 |
MTDiscord |
<warr1024> I can't comment on whether they're a disaster, but without them, mipmapping is a disaster |
| 05:30 |
MTDiscord |
<warr1024> 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. |
| 05:38 |
|
SFENCE joined #minetest-dev |
| 06:11 |
|
SFENCE joined #minetest-dev |
| 06:15 |
|
SFENCE joined #minetest-dev |
| 06:54 |
|
SFENCE joined #minetest-dev |
| 07:02 |
|
hwpplayer1 joined #minetest-dev |
| 07:08 |
|
SFENCE joined #minetest-dev |
| 07:11 |
|
SFENCE joined #minetest-dev |
| 07:48 |
|
Noisytoot joined #minetest-dev |
| 08:02 |
|
Noisytoot joined #minetest-dev |
| 08:25 |
|
SFENCE joined #minetest-dev |
| 09:23 |
|
SFENCE joined #minetest-dev |
| 09:31 |
|
SFENCE joined #minetest-dev |
| 09:37 |
[MatrxMT] |
<Zughy> 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 |
| 09:57 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:44 |
|
Juri joined #minetest-dev |
| 10:44 |
|
Niklp joined #minetest-dev |
| 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 |
| 12:09 |
|
grorp joined #minetest-dev |
| 12:57 |
|
grorp left #minetest-dev |
| 13:14 |
|
TheCoffeMaker joined #minetest-dev |
| 14:05 |
|
TheCoffeMaker joined #minetest-dev |
| 14:27 |
|
SFENCE joined #minetest-dev |
| 14:30 |
|
SFENCE joined #minetest-dev |
| 14:48 |
|
TheCoffeMaker joined #minetest-dev |
| 15:21 |
|
mark-wiemer joined #minetest-dev |
| 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 |
<warr1024> sfan5, I'll have to take a look at it and see if I can get some screenshots |
| 15:42 |
|
TheCoffeMaker joined #minetest-dev |
| 15:43 |
[MatrxMT] |
<Zughy> 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] |
<Zughy> We're currently at 30 out of 39 |
| 16:08 |
|
SFENCE joined #minetest-dev |
| 16:28 |
|
hwpplayer1 joined #minetest-dev |
| 16:50 |
|
mark-wiemer joined #minetest-dev |
| 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 |
<wsor4035> @mark.wiemer 👆 |
| 17:23 |
|
grorp joined #minetest-dev |
| 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:12 |
|
Eragon joined #minetest-dev |
| 18:23 |
grorp |
sfan5: yes, I am |
| 18:38 |
|
Desour joined #minetest-dev |
| 19:11 |
|
fluxionary joined #minetest-dev |
| 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> (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 |
<warr1024> Like I just said above, it's necessary to get intratexture antialiasing with our current pipeline. |
| 19:33 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> No, that'd be me |
| 19:36 |
Desour |
also happens mesa llvmpipe, fyi |
| 19:37 |
MTDiscord |
<warr1024> 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 |
<luatic> 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 |
<warr1024> 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 |
<warr1024> If we made a dedicated GPU a requirement, how much of our audience would we lose though? |
| 19:39 |
MTDiscord |
<luatic> Desour: since you're here, can we go ahead and merge docs#115? |
| 19:40 |
MTDiscord |
<luatic> ah dangit |
| 19:40 |
Desour |
@warr my gpu is an itegrated, fyi |
| 19:40 |
MTDiscord |
<luatic> https://github.com/minetest/dev.luanti.org/pull/115 |
| 19:40 |
MTDiscord |
<luatic> (Lua code style guidelines dev.luanti.org PR) |
| 19:41 |
Desour |
luatic: ah yes, sure |
| 19:41 |
MTDiscord |
<luatic> alright, thanks |
| 19:42 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> For me, mipmap + aniso is just mipmap unless filtering is enabled, and FSAA @4 means 2fps. |
| 20:02 |
sfan5 |
it does |
| 20:03 |
|
SFENCE joined #minetest-dev |
| 20:04 |
sfan5 |
well I can't judge "properly" but it does have an effect on its own |
| 20:04 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> lol, it's gotta specify whether aniso implies doing aniso or not XD |
| 20:11 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> Driver bugs MAY exist but I'm unwilling to blame the weirdness of sfan's results on that quite yet :-) |
| 20:17 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> haha |
| 20:18 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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:40 |
|
hwpplayer1 joined #minetest-dev |
| 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 (<https://en.wikipedia.org/wiki/Jaggies?useskin=vector>) 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:52 |
|
Noisytoot joined #minetest-dev |
| 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 |
<warr1024> "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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
|
YuGiOhJCJ joined #minetest-dev |
| 21:35 |
sfan5 |
(IMO) |
| 21:36 |
MTDiscord |
<warr1024> 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 |
<warr1024> cost* |
| 21:39 |
sfan5 |
12us per run to 0.5us per run |
| 21:39 |
sfan5 |
now that's a success |
| 21:40 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<greenxenith> "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 |
<greenxenith> (s/on/in) |
| 22:16 |
[ |
both in the case of javascript and shaders, requiring them is a bad thing |
| 22:17 |
MTDiscord |
<warr1024> 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 |
<warr1024> of Luanti? Â Sounds easy. Â Of the web? Â Maybe a bit less easy. |
| 22:38 |
[ |
or rather works-without-shaders |
| 22:39 |
MTDiscord |
<luatic> I believe our image handling code could be more efficient & simpler if we standardized images to ARGB8 |
| 22:39 |
MTDiscord |
<luatic> 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 |
| 23:33 |
|
panwolfram joined #minetest-dev |
