So I have a nav mesh, the implementation and usage of which is pretty easy. The part of navigation systems that I typically struggle with a bit is the logic for following a path, which in principal doesn't sound like it would be difficult, but it has a number of non trivial elements.

Suppose you have a series of points representing a path to a destination. You often simply 'seek' to the next point in the path, but the tricky part comes in when it comes to what the logic is for 'advancing' the 'active' point to the next point. If you use some sort of 'in radius' check it can sometimes cause guys to abandon a point early and seek to the next point where they haven't cleared a corner for instance, and may get caught on the corner. In nav meshes in particular, paths around corners tend to hug the wall as closely as possible, whether due to string pulling or whatever, so incrementing the seek point needs to do so in a reliable way so as to recover from getting hung on a ledge.

In the past I would increment the current point index and/or remove points from the head of the list, but what I don't like about that is that it is destructive to the path points in a way that removes information useful if the A.I. needs to get back on the path. Maybe he was blown out of a navmesh region, or got hung on something or whatever. Since the path alteration is destructive errors often manifest as guys running into walls seeking to a point because they didn't fully get around the last corner vertex and got hung up.

Curious how others avoid this issue and/or maintain their path following such that it can recover and reliably follow the path. In many ways the path following part has proved more difficult for me than implementing the navmesh itself.

If you use some sort of 'in radius' check it can sometimes cause guys to abandon a point early and seek to the next point where they haven't cleared a corner for instance, and may get caught on the corner. In nav meshes in particular, paths around corners tend to hug the wall as closely as possible, whether due to string pulling or whatever, so incrementing the seek point needs to do so in a reliable way so as to recover from getting hung on a ledge.

If your mobile guy entities are approximately the same size, it could be possible to offset the navigation mesh away from obstacles by a little more than the radius of the moving guy enties. It's a sort of baked-in method, like the way they did it in Fallout 3.

Even with an extruded nav mesh this problem arises due to the navigation and collision differences.

I've put together a reasonable I think implementation that seems to address the question and a number of other issues.

When I pathfind through my navmesh, I ultimately get back a list of edges that may be portal edges, which are the crossing segments between sectors, or if it doesn't point to a portal, it uses the position, which is what the start and destination will show up as. The edge also has a pointer to the sector it belongs to, and a copy of the 'version' of the sector that was used to generate the path.

Basically what I do each frame is when I update what navmesh area the guy is in, I update his current sector, and iterate the edges to update what edge index corresponds to the current sector the guy is in. This allows me to maintain the entire result path without destructively culling points as they are reached and such. This means that getting blown back into a previous sector will not require a repath, getting blown ahead in the path doesn't require a repath, etc. Also during this loop I check to see if the sector versions have changed from the sector version number that the path was built with, and replan the path, as that means the sector has been rebuilt due to temporary obstacle baking or other such change that affects pathing. If I get through the edge list and don't find an edge pointing to the current sector, that means the guy is 'off path' so again there I re-path.

So far it seems to work well. Having the path be non destructive also helps debugging, as I don't lose the context of the entire path of the AI if they are in the middle of following it.

I'll post a vid later if anyone is interested.