Toward more realistic pathfinding
Download
1 / 35

- PowerPoint PPT Presentation


  • 296 Views
  • Uploaded on

Toward More Realistic Pathfinding. Authored by: Marco Pinter Presentation Date: 11/17/03 Presented by: Ricky Uy. Background – A*. Commonly used in video games Finds a path from start to goal, if one exists

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '' - Leo


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Toward more realistic pathfinding l.jpg

Toward More Realistic Pathfinding

Authored by: Marco Pinter

Presentation Date: 11/17/03

Presented by: Ricky Uy


Background a l.jpg
Background – A*

  • Commonly used in video games

  • Finds a path from start to goal, if one exists

  • Finds optimal path given that the heuristic is an underestimate, i.e. always <= actual cheapest path cost from a node X to the goal


Background a3 l.jpg
Background – A*

Algorithm

  • Repeatedly examines the most promising unexplored location it has seen

  • If an examined location is the goal, algorithm is complete; else, note all neighboring locations for further exploration


Background a4 l.jpg
Background – A*

Algorithm

  • Uses “Open” and “Closed” states for unexamined and examined nodes

  • “Open” is a priority queue

  • Priority determined by whatever the path is trying to minimize, e.g. distance traveled

  • Total cost = actual cost from start to node X + heuristic cost from X to goal


Background a5 l.jpg
Background – A*

Algorithm

  • Initially only the start location is in Open, with start.parent = null

  • Pop node off Open and examine it

  • Place node into Closed list

  • All unblocked neighbors updated and placed into Open queue

  • If Open list becomes empty before goal is found, there is no path from the start to the goal location


Background a6 l.jpg
Background – A*

Demo – taken from an article by Bryan Stout in Game Programming Gems


Background a7 l.jpg
Background – A*

Limitations

  • Worst case time: when there is no path from start to goal

  • Produces zigzag effect

  • Does not produce smooth turns

  • Does not check for “illegal moves” or for abrupt turning when a unit has a particular turning radius

  • Memory limitations: huge number of nodes in Open and Closed lists


Background a8 l.jpg
Background – A*

Optimizations

  • Hierarchical pathfinding, albeit subject to path failure by choosing impossible locations as midpoints

  • Use a basic non-priority list with previous and next pointers instead of a priority queue

  • Loses on search time: O(n) compared to O(log n), but wins on insertions and deletions


Removing the zigzag effect l.jpg
Removing the Zigzag Effect

Can just associate a cost with each turn, but that does not solve the problem entirely. A better smoothing process is to remove as many waypoints as possible.


Removing the zigzag effect10 l.jpg
Removing the Zigzag Effect

checkPoint = starting point of pathcurrentPoint = next point in pathwhile (currentPoint->next != NULL)   if Walkable(checkPoint, currentPoint->next)      // Make a straight path between those points:      temp = currentPoint      currentPoint = currentPoint->next      delete temp from the path   else      checkPoint = currentPoint      currentPoint = currentPoint->next


Removing the zigzag effect11 l.jpg
Removing the Zigzag Effect

Checks path from waypoint to waypoint. If the path traveled intersects a blocked location, the waypoint is not removed. Otherwise, remove the waypoint.

Leaves “impossible” sections as is.


Adding realistic turns l.jpg
Adding Realistic Turns

Want to be aware of a unit’s turning radius and choose shortest route to destination, in this case the right turn will lead to the shortest route.


Adding realistic turns13 l.jpg
Adding Realistic Turns

  • Calculate the length of the arc plus the line segment for both left and right turns. Shortest path is the one to use.


Adding legal turns l.jpg
Adding Legal Turns

Several Postprocess Solutions (cheats)

  • Ignore blocked tiles – obviously bad

  • Path recalculations – associate a byte with each tile, each bit denoting the surrounding tiles as legal or illegal; may invalidate legal paths from other directions = bad

  • Decrease turning radius until it is legal – bad for units with constant turning radius (e.g. truck), good for units such as people

  • Backing up – make a three point turn – good for units such as trucks, weird for people


Adding legal turns15 l.jpg
Adding Legal Turns

Problems

  • Methods shown previously are basically cheats, except for the second one (path recalculations), which can fail to find valid paths

  • How can we make sure that paths taken are both legal and do not violate the turning radius?


Directional a l.jpg
Directional A*

Sometimes the only legal path that does not violate the turning radius constraints is completely different from the path that the standard A* algorithm produces. To get around this, Pinter proposes a modification known as Directional A*.


Directional a17 l.jpg
Directional A*

First things first

  • Add an orientation associated with each node, where the orientation can be any one of the eight compass directions

  • Each node now represented by three dimensions: [x, y, orientation]


Directional a18 l.jpg
Directional A*

  • Check the path from a parent to a child node, not just whether or not the child is a blocked tile

  • Consider the orientation at parent and child nodes as well as the turning radius and size of the unit to see if path hits any blocked tiles

  • Result: a valid path given the size and turning radius of the unit


Directional a19 l.jpg
Directional A*

Directional A* does not go directly from a to c because it sees that an abrupt right turn would cause the unit to hit blocked tiles. Thus, waypoint b is found as the shortest legal path.


Directional a20 l.jpg
Directional A*

Problem: adding an end orientation

  • Four common paths


Directional a21 l.jpg
Directional A*

  • Can easily compute the four common paths and choose the shortest one

  • Can add smoothing algorithm presented earlier, with the modification of sampling points along a valid curve between two points rather than just a straight line between two points


Expanding the search l.jpg
Expanding the Search

  • So far, have been using a Directional-8 search

  • Some paths will fail under this method

  • Try searching more than one tile away

  • Directional-24: search two tiles away, rarely fails to find a valid path

  • Directional-48: search three tiles away, almost never fails to find a valid path


Expanding the search23 l.jpg
Expanding the Search

Example of a case where Directional-8 fails, but Directional-24 finds a valid path


Modifying the heuristic l.jpg
Modifying the Heuristic

  • Standard A* measures straight line distance from start to goal

  • Modify so that it measures the shortest curve and line segment as calculated earlier, considering turn radius

  • If units can go in reverse, consider adding a cost penalty to encourage units to move in reverse only when necessary


Directional a limitations l.jpg
Directional A* Limitations

  • Very slow, constantly uses tables as a means to optimize it (directional table, heuristic table, hit-check table, etc)

  • Directional-48 may still possibly (though rarely) fail

  • The four common paths from origin to destination are not the only ones; there is an infinite number of paths


Better smoothing algorithm l.jpg
Better Smoothing Algorithm

  • Previous method of removing waypoints has some faults


Better smoothing algorithm27 l.jpg
Better Smoothing Algorithm

  • Perform standard A* algorithm

  • Then, perform Directional-48 algorithm that favors the path found by the standard A* algorithm by modifying the cost heuristic

  • Finally, perform the smoothing algorithm described earlier (removing waypoints)

  • This will find the blue line path on the previous slide


Limitations on better smoothing algorithm l.jpg
Limitations on Better Smoothing Algorithm

  • Fails to find valid paths that a full Directional-48 search would find


Limitations on better smoothing algorithm29 l.jpg
Limitations on Better Smoothing Algorithm

  • Does not find blue line path because of its bias towards the original path

  • Ends up not finding any path at all

  • To help performance in this worst case scenario, return failure if six or more points have been searched backwards


More optimizations l.jpg
More Optimizations

  • Timeslice the search

  • Only use Directional-24 and -48 if a Directional-8 fails

  • Divide map into regions and pre-compute whether a tile in one region can reach a tile in another

  • Use two matrices to calculate intermediate search results, one for slow, timesliced searches and the other for faster searches


One possible hybrid solution l.jpg
One Possible Hybrid Solution

  • Perform standard A* search, checking only four tiles at every node

  • Perform Smoothing-48 pass; if successful, skip to last step, otherwise note farthest node hit

  • Work backwards from goal using Smoothing-48 pass and note farthest node hit

  • Take the two farthest point nodes and make sure they are less than, but close to, 12 tiles apart. If more than 12 tiles, return failure.

  • Perform Directional-8 between the two nodes and connect the three segments into one path

  • Perform the initial simple smoothing algorithm (the one that removes unnecessary waypoints)



Speed and other considerations l.jpg
Speed and Other Considerations

  • For sand, add a cost to the heuristic

  • For speed, add a cost for turns made


Summary l.jpg
Summary

  • Directional A* finds legal paths and realistic turns

  • Directional A* is slow

  • Examples only take into account a 2D space partitioned into a grid, but can be extended to support various partitioning methods in 2D or 3D

  • Suggest standard A* for most units and Directional A* for various large units



ad