• FEATURED

View more

View more

View more

GameDev Marketplace

Energy Hard Rock Pack

$15$10

Image of the Day Submit

IOTD | Top Screenshots

A.I. Path Following

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

5 replies to this topic

#1DrEvil  Members

Posted 14 September 2013 - 11:31 AM

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.

#2Álvaro  Members

Posted 14 September 2013 - 06:56 PM

Disclaimer: I don't have much experience with path following (it was pretty trivial in the cases where I've done it).

Instead of dumbly going straight to the target node, you can use steering behaviors to tend to go towards that position but avoiding obstacles.

Another idea is to change your target node when you are within a certain radius of the current one and you have a line of sight to the next one.

Some combination of those two ideas should get rid of most of the problematic cases, if not all.

Posted 15 September 2013 - 06:36 AM

Disclaimer: Neither do I have much practical experience doing path following in more complex scenarios.

Instead of dumbly going straight to the target node, you can use steering behaviors to tend to go towards that position but avoiding obstacles.

I think this approach can fall short when the agent has been pushed off his course far enough to end up behind a wall whereas his target position resides exactly on the opposite side of that wall -> steering forces would eventually cancel out each other. And worse: he could then start sliding himself into a dead-end while still trying to reach the target position and avoiding that wall.

Here's what I would try to experiement with: apply a slightly modified Funnel algorithm on a more local basis while moving. You could pass in the target point where your agent intends to steer towards to, then let the algorithm figure out a point that lies withing a valid funnel. If the figured-out point happens to be your target point, just steer straight towards it as your agent won't go off the navmesh. Otherwise, scale the direction from your agent to that point by some amont representing your intended steering force, and move towards that point. Repeat while moving.

Does that make sense?

--

Edited by Shadax, 15 September 2013 - 06:39 AM.

#4mklingen  Members

Posted 15 September 2013 - 02:30 PM

I have two solutions. Both of them rely on treating the path not as a path per-se but as a trajectory. What you want is for your agent to move such that at each point in time, the agent is close to the path, and his velocity is along the path. So, you've got to add another dimension to your path: time. You can turn your static path into a function that says "where should I be at time t?" the agent then tries to get to the point "where he should be". This is called a trajectory.

The easy solution:

• Take the entire trajectory as a single curve paramaterized by time t between 0 and 1. Create a function which goes from [0,1] to a 3D point f(t).
• The agent starts at t = 0. He seeks the point f(t) until he's within a radius (called the blend radius).
• t then advances by a small amount.

That's it!

The better solution:

• Start again with a trajectory paramaterized by a single number between 0 and 1.
• Find t_x such that the distance between the agent and the trajectory is minimized. (If you trajectory is piecewise linear, this involves projecting to the nearest line)
• Seek the point  f(t_x + e)  where e is a small number representing the "lookahead time". e can be larger the further away the agent is from the trajectory.

I also have source code and a graphical example for the second solution:

http://www.openprocessing.org/sketch/96006

Edited by mklingen, 15 September 2013 - 04:24 PM.

#5AngleWyrm  Members

Posted 15 September 2013 - 04:33 PM

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.

--"I'm not at home right now, but" = lights on, but no ones home

#6DrEvil  Members

Posted 18 September 2013 - 11:33 AM

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.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.