Time  Nick        Message
04:17 lhofhansl   Going to merge #15960 in a bit
04:17 ShadowBot   https://github.com/luanti-org/luanti/issues/15960 -- Slight fix to #15949 to handle emerge queue full by lhofhansl
04:31 lhofhansl   Done.
10:26 MTDiscord   <andrey2470t> And as to the texture arrays, you need also to consider there may be textures with various dimensions multiple 8 combinations (not only 8x8, 16x16, 32x32, but also 8x16, 64x32, 128x32 and etc). Except that, considering Luanti generally creates pretty many textures (in a result of applying various texture modifiers, overlaying the crack frames), the atlas would fit better for this situation since it can pack inside itself millions of
10:26 MTDiscord   16pix textures and even thousands of only 128pix ones (I counted that in my PR). Minimal allowed array texture size is 2048, so that is much less that the atlas can fit.
10:29 MTDiscord   <andrey2470t> Also, you need to handle the crack animations somehow, adding new textures inside the array with the overlaid crack frames and then changing temporarily the layer index for the cracked faces
10:32 MTDiscord   <andrey2470t> for my atlas I allocated the additional space with the constant tile offset, but for arrays you will possibly need to double the layers count and that would increase still risk of fast getting beyond the array size limit
10:33 MTDiscord   <andrey2470t> considering the arrays allows packing a few textures relatively to the atlases
11:37 [MatrxMT]   <grorp> merging #15756 in 15 min
11:37 ShadowBot   https://github.com/luanti-org/luanti/issues/15756 -- Add server/client annotations to settingtypes.txt and use them by grorp
12:19 MTDiscord   <luatic> Cracks are not the problem. You can handle cracks just about any way you like and it will be fine, because there is just a single cracked node. It's a low constant amount of additional drawcalls you're doing. So "doubling the layers count" for array textures would not be necessary.
15:17 sfan5       adding some basic structure for a decal system does not sound like bad idea
15:24 sfan5       think having a second texture and doing the overlaying in the shader
15:27 MTDiscord   <luatic> yeah absolutely, should also help with the overlay tiles
15:27 MTDiscord   <luatic> but the general point is just, we don't need to go to absurd lengths at the texture level to accomodate cracks specifically
15:27 sfan5       well that would be a third thing to overlay
15:27 sfan5       that's not what decals are for
16:57 sfan5       merging #15965, #15966, #15950 in 10m
16:57 ShadowBot   https://github.com/luanti-org/luanti/issues/15965 -- ImageSource: restrict max dimensions to protect from integer overflows by sfan5
16:57 ShadowBot   https://github.com/luanti-org/luanti/issues/15966 -- docs: Max area volume is now 150 million by Jiskster
16:57 ShadowBot   https://github.com/luanti-org/luanti/issues/15950 -- Deprecate some legacy item registration logic by appgurueu
20:43 MTDiscord   <andrey2470t> I assume you will need to reallocate the whole texture array and even not the single one since their size is fixed and you can not know beforehand which a count of textures the given cracked node has and of how many different resolutions each of those textures has. E.g. if the conditional node has three materials with 16x16, 32x32 and 64x64 textures, you will need to rebuild three texture arrays each with those resolutions like
20:43 MTDiscord   rebuilding VBOs when it is necessary to extend them with a new bunch of vertices. Such rebuilding is pretty possibly much worth the performance
20:44 MTDiscord   <andrey2470t> This is the case if you don't want to double the texture array size allocating the space for each potential cracked texture beforehand
22:36 exoticalexo Is there a way to make a priv like “basic_priv”, where I can group privs together?
22:44 MTDiscord   <warr1024> szutil_roles
22:45 MTDiscord   <warr1024> szutilpack on CDB.  Also, ask that sort of thing in #luanti, not #luanti-dev.
22:49 exoticalexo 03Oh, sorry03