| Time |
Nick |
Message |
| 01:48 |
MTDiscord |
<warr1024> Re: the oft-rumored "entity rendering is slow" problem ... is there an existing issue for it in GH already? I looked for one but only found one for particles, not entities. |
| 01:49 |
MTDiscord |
<warr1024> It has been suggested to me that this may be because people assumed that you'd run into severe server-side performance problems with many entities long before client-side became a problem, but I've actually already encountered (and worked around) this problem in the real world, so I'd like to have an issue open for a possible proper fix someday. |
| 01:50 |
MTDiscord |
<warr1024> If I DO end up having to open a new issue for this, is it a bug (like "entity rendering slow") or a feature request (like "make entity rendering more optimal")? |
| 02:55 |
|
srifqi joined #minetest-dev |
| 03:00 |
srifqi |
hello. #13872 is ready for review. the APKs are not ready yet |
| 03:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/13872 -- Formspec: Pass the second-touch event as is by srifqi |
| 03:24 |
srifqi |
ah, the VS checks are failed due to vcpkg |
| 03:40 |
srifqi |
the APKs are ready for testing (or use the one from GitHub action) |
| 04:52 |
erle |
warr1024 i would be very amused (and slightly irritated) if someone would tell you that opening an issue about a long-standing performance issue would be a feature request. or was this sarcasm, given that ”more optimal” is … a bit weird? |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:08 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:57 |
|
[MTMatrix] joined #minetest-dev |
| 05:57 |
|
[MTMatrix] joined #minetest-dev |
| 07:22 |
|
calcul0n joined #minetest-dev |
| 09:22 |
|
Warr1024 joined #minetest-dev |
| 09:40 |
|
pmp-p joined #minetest-dev |
| 09:46 |
|
Warr1024 joined #minetest-dev |
| 09:51 |
|
pmp-p joined #minetest-dev |
| 10:37 |
|
Desour joined #minetest-dev |
| 11:03 |
|
appguru joined #minetest-dev |
| 11:15 |
|
imi joined #minetest-dev |
| 11:29 |
|
calcul0n joined #minetest-dev |
| 11:43 |
Desour |
warr1024: I don't think we have an issue for that. (issues about the quality/performance of certain parts of the engine are generally rare. probably because it feels so in-concrete) if you can't find one either, please open it. I don't care if you take the bug report or feature request template, bug report might be more suitable for reproduction steps |
| 11:58 |
MTDiscord |
<luatic> Ultimately "performance issue" is a third category; it's neither "bug" nor "feature request". |
| 12:03 |
[MTMatrix] |
<localhost> minetest 5.8.0 in 2024? |
| 12:53 |
[MTMatrix] |
<Zughy> localhost: a couple weeks I guess |
| 13:36 |
rubenwardy |
5.8.0 in November |
| 13:37 |
rubenwardy |
(if we release in november, it can be used in the game jam) |
| 14:03 |
|
appguru joined #minetest-dev |
| 14:46 |
[MTMatrix] |
<Zughy> I host a workshop in December, it'd be great to have people interact with MT 5.8 |
| 14:48 |
erle |
oh, what kind of workshop and where? is it online? |
| 14:50 |
|
grorp joined #minetest-dev |
| 14:58 |
grorp |
Hi. Regarding #14007: I have authored 2 Irrlicht PRs and 2 Minetest PRs about texture filtering since the 5.7.0 release. These PRs have resulted in bugs and are causing a lot of unnecessary drama on IRC and Github. |
| 14:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/14007 -- Texture filtering regressions (biilinear and trilinear filtering broken, anisotropic filtering results inconsistent depending on GPU) |
| 14:58 |
grorp |
I don't currently have the time or the motivation to investigate and fix these bugs. For this reason, my approach would be to revert the relevant PR(s). |
| 14:58 |
grorp |
If someone else wants to investigate and fix these bugs, a revert is of course unncessary. |
| 14:59 |
rubenwardy |
I haven't had time to look into these bug reports, but if confirmed then I'm fine with a revert |
| 14:59 |
erle |
grorp what is the second PR? |
| 14:59 |
rubenwardy |
(with a caveat of the minetest filters being in MT) |
| 15:01 |
erle |
like we have https://github.com/minetest/minetest/pull/13683 is the second one this change? https://github.com/minetest/minetest/commit/9bef3c136a12c9238d6a55b5c8e14fc9b779db61 |
| 15:02 |
erle |
Warr1024 would you please check if the code in https://github.com/minetest/minetest/pull/14006 fixes your screenshot isuses or not? i feel unqualified to determine if it still occurs. |
| 15:09 |
sfan5 |
for this release it should definitely be reverted |
| 15:09 |
sfan5 |
I think the idea to get rid of bilinear for upscaling was good however |
| 15:36 |
MTDiscord |
<warr1024> I am also in favor of deprecating bilinear upscaling, as long as we don't trash downscaling in the process. If we eventually ever achieve a modernized shader-driven rendering pipeline (assuming it doesn't bar me from running MT altogether) then there are actually good "crisp" upscaling algos that preserve the squareness of pixels but offer intra-texture antialiasing without blurring that would be really nice to see. I've seen at |
| 15:36 |
MTDiscord |
least webgl demos of these things so I know they're achievable in principle. |
| 15:37 |
MTDiscord |
<warr1024> In the meantime, I can definitely live with upscaling without antialiasing; the "jagged edges" of pixels within a texture are at least consistent with the edges of polygonal geometry without AA (and we have other AA options for people who have the horsepower for it). |
| 15:37 |
erle |
refering the “squareness” of pixels is something that implies that the art stdle where pixels are point samples that need interpolation is not welcome (a POV which i can understand, i just want to point it out) |
| 15:38 |
MTDiscord |
<warr1024> Linear upscaling as an artistic choice option would be nice, but it would really be an enhancement because we've never actually offered creators control over this... |
| 15:38 |
MTDiscord |
<warr1024> and tbh linear upscaling is a shitty implementation of "pixels as point samples"; there are much better models, like gaussian, cubic, or sync, which better capture it 😄 |
| 15:39 |
erle |
which i think would *also* not be desired |
| 15:39 |
erle |
if we go with the art style justification |
| 15:39 |
erle |
btw i think the question if filtering is desired by users can probably be figured out by looking at screenshots and comparing it to other non-default options that are turned on in screenshots. |
| 15:40 |
erle |
(most users go with defaults, same as most devs go with defaults, so the question for me here is: is this enabled at the same rate as other non-default graphics options are? maybe more? maybe less?) |
| 15:41 |
MTDiscord |
<warr1024> oh, ick, we have to revert both MT and IrrMT in sync? That makes it majorly more complicated for me to compile 😒 ... it would have been so much nicer to just migrate the IrrMT stuff into MT, even if it does make the change inherently riskier... |
| 15:41 |
erle |
the entire irrlichtmt situation is homegrown. but if you can tell me WHERE to place this with zero risk of regressions, please do. |
| 15:42 |
erle |
my POV right now is: “i have no more experience than others which spent more time on coming up with it, any change i do that is not exactly like it was before has a non-zero chance of breaking something” |
| 15:43 |
erle |
especially because this stuff was approved and has no testing, i would not have much faith in an approval. but tell me, where would you put that filter function logically? |
| 15:45 |
MTDiscord |
<warr1024> I don't know the solutions for any of this stuff, I'm just pointing out that obstacles to testing are a problem. If somebody who knows the system better knows a solution, then all other things being equal, I would like it. If somebody does not, then I guess I'll take the L, it'll just be a bit longer before I figure out how to test certain things. |
| 15:55 |
|
Desour joined #minetest-dev |
| 15:58 |
|
grorp1 joined #minetest-dev |
| 18:01 |
sfan5 |
Announcement: |
| 18:01 |
sfan5 |
Per an internal team discussion and vote (6Y 1N) I am announcing that erlehmann will be banned from participating in minetest-dev IRC and the Minetest Github Org for one year, effective immediately. |
| 18:05 |
|
grorp joined #minetest-dev |
| 18:21 |
[MTMatrix] |
<Zughy> Reasons: |
| 18:21 |
[MTMatrix] |
<Zughy> 1. forcing development to spend a disproportinate amount of time on minor issues |
| 18:22 |
[MTMatrix] |
<Zughy> 2. lots of talking, very little dev work actually done |
| 18:22 |
[MTMatrix] |
<Zughy> 3. walls of text on IRC with the tendency to derail conversation |
| 18:22 |
[MTMatrix] |
<Zughy> 4. passive-aggression reported by multiple staff members |
| 18:22 |
[MTMatrix] |
<Zughy> All these aspects had been reported to erlehmann in the past, multiple times; unfortunately sorting little to no effect |
| 18:22 |
nrz |
Thanks for the info. He talk so much that it confuse people |
| 18:22 |
[MTMatrix] |
<Zughy> *disproportionate |
| 18:39 |
|
appguru joined #minetest-dev |
| 19:04 |
sfan5 |
can I push https://github.com/minetest/minetest/commit/0e4de28988a96e87f6391a654eff8eaeed3ef801? |
| 19:05 |
celeron55 |
seems harmless |
| 19:05 |
sfan5 |
done |
| 19:11 |
MTDiscord |
<warr1024> In the dreaded #14007, it looks like we (at least I) may have gotten 2 different issues mixed together: there's the loss of linear filtered upscaling (a controversial "feature" that was intentionally removed) and the loss of filtered downscaling on at least some hardware (seemingly an unintentional consequence). Should these be split into separate issues? |
| 19:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/14007 -- Texture filtering regressions (biilinear and trilinear filtering broken, anisotropic filtering results inconsistent depending on GPU) |
| 19:12 |
sfan5 |
they should |
| 19:12 |
MTDiscord |
<warr1024> I think it was my mistake; I misintepreted the issue when I first read it, but it does look like it was originally specifically about the upscaling. |
| 19:13 |
MTDiscord |
<warr1024> I can open a new issue, transfer my screenshots and whatnot, and then I'll just mark my comments on the original as off-topic (I think I have the ability to modify my own, right?) |
| 19:16 |
MTDiscord |
<warr1024> unless we're just gonna do the revert for 5.8 already (making it moot), in which case I suppose I should just wait and see if it gets reintroduced in 5.9-dev. |
| 19:16 |
MTDiscord |
<warr1024> Let me know which you prefer. |
| 19:17 |
sfan5 |
it will be reverted before release |
| 19:19 |
MTDiscord |
<warr1024> Thanks! I'll just leave it alone then. |
| 19:34 |
Desour |
14007 is also about a 3rd issue: anisotripic filter causes bilinear filtering on some platforms, for which the texture size min is a workaround |
| 19:34 |
MTDiscord |
<warr1024> Oof, I didn't even notice that was a separable issue. That sucks. |
| 19:37 |
sfan5 |
merging #14009, #14002, #14000, #13974 in 5m |
| 19:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/14009 -- [NOSQUASH :3] Fix some invalid float to integer conversions by Desour |
| 19:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/14002 -- Fix openSUSE build dependencies by jordan4ibanez |
| 19:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/14000 -- Add tick marks to position HUD element docs by MisterE123 |
| 19:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/13974 -- Fix mod translation updater bugs by Wuzzy2 |
| 22:46 |
|
LizzyFleck joined #minetest-dev |
| 22:50 |
|
appguru joined #minetest-dev |
| 23:34 |
|
panwolfram joined #minetest-dev |
| 23:53 |
|
appguru joined #minetest-dev |
| 23:54 |
|
fluxionary joined #minetest-dev |
