Prioritize played made chunk updates
XeonG opened this issue · comments
For player made block changes.. or chunks affected by the worldedit opperations..
Example player breaking/adding blocks on a chunk at camera position, then crosses over a chunk border.. any block add/removes they now make will be delayed and they won't see any update, until newer chunks off at the max view distance are generated.. when those chunks should lower priority than player made operations to the world. Or a different list that gets updated chunks that the player had edited and that gets processed until empty before m_updateRequests is in the ProcessChunks()
?
I feel it would improve the perceived performance of things a little better if we could prioritize what is more important to the player interaction of the world in what gets updated faster.
Yes, definitelly. Funny thing is, it's already implemented but does not work exactly as expected.
The reason why updates do not seem prioritized at the moment is that tasks created in one frame are first collected and then commited together. This is good for performance because there's minimal amount of locking involved. However, this approach has its issues.
Imagine you generate 50 tasks in one frame. A frame later you modify a block which generates another task. However, previous tasks had already been commited at the end of previous frame and it takes a while to process them. This creates the effect of not prioritizing.
I'll simply have to approach this problem a bit differently.
Yeh I noticed there is optimizations in how alot of things work in this.. just not all of it pays off on the perceived performance when adding/removing things or moving across chunks and triggering a whole lot of chunks in the distance to get processed, so prioritization can be a bit off.
perhaps some way to set certain prioritization on setblock stuff,... worldgen (nearby player) > player changes > worldedit type stuff> worldgen (further from player).