**0**

# Smoothing a path calculated by A*

Started by Sep 19 2012 11:02 AM

,
3 replies to this topic

###
#1
Members - Reputation: **137**

Posted 19 September 2012 - 11:02 AM

Hi everyone. I need to know if there is any way to smooth a path gained from the standard A*. I store the path as indces of each tile of the grid into a std::list<unsigned int>. I've actually read the article "Toward More Realistic Pathfinding" in Gamasutra but since the sample code is not available, it's hard for me to understand it correctly. so I would be grateful if someone could help me on this. thank you.

###
#2
Moderators - Reputation: **3451**

Posted 19 September 2012 - 02:01 PM

There are about 40 ways, I'm sure and probably 400 articles on the web about it.

Did you even bother to search this forum for "path smoothing"?

Did you even bother to search this forum for "path smoothing"?

**Dave Mark**- President and Lead Designer of Intrinsic Algorithm LLC

Professional consultant on game AI, mathematical modeling, simulation modeling

Co-advisor of the GDC AI Summit

Co-founder of the AI Game Programmers Guild

Author of the book, **Behavioral Mathematics for Game AI**

**Blogs I write:**

**IA News**- What's happening at IA |

**IA on AI**- AI news and notes |

**Post-Play'em**- Observations on AI of games I play

*"Reducing the world to mathematical equations!"*

###
#4
Members - Reputation: **982**

Posted 29 September 2012 - 08:14 AM

It sounds like the pathfinding algorithm described in "Toward More Realistic Pathfinding" is a bit complicated for your purposes.

I think the easiest solution is a feedback controller that's willing to "cut corners." Here's a nice one that's not too complicated:

Keep track of two points:

- Where the agent is. Call this point

- The point furthest along the path that the agent can see in a straight line. Call this point

At every frame,

1. Advance

2. Walk

It's not the most efficient method -- it requires a bunch of raycasts that fancier computational geometry algorithms like "string pulling" avoid -- but it's simple; it's flexible; and you can start out with a very basic implementation and then "slot in" improvements.

For step 1, you can do one of,

- sequential search

- binary search (you could use std::lower_bound to do this by saying that a point

- step-doubling forward search, followed by binary search (i.e., try the point one ahead of

For step 2, if you want smooth turns, you can simulate the following ODE:

(This part simulates a "turn-on-a-dime" car with sped s and turning rate w:)

dx/dt = s [cos(theta); sin(theta)];

dtheta/dt = w;

where

(This part is the controller for the car that determines its speed and turning rate.)

s = v1 cos(theta) + v2 sin(theta)

w = v1 sin(theta) - v2 cos(theta)

and v = (v1, v2) is the vector from x to p; i.e., v = p - x.

(By "simulate" I mean do e.g. Euler integration; e.g., when I write

dtheta/dt = w

I mean

theta_next = theta + w*dt

where "dt" is some small number.)

This is quick to code and gives pretty good results.

I think the easiest solution is a feedback controller that's willing to "cut corners." Here's a nice one that's not too complicated:

Keep track of two points:

- Where the agent is. Call this point

*x*.- The point furthest along the path that the agent can see in a straight line. Call this point

*p**.*At every frame,

1. Advance

*p*along the path until just before*x*cannot see it. (On most frames,*p*will not move.)2. Walk

*x*towards*p*.It's not the most efficient method -- it requires a bunch of raycasts that fancier computational geometry algorithms like "string pulling" avoid -- but it's simple; it's flexible; and you can start out with a very basic implementation and then "slot in" improvements.

For step 1, you can do one of,

- sequential search

- binary search (you could use std::lower_bound to do this by saying that a point

*p*on the path is "less than" a point*x*if it is visible from*x*.)- step-doubling forward search, followed by binary search (i.e., try the point one ahead of

*p*; then two ahead, then four ahead, then eight ahead, and so-on, until you encounter a point that's not visible; then do binary search on the interval between the last two points. Like binary search, this has logarithmic worst-case complexity, but the average-case will be better if the point you're looking for is usually not very far ahead of the one you're at).For step 2, if you want smooth turns, you can simulate the following ODE:

(This part simulates a "turn-on-a-dime" car with sped s and turning rate w:)

dx/dt = s [cos(theta); sin(theta)];

dtheta/dt = w;

where

(This part is the controller for the car that determines its speed and turning rate.)

s = v1 cos(theta) + v2 sin(theta)

w = v1 sin(theta) - v2 cos(theta)

and v = (v1, v2) is the vector from x to p; i.e., v = p - x.

(By "simulate" I mean do e.g. Euler integration; e.g., when I write

dtheta/dt = w

I mean

theta_next = theta + w*dt

where "dt" is some small number.)

This is quick to code and gives pretty good results.