| Time |
Nick |
Message |
| 00:05 |
|
Eragon joined #minetest-dev |
| 00:18 |
|
hwpplayer1 joined #minetest-dev |
| 02:44 |
|
hwpplayer1 joined #minetest-dev |
| 03:53 |
|
izzyb joined #minetest-dev |
| 04:00 |
|
Mantar joined #minetest-dev |
| 04:06 |
|
Sokomine joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:29 |
|
hwpplayer1 joined #minetest-dev |
| 09:22 |
|
Warr1024 joined #minetest-dev |
| 09:42 |
|
hwpplayer1 joined #minetest-dev |
| 09:47 |
|
Warr1024 joined #minetest-dev |
| 09:58 |
[MatrxMT] |
<grorp> ow |
| 10:04 |
MTDiscord |
<jordan4ibanez> Leave that poor man alone man |
| 10:05 |
MTDiscord |
<jordan4ibanez> Pokes @grorp with a girder |
| 10:05 |
MTDiscord |
<jordan4ibanez> Much larger surface area |
| 10:13 |
MTDiscord |
<zmv7> 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] |
<grorp> merged 🎉 |
| 10:59 |
|
Desour joined #minetest-dev |
| 11:20 |
|
hwpplayer1 joined #minetest-dev |
| 12:54 |
|
SFENCE joined #minetest-dev |
| 14:03 |
|
vampirefrog joined #minetest-dev |
| 14:25 |
|
vampiref- joined #minetest-dev |
| 15:18 |
|
Desour joined #minetest-dev |
| 15:55 |
|
cx384 joined #minetest-dev |
| 15:56 |
|
cx384 joined #minetest-dev |
| 15:56 |
|
cx384 left #minetest-dev |
| 15:56 |
|
cx384 joined #minetest-dev |
| 16:33 |
|
Desour joined #minetest-dev |
| 16:33 |
|
hwpplayer1 joined #minetest-dev |
| 16:40 |
MTDiscord |
<siliconsniffer> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> :( |
| 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 |
> <celeron55> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> Oh man |
| 18:08 |
MTDiscord |
<herowl> 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 |
<herowl> Krock: it's exactly about precision issues |
| 18:20 |
MTDiscord |
<herowl> 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 |
<herowl> 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 |
<herowl> 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 |
<herowl> 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 |
<herowl> Which value? The whole SColor returned from that function? |
| 18:27 |
MTDiscord |
<herowl> 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 |
<herowl> Since I'm compressing two values in one byte there, giving 4 bits for each, we're losing precision. |
| 18:29 |
MTDiscord |
<herowl> Master branch returns light value in rgb channels, which causes hardware coloring color loss in dark places. |
| 18:29 |
MTDiscord |
<herowl> 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 |
<herowl> 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 |
<herowl> 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 |
<herowl> 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 |
<herowl> 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 |
<herowl> My research based on working with all that code and pulling my hair out |
| 18:35 |
Krock |
understandable |
| 18:37 |
MTDiscord |
<herowl> 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 |
<herowl> 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 |
<herowl> 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] |
<grorp> 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 |
<herowl> Krock: sfan5 was against SColorf |
| 19:01 |
MTDiscord |
<herowl> 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 |
<herowl> SColorf would be enough, but would take 128 bits, vs 40 bits in the SColor + byte approach |
| 19:03 |
MTDiscord |
<herowl> 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 |
<luatic> 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 |
<herowl> 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 |
<herowl> 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 |
<herowl> 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 |
<herowl> I do realize that, but I feel that's still sort of doable |
| 19:20 |
MTDiscord |
<herowl> Although wait, when is it actually used? |
| 19:20 |
MTDiscord |
<herowl> With what backend? |
| 19:20 |
sfan5 |
when is what used? |
| 19:20 |
MTDiscord |
<herowl> The legacy driver |
| 19:21 |
sfan5 |
on all platforms except mobile, with all backends |
| 19:21 |
sfan5 |
it's the default |
| 19:21 |
MTDiscord |
<herowl> 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] |
<grorp> 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] |
<grorp> 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] |
<grorp> btw, when using dynamic shadows with opengl3, I don't see a player shadow. did someone notice this too? |
| 19:25 |
[MatrxMT] |
<grorp> *someone else |
| 19:26 |
Desour |
weren't shadows dependent on the opengl driver? |
| 19:26 |
sfan5 |
Krock fixed that |
| 19:27 |
[MatrxMT] |
<grorp> I made a PoC with dynamic shadows on Android via OpenGL ES 3 a few weeks ago btw |
| 19:27 |
[MatrxMT] |
<grorp> based on an ancient branch by x2048 |
| 19:28 |
Desour |
ah, nice. but grorp: I can reproduce |
| 19:28 |
[MatrxMT] |
<grorp> it's possible, but too much work to do it properly. not planning to finish it. |
| 19:28 |
[MatrxMT] |
<grorp> *PoC for |
| 19:29 |
[MatrxMT] |
<grorp> Desour: thanks |
| 19:33 |
[MatrxMT] |
<grorp> https://matrix.org/_matrix/media/v1/download/matrix.org/SLGKxdztNyDiQgfRlqjROuvT |
| 19:34 |
[MatrxMT] |
<grorp> https://github.com/grorp/minetest/tree/shadows-try-2 |
| 19:34 |
MTDiscord |
<luatic> 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 |
<luatic> And further bloating a singular vertex format certainly is a step in the wrong direction for that. |
| 19:36 |
MTDiscord |
<luatic> 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 |
<herowl> No I'm not saying change this |
| 19:36 |
sfan5 |
i don't think we're talking about extending S3DVertex |
| 19:36 |
MTDiscord |
<herowl> 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 |
<luatic> Currently yes |
| 19:36 |
MTDiscord |
<herowl> And in the future too |
| 19:36 |
MTDiscord |
<luatic> No |
| 19:37 |
MTDiscord |
<herowl> 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 |
<herowl> 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 |
<luatic> 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 |
<herowl> How is the format inefficient? |
| 19:38 |
MTDiscord |
<luatic> 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 |
<luatic> ah yeah ofc |
| 19:39 |
MTDiscord |
<herowl> So you're saying the normal doesn't need that much precision? |
| 19:39 |
MTDiscord |
<luatic> doesn't need that much bytes for most nodes |
| 19:39 |
MTDiscord |
<herowl> Because position sure does, and probably UV too |
| 19:39 |
MTDiscord |
<luatic> 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 |
<herowl> Aren't the positions global? |
| 19:39 |
sfan5 |
no |
| 19:40 |
MTDiscord |
<herowl> That's great |
| 19:40 |
MTDiscord |
<luatic> Many of the UVs are essentially also just 0 or 1 |
| 19:40 |
MTDiscord |
<luatic> 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 |
<luatic> Though in the short term it'd probably be okay if we don't bloat the color too much |
| 19:40 |
MTDiscord |
<luatic> each node vertex* |
| 19:40 |
MTDiscord |
<herowl> 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 |
<luatic> 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 |
<herowl> 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 |
<herowl> 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 |
<luatic> this is not a micro optimization, though its value would be diminished by our lack of current different optimizations |
| 19:45 |
MTDiscord |
<luatic> other bottlenecks, that is, likely |
| 19:45 |
MTDiscord |
<luatic> can we even guarantee geometry shaders? we don't require OGL 3.2+ (yet). |
| 19:46 |
sfan5 |
we can't |
| 19:46 |
MTDiscord |
<luatic> 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 |
<luatic> though we might be able to optimize for the simple, common cases. |
| 19:49 |
MTDiscord |
<herowl> That's for the far future, geometry shaders mean forgoing web support according to devsh I believe |
| 19:50 |
MTDiscord |
<herowl> 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 |
<herowl> 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 |
<herowl> 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 |
<herowl> *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 |
<luatic> 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 |
<herowl> 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 |
<luatic> 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 |
<luatic> 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 |
<herowl> Bit packing... I feel like I've heard it recently :juanchi_face: |
| 19:56 |
MTDiscord |
<herowl> 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 |
<herowl> Probably no |
| 19:57 |
sfan5 |
great. we have solved zero problems. |
| 19:58 |
MTDiscord |
<herowl> So anyway we need to add the byte and decouple ambient occlusion from light/shadow data |
| 20:04 |
MTDiscord |
<herowl> 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 |
| 22:10 |
|
pgimeno joined #minetest-dev |
| 23:33 |
|
panwolfram joined #minetest-dev |
