Accelerating recastnavigation with Unity.Physics

I'm moving our game to using recastnavigation directly and was thinking that Unity.Physics might be a good way to get all triangles needed to rebuild any specific tile. With recast all I need is just the triangle soup for the given tile bounds.

So if I do an overlap query I should be able to follow leaves to PolygonColliders and that seems like what I need. Anything that I'm missing here?

 

Sounds right. There are a bunch of functions you could use directly (though most are not public at the moment as we hadn't finalised the API surface).
For example, if you already know the mesh you are checking, the following is in com.unity.physics\Unity.Physics\Collision\Queries\Overlap.cs:

Code (CSharp):

1.         private static unsafe void AabbMesh<T>(OverlapAabbInput input, MeshCollider* mesh, ref T collector)
2.             where T : struct, IOverlapCollector
3.         {
4.             var leafProcessor = new MeshLeafProcessor(mesh);
5.             mesh->Mesh.BoundingVolumeHierarchy.AabbOverlap(input, ref leafProcessor, ref collector);
6.             leafProcessor.Flush(ref collector);
7.         }

Do you already have Unity Physics as a local package to make things public as you want to try them? When you collect all the results you can use the ColliderKeys to GetChild from your MeshCollider.

It is logged for us to add simple OverlappAabb and CastSphere functions to the query interface to make this sort of thing much easier.

 

We do have it as a local package. And OverlappAabb would actually be ideal.

One goal here is to *not* have to track all the geometry in the navmesh ourselves, leverage physics to do what it's good at and avoid a ton of complexity on our end in the process.

Most recast wrappers track it all internally and they don't track at the granularity recast actually wants. Which results in pathological behavior of tile rebuilding taking longer the more tiles there are in the navmesh, and smaller tiles actually making the times increase significantly.

 

Worth noting that there is already a CollisionWorld.OverlapAabb however, this only returns the overlapping bodies indices and not the leaf/triangle details you are looking for.

 

Hmm so it looks like leaf collectors are still considered internal, was trying to work through how to use them and things like ColliderKeyPath methods were internal. Not that I can't fix that it just gives me pause on going in this direction. It also seems more complex then the use case really calls for now that I've looked at it closer.

Mesh colliders are really the only case I would actually need to get geometry anyways and we have very few of those to start with, so just stashing the geometry where I can do an index lookup by rigidbody is good. Everything else is basic shapes I can just work off of template data and scale/translate that per body.