| Time |
Nick |
Message |
| 00:54 |
|
tibtoblezob joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 04:15 |
|
lhofhansl joined #luanti-dev |
| 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. |
| 04:42 |
|
_____ joined #luanti-dev |
| 08:46 |
|
Warr1024 joined #luanti-dev |
| 10:01 |
|
sugarbeet joined #luanti-dev |
| 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. |
| 14:21 |
|
SFENCE joined #luanti-dev |
| 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 |
| 15:50 |
|
SFENCE joined #luanti-dev |
| 16:12 |
|
SFENCE joined #luanti-dev |
| 16:26 |
|
imi joined #luanti-dev |
| 16:57 |
|
SFENCE joined #luanti-dev |
| 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 |
| 17:11 |
|
SFENCE joined #luanti-dev |
| 17:26 |
|
SFENCE joined #luanti-dev |
| 17:31 |
|
Desour joined #luanti-dev |
| 17:34 |
|
SFENCE joined #luanti-dev |
| 17:44 |
|
SFENCE joined #luanti-dev |
| 17:49 |
|
SFENCE joined #luanti-dev |
| 18:10 |
|
SFENCE joined #luanti-dev |
| 18:19 |
|
SFENCE joined #luanti-dev |
| 18:31 |
|
SFENCE joined #luanti-dev |
| 18:37 |
|
SFENCE joined #luanti-dev |
| 18:39 |
|
SFENCE joined #luanti-dev |
| 18:47 |
|
SFENCE joined #luanti-dev |
| 18:58 |
|
SFENCE joined #luanti-dev |
| 19:05 |
|
SFENCE joined #luanti-dev |
| 19:10 |
|
SFENCE joined #luanti-dev |
| 19:23 |
|
hwpplayer1 joined #luanti-dev |
| 19:42 |
|
tibtoblezob joined #luanti-dev |
| 19:50 |
|
hwpplayer1 joined #luanti-dev |
| 19:56 |
|
hwpplayer1 joined #luanti-dev |
| 20:05 |
|
hwpplayer1 joined #luanti-dev |
| 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 |
| 20:44 |
|
GreenXenith joined #luanti-dev |
| 21:10 |
|
MTDiscord joined #luanti-dev |
| 22:34 |
|
panwolfram joined #luanti-dev |
| 22:35 |
|
exoticalexo joined #luanti-dev |
| 22:36 |
exoticalexo |
Is there a way to make a priv like “basic_priv”, where I can group privs together? |
| 22:43 |
|
tibtoblezob joined #luanti-dev |
| 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 |
Oh, sorry |
| 23:54 |
|
fluxionary joined #luanti-dev |
