I am running into performance issues trying to update a very large NavMesh. The NavMesh is baked over a 500x500 terrain, with voxel radius .1, agent radius .12, tile size 25. Effectively, it’s a 5000x5000 map. Updates occur because of dynamically assigning hundreds of temporary square buildsources that comprise a grid of weights. Right now I am updating using NavMeshBuilder.UpdateNavMeshDataAsync, and awaiting the resulting AsyncOperation object. However, there are an issue and a path to optimizaiton
Despite the thread updating asynchronously, the main thread is occasionally blocked for huge amount of time - 5 seconds at extreme cases. According to the profiler, the blocking operations are NavMesh.ExtractTileMesh, Physics.Processing, NavMesh.RasterizeTriangles, . Strangely enough, some of the ECS systems are blocking on those operations - EndFrameParentSystem and EntityCommandBuffer.Playback, for example, have WaitForJobGroupIDs on NavMesh.RasterizeTriangles. Even one of my custom systems sometimes wait on NavMesh background threads to finish. The worst offender is the final frame before the update is finished - NavMesh.Integrate.RemoveTiles takes 5500ms to complete. Why are there update operations taking place on the main thread, and how do I prevent them?
There is a property of my implementation that could be used to reduce overhead. The grids of weights are all same-size squares and are distributed around the NavMesh. The total area of these grids is at most 5% of the total NavMesh area. If I could just update only the sections of the NavMesh with weights then a huge amount of latency can be avoided. Any idea on what I can do to accomplish this?