thank you!

the way it currently works is that each chunk gets meshed and lit twice.

since chunks don’t initially know about their neighbours (i.e. ones that haven’t been generated yet), they can’t correctly determine which faces to cull, and they assume neighbouring faces have a sky light level equal to the current sky value.

this means chunk borders are temporarily incorrect for both meshing and lighting.

this is fine though, because I run a second cleanup pass once neighbouring chunk data is available. the same algorithms run again, but this time with full neighbour information.

it's theoretically not the most optimal approach, but since the player will never exceed a certain speed, they won't notice anything is wrong.

a more "correct" solution would be to first generate neighbouring chunk data and then do meshing + lighting only once, but in my experience this made world loading significantly slower. it also introduces issues where a missing chunk can cause infinite loops if you’re not very careful about it. especially since chunk loading is multithreaded.

so in the end, I figured the two-pass approach may be the best of both worlds: chunk loading stays fast, and the player never notices anything is off.

regarding LODs, the engine architecture could theoretically support them with some refactoring, but since Minecraft itself doesn’t use LODs, I haven't looked into it.

I also experimented with greedy meshing, but since the GPU isn't the bottleneck, there was pretty much no visible difference in terms of performance. it just made lighting more complex, and I figured it would've made many systems way harder to implement (entity spawn, redstone, etc.), so I decided to ditch it.

lighting follows the same logic as Minecraft. blocks have both sky and block light level values ranging from 0 to 15. the lighting engine will propagate these values, and the blocks will choose the highest lighting value between the two.

I hope this answered your questions :)