Time Nick Message 01:44 MTDiscord Command sent from Discord by herowl: 01:44 MTDiscord !tell sfan5 The point is to get final review(s) from coredevs during the meeting and potentially get something merged, not to "technically not violate the rules". Just getting a review&merge during the meeting is slightly more probable than in the last hours before the meeting. 01:44 ShadowBot MTDiscord: OK. 04:08 \o` I'm not sure why framerate is so low for the client. IIRC I got it to never go below 60fps about 6 years ago. But, now, I've tried several servers and 20 fps is about average. Maybe it's Wayland I'm not sure 04:08 \o` and that's with draw distance reduced 08:03 sfan5 . 08:13 sfan5 merging #15279 in 10m 08:13 ShadowBot https://github.com/minetest/minetest/issues/15279 -- [no squash] JSON fix and update our copy by sfan5 08:57 [MatrxMT] sfan5: how about #14726 at this point? It has two approvals 08:57 ShadowBot https://github.com/minetest/minetest/issues/14726 -- (Adoption) Gettext and plural support for client-side translations by y5nw 08:57 sfan5 if coredevs consider it fine then they may merge it 08:57 sfan5 (I have not looked at it) 08:59 nore I'm good with it, yes 09:17 nore rubenwardy: will merge in 2-3 hours except if you object, or if you want to do it first 09:17 rubenwardy Feel free to go ahead 09:20 nore Ok, doing that then 09:21 nore I don't remember the specific situations for rebase vs squash though 09:24 nore (after checking the git guidelines I don't see anything about it, but the commit history wouldn't pass the other conditions for commits so I'll squash) 09:29 nore Merged! 09:33 [MatrxMT] NICE! 10:53 MTDiscord \o`: obligatory "try setting transparency_sorting_distance = 0" 10:58 \o` luatic, ok thanks. After 6 years I'm trying to find my feet again. I'll try that 10:58 \o` I dunno if 6 years is right... I think my last commit was in 2018, not sure 10:59 rubenwardy https://zirk.us/@dosch/113299457486670058 11:02 MTDiscord rubenwardy: the link is broken for me 11:03 rubenwardy It's a user complaining about bad performance on rpi400, since 5.9. Disabling sorting distance doesn't fix it 11:05 \o` I dunno. 6 years ago I was getting a lot more than 20 fps after my optimisations 11:11 sfan5 rubenwardy: isn't that literally https://github.com/minetest/minetest/issues/14993 11:11 rubenwardy Disabling doesn't fix it 11:13 sfan5 https://github.com/minetest/minetest/pull/15115 maybe then 11:13 sfan5 either way this is not actionable without more info 11:15 rubenwardy I can ask them to open an issue or forward any questions you have 11:16 sfan5 I don't want to spend any time on this now but the reproduction steps are basically the same as #14993 11:16 ShadowBot https://github.com/minetest/minetest/issues/14993 -- Large FPS drop at certain locations on RPi 400, caused by transparency sorting 11:17 sfan5 hw info, screenshot, profiler output, detailed info what worked better when/where/... 13:41 MTDiscord pushing https://gist.github.com/appgurueu/662c1cd0b97e2c43f6ae3cd5c4a8be68 in 10m (fixes a regression i introduced which broke local anims) 13:44 Krock LGTM 13:44 Krock ( https://github.com/minetest/minetest/commit/06907aa99b56ecd ) 13:44 [MatrxMT] should add the PR number or commit hash that introduced the regression to the commit message 13:48 MTDiscord sure, will do 13:51 MTDiscord done 14:25 MTDiscord @Lars you mentioned reviewing the scrollbar pr today? 14:26 MTDiscord im at my pc for a couple hours, so any changes i can fix asap 15:46 chmodsayshello It seems like that through the "screenshot-preview" feature in the minetest client a content-db server can place files (with the user only opening the formspec, and not installing anything) on the user's hard drive outside of the "cdb" directory through path traversal, yet still is limitied to minetest's cache. Is this considered a bug or would it 15:46 chmodsayshello be a "won't fix" issue? 15:58 grorp imo we shouldn't try to get #14343 into 5.10.0. it's too late for the risky changes the PR makes to node lighting. 15:58 ShadowBot https://github.com/minetest/minetest/issues/14343 -- Ambient light and server control for it by Andrey2470T 16:00 grorp the PR has only really been ready-for-review for a 7 days now (https://github.com/minetest/minetest/pull/14343#issuecomment-2395253950) and it's a complex PR, so it doesn't even make sense to expect it to be merged for 5.10.0 16:00 grorp s/for a/for/ 16:00 MTDiscord It could be reverted if it continues to break the lighting 16:01 MTDiscord I thought that's what was agreed on 16:01 MTDiscord Yes, Lars suggested that and I and Herowl agreed on that 16:02 MTDiscord tbh just looking over the last few comments on the pr, it looks like your trying to show in a half finished project right before feature freeze 16:03 MTDiscord . s/show/shove 16:04 MTDiscord @herowl I've merged your branch 16:04 grorp jordan4ibanez: your "they want your PR to rot" complaint in https://irc.minetest.net/minetest-dev/2024-10-11#i_6207755 is unjustified imo. the PR has only been ready-for-review again for 7 days now and it has proven to be complex. 16:05 MTDiscord wsor: The project is quite finished, but unit tests are failing, and it's fault of the unit tests. I wrote correct code that worked properly, but didn't check unit tests on it. Andrey took my code and made changes to satisfy unit tests, and the changes broke rendering. 16:06 MTDiscord grorp: I don't see differences on the screenshots in your latest comment. Maybe I'm blind. 16:06 MTDiscord Anyway, if it is decided that the precision is not enough and we need the new vertex format etc., I'm fine with it. 16:06 MTDiscord I literally read the entire thing in 5 minutes with a basic understanding of it 16:07 MTDiscord But those unit tests shouldn't be used as a justification to reject it. 16:07 [MatrxMT] +1 with what wsor said 16:07 MTDiscord herowl: more so a combo of unresolved review comments, grorps screenshots, unit tests, etc 16:07 MTDiscord I understand I has probably changed, but your deplatforming of my previous statement with the older version as the context is quite unfair 16:07 MTDiscord It 16:08 MTDiscord Review comments are resolved. I don't see the differences in the grorp's screenshots, maybe something's wrong with me, but the way I see it, it's correct. Unit tests are broken themselves. 16:09 MTDiscord Tbh I have one more idea 16:09 MTDiscord anyways, my two bent pennies dont really matter, its more so up to the core devs. 16:10 MTDiscord To use the new packing only when ambient light is not black (i.e. unset). 16:10 MTDiscord In that case, it doesn't cause any sort of regressions when the new API is not used, and it may look off only when the new API is actually used. 16:10 grorp jordan4ibanez: I responded to your statement because that one seemed unfair to me. I'm not sure what you mean. 16:11 MTDiscord Because I've seen simpler prs than this sit for years. Do you think that's fair to the contributors? Why do you think we lose so many 16:11 MTDiscord @grorp why did you add "Action/change needed" tag? Are the last commits not really changes? 16:12 MTDiscord jordan: +1 16:12 MTDiscord It's caused by understaffing mostly, but yeah, there are other cases too. 16:14 sfan5 chmodsayshello: that would be a bug 16:15 sfan5 <+MTDiscord> grorp: I don't see differences on the screenshots in your latest comment. Maybe I'm blind. 16:15 sfan5 please them in side-by-side tabs and switch between them 16:16 sfan5 alternative someone could post them to https://slow.pics/ 16:16 MTDiscord I don't see the difference on the screenshots also at all 16:18 MTDiscord look at the shaded sand node sides 16:19 grorp For the first two screenshots: Consider the right half of the picture. The top of the sand far away is brighter than on master. On master, the sand becomes brighter smoothly when getting closer to the light. With the PR, the sand becomes brighter in slight stripes. 16:19 grorp but describing this is hard, better if you see it yourself 16:22 MTDiscord I wrote in the PR the broken face shading that you showed on the first two screenshots was fixed by Herowl and I merged these fixes. These ones are already invalid. 16:22 sfan5 there are noticable differences in how smooth light levels are 16:22 grorp The screenshots in https://github.com/minetest/minetest/pull/14343#issuecomment-2409027834 were taken with https://github.com/Andrey2470T/minetest/pull/3 applied 16:23 grorp so they're not "invalid" 16:25 [MatrxMT] We're also wasting a lot of time debating about this thing. Can't it wait 3 more months? It's not like we're releasing every 8 months like we used to 16:28 MTDiscord Zughy: Well... in that case, we'll need to add the new format, migrate AO calculation, and adjust the unit tests. I.e. there's no point in "waiting". Either the current state is utterly unsatisfying and we need the new format or we don't. 16:29 MTDiscord What I'm afraid is that the new vertex format will cause performance issues or other crap. 16:29 sfan5 the precision problem could potentially be worked around by moving decode_light to the shader 16:30 [MatrxMT] It's one hour and a half to the feature freeze, with a meeting incoming, where EU core devs are also supposed to eat in the meanwhile 16:30 grorp and we have something much more important to get done in the meeting 16:30 MTDiscord @grorp how I would not struggle to differ these screenshots from each other I fail in that, don't see the any difference 16:32 sfan5 <+sfan5> place them in side-by-side tabs and repeatedly switch between them 16:32 sfan5 if you can't see the difference that way I don't know what else we can do 16:32 sfan5 hopefully you have a monitor that was manufactured in the last 8 years and not totally messed up gamma/color reproduction? 16:33 MTDiscord Color difference between layers in gimp 16:33 cx384 merging #14318 in 5 min 16:33 ShadowBot https://github.com/minetest/minetest/issues/14318 -- Fix HUD inventory direction position by cx384 16:33 MTDiscord sfan5: yeah, with smooth lighting off it is quite visible... 16:34 MTDiscord so screw my hack and we need the precision? 16:35 sfan5 correct 16:36 MTDiscord Zughy, my feature is hanging open during a half-year and see how many changes it endured... I even needed to squash all commits into the single one because their count did it difficult to solve the conflicts for me. Also, the comments count is about 200. And leaving it for still 3 months when it is about to be ready and needs only in solving the unittests problem is pretty dump as I think 16:36 MTDiscord Well, there is the precision loss, and AO issue. 16:36 MTDiscord I wouldn't care about those if it depended on me. 16:36 MTDiscord But I can see that others can care about it. 16:36 sfan5 "I even needed to squash all commits into the single one" you can use git merge btw 16:38 MTDiscord Also I looked deep into the unittests, and I'm not sure why they are failing. 16:38 MTDiscord I personally don't see why those particular unittests are even there, but that's another issue. 16:39 MTDiscord Essentially, looks like we need to rewrite the underlying code. Not from the ground up, but we need to rewrite the meshgen a lot. 16:40 MTDiscord All that to allow the new vertex format, increase precision to what was before, and accommodate for AO. 16:40 MTDiscord Hopefully how to improve the unittests will get clearer along the way. 16:41 MTDiscord As it is now, I'm kind of giving up. I don't see a way to fix those unittests, and I don't see who does and wants to fix them. 16:41 MTDiscord I gather #14543 is also postponed? 16:41 ShadowBot https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus 16:41 MTDiscord And on that one there are not even visible issues. 16:42 MTDiscord ...anymore 16:42 sfan5 freeze has not officially started but I don't see a chance 16:43 MTDiscord gl on the rename, will grab popcorn 16:43 MTDiscord I think we probably need something like a new format, but it should be thought out well 16:44 MTDiscord Another idea I had: In principle a single byte suffices for hardware coloring if we pass the palette to the shader 16:45 MTDiscord @herowl I suppose all hacks that we made in the latest commits were a waste of time? The PR has postponed for 5.11. And for fixing other issues e.g. AO and shadows it will certainly need in a new format since there is no a more free space for encoding something more 16:45 sfan5 <+sfan5> the precision problem could potentially be worked around by moving decode_light to the shader 16:45 sfan5 ^ 16:45 sfan5 but idk about the issue with AO 16:46 sfan5 either way a new vertex format is relatively easy to do 16:46 sfan5 just please do it in a separate PR 16:46 sfan5 and we will need to drop non-shader support 16:46 sfan5 (probably) 16:49 MTDiscord Yes, I lost about 20h working on hacks that don't suffice. 16:50 MTDiscord What palette? There's no universal palette. 16:50 MTDiscord It is still necessary to think on which structure the format will have. Adding only another color attribute? Probably it could be extendable. 16:50 MTDiscord Adding only one byte 16:50 MTDiscord The palette specified in the node def. I'm not claiming it is universal. Depending on how our meshgen works this might require creating more mesh buffers however, which might be a drawback. 16:51 MTDiscord I'm afraid it won't work like that. 16:52 sfan5 i don't see why not. if we group buffers by texture right now it should work fine to include the palette 16:52 sfan5 only problem is it needs multitexture support 16:53 sfan5 or you'd have to pass it as shader uniform 16:53 MTDiscord hw color can be done without a palette though 16:53 MTDiscord palette is only for when you're using param2 coloring 16:53 MTDiscord Tbh it is very distressing that I took it upon myself to solve the remainig problems in the ambient PR. I should focus on my closed vertex format... 16:53 sfan5 arbitrary colors? in that case it won't work 16:54 MTDiscord sfan5: https://api.minetest.net/textures/#global-color 16:55 sfan5 in any case I reiterate my suggestion to do iterative steps and not everything in one PR 16:55 MTDiscord andrey: it was me who made the hacks that don't require the new format 16:55 sfan5 it's okay if we change the vertex format in preparation without any visible benefit 16:55 sfan5 or refactor hw coloring or whatever 16:56 MTDiscord I guess we'll have to do it like that... 16:57 MTDiscord these aren't really arbitrary colors 16:57 MTDiscord the color thing is again per-def 16:57 MTDiscord Actually me too, because I wasted much time on the awareness of the whole problem and I also suggested a few fixes that didn't work 16:57 MTDiscord the itemstack meta would be a bit trickier for itemstack objects but since we're currently doing one drawcall per entity a simple uniform would work there 16:58 MTDiscord luatic: Making entirely separate buffers for all nodes is the opposite of optimization. 16:58 MTDiscord this does not need entirely separate buffers for all nodes 16:59 MTDiscord This feels janky really 17:00 MTDiscord Hang on... 17:00 MTDiscord we could make an extra large palette 17:00 MTDiscord and use two bytes to index it 17:01 MTDiscord technically would work 17:01 MTDiscord but tbh 17:01 MTDiscord I think we should move towards smooth hw coloring, so you could interpolate the color on a range of nodes 17:01 MTDiscord and that requires arbitrary hw color 17:01 MTDiscord if we want colored lighting, we probably need a new color format anyway... 17:09 MTDiscord I don't certainly think only one byte... imagine it would need to save something still, e.g. smooth color transitions like gradients no node tiles. Or a node could have a few UVs, e.g. for future lightmaps optimizing the lighting calculations. Or it could be something shader-specific when the custom shader pipeline gets implemented. So the format should be extendable. 17:09 MTDiscord Well, you can change the format later anyway 17:09 MTDiscord If do a new vertex format, do it with a quality and taking into account for future changes 17:10 MTDiscord Do it in a way so it's less hardcoded and easier to change in the future, but for now support only what we have now. 17:10 MTDiscord It's all clientside, so you can just change it and it doesn't break any compatibility. 17:11 MTDiscord I'm only considering one byte vs color 17:11 MTDiscord the latter to allow colored lighting 17:12 MTDiscord which could happen very soon if we refactor the light calculations, which we need anyway to unhardcode AO 17:12 MTDiscord yep so far I see a need for 3x 1 byte RGB hw color, 1 byte light ratio, 1 byte light brightness 17:12 MTDiscord we currently have a 4x 1 byte RGBA vertex colors and abuse alpha for the light ratio 17:12 MTDiscord adding just one more byte should also be acceptable for performance 17:13 MTDiscord Possible still a separate 3 x 1 byte color will be needed for the colored node lighting 17:15 MTDiscord I think the new vertex formar could be a just byte buffer with a varyable length, so it could be differ from node to node. E.g. those nodes that doesn't need in the hw, just won't have that 17:15 MTDiscord buffer of buffers? uh oh 17:16 MTDiscord For the optimisation 17:16 MTDiscord I think it essentially just needs to be a tagged union 17:16 MTDiscord which to an extent Irrlicht already tries to implement, just the options aren't quite what we're looking for 17:16 MTDiscord Or better call it the byte array, not buffer 17:16 MTDiscord tagged union is size of its largest member though? 17:17 MTDiscord i should be more specific 17:17 MTDiscord a tagged union of buffers (pointers) basically 17:17 MTDiscord not a buffer of tagged unions or anything like that 17:17 MTDiscord I'm afraid that it either won't work on older hardware or won't be very efficient 17:18 MTDiscord I don't think we're striving to support OGL 1 indefinitely 17:18 MTDiscord lol 17:18 MTDiscord what about performance though? 17:18 MTDiscord I am optimistic but ultimately only benchmarks can tell 17:18 MTDiscord It would certainly not work with the fixed function pipeline 17:18 MTDiscord Which is in ogl1 now 17:19 MTDiscord But since it is deprecated and is about to be removed, I think the varyable-sized vertex format could be considered 17:20 MTDiscord we're to support ogl3 and ogles2, right? 17:20 MTDiscord I think only to support them now, yes 17:33 Krock opengl3 requires SDL and we're yet not far enough to enable SDL by default for release 17:33 Krock just throwing that in 17:33 Krock also: meeting in 27 minutes 17:38 [ Please do not drop support for OpenGL 2.1. Or if you do, at least make sure that OpenGL ES support is enabled by default and used if OpenGL 3 is unavailable 17:38 [ Do dynamic shadows work on GLES2? 17:38 MTDiscord pretty sure the only support that might be dropped atm is opengl 1 17:38 sfan5 shadows only work on opengl, not ogles2 or opengl3 17:39 sfan5 not due to technical limitations, just nobody spent time to make it work 17:41 sfan5 what is likely to be dropped is support opengl older than 2.0 (so w/o shaders) 17:41 sfan5 dropping the opengl driver is more long-term and unclear 17:42 sfan5 <+MTDiscord> But since it is deprecated and is about to be removed, I think the varyable-sized vertex format could be considered 17:42 Krock at least dependency-wise it does not matter whether OpenGL 1 is used, or only 2.x 17:43 sfan5 the complexity of choosing different vertex formats depending on what the nodes actually need just to save one or two bytes is likely not to be worth it 17:46 sfan5 btw there's no reason opengl3 couldn't work without SDL. just nobody made it work 17:52 Krock right. Makes sense. 17:55 MTDiscord Currently Irrlicht implements only the dynamic setting the vertex attribute arrays based on the varyable VertexType as it happens in the OGL3 driver, but the problem is that the vertex types in meshes are not varyable, but fixed. There are only three accessible variants. 17:55 MTDiscord Yes, I think we need more variants there. 17:56 MTDiscord Or better implement the vertex type as a varyable byte array without hardcoding the certain types 17:58 MTDiscord Such way dropping video::S3DVertex, S3DVertex2TCoords and S3DVertexTangents 17:58 MTDiscord If I don't mistake, the two last ones are not even used anywhere around the engine 18:00 Krock Start of the meeting. pinging those who reacted to the announcement. sfan5 Desour grorp cx384 Zughy 18:01 nore I'm there also! 18:01 MTDiscord me too :) 18:01 Krock hello and welcome! that's great to see :) 18:01 nore hello everyone :) 18:01 grorp hi :) 18:01 Desour I'm here. but I've not yet read the irc logs 18:01 MTDiscord I am on a train. Expect to leave it in 15 minutes. 18:02 [MatrxMT] hi! 18:02 cx384 I'm here but I doubt I will be of any use. 18:04 Krock cx384: oh? I wouldn't think so. let's see what's to discuss. 18:04 Krock > rename time! 18:04 Krock this has been discussed internally already and is most likely a topic that should be continued there 18:05 Krock I see that a few clarifications were made today regarding the organization renaming - so it must be still ongoing. 18:06 [MatrxMT] we need to rename today, we need the new name before 5.10 18:06 Krock why exactly 5.10? 18:06 [MatrxMT] we can't apply for FOSDEM with Minetest if we're gonna rename in the meanwhile 18:07 [MatrxMT] 5.11 will happen in late January, that's way too late 18:07 Krock then apply as Minetest and rename later because things take time and the FOSDEM happened so often in the past witohut issues 18:07 [MatrxMT] I don't agree, also because everything seems ready? 18:07 grorp why don't we do the rename today though? 18:07 [ what's the point of renaming? 18:07 Krock no need to rush things now 18:08 MTDiscord [_: that discussion has been long had 18:08 nore even if we do the renaming, I'd say we can still apply for FOSDEM with Minetest, can't we? 18:08 [MatrxMT] rush? It's been over a year, that doesn't seem like rushing 18:08 rubenwardy I don't think we need to do all the renaming at once, just announce it soon and start doing it in the open 18:08 grorp +1 18:08 MTDiscord +1 18:08 [MatrxMT] I'm sorry but it's not you the ones who're gonna apply for FOSDEM. I don't want to do things twice 18:08 grorp I think we're ready to publish the blog post now, though 18:08 nore +1 18:08 [MatrxMT] +1 with rubenwardy 18:09 [ what will the new name be? 18:09 rubenwardy To be announced 18:09 [MatrxMT] Broccoloni 18:09 [MatrxMT] jk 18:10 grorp I guess somebody needs to create a minetest/blog PR with the annoucement so it can be reviewed, which would reveal the name 18:10 nore I think that as soon as the annoucement concerning the new name is made, we can start to use it in various places, such as the fosdem application 18:10 [MatrxMT] Was GreenXenith being pinged in the end? 18:10 [MatrxMT] grorp: also a forum post 18:10 [MatrxMT] no need to review by the way, at least 4 of us went through the document 18:11 Krock looking at the discussion on GitHub it seems that all major endpoints are reserved now 18:11 grorp Zughy: I meant the technical aspects 18:14 Krock so the next steps are to announce the change. rubenwardy would you be willing to coordinate this a bit, or is someone else taking the lead? 18:14 [MatrxMT] I'm stressing people privately 🙃 18:14 Krock okay so Zughy it is. 18:16 Krock any additional points to add here? something to clarify? 18:17 MTDiscord should we start working on some s/minetest/broccoloni PRs for some of the non-main repos already? 18:17 MTDiscord Broccoloni?? 18:18 Krock @zmv7 temporary name until disclosure 18:18 Krock @luatic I suppose you could start to work on them without publishing. Problem here is that it would need coodination to not do the same thing twice 18:19 [MatrxMT] Extra: I love Codeberg guys, trolled half of Mastodon https://social.anoxinon.de/@Codeberg/113296648740470783 18:19 Krock thus it might be easier to just await the publication and then work on the PR where nobody yet has begun 18:20 Krock Zughy: I didn't know that Google Drive is going to be renamed 18:20 Krock ( /jk ) 18:20 MTDiscord New name is "proprietary"? 😆 GNUn't 18:21 Krock > feature freeze time 18:21 Krock https://github.com/minetest/minetest/milestone/24 18:21 MTDiscord Btw, how about the texture atlas PR? Does anybody have a will of reviewing it? 18:23 MTDiscord I did some late fixes in that and I got much better rendering performance than in the master, FPS is 2-3 higher at the middle and drawtime hesitates always from 1-2 ms 18:24 Krock @andrey2470t you mention a reduction of drawcalls - what's the difference in percent (demo world) ? 18:24 MTDiscord Will recently-merged #15279 and #15040 prs be in 5.10.0 tho? 18:24 ShadowBot https://github.com/minetest/minetest/issues/15279 -- [no squash] JSON fix and update our copy by sfan5 18:24 ShadowBot https://github.com/minetest/minetest/issues/15040 -- Separate anticheat settings [#2] by zmv7 18:25 MTDiscord zmv7: yes of course, why wouldn't they be? 18:25 MTDiscord But there are still issues in the textures packing when there are many textures from the tile layers and also there's an issue with the crack animation since it tries to overlay the cracks atop the atlas 18:25 Krock @zmv7 what's contained in master will be in the next release 18:25 Krock that's why there'll be a feature freeze 18:25 MTDiscord I just don't see them in the milestone 18:25 Krock they didn't target 5.10.0 specifically, thus no milestone. they aren't necessary for that release. 18:25 [ why doesn't minetest move to codeberg (or something other free github replacement)? 18:25 MTDiscord the milestone is just sort of a wishlist, not a collection of everything that's part of the release 18:26 MTDiscord Got it 18:26 Krock [: off-topic. please save that discussion for later. there's also an issue about this. 18:27 sfan5 did I miss anything 18:27 MTDiscord For some reason I thought that this works like with debian's system(unstable, testing, stable, ...) lol 18:27 Krock sfan5: rename announcement soon. the broccoli is the temporary pseudonyme. then rename as the time goes on. 18:28 MTDiscord I don't know in the percents, I can say only how higher the framerate is at the middle, with and without atlas 18:28 sfan5 I see 18:28 sfan5 so someone will work on publishing the blogpost? 18:28 nore concerning the fixes in the milestone, I can review #15272 if needed 18:28 ShadowBot https://github.com/minetest/minetest/issues/15272 -- Show warning in the settings menu when shaders are disabled by grorp 18:28 chmodsayshello Zughy: Could you please remove "Rebase needed" from #15104 again as I have resolved the merge conflict? 18:28 ShadowBot https://github.com/minetest/minetest/issues/15104 -- Add console-scrollbar by chmodsayshello 18:29 MTDiscord by "at the middle" you mean on average? so 2x - 3x the fps on average on your config? 18:29 Krock @andrey2470t I always question whether it's worth the N lines of additional code (that needs maintenance) to e.g. boost the FPS from 60 to 62. That's why it would be important to have some repeatable performance measurements. 18:29 Krock s/repeatable/reproducible/ 18:29 MTDiscord On average in other words 18:30 Krock nore: that would help. thanks. 18:31 Krock sfan5: the blog post was mentioned previously by grorp, thus I assumed there's already something. This might be best discussed in the internal chat to do a peer review. 18:31 sfan5 there's a draft linked in our internal discussions. I have looked at it 18:31 sfan5 and others too 18:31 grorp Zughy and I are working to publish it 18:31 Krock great thanks, grorp . 18:31 grorp or "and me"? English is complicated. 18:32 MTDiscord i vaguely feel like there might be a cleaner solution than atlases using modern opengl features but i haven't yet looked into it properly. hence why i'm not reviewing it just yet. 18:32 Krock I don't know either when to use I or me, but it sounds correct and that's what counts ;) 18:32 Desour Krock: the texture atlas PR fixes a performance bottleneck, so it's definitely worth it. (or something similar, i.e. based on array textures) 18:32 MTDiscord No, if the master has 180-270 FPS with a simple scene, e.g. with plains without water, my PR will have the stable 400 and even higher. That's a result of my tests without shaders enabled, with viewing_range=190 18:32 MTDiscord specifically: bindless textures, see https://www.khronos.org/opengl/wiki/Bindless_Texture 18:33 sfan5 have we formally declared feature freeze? 18:33 Krock not yet 18:34 sfan5 then let's do so 18:34 Krock currently going through the milestone and it looks pretty good 18:34 Krock I'll move my PR to 5.11 18:35 Krock because that code is quite brittle and I'd prefer to have it in an early dev version 18:35 MTDiscord With the water scene with the atlas FPS sinks down before 350, but not before 50 how it happens now. That happens due to an improved material and buffer batching (almost all nodes has the same texture - atlas, so it is not needed in additional switches how it happens with the separate textures 18:35 Krock ("that code" = the entirety of inventory movement) 18:36 nore we should probably move #13961 which is the associated issue as well in that case 18:36 ShadowBot https://github.com/minetest/minetest/issues/13961 -- Strange behavior when dragging&dropping from MTG creative inventory (since #13146) 18:37 Krock any objections for doing the feature freeze now? 18:37 Krock nore: moved. 18:37 MTDiscord freeze it 🧊 18:38 sfan5 i think we should review issues in the milestone now 18:39 Krock > #14613 18:39 ShadowBot https://github.com/minetest/minetest/issues/14613 -- The data structure problem with active objects 18:39 sfan5 move to 5.11, next. 18:39 Krock > #14817 18:39 ShadowBot https://github.com/minetest/minetest/issues/14817 -- Animation blending no longer works 18:39 Krock PR #15267 18:39 ShadowBot https://github.com/minetest/minetest/issues/15267 -- Fix animation blending by appgurueu 18:40 sfan5 can't say much about it but if we have a fix I guess we can keep it 18:40 Krock @luatic Do you happen to have the time to get the PR ready during the feature freeze? 18:41 Krock it might not be too important after all. not a blocker. 18:41 Krock let's keep the issue in the milestone for now. we can still skip over it for 5.10. 18:41 MTDiscord I can't say. But don't wait on it. 18:42 Krock alright. 18:42 Krock > #14939 18:42 ShadowBot https://github.com/minetest/minetest/issues/14939 -- Minetest builds for Mac don't have signature 18:42 nore from the discussion, looks like we won't be able to get a signed version in the next too weeks 18:42 grorp when I open the blog PR, may I include the real new name? 18:42 grorp would be the first public use :o 18:43 rubenwardy might be worth doing prelimarly code review without pushing publicly? 18:43 MTDiscord I think if possible the first public use should be in the announcement 18:43 rubenwardy if you can build the blog, send a screenshot 18:43 rubenwardy and send me the diff 18:43 sfan5 I think sfence would have to address that issue, Krock 18:43 sfan5 i think the UX of running unsigned apps is quite annoying but nothing we can (urgently) do 18:43 sfan5 so I'd remove from milestone 18:44 Krock sfan5: yes and he's currently in transit so probably no answer. I waited a bit for the blog discussion to finish 18:44 Krock moved to 5.11 because we eventually need to fix it 18:44 MTDiscord Someone (say rubenwardy) could make a private repo or use their private fork of the blog repo, then review the PR on that, and once it's fine just manually push it and boom 18:44 nore from the discussion, "it took GNOME almost 2 months to get a key/cert/thing and start to sign GIMP builds" anyway 18:44 Krock > #14818 18:44 ShadowBot https://github.com/minetest/minetest/issues/14818 -- Attachments lag behind bones under some circumstances 18:45 rubenwardy rememebr to disable SDL2 at the start of freeze 18:45 Krock yet no PR to fix it and not a blocker 18:45 Krock rubenwardy: it's already in the milestone 18:45 sfan5 yeah 18:46 Krock removing the milestone assignment here because it's not as much of an every-day issue for end users. otherwise we'd keep pushing the same issues from one milestone to the next 18:46 nore it looks like it is a long-standing bug, not a new one 18:47 MTDiscord freeze happening now? 18:47 MTDiscord 14818 definitely is older than 5.9.x 18:47 MTDiscord I'm hoping i can take sdl2 by 5.12 18:47 MTDiscord *11 18:47 sfan5 > #15027 18:47 MTDiscord for input that is 18:47 ShadowBot https://github.com/minetest/minetest/issues/15027 -- Bounciness issues with large dtime steps 18:47 sfan5 fix pending, next. 18:47 Krock send review needed 18:47 Krock *second 18:47 MTDiscord i'll review the PR for that one 18:48 sfan5 > #15005 18:48 ShadowBot https://github.com/minetest/minetest/issues/15005 -- Touchscreen can be enabled when Irrlicht device doesn't support touchscreen (CIrrDeviceWin32, CIrrDeviceMacOSX) 18:48 sfan5 waiting for answer to comment, next. 18:48 Krock replied for clarification 18:48 Krock > #15193 18:48 ShadowBot https://github.com/minetest/minetest/issues/15193 -- Different globalstep compared to <5.9? 18:48 sfan5 unclear. no reproducer, cause or fix. 18:48 Krock is this another ghostbuster-like issue? 18:48 sfan5 move to next 18:48 Krock > #15264 rubenwardy here's your reminder 18:48 ShadowBot https://github.com/minetest/minetest/issues/15264 -- Revert SDL for 5.10, try again in 5.11 18:49 Krock > #15270 PR is pending here 18:49 ShadowBot https://github.com/minetest/minetest/issues/15270 -- Bad UX when upgrading to 5.10 with shaders disabled 18:49 Krock at least the one about a notification in the settings. nore wanted to review it soon. 18:49 nore yes, I'll review it tonight or tomorrow night 18:49 Krock no worries. you've got more time than that. 18:50 Krock and of list 18:50 MTDiscord im gonna say no to 15005 and I'll elaborate later 18:50 Krock * -- end of milestone -- 18:50 nore (I know I have but I'll forget otherwise :) ) 18:50 MTDiscord a user using a Chromebook complained about touch screens 18:50 MTDiscord we shouldn't hide it 18:51 Krock @cscscscscscscscscscscscscscscscs what OS are they using on the Chomebook? We might need a public support matrix for SDL vs Irrlicht because I keep running into the same uncertianinties 18:51 MTDiscord i believe it's Android related 18:52 Krock if it's Android then touch controls already work out of the box 18:52 MTDiscord Yes they wanted to disable touchscreen 18:52 MTDiscord Android removes it 18:52 Krock let them test a master build after #14542 18:52 ShadowBot https://github.com/minetest/minetest/issues/14542 -- [no squash] Auto-toggle TouchScreenGUI in-game when receiving touch/mouse input by grorp 18:52 Krock then report back whether it worked well enough. 18:53 MTDiscord I'm afraid they pregnant won't be able to test it 18:53 MTDiscord *PROBABLY 18:53 Krock Any other topics/PRs to discuss (in concept or review) ? 18:54 MTDiscord for chromebook users it's probably better to run minetest in the crostini linux container 18:54 MTDiscord worked well last time I tried it there at least 18:54 sfan5 don't think so 18:54 Krock general reminder that there's PR's waiting on a second approval 18:55 MTDiscord I'm so sorry I'm using my phone swipe text 18:55 Krock ofc feature ones are not too important in the next few weeks. 18:55 [ there's also GNU/Linux phones 18:55 MTDiscord it was for his students 18:55 MTDiscord we shouldn't remove/hide the option 18:56 MTDiscord you can still use touchscreen menus with it off 18:57 MTDiscord Linux support on new Chromebook didn't exist 18:57 MTDiscord *old 18:57 Krock saving the meeting notes now. Thank you for participating. Other PRs can still be discussed here, just without the meeting schedule behind it. 18:57 MTDiscord okay yeah I understand, easier to deploy android apps on chrome OS than crostini, which most managed domains block because of the risk of students having fun with it 18:57 MTDiscord I'll reply to the issues late but I'm at work 18:57 MTDiscord that too yeah 18:59 MTDiscord I think his complaint was that his students in school used the older Chromebooks which don't support Christine 18:59 MTDiscord crostini 19:01 Krock the wiki died. 504 Gateway Time-out 19:06 [MatrxMT] it's working again, at least the dev one 19:19 sfan5 something I just noticed is that since clouds now use shaders and we have clouds in the main menu that means Minetest will just not launch if you don't have shader support 19:19 sfan5 this should affect approximately nobody and can be fixed by adding 'enable_shaders = false' to minetest.conf 19:20 sfan5 IMO we should just keep it like this and see if anyone ever complains 19:20 Desour minetest is a test 19:21 [MatrxMT] *Broccoloni is a test 19:32 nore approved #15272, I think we can merge it since grorp is a core dev? 19:32 ShadowBot https://github.com/minetest/minetest/issues/15272 -- Show warning in the settings menu when shaders are disabled by grorp 19:37 sfan5 sure 19:59 nore ok, will merge tomorrow if no-one objects before then 21:19 MTDiscord I think I will make the solution of #15287 later 21:19 ShadowBot https://github.com/minetest/minetest/issues/15287 -- Render the cracked node counterpart instead of the rebuilding the whole mapblock mesh 21:26 MTDiscord Except that, it seems when nodes are dug the same mapblock mesh gets rebuilt a tens of times instead of only three ones (at the begin, at the end of the crack animation and dire tly when the node gets dug 21:50 sfan5 for completeness: https://blog.minetest.net/2024/10/13/Introducing-Our-New-Name/ 21:51 [MatrxMT] Wait, it's not Broccoloni?! OH C'MON 21:52 sfan5 Broccolibre 21:52 sfan5 need a broccoli themed game 21:53 [MatrxMT] fun fact: "brocco" is a way to say stupid in Italian, so "Broccolibre" sounded like "Free dumdum" 21:56 ROllerozxa I have to say I am very happy with the new name, I used to be worried but now I am extremely excited 21:56 MTDiscord luatic is my favorite game to play with 21:57 [ So will the IRC channels be renamed to #luanti and #luanti-dev? 21:59 sfan5 dunno 22:01 MTDiscord Some insight: https://en.wiktionary.org/wiki/%CE%BB%CF%85%CF%8C%CE%BD%CF%84%CF%89%CE%BD 22:01 MTDiscord lyonton, means "let them set free" 22:03 MTDiscord I've been overwhelmed with this news, but I don't think I will call the project by the new name after renaming, "Minetest" is for me a familiar and established name 22:15 sfan5 https://en.m.wiktionary.org/wiki/Luanci hmm 23:01 MTDiscord Great work on the rename! I'm really actually quite impressed. You captured the core (Lua) and it's generic in terms of what is possible, yet distinct. I may not love it, but on first glance I don't hate it. Name went from a 2 -> 7 or 8. Thanks for the hard work! 23:49 MTDiscord So... Logo? It looks like everything else has been considered... 23:50 [MatrxMT] Not touching it. Surely not for the foreseeable future 23:51 MTDiscord seems reasonable to me, jsut curious