Why use this navmesh over unity's?

So unity out of box provides navmesh obstacles which i can move around at run time, and soon to be adding component based navmeshes, am curious what the benefit is to use the navmesh from this project?

My level involves rooms with doors and lock and so, need to slice into the navmesh, can this be done in this project? Also the documentation seems to say i have to build the navmesh in a modelling program, why isn’t there a simple “build” option to do it in unity with the project ?

Hi

There are several advantages.
You can recalculate the graph during runtime. Navmesh obstacles can have more complicated shapes than just a box or a capsule. You have access to the full graph data should that be necessary. Multiple graphs can be used at the same time (e.g for different character sizes).

Here is a list of a few more differences: http://arongranberg.com/astar/freevspro

There is a method to automatically calculate the navmesh. It is called the ‘Recast Graph’ which is based on the same method as Unity uses (and a number of other engines).

The first sentence under the ‘Creating a Navmesh’ section in part 2 of the get started tutorial says

Navmeshes can be modelled by hand, or automatically generated. The automatic generation is only available in the pro version and is described later in this tutorial.

Thanks for the reply seems i need the pro version then.

Just to ask some additional things:

In unity i have like a corridor type situation, and their nav mesh finds a path where by the points are right on the edges of the nav mesh - is there a way with your nav mesh to essentially tell it to find a path with points that don’t hug the edges of the nav mesh - that way it looks more human and although is slightly longer path overall, more believable for humans.

See image attatched, the red spheres is the path found, my mouse drawing is how i would prefer it to have found a path:

I couldn’t increase the agent radius because then it chokes the door way too much and so two agents would not be able to pass each other, so is there a way to tell your navmesh system to not hug the navmesh edges as much thus more human like?

Finally this is a suggestion which would be very cool:

Navmeshes with directional rules! Example:

This would be very useful in some situations to have one way directions :slight_smile: Don’t know if that is possible on a navmesh but i think it should be.
In my mind one way of thinking was to use cost with a directional rule attatched. So positive cost is bi-directional, negative number is mono directional (use mathf.Abs() for pathfinder to always use positive cost how ever) with then an additional value to determine the game world direction that is permitted on that painted area.

Could this be possible?

Hi

No, this pathfinding system will also find the path hugging the wall. You can use a Radius Modifier and/or a Simple Smooth Modifier (see documentation), but I am not sure how much that will help.

Navmeshes cannot have directionality I am afraid (well, it is possible with some scripting, but even then I don’t think it will be the exact behavior you are looking for).

What kind of system would work better for directional rules then ?

Hi

Point graphs can be used with directionality.
One option could be to use a very coarse point graph (e.g with one node at the ends of those arrows in the screenshot) which you request a path on, and then request a path using the recast graph to a point say 10 meters ahead of the character on the path from the point graph. I have never tested such an approach myself, so I cannot say how well it would work, but it is definitely an option. You would need some scripting to tie everything together, it will not work out of the box.

Yeah point graph is even less human like in terms of paths, i’ll try see if i can make a hybrid from it - going to be difficult. But your project seems to be the closest out there. No one else seems to have even attempted the idea !