| 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 |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 07:01 |
|
YuGiOhJCJ joined #minetest-dev |
| 13:22 |
|
Desour joined #minetest-dev |
| 14:20 |
|
Desour joined #minetest-dev |
| 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 |
| 16:59 |
|
grorp joined #minetest-dev |
| 17:13 |
|
SFENCE joined #minetest-dev |
| 17:36 |
|
thelounge6564 joined #minetest-dev |
| 17:46 |
|
SFENCE joined #minetest-dev |
| 17:55 |
|
SFENCE joined #minetest-dev |
| 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:48 |
|
SFENCE joined #minetest-dev |
| 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:01 |
|
SFENCE joined #minetest-dev |
| 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 |
|
SFENCE joined #minetest-dev |
| 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:37 |
|
SFENCE joined #minetest-dev |
| 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:32 |
|
SFENCE joined #minetest-dev |
| 21:35 |
sfan5 |
turns out we have this option |
| 21:47 |
sfan5 |
well sort of |
| 21:50 |
|
SFENCE joined #minetest-dev |
| 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:03 |
|
SFENCE joined #minetest-dev |
| 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 |
| 22:33 |
|
panwolfram joined #minetest-dev |
| 22:40 |
|
SFENCE joined #minetest-dev |
| 23:01 |
|
SFENCE joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:19 |
|
SFENCE joined #minetest-dev |
| 23:38 |
|
SFENCE joined #minetest-dev |
| 23:56 |
|
SFENCE joined #minetest-dev |
