Time  Nick       Message
00:14 [MatrxMT]  <Zughy> Kind of related, v-rob: I think that if you reviewed more PRs people would look at your code faster, no matter the choice taken
00:16 Mantar     I never thought about it like that, but it makes sense. Reducing the pool of PRs waiting around for review means a greater chance yours will get looked at
00:25 rubenwardy Quid pro quo
01:15 MTDiscord  <exe_virus> Do more work for your work!   Yeah if you review mine I'll read all of your part 1 and try to make sane recommendations: https://github.com/minetest/minetest/pull/14643
01:15 MTDiscord  <exe_virus> but yeah also don't do more work too - this is pro bono
16:20 sfan5      merging #15049, #15052, #15044 in n minutes (n >= 5, n < 30)
16:20 ShadowBot  https://github.com/minetest/minetest/issues/15049 -- Reword CMake message for LuaJIT detection by wsor4035
16:20 ShadowBot  https://github.com/minetest/minetest/issues/15052 -- Meshgen: Don't get lights for not drawn solid faces by Desour
16:20 ShadowBot  https://github.com/minetest/minetest/issues/15044 -- zstd: Fix minetest.decompress lockup when data ends too early by SmallJoker
19:07 Krock      will merge #15007 and #15015 in 15 minutes
19:07 ShadowBot  https://github.com/minetest/minetest/issues/15007 -- Make getting bone overrides return the "same" euler angles by appgurueu
19:07 ShadowBot  https://github.com/minetest/minetest/issues/15015 -- LocalPlayer: Restore 2u height sneak jump by SmallJoker
19:22 Krock      merging
19:23 Krock      done
19:51 sfan5      any more comments on #14900?
19:51 ShadowBot  https://github.com/minetest/minetest/issues/14900 -- Mods should be able to influence the fixed map lighting
20:05 Krock      there's also light corrections by shaders. having this one customizable - preferably at no performance penalty - would be a convenient way to make adjustments for all clients
20:05 Krock      I'd also very much like to get rid of some settings
20:08 sfan5      you mean the artifical light blue / sun light yellow thing?
20:08 sfan5      if yes then I think that other light PR touched on it
20:09 Krock      there's #14343
20:09 ShadowBot  https://github.com/minetest/minetest/issues/14343 -- Ambient light and server control for it by Andrey2470T
20:09 MTDiscord  <warr1024> I've got at least one use-case where I can't use shaders, i.e. my minetestcast container that continuously livestreams Minetest to a streaming service like twitch.  Because of the container, its access to 3D accel is very limited, so shaders are a significant performance cost.
20:09 [MatrxMT]  <grorp> allowing mods to set that table sounds like a good idea, I'm just wondering whether changing it at runtime will mess things up.
20:09 MTDiscord  <warr1024> Shader, dependent features are only really usable for "nice to have" stuff.
20:10 Krock      grorp: cached mapblock meshes would cause obvious mismatches
20:10 MTDiscord  <warr1024> If changing it at runtime requried invalidating all the mapblock meshes, so it came with a "use sparingly" caveat for modders, I could live with that.
20:10 MTDiscord  <herowl> Krock: for that PR, I'm looking at the code right
20:10 sfan5      Warr1024: did you measure it or it that a guess?
20:10 Krock      like seen in day/night changes where mapblocks are updated one my one (far view). maybe that's been improved since the last time I've noticed it
20:11 sfan5      is that*
20:11 MTDiscord  <warr1024> Lol, I can measure joining a new server and watching the mapblocks reload.  I'm not sure how you could make it worse than that.
20:11 sfan5      given how omnipresent shaders are software rendering implementations would surely optimize them as much as possible
20:11 Krock      maybe containers weren't meant to run graphical "demanding" applications
20:12 sfan5      actually nothing wrong with that in principle. offscreen rendering works fine with EGL
20:12 MTDiscord  <warr1024> Oh, if you're asking about my remark about shaders: I don't think I ever exactly measured fps, but going down from ~20 to ~10 is quite noticeable.
20:13 [MatrxMT]  <grorp> regarding the "what to do with the settings" thing: I think it would make sense for a mod-specified table not to be affected by any settings.
20:13 MTDiscord  <warr1024> I think turning on shaders had about a comparable performance cost to the 5.5 to 5.6 upgrade 😆
20:13 [MatrxMT]  <grorp> games/mods can still provide in-game customization to users if they want, like it's already the case with stuff in set_lighting (e.g. shadow strength)
20:13 [MatrxMT]  <Zughy> I agree with grorp
20:14 sfan5      grorp: sure, but at this opportunity I'd just get rid of these niche settings entirely
20:14 [MatrxMT]  <Zughy> Actually, clients shouldn't be able to touch game settings (with client side options). Like, if the game is too dark, either complain with the dev or increase your screen lighting
20:15 [MatrxMT]  <Zughy> sfan5: yes please
20:15 Krock      depending on how bad your contrasts are on a screen, there's still demand for gamma correction
20:16 Krock      or rather: gamma tuning. so that not everything has similar dull black touch
20:16 [MatrxMT]  <grorp> sfan5: I'm sure a lot of people would be fed up if you just removed the display_gamma setting though
20:16 MTDiscord  <warr1024> The way we do gamma correction in MT isn't quite what users need anyway
20:17 MTDiscord  <warr1024> I don't see a need to remove the client option, but it would be nice to make it unnecessary in more circumstances.
20:17 [MatrxMT]  <Zughy> Krock: but it should be up to the game. Like those horror games telling you "set this value until you can barely see the thing" (and you put it a bit lighter because you don't want to be scared :^])
20:18 sfan5      i think gamma is a reasonable candidate to keep
20:18 [MatrxMT]  <Zughy> grorp: people would be fed up even if you touched the slightest thing on Minetest (brace yourself for the name change)
20:18 Krock      Zughy: not seeing the difference between the darker light levels is plain bad UX
20:19 MTDiscord  <herowl> But which settings would be removed?
20:19 MTDiscord  <warr1024> I want to be able to give my game a reasonable baseline brightness based on what I want players to be able to see easily and what I want them not to be able to see. I want my players to be able to make adjustments on top of that to compensate for their devices so that I don't have to be responsible for shoehorning a menu into my game just to support per-user device variation ... and then I'm unable to make them per-device, only
20:19 MTDiscord  per-player account.
20:19 MTDiscord  <herowl> Saturation is fine and useful.
20:19 MTDiscord  <herowl> Including negative values
20:20 MTDiscord  <herowl> ...which should get documented now that I think about it
20:20 [MatrxMT]  <Zughy> why? I'm the one choosing the saturation of my game, not the client
20:20 MTDiscord  <herowl> yeah
20:21 MTDiscord  <herowl> but I felt like sfan5 wants to remove the ObjectRef:set_lighting() settings...?
20:21 [MatrxMT]  <grorp> herowl: what are you talking about? there isn't even a client-side saturation setting
20:21 [MatrxMT]  <grorp> oh, ok, you misunderstood everything
20:21 MTDiscord  <herowl> yeah looks like it
20:22 [MatrxMT]  <grorp> the discussion was removing some client-side settings and giving more control to mods via functions like set_lighting instead
20:35 sfan5      lighting_alpha, lighting_beta, lighting_boost to be specific
20:35 sfan5      if you've never heard of them that's no surprise
20:38 sfan5      free task assignment: optimize the profiler drawing
20:38 sfan5      it cuts fps in half (60 -> 30) on this arm board
20:39 sfan5      as a short refresher every pixel column is its own drawcall
20:39 sfan5      font rendering also still seems to be quite inefficient
20:39 Krock      hmm no idea what could possibly cause that
20:39 sfan5      should be possible to batch it across lines
20:40 Krock      alpha texture drawing after zbuffer clear used to be a problem in the past
20:40 Krock      e.g. HUD textures slowing down things a lot
20:41 Krock      but I don't remember what the cause or fix for that was. as for the profiler it's easier to see what to do
20:41 sfan5      also gui rendering is not batched at all. I also see some individual pixel columns being drawn with its own call
20:41 Krock      batch render 2D lines
20:41 Krock      problem inherited from Irrlicht.
20:41 sfan5      1 checkbox = 9 drawcalls apparently
20:43 Krock      having a quick look at Dear ImGUI might not be so bad. it does batch basically everything
20:44 sfan5      i think we should invest a small amount of work to improve the existing gui and hope v-rob's new implementation does everything better
20:44 sfan5      could even just write a wrapper that captures drawLine or similar calls and replays in batch
20:46 sfan5      a problem is that AFAIK we have somewhat committed to a certain draw order in formspecs
20:46 sfan5      so you'd need to make sure that the batching respects z index
20:46 sfan5      somehow
20:47 Krock      it's possible with isometric top-down rendering. no depth distortions. but I don't know whether there's pixel perfect functions that also use the depth
20:48 Krock      (e.g. to render vertices at separate Z values and let the GPU overlay it automatically. can be done by changing the viewport back and forth)
20:49 sfan5      yeah
20:49 sfan5      oh hey the capture from issue 14993 opens perfectly in renderdoc on this totally different device, how nice
20:50 sfan5      except no, it caused renderdoc to segfault
20:50 Krock      at least the joy lasted almost 30 seconds
20:50 sfan5      I should have just tried my desktop instead
20:51 sfan5      aha. it crashes in panfrost_dri.so so not even their fault
20:53 Krock      LIBGL_ALWAYS_SOFTWARE=true
21:01 [MatrxMT]  <Zughy> wait what #15062
21:01 ShadowBot  https://github.com/minetest/minetest/issues/15062 -- Document negative saturation by nauta-turbidus
21:04 sfan5      i think we may want a debug option to disable transparency sorting
21:07 sfan5      https://www.khronos.org/opengl/wiki/Debug_Output#Scoping_messages would also be useful to make use of this
21:07 sfan5      and the object labels
21:18 sfan5      why again do we not draw solid stuff closest to the camera first?
21:25 sfan5      nvm, we do
21:25 sfan5      but all transparent stuff comes first
21:26 sfan5      or last? whatever
21:35 sfan5      turns out we have this option
21:47 sfan5      well sort of
21:58 sfan5      hmm we seem to be invalidating the indices of transparent block meshes every drawcall
21:58 sfan5      anyway time for bed
22:00 MTDiscord  <landarvargan> Will there be a release candidate for 5.9.1?
22:05 MTDiscord  <andrey2470t> How about adding the texture atlas support #15061 in 5.10 or 5.11 milestone if it is on the roadmap?
22:05 ShadowBot  https://github.com/minetest/minetest/issues/15061 -- Texture atlas for mapblocks meshes by Andrey2470T
22:20 MTDiscord  <andrey2470t> I don't think the array textures are more suitable alternative than atlases in MT as appgurueu wrote. The textures size in the arrays set fixed. Also the Irrlicht doesn't support it
22:23 MTDiscord  <andrey2470t> As for overfilling atlases, it is very unlikely it can happen even with hundreds mods installed. The textures sizes in OpenGL can be very huge and the atlases can fit manu thousands of the separate textures
22:26 MTDiscord  <andrey2470t> Even if it is close to the overflow, another atlas texture could be created in such case