i was wondering, before i jump into optimization, what’s the performance profile of navmesh nowadays?
back in the prehistoric days of 3.x it was single threaded and fast but not that fast.
The pathfinding operations of all agents are executed single-threaded and they are thus able to stay under the limit set with NavMesh.pathfindingIterationsPerFrame
.
The simulation of the NavMeshAgent crowd movement is multi-threaded and, if necessary, it will use as many worker threads as there are available. One thread will execute the simulation of a group of agents that are nearby each other.
Single thread … not on the main thread I hope, main thread cycles are too precious to waste on non synchronous processes.
The pathfinding code runs on the main thread.
When is it being moved to jobs? There is no reason to hog the main thread with an async operations.
It makes sense to try and move it to a worker thread. I’ve added it to our backlog and we’ll need to find a place for it in our plans. When we’ll have news I’ll share them here.
Thanks, we on Switch appreciate.
Looking forward to this!
Hello. anything changed in 2023.1 alpha 11 about multithreaded navmesh and pathfinding?
Over a year has passed and still no news on fixing Navmesh needlessly being on the main thread? Has it been moved or is it time for us to learn dots 1.0 to do it ourselves?
It’s planned but it will probably take a long time. AI/Navigation has no priority and afaik only 1-2 persons are working on stuff like that.
Progressive Rearchitecture: Queryable navigation model
Is it possible to force the crowd movement to be single threaded? I’m getting various freezes related to crowd manager multithreaded code.