some chunks are not rendered, compared to Minecraft Vanilla
Lolothepro opened this issue · 5 comments
Bug Description
some chunks are not rendered, compared to Minecraft Vanilla
Reproduction Steps
-7863674087020843295
/execute in minecraft:overworld run tp @s 992.61 71.88 -380.73 -105.35 90.00
RD: 2
Log File
Crash Report
Oh for fucks sake, I just noticed the almost impossible to see black circle that you left on the original image.
Vanilla and Sodium render exactly the same, and there isn't any "missing chunk"... It's just that the water temple is slightly offset into the ocean floor, and that causes a "gap" to appear since the fog cuts off rendering before the floor of the temple is rendered.
The problem is that the server doesn't send enough chunks around the player, because the algorithm used is not exactly correct, and sometimes stuff at the very edge of the view distance is omitted. The corner which doesn't render will only appear once you move close enough to it, at which point the server sends the adjacent chunks, and the renderer becomes able to load it.
Why does this not happen in Vanilla? Well, it does, but there is a hack so that chunks which are closer than 24 blocks to the camera will always be eligible for loading, even if their neighboring chunks aren't loaded. Disabling this code results in the same behavior being seen in both renderers.
Unfortunately, simply copying this behavior into Sodium isn't really feasible, because our renderer has a hard requirement that all adjacent chunks are present before loading of a chunk can begin.
Even if we could do it, it feels like a really bad idea. Because it effectively means every time a chunk loads near a player, all the adjacent chunks will have to be re-loaded, as they were built too early and now have invalid data. At a short render distance, this results in each chunk being being submitted for reloads nine times each, which has a serious performance cost, and distracts the renderer from loading stuff in the distance.
So I'm just going to close this issue as "won't fix", as we can't reasonably work around it. The solution is to simply use a higher render distance.
