Moving from Unity NavMesh to A* Pathfinding

Hello @aron_granberg and thanks for what looks like a promising asset!

I’m interested in trying out the pro version of this asset, but before I do I had a few questions regarding Unity NavMesh vs this asset.

With Unity’s NavMesh I can:
-Carve Obstacles at runtime
-Bake NavMeshes at runtime
-Pathfind various Agent sizes round various NavMeshSurfaces
-Jump an Agent around a NavMesh by carving obstacles on top of it

I’m sure your asset can handle the first 3 (lmk if it doesn’t), but the last one is what I’m not sure about. The game I’m working on requires manipulating physics, and “jumping” yourself around when placing objects that carve the NavMesh on top of your NavMeshAgent. So in your A* asset what happens when you place a obstacle that carves a navmesh ontop of an agent? My hope is the Agent would “jump” to the closest available NavMesh.

Then there are reasons why I’m looking for alternatives to Unity’s NavMesh System, because it cant do:
-Agent avoidance (Unity’s agents stack on top of each other instead of avoiding each other when ordered to the same destination) I’d like my agents smart enough to know not to walk through one another.
-Non-contiguous NavMesh areas. In Unity there is a “min region area” setting, but it doesn’t work very well, and even the documentation says it doesn’t work all the time: https://docs.unity3d.com/Manual/nav-AdvancedSettings.html
So what I’d like is for any NavMesh not connected to be removed.

So can A* Pathfinding handle all of the above?

Hey,
Thank you for your interest in the package.

The package provides Navmesh cutting, both static and dynamic. You can see a demo in action (here)[https://arongranberg.com/2013/08/navmesh-cutting/]

You are indeed able to Scan graphs during runtime. But also partial updates are possible, more info (here)[https://arongranberg.com/astar/docs/graphupdates.html]

Agraph usually has a preset agent radius. Though you’re able to create multiple graphs with different radiuses. And set your larger agents to only use the larg graph, while smaller agents use the smaller radius graph.

This is a bit tricky. I know the RichAI movement system handels being off the navmesh pretty well. But it always comes down to how far the agent is. Agents also come with a feature to constrain them to the graph. I can’t guarantee this will give the desired result.

Last but not least I want to say that RVO is a great tool, and can be a great system ontop of your already existing agents. But it won’t just solve issues for you. There is a balance to be found.

I hope that helps,
Im sure that if I missed anything Aron will fill in the details.

Excellent breakdown thank you. And what about my last two questions.

Do agents avoid each other? Without bumping/stacking on top of one another.

And is there a way to remove non-contiguous Nav Meshes from the graph? As to avoid jumping to a non-contiguous place if forced off the graph via carving.

Depends on how you set up the collision on your agents and so on. If you’re using Character controllers for example, you’ll have to make sure their step height isn’t too tall, compared to other agents their height.

At the moment this the package does not automatically clean up graphs.
However I’m working on a third party tool for automatically find connections between graphs, and this will be able to remove unreachable areas. You can read more about it here: Automatic nodelink placer tool

1 Like

This is supported. This package contains multiple movement scripts. The RichAI movement script requires that the agent is always on the navmesh, so it will also snap to the closest point on the navmesh if it detects that it is outside it. The AIPath script has this feature disabled by default but you can enable it using the “Constrain Inside Graph” setting on the AIPath component.

There is the same “min region area” setting that Unity has. However it has the same limitations.
The problem is that if you recalculate a part of the navmesh later then some region which was previously too small might now be big enough to be included. This makes it tricky to remove small regions without being overly aggressive.
There is the https://arongranberg.com/astar/docs/recastgraph.html#relevantGraphSurfaceMode setting, but the workflow is not the best.

I think @ToastyStoemp answered the rest.

Thank you for the thorough response. It sounds like it should be capable of meeting my needs. I’ll have to dive into it to find out! Thanks again.

1 Like