22 Replies
DH 2.1.2-a
DH 2.2.0-a
Latest Nightly
Long story short:
This is expected behavior and is unlikely to be fixed.
Long story long:
In old DH versions DH would attempt to first pull chunk lighting in from MC and if that failed, generate the lighting ourselves.
This worked well in some cases but burst into flames for others. Specifically there's a high likely hood that Minecraft will return the wrong lighting (or no lighting at all) if you fly around fast enough. Unfortunately due to how how the incorrect lighting was returned there is no good way to determine if the lighting MC returned was correct or not. this lead to a lot of broken LODs where LODs would either appear black, or would have correct lighting for parts, but incorrect for others (oceans in particular often had correct lighting on the surface but were full bright under the water).
So in order to circumvent the problem DH moved all chunk lighting to our own lighting engine. This engine is almost identical to MC's while being much faster and consistent, if it's provided all adjacent chunks.
However, sometimes DH only has access to some of the adjacent chunks, which is where the partial lighting you're seeing there comes from.
This isn't a great solution, however since DH is generally in the distance lighting issues like this are generally minor and easy to ignore unless you're looking for them.
Hopefully that answers your question.
Fixed it! (partially)
LOL
So there is this 'if' statement that checks if the old chunk hash is the same as the new one. If so, it skips the lighting engine pass. Now, if adjacent chunks update their lighting, they will queue adjacent chunks for updating, but these will skip themselves because they haven't changed their hash
Although your comment is true, by simply disabling this, the lighting engine will update LODs correctly.
WEll, most of the time at least. because at random times it still breaks for some reason
Gotta debug some more..
Oh I see, another optimization in DH that negatively impacts the lighting engine is that when you load a new chunk into your vanilla render distance, it only gets added to the queue without adjacent chunks (I get it might be for optimization). But, that causes lighting to break (because of the missing data).
But there's still something else...
Ok, so the last problem comes like this
When a chunk updates by placing a block. it collects the 8 adjacent chunks + itself. It adds them all to the queue, but only passes them these same 9 chunks. Therefore, the chunks in the edges lack knowledge of THEIR adjacent chunks.
A better way to handle that would probably be to grab the adjacent chunks and use them to light the center chunk, but only save the center chunk.
The fix was that, simply adding the center chunk, and not the other chunks to the queue. 1 it makes the queue less likely to fill up (about 8 chunks less per block update) and 2 it fixes the lighting issues along with the other 2 fixes I might implement. I'm cleaning up my testing code and if I get it working I might push a merge request tomorrow
Before, Now
The one change I think that might affect performance is that now chunks queued would always run the lighting engine even if the hash hasn't changed. HOWEVER, this is compensated by avoiding 8 adjacent chunks getting queued for no reason as well.
lol I crashed the internal server
Good news, bad news
Bad news:
Yesterday's fix horribly affects performance because random chunk saves will make them re process all the lighting engine
Good news:
I simply enabled back the 'if new chunk hash = old then skip' and it is fixed
Bader news:
Chunks get saved when Light gets updated in vanilla terrain, so they naturally get added to the queue of LOD updates. But since their new hash = old hash, they will skip lighting engine. And break again.
I'm so happy
No impact on performance. But It all works 100% of the time
Time to clean up test code, add some comments. And submit a merge request
I look forward to seeing it!
The only performance hit I find.. is that update propagator tasks seem to increase by a lot. I imagine it is because now the 9 chunks are each requesting their adjacent chunks.
Is that what update propagators are used for? collecting adjacent chunks?
The Update propagator is the system that converts high quality LODs into low quality LODs.
When you modify a chunk/LOD that system is responsible for making that change visible at lower quality settings and from farther away.
Excuse me, you might have missed my merge request
I saw it. I just haven’t had the time to test it yet.
Yoo awesome dude, nice work!
Thanks! after force updating the LODs, it is fixed!
