I’ve created a sample project using ECS to query the navmesh and moving 100,000 entities at the same time. I’m getting around 40-50 fps with mid range desktop. Right now the bottleneck is the command buffers that can’t be called in parallel inside the IJobProcessComponentData. I believe if that is solved it can easily scale to a few hundred thousand.
The buildings are generated via the MapBox Unity API (you can change the location) and the navmesh is baked afterwards.
Navmesh path query results are heavily cached so that helps a lot.
Good stuff. One question please. I’m digging your solution, and can’t find, how you move capsules I saw systems where you attach needed tags components, calculate path corners and cache them, but I can’t see moving directly. Kick me to the right class please
Hey guys. I’ve updated the code to fully utilise the job system and ECS. Right now the only bottleneck is the mesh rendering system where DrawMeshInstanced can’t be called outside of the main thread.
The navmesh queries are also jobified which means that it will run on all threads. In my tests it shows that I’m able to query resolve around 1000 paths per second. I’ve moved all the navmesh querying code into one NavMeshQuerySystem.cs file. You can drop that file into your project and start querying the navmesh.
Nice! Did you tried using DrawMeshInstancedIndirect and pass positions and rotations through the shader? That could improve performance further. I think in Nordeus demo DrawMeshInstancedIndirect is called outside the main thread, but need to check that…
Yes I’m aware that raycast jobs are available, but implementing that would mean i would need a gameobject for each unit and a collider too. It won’t be “pure” ECS anymore
I agree, I think the best here would be to have ECS alternative for NavMeshAgent component with its local avoidance. And also NavMeshAgentSystem.
As for PhysX, I think only colliders can make local avoidance. But I think PhysX limits are around 1k colliders, so it’s quite far from 100k. In boids demo it was used “sparse” grid. While in Nordeus demo there is implemented Crowd System. I think these could be good directions to look further when going towards 100k.
I tried to get your project running from github but unfortunately when pressing play I get an error from Mapbox that is tries to acces a non existing path. Did you forget to include some files in git or did I miss a configuration step?
Yeah this project is turning into a plug and play solution for jobified navmesh thus i’m going to remove the existing dependency on mapbox and upload to a new repo.
I’ll be adding a couple more examples such as a hybrid approach with rigidbodies and colliders soon so stay tuned.
But the current repo should work. I just pulled a fresh one a couple of days ago.
Sparse grid is okay I guess for a demo with a fixed size grid. I’m not sure how it would work on maps with dynamic nav meshes that can change sizes. I wouldn’t want to impose any limitations on the map size even if it were via an adjustable property.
I guess for the time being using kinematic rigidbodies and colliders with game object entities would suffice until there’s a ECS solution for physics. I would be happy to have 5000 units running around with local avoidance at 60fps via this method.
The Unity team did mention that they’re working on the physics too.
I saw systems where you attach needed tags components, calculate path corners and cache them, but I can’t see moving directly. Kick me to the right class please 
