Time Nick Message 09:58 [MatrxMT] ow 10:04 MTDiscord Leave that poor man alone man 10:05 MTDiscord Pokes @grorp with a girder 10:05 MTDiscord Much larger surface area 10:13 MTDiscord Why #15030 still have "Action/change needed" label? I have provided the minimal config as requested though... I worry it can be closed due to timeout 10:13 ShadowBot https://github.com/minetest/minetest/issues/15030 -- Particles are textureless on opengl3 video driver with fog disabled 10:37 [MatrxMT] merged 🎉 16:40 MTDiscord Nice! 17:37 Krock Meeting in 22 minutes. The wiki page is empty, thus no agenda so far. 18:00 Krock pinging those who reacted to the meeting post: @luatic Desour cx384 18:00 cx384 hi 18:00 Krock Still no meeting points. I'll keep an eye on this chat in case something appears. 18:01 Desour hi 18:01 MTDiscord Meeting point: please fix forum 18:01 Krock hello :) 18:02 Krock @jordan4ibanez I also forwarded a few points to c_55 and it seems he has given up at some point due to the complexity of phpbb. And yet - it needs to be fixed. 18:02 MTDiscord :( 18:02 ROllerozxa phpbb provides its own example config for nginx, has c55 looked at it yet? 18:03 ROllerozxa it properly handles the app.php router script 18:03 Krock yes. app.php is also which didn't work properly for reporting posts 18:04 Krock > i got so depressed with trying to get the reverse proxy and phpbb to behave a long time ago that it's simply no-go. i hope i stumble upon the solution some day 18:06 MTDiscord Roller, it's up to you, you love php 18:06 ROllerozxa https://github.com/phpbb/area51-phpbb3/blob/master/phpBB/docs/nginx.sample.conf#L43 18:07 ROllerozxa try_files falls back to @rewriteapp which routes it to app.php. then there is a setting in the ACP you will have to change that's "URL rewriting" or something 18:07 Krock Will merge #15465 and #15461 in 15 minutes 18:07 ShadowBot https://github.com/minetest/minetest/issues/15465 -- Sanitize invalid particle spawner time by appgurueu 18:07 ShadowBot https://github.com/minetest/minetest/issues/15461 -- [Trivial] Doc: Add missing packages for Arch Linux by veprogames 18:08 ROllerozxa jordan: this isn't even about php, this is just nginx configuration 18:08 MTDiscord Oh man 18:08 MTDiscord Meeting point: Does anyone else care about ambient light or now it is purely on me to try to implement a new vertex format and then adopt #14343? 18:08 ShadowBot https://github.com/minetest/minetest/issues/14343 -- Ambient light and server control for it by Andrey2470T 18:11 Krock the general idea is OK. I'm currently trying to understand what it does. 18:18 Krock @herowl Whaat do you mean by "implement a new vertex format"? Is it to overcome the mentioned precision issues? 18:19 Krock in the meantime, basic shaders became mandatory, thus we could argue that the backwards compat code is not 100% necessary 18:20 Krock correction: they're yet not mandatory but are planned to be. 18:20 MTDiscord Krock: it's exactly about precision issues 18:20 MTDiscord I managed to fix up everything, at the cost of causing precision issues 18:21 Desour Krock: wdym meant to be? I thought that one PR by sfan removed the non shader stuff 18:21 MTDiscord The decision back then was that we need to change to vertex format to include not just an rgba color (where one channel is 8-bit, currently and it seems to be enough), but also another byte of data. 18:22 Krock Desour: oh right. apparently I forgot about that follow-up PR. 18:22 Krock merging the mentioned 2 PRs 18:23 Krock done 18:24 Krock > return video::SColor((r&0xF0)|(b>>4), 255, 255, 255); 18:24 MTDiscord Then we could put hardware coloring (+ baked ambient occlusion) in rgb channels, split shadows/light intensity from ambient occlusion and make them not baked, instead putting them into the added byte, and leave whole alpha channel for the artificial/natural ratio, as it is now. 18:25 MTDiscord Yeah what about that line? 18:26 Krock that's the limiting line from what I can see. However, I do yet not understand what this value does and why it's important. I suppose that's a matter of taking more time to understand the PR. 18:26 MTDiscord Which value? The whole SColor returned from that function? 18:27 MTDiscord It's argb color, where rgb values get multiplied by hardware coloring color later, and alpha channel value is passed directly to the shader. 18:28 MTDiscord Since I'm compressing two values in one byte there, giving 4 bits for each, we're losing precision. 18:29 MTDiscord Master branch returns light value in rgb channels, which causes hardware coloring color loss in dark places. 18:29 MTDiscord And the alpha channel is fully dedicated to the ratio, which in turn allows a slightly different natural (sun/moon) and artificial light colors. 18:30 MTDiscord Once we do the separate byte for lighting thing, it should also be easier to get colored node lighting later. 18:31 Krock hmm. so the ambient light must be > 0 such that the light multiplication later on does not cancel out? 18:31 MTDiscord At the point of that function ambient light is not considered I think 18:32 Krock because it would be somewhat convenient if we could use the alpha channel for e.g. the sunlight and R G B for artificial light (or whatever it might be) 18:32 Krock and somehow work around the multiplication losses later on - if we could shift the vlue range by a factor of 1024 or similar 18:32 Krock *value range 18:33 MTDiscord Currently in master we're using rgb channels for hardware coloring and light intensity (or shadows) and ambient occlusion, and alpha channel for ratio to determine light color on the natural-artifical scale. 18:34 MTDiscord This approach causes dark places to be pitch black. 18:34 Krock by the way - is that explained somewhere, or knowledge gathered by your research based on the code? 18:35 MTDiscord My research based on working with all that code and pulling my hair out 18:35 Krock understandable 18:37 MTDiscord Anyway as I said dark places are pitch black, so we can't just slap ambient light on it, because: 1. You lose hardware coloring, all channels are 0, so lighting it back in the shader makes it just look grey 2. You lose ambient occlusion data, because it is treated the same as shadows, and lit up by ambient light, which it shouldn't be because it causes everything to look flat 18:39 MTDiscord We theoretically could work around the color lost issue without losing precision by passing the value to the shader as hsv or hsl or hue-chroma-luma, where light/shadow would impact just one channel, but it doesn't solve the ambient occlusion issue, and would be computationally less efficient 18:41 MTDiscord BTW remember that it's not just about literally 0 values: those cause complete color data loss, obviously, but low light level causes color precision loss anyway. 18:42 [MatrxMT] I've redone my message draft in discussion 102, can someone read the new version and tell me whether it's fine before I post it? 18:43 Krock might video::SColorf be an alternative approach to fix the precision issue? You'd have enough alpha channel bits to use there. You'd still pass the magic values + R (1.0f) + G (1.0f) + B (1.0f) when shaders are enabled 18:44 Krock and if they're disabled, fall back to the previous r, b, b, b values. 18:44 Krock so if there's shaders to "post process" the vertices, they'd still have the color data to work with. 18:45 Krock and without shaders the behaviour is left unchanged. 18:45 Krock please forgive me if I'm thinking into the wrong direction. I yet haven't fully understood what's happening there. 18:46 Krock grorp: "looked at" could be replaced by "consulted" or "got inspired by" 18:49 Krock (moved to the discussion) 19:01 MTDiscord Krock: sfan5 was against SColorf 19:01 MTDiscord Skim #15176 19:01 ShadowBot https://github.com/minetest/minetest/issues/15176 -- Decouple Ambient Occlusion from Shadows 19:02 Krock oh man the madness continues 19:03 MTDiscord SColorf would be enough, but would take 128 bits, vs 40 bits in the SColor + byte approach 19:03 MTDiscord Anyway pretty sure it needs a new vertex format anyway 19:04 sfan5 moving to SColorf so there's more precision to creatively pack information into is a bad hack 19:05 sfan5 there's a solution for passing more data with each vertex and it's called a different vertex format 19:05 Krock hmm. But param1 (light) is also only 1 byte. The alpha channel must suffice if we can push the light calculations entirely to the shader 19:06 Krock i.e. to perform the most lossy calculations at the end 19:07 sfan5 that is another possibility but it also has "workaround" feeling 19:07 MTDiscord Yes, this should use a different vertex format, and this new vertex format should only be used for hardware colored nodes that need it. 19:07 sfan5 we have 4-bit colors so moving light_decode_table into shaders would free up space in the current vertex format 19:10 MTDiscord No, it has to be used for all nodes, because added complexity of different formats, mesh building, everything.... maaaaaaaan. And also because there is ambient occlusion too, and just that could be creatively packed in the old format, but IMHO not worth the complexity just to save up a few bytes on mostly underground mapblocks 19:12 Krock a middle ground solution could be to introduce something like video::SColor16 with u16 components. 19:12 Krock that's still small enough to fit into a 64-bit register 19:12 sfan5 that's not a middle ground 19:12 MTDiscord sfan5: let's see... you could put param1 into the shader, yeah... but (param2 and nodedef) hardware coloring resolution and ambient occlusion would have to stay partially on the CPU side 19:12 sfan5 any changes to S3DVertex means a different vertex format 19:13 MTDiscord Probably you could get away with giving param1 in the alpha channel and then color + baked ambient occlusion in rgb channels 19:13 Krock sfan5: yes. But it wouldn't be as bloated or inefficient as 32-bit floating point at lease. however, I see that this is unfortunate. 19:16 Desour we should have multiple separate vertex formats anyways, imo. the current one is not optimized for size anyways (could for example use normed u8 for normals, and integer uv and world coords) 19:17 sfan5 it's worth noting that introducing a custom vertex format will require changes to COpenGLDriver code because it still uses glColorPointer etc. over vertex attributes 19:17 sfan5 at that point it might be easier to drop the legacy GL driver 19:18 sfan5 (however we're missing information on how many users that would affect) 19:20 MTDiscord I do realize that, but I feel that's still sort of doable 19:20 MTDiscord Although wait, when is it actually used? 19:20 MTDiscord With what backend? 19:20 sfan5 when is what used? 19:20 MTDiscord The legacy driver 19:21 sfan5 on all platforms except mobile, with all backends 19:21 sfan5 it's the default 19:21 MTDiscord And dropping it would affect people with what kind of hardware? 19:21 Krock on that side - I did notice that the implementation of draw2DVertexPrimitiveList is apparently missing for the OpenGL 3 driver, which will be important once we start optimizing the IGUIElement draws 19:22 Krock it's yet not used, so that's not a showstopper. 19:22 sfan5 anything older than opengl 3.0 19:22 Krock * opengl 3.2 19:22 sfan5 ah yes 19:22 [MatrxMT] since iirc numzero added automatic fallback for video drivers at some point, couldn't me make the opengl3 driver the default? 19:22 sfan5 we sure could 19:23 [MatrxMT] would allow it to get more testing 19:24 sfan5 there's one unfinished goal however: the target for the gl3 driver was core profile, but we're still using compatibility profile 19:24 sfan5 because there is still some reliance on legacy stuff 19:24 sfan5 this isn't that hard to fix but require some of my time 19:25 [ please do not drop the legacy GL driver 19:25 [MatrxMT] btw, when using dynamic shadows with opengl3, I don't see a player shadow. did someone notice this too? 19:25 [MatrxMT] *someone else 19:26 Desour weren't shadows dependent on the opengl driver? 19:26 sfan5 Krock fixed that 19:27 [MatrxMT] I made a PoC with dynamic shadows on Android via OpenGL ES 3 a few weeks ago btw 19:27 [MatrxMT] based on an ancient branch by x2048 19:28 Desour ah, nice. but grorp: I can reproduce 19:28 [MatrxMT] it's possible, but too much work to do it properly. not planning to finish it. 19:28 [MatrxMT] *PoC for 19:29 [MatrxMT] Desour: thanks 19:33 [MatrxMT] https://matrix.org/_matrix/media/v1/download/matrix.org/SLGKxdztNyDiQgfRlqjROuvT 19:34 [MatrxMT] https://github.com/grorp/minetest/tree/shadows-try-2 19:34 MTDiscord Herowl: I don't think this is a future-proof solution. Maintaining good framerates seems to be largely a problem of efficiently shoveling vertex data to the GPU. 19:34 MTDiscord And further bloating a singular vertex format certainly is a step in the wrong direction for that. 19:36 MTDiscord Additionally, if the vertex format is changed, that propagates everywhere, which it shouldn't. Why should entities, particles, inventory meshes etc. care about a new vertex format? 19:36 MTDiscord No I'm not saying change this 19:36 sfan5 i don't think we're talking about extending S3DVertex 19:36 MTDiscord I'm saying "use the new format for all nodes" 19:36 sfan5 also our singular biggest problem is drawcalls, not uploading data 19:36 MTDiscord Currently yes 19:36 MTDiscord And in the future too 19:36 MTDiscord No 19:37 MTDiscord We're already optimizing for legacy hardware here (which is fine) 19:37 sfan5 i don't disagree with the "future tech debt" angle but this isn't digging ourselves a hole 19:37 MTDiscord 4 floats or even 8 floats is common in modern engine 19:37 sfan5 it's merely "not implementing an optimization until it's needed" 19:37 MTDiscord I'm not talking about legacy hardware, I'm talking about the fact that the current vertex format for nodes is grossly inefficient and we shouldn't make that worse 19:37 MTDiscord How is the format inefficient? 19:38 MTDiscord IIRC it is position + normal + color, correct? 3 floats for the position, 3 for the normal, 4 bytes for the color 19:39 Desour +2 uv 19:39 MTDiscord ah yeah ofc 19:39 MTDiscord So you're saying the normal doesn't need that much precision? 19:39 MTDiscord doesn't need that much bytes for most nodes 19:39 MTDiscord Because position sure does, and probably UV too 19:39 MTDiscord Most normals are one of 6 normals, those fit in a couple bits. The positions could also be optimized since most of them are aligned to multiples of 1/16th in a mapblock. 19:39 MTDiscord Aren't the positions global? 19:39 sfan5 no 19:40 MTDiscord That's great 19:40 MTDiscord Many of the UVs are essentially also just 0 or 1 19:40 MTDiscord Anyways it just doesn't make sense to have each node deal with a color and then to further bloat that color 19:40 MTDiscord Though in the short term it'd probably be okay if we don't bloat the color too much 19:40 MTDiscord each node vertex* 19:40 MTDiscord Technically yeah, but aren't all nodes in a mapblock stitched into one mesh? 19:41 sfan5 it's a different mesh for each material 19:41 MTDiscord It's per-material, at least without atlases 19:41 Desour could also use instancing to render squares. => one node pos per square, not per vertex 19:41 MTDiscord And material is per node def? 19:41 sfan5 S3DVertex is 36 bytes. let's say we we magically halve that I don't believe it will bring a performance miracle 19:42 sfan5 most of this sounds like micro-optimizations 19:42 MTDiscord sfan5: +1 19:42 sfan5 theory: using programmable vertex pulling or geometry shaders to render solid 1x1x1 blocks would be much more worthwhile 19:43 sfan5 in the most extreme case you could provide a 16x16x16 bitmap to the shader and it synthesizes the geometry entirely 19:44 MTDiscord this is not a micro optimization, though its value would be diminished by our lack of current different optimizations 19:45 MTDiscord other bottlenecks, that is, likely 19:45 MTDiscord can we even guarantee geometry shaders? we don't require OGL 3.2+ (yet). 19:46 sfan5 we can't 19:46 MTDiscord as for the bitmap thing, yes that's an option and people have done it, but generally those people have "pure" voxel engines so everything is like an order of magnitude less complex and you basically just have colored (maybe textured) voxels. 19:47 MTDiscord though we might be able to optimize for the simple, common cases. 19:49 MTDiscord That's for the far future, geometry shaders mean forgoing web support according to devsh I believe 19:50 MTDiscord Anyway we're kind of scope creeping at this point 19:50 sfan5 so are we optimizing for the lowest common denominator? 19:51 MTDiscord Tbh I'm fine with a "pro" backend with optimizations for new hardware, allowing amazing things on that, while still playable something with a different "basic" backend on older hardware. 19:52 MTDiscord But this is scope creep to mention it in context of "what has to be done to allow an important* feature without hampering performance or causing artifacts/glitches" 19:52 Desour we could also... reduce the number of vertices, with LOD. but anyways, optimizing the bottlenecks makes more sense than optimizing something that has a theoretical influence on performance. so I was wondering why people discuss so hard around adding a member to the vertex format 19:53 sfan5 ^ ack 19:53 MTDiscord *important - in this context, I mean that it's not just a graphical improvement, it allows for some effects important for gameplay 19:54 MTDiscord I would accept an efficient color + light vertex format. This should only be like one byte larger than the current vertex format, correct? 19:54 MTDiscord Yes 19:54 sfan5 by the way it's not like trying to down-size the vertex format can ignore compatibility. let's say you want to use half floats for N and UV -> GL2.0 and GLES2.0 don't have it 19:55 MTDiscord I think we will need proper switchable vertex formats in the long run but I suppose it's fine to not really expect this as a prerequisite of the ambient light PR 19:55 sfan5 so you'd again be introducing an optimization that only people with better hardware can benefit from 19:55 MTDiscord sfan5: The downsizing plans I have don't use floats, they use bitpacking 19:55 sfan5 bit ops in glsl have version requirements 19:55 MTDiscord Bit packing... I feel like I've heard it recently :juanchi_face: 19:56 MTDiscord sfan5: I did bit unpacking without bitops though 19:56 sfan5 yes you can emulate bitops with floating point math. will it be faster in the end? 19:56 MTDiscord Probably no 19:57 sfan5 great. we have solved zero problems. 19:58 MTDiscord So anyway we need to add the byte and decouple ambient occlusion from light/shadow data 20:04 MTDiscord My initial question was whether anyone cares about the Ambient Light enough to at least do some of that or am I all alone? 20:13 sfan5 what I'm trying to say in all of these discussions is that we're not at a point to discuss fine grained optimizations, because we have a dumb bottleneck we need to solve first. 20:14 sfan5 especially given limited time and gfx experience in our team 20:23 Krock whoever has the will to do it first shall do it