Request Description

The current method for loading chunks on the client is absolutely fine for loading any reasonable render distance. BUT it would be really nice if you moved everything off the main thread, as when you get to 64 chunks and over, it starts to get extremely laggy, especially when moving and unloading the chunks behind you. It has gotten to the point where the problem isn't rendering 128 chunks, nor generating them, but the actual chunk loading done by sodium. Moving the chunk loading completely off the main thread would solve this. Maybe? I don't know, I'm not a developer. This is a very niche problem I know, but it would improve everyone's experience regardless, even if most didn't notice it.

Case and point:
Completely playable fps at 128 chunk render distance, even with just a 3060. No stutering, high 1% lows and so on.

As soon as you start moving it suddenly becomes impossible to play. Other than the stuttering from the garbage collector, which is to be expected and can be mitigated, there are constant frame drops due to loading new and unloading old chunks:

I'm testing this on a server just to be absolutely sure that my client is doing no work generating the chunks itself. All it's doing is loading them.

Thanks for reading.

Some of the CPU load you're getting at high RD is the graph search bottlenecking on the CPU side. You can verify how much overhead that is by shaking the camera instead of moving.

Never mind, it turns out I was just maxing out my CPU. For some reason I didn't think that was a possibility because I'm playing Minecraft on a 7700x, but apparently I just don't have enough cores. It may very well be a possibility that chunk loading is already off the main thread, and I just hadn't realized it. Shaking the camera doesn't create any stuttering at all so I don't think it's the graph search.

Make sure you haven't increased the chunk builder thread count in Sodium settings. If you set it to a non-default high value, it could cause those stutters.

Chunk loading is part of the graph search so this is particularly valid. Sodium uses the visibility graph to load/update chunks within visibility. However the actual processing / building is done multi-threaded.

I have an 8C/16T system and tried 4,8 and 16 threads for the chunk builder. There was about the same amount of stuttering across all configurations, but predictably, chunk loading was slowest with 4, faster with 8 and fastest with 16 threads while cpu usage was around 40% with 4, 70% with 8 and 100% with 16. Since the chunks were loading faster the more threads I added, I figured I don't have the cpu horsepower necessary to load the chunks as fast as the server is sending them, so that could be part of the issue. I thought the whole process was already async and fully multithreaded and the stuttering was solely due to the fact that I don't have enough threads, but if the graph search is on the main thread, it might still cause stuttering even if I get a cpu with more cores. I don't have another cpu though so can't test it.