Time  Nick      Message
13:50 MTDiscord <x2048> Pushing a small patch in a few minutes https://pastebin.com/VfAqeB1Y. Fixes #12686
13:50 ShadowBot https://github.com/minetest/minetest/issues/12686 -- 5.6 changed object glow drastically
14:04 sfan5     I looked at that issue before and wondered if that was the right fix since the glow stuff changed so drastically
14:04 sfan5     thanks for fixing
15:18 MTDiscord <x2048> There's a multiplier of 2.5 applied to emissive_light here: https://github.com/minetest/minetest/blob/master/src/client/mapblock_mesh.cpp#L1561.
18:39 MTDiscord <x2048> Any ideas about this 'if' in getInteriorLight? https://github.com/minetest/minetest/blob/master/src/client/mapblock_mesh.cpp#L106
18:53 MTDiscord <x2048> Looks like a leftover from legacy, and the reason is not clear from the logs.
19:03 celeron55 i'll take a look
19:05 celeron55 https://github.com/minetest/minetest/commit/f5fd4a0af1fef2e9cd3f7f368884349013a06dcc#diff-773af0bb916fbeab5135fa2e7d9ca54413bbbd7db33ae4f5cd147473cc8425cbL133
19:05 Pexin     all I can tell is that https://github.com/minetest/minetest/blob/master/src/client/game.cpp#L3263 passes -1 as increment in 2 places
19:06 Pexin     which gets relayed to the file local func in mapblock_mesh
19:06 celeron55 i think this commit that introduces the particular >0 explains it
19:06 celeron55 i mean, explains the logic it's based on, and the logic it's based on has a comment that says "We don't know if light should undiminish from this particular 0. Thus, keep it at 0."
19:07 celeron55 that comment is written by me... in 2010
19:08 celeron55 it's not likely whatever that logic comes from matters at all nowadays
19:09 celeron55 probably has something to do with how lighting updates were done originally... maybe
19:10 Pexin     mathematically just removing the if does nothing, because it will still be floored at 0 either way
19:12 MTDiscord <x2048> If prevents adding increment if the previously calculated light is zero. For example, if I want to add glow for an entity which is in complete darkness.
19:13 Pexin     oh, yeah doi. sorry.
19:15 celeron55 i'd say just get rid of it. but it needs some heavy testing as light is persistent
19:15 celeron55 entity lighting isn't but nodes
19:20 MTDiscord <x2048> This increment is only used in flat (non-smooth) light code (fixed value of 1) and selection mesh (fixed value of -1)
19:21 celeron55 then it's not persistent
19:23 MTDiscord <x2048> It's not. But in those cases the 'if' is important, otherwise non-solid nodes will glow in the dark with flat lighting.
19:23 MTDiscord <x2048> non-solid = non-fast-faces
19:38 sfan5     PSA: this year's serverlist statistics -> https://kitsunemimi.pw/tmp/serverlist_stats_2022-09-04.txt
19:45 MTDiscord <x2048> Further digging into getInteriorLight(), this increment of 1 makes nodebox nodes appear lighter than solid nodes at the same map light level: https://i.imgur.com/NdUoJhO.png
19:45 MTDiscord <x2048> (on the right side I remove the +1 from the increment)
21:09 MTDiscord <x2048> Added #12741 to change behavior of getInteriorLight, align brightness of solid and non-solid draw types and formally correct entity glow.
21:09 ShadowBot https://github.com/minetest/minetest/issues/12741 -- [No squash] Corrections to entity and node light calculation by x2048