Prioritizing mesh/collision rebuilds over new chunks

[XeonG]

Doesn't seem to be a way to get recently edited meshes to jump the queue on what is processed again, leaving sometimes an unnecessary amount of time before immediate chunks are processed. It should really take priority over distant/border edge chunks being generated if the player moves positions imo.

Another weird issues is HorizontalChunkLoadRadius if you set it too 11 or higher, it jumps cpu to twice the time to calculate.. ie

HorizontalChunkLoadRadius = 9...I get ~4.5ms updates
HorizontalChunkLoadRadius = 10 ...I get ~5ms updates
HorizontalChunkLoadRadius = 11 ... ~13ms +200kb GC

I'm not sure what is causing this sudden jump.. anything less than 11 and the decrements in chunk calculations are fine.. above 11 and its suddenly choking and doubling up the time.

And the whole ProcessChunks() could probably do with optimizing, it wastes so much cpu on just checking chunks (like maybe 2500 calls everyframe depending on ChunkLoadRadius setting..)

Obviously chunks it should check everyframe or near enough are the immediate ones around the player and any chunk that is player modified. The chunks that come into view as player gets near to the loadradius would be lower priority to me. Up until they are an in immediate area of the player like another LoadPriority Radius of 4chunks away or something. I messed LoadChunksimple script to see how it works and where it can be improved, maybe splitting up m_updateRequests so its processed over multiple frames. I did just have a timer on it at 20ms obviously it delayed everything doing it like that it would need to allow for higher priority things to override that timer.

I'm not sure how much you might still change the framework but is definitely an area with plenty of room to reduce the constant ~5ms per frame overhead, with it just going through 2500's calls on ProcessChunk (at view distance 10)

..Also using the bitwise trick instead of Mathf.Abs actually helped a bit, shaved like 0.2ms off with many chunks being processed.

`public void ProcessChunk(Chunk chunk) {
/*
int xd = Mathf.Abs((m_viewerPos.x - chunk.pos.x) >> Env.ChunkPower);
int yd = Mathf.Abs((m_viewerPos.y - chunk.pos.y) >> Env.ChunkPower);
int zd = Mathf.Abs((m_viewerPos.z - chunk.pos.z) >> Env.ChunkPower);
*/

        int xd = (m_viewerPos.x - chunk.pos.x) >> Env.ChunkPower;
        int yd = (m_viewerPos.y - chunk.pos.y) >> Env.ChunkPower;
        int zd = (m_viewerPos.z - chunk.pos.z) >> Env.ChunkPower;
        xd = ((xd >> 31) ^ xd) - (xd >> 31);
        yd = ((yd >> 31) ^ yd) - (yd >> 31);
        zd = ((zd >> 31) ^ zd) - (zd >> 31);`

[richardbiely]

Current implementation of LoadChunks/LoadChunksSimple is rather rudimentary. There's a ton of things I can do to optimize their performance by a lot, many of which I already have planned in my mind. I only have to find some time to implement them :)

For now, you're you can work this around by turning off "Use frustum culling". It does not affect the real frustum culling done on GPU. It only says that chunks which are not in the view frustum are not generated.

[XeonG]

And the whole ProcessChunks() could probably do with optimizing, it wastes so much cpu on just checking chunks (like maybe 2500 calls everyframe depending on ChunkLoadRadius setting..)

That area is still the problematic part for me really, I've found some ways to half it from 5ms down too 2.5ms every frame but its not ideal ie it alternates every frame the chunks it processes so every 2frames all of them are processed. But especially if you increase the view distance, it just jumps up again even more, even though those of chunks that are further out from the player and are far less likely to need chunk processing calls every frame anyway. So it needs a better implementation

for my game i have already taken off frustrum culling(well its on for like the first 30sec of load up just to prioritize whats in view first) then its off.

did you ever look into the problem of..

Another weird issues is HorizontalChunkLoadRadius if you set it too 11 or higher, it jumps cpu to twice the time to calculate.. ie

HorizontalChunkLoadRadius = 9...I get ~4.5ms updates
HorizontalChunkLoadRadius = 10 ...I get ~5ms updates
HorizontalChunkLoadRadius = 11 ... ~13ms +200kb GC

I haven't checked it recently but it was weird problem especially if you wanted to bump up the view distance with it the extra GC .