Path Look-up Tables & An Overview of Navigation Systems

1. Path Look-up Tables & An Overview of Navigation Systems Hai Hoang 10/4/2004

2. Path Look-up Tables (2.3) • Outline: • Why Use Look-up Tables? • 3 types of look-up tables • Path look-up matrix • Indexed path look-up matrix • Area-based look-up table • Design and Performance of each

3. Why Use Path-Look Up Tables? • A* is a popular path search algorithm, but slow. • Fastest way to find a path • NOT to search • but to look up a path from a precomputed table • Free up the CPU for other AI decisions • How much faster? • 10 to 200 times faster, depending on implementation and terrain • A* Explorer demo • http://www.generation5.org/content/2002/ase.asp

4. 1st Type of Path Look-Up Table • Using a matrix • For N waypoints, the matrix size is N x N • Each cell stores • The next neighboring waypoint to visit on the path • Or the “no path available” marker • To look up path from a to b • Retrieve next neighbor n0 for (a , b) • Followed by next neighbor n1 for (n0 , b) • Repeat until ni = b

5. Path Look-Up Matrix Example

6. Benefits • Fast path retrieval • Predictable path • Low CPU consumption • Path retrieval performance is not influenced by terrain layout • Unlike A* - as efficiently with deserted plains as with 3D mazes

7. Problems • Hug memory consumption • Increases quadratically with the number of waypoints • Typically, each entry is 2 bytes • For 1,000 waypoints – 2MB • For 2,000 waypoints – 8MB • Contains only static representation of terrain • Can only reflect changes via an update or patch • O(n3) to update

8. 2nd Type of Path Look-Up Table • Using an Indexed Path Look-up Matrix • Reduce memory consumption by factor of 4 by: • using 1 matrix to store an index, • another to store the outgoing waypoints • Replace the 2 bytes “next waypoint to visit” with a 4-bit index into the waypoint list of outgoing waypoints • Assumption: • Reduce the waypoint graph so each waypoint use a maximum of only 15 outgoing waypoints • By trimming away outgoing waypoints best approximated by another link or via a shorter path

9. Example of Indexed Look-Up Table

10. Example of Indexed Look-Up Table(cont.)

11. Memory Consumption • Memory consumed for the 4 bit index look-up matrix is: • N x N x .5 (.5 byte is 4 bits) • For the 15 outgoing waypoints look-up matrix: • N x 15 x 2 • For 1,000 waypoints: 542 kb • For 2,000 waypoints: 4 MB

12. Benefits and Problems • Benefits: • 4 times a much terrain for the same amount of memory as regular path-look up matrix • Only about 5% reduction in performance • 2 to 5 times better than area-based matrix • Problem: • Hard to update for terrain changes • Still grows very fast

13. 3rd Type of Path Look-Up Table • Using Area-Based look-up matrix • Divide terrain up into areas • Move from area to area using portals • Path look-up is performed on two levels

14. Designing Portal Path Table

16. Look-Up at Top Level (pseudo-code) Problem: to move from a (in area A) to b (in area B) • if (A==B) then both waypoints in the same area, just look in the area table • If (A!=B) - 2 different areas • Retrieve portal for area A , call it Pa • Stores the path from a to Pa in path[] • Retrieve portal for area B, call it Pb • Find the shortest path from Pa to Pb • From Pa to Pb, there might be portals in between • If there is, find path from Pa to Pi • Translate the portal path into waypoints moves and add to path[] • until Pi == Pb • Finally, add path from Pb to b to path[]

17. In Area Look-Up

18. Benefitsover Matrix & Indexed Look-up Table • Using many smaller tables, 1 for portals paths, several for the path with in each area. • Save lots of memory, especially for larger numbers of waypoints • Since look-up tables are quadratic, • a2 + b2 < (a + b)2 • More suitable for patching to reflect changes in the terrain • Can open or close portals • Patch an area

19. Problems? • Memory consumption depends on the quality of the area and the size of areas interconnection • And the reason: open areas • More memory if not partitioned well • Larger area interconnections – needs more portals • Could be harder to patch

20. Memory Consumption & Performance Relative to A*

21. Area-Based Look-Up Table???

22. Quake 3 Arena • Used a technique similar to area look-up table • Map is divided into convex hulls called areas • Minimal navigation complexity, such as walk or swim • Maps with 5000 or more areas are common. • Moving from one area to another depends on reachability • Quake uses a real-time dynamic routing algorithm • The routing data is caches for fast look-up • The idea of portals are used for teleporting between areas

23. Does it make you wonder? • How graphics are rendered fast enough. • Handle multi-players – added delay • CPU Time left for AI for bots • “If you're a fan of Quake like I am, you're surely aware that your computer is not able to render that entire 3D, shadowed, textured world at 30 frames a second. But for some reason, it appears to.” Alex Zavatone • Video from: • http://www.planetquake3.net/

24. Fast graphics??? • What it is doing is taking data from a prerendered world and turning that into a textured, shadowed realistic looking environment. That's possible because the information has already been calculated and is stored in some sort of look up tables. “ Alex Zavatone http://www.director-online.com/buildArticle.php?id=152

25. An Overview of Navigation Systems (2.4)

26. Navigation System • A Navigation System is a separate component responsible for synthesizing movement behaviors. • By encapsulating navigation into a component, it’s simpler to craft behaviors and movements. • Purpose is to provide modularity in AI programming.

27. 3 Levels of Abstraction • Planner: • Only the shortest path algorithm abstracted and implemented in the navigation system • The agent has to make the request and interpret the result. • Pathfinder: • The pathfinder would deal with the execution of the plans • The agent still has direct control of the paths • Sub-architecture: • Planning abilities and composing different movement behaviors

28. Navigation Interfaces • Allows agent to send information to the navigation system • When designing the interface the programmer must decide between a focused or flexible interface • Existing paradigms for navigation interfaces (starting with the most focused) • Single pair: Two points are specified, the shortest path is returned. • Weighted destinations: Can have multiple destinations, each with its own reward coefficient. • Spatial desires: Specifying the movement by passing the motivation from the agent to the navigation system (e.g. get armor or get weapon)

29. AI Paradigms for Movement • Reactive Behaviors • Deliberative Planning • Hybrid Systems

30. AI Paradigms for Movement • Reactive Behaviors (reactive steering): • Takes sensory input and performs a direct mapping to determine output • Example: takes in local info about obstacles and outputs commands as to where to move • Possible behaviors include obstacles avoidance, seeking, and fleeing. • Cannot handle traps ,complex layout, intricate scenarios, and human-level movement with these behaviors

31. AI Paradigms for Movement (cont) • Deliberative Planning: • Reactive behaviors can’t handle traps ,complex layout, intricate scenarios, and human-level movement • Planning can formulate suitable paths in the world before used to solve these problems • Plans are made according to the terrain representation

32. AI Paradigms for Movement (cont) • Hybrid Systems: • Simple obstacles can be handled by reactive behaviors, no need to waste a lot of time on finding paths that could be handled straightforwardly • Planned is need to optimized between speed or quality of movement • Solution is to use both paradigms

33. Implementing Reactive Behavior • Simplest technique is steering behaviors • Using mathematical equations to decide where to steer next • Problem with: • Integration of multiple behaviors • Fixed by prioritize behaviors • Realism • Fuzzy logic – blend the behaviors together to make it look more realistic

34. Implementing Deliberate Planning • Planning doesn’t necessary mean search • Precompute everything • Use reactive approximation to build near optimal path • Use threshold to trigger replan • Use D* to research the tree from A* • Use quality of service algorithm

35. Conclusion • Choose the right navigation architecture is important • Improve quality of the behaviors • Increase performance • Make it easier for Agent to integrate with your navigation system

36. Examples of Navigation Systems • PathEngine • http://www.pathengine.com • BioGraphic Technologies AI.implant • http://www.biographictech.com

37. D* Algorithm

38. D* Simplified • S = Start state • G = Goal state • X = Current state • M = Current map • 1) Store all known, approximate, estimated, and believed information about the environment in M • 2) Let X = S

39. D* Simplified (cont.) • 3) Plan an optimal path from X to G using M -terminate with failure if no path found • 4) Follow path found in 3 until find G or find discrepancy in M and the environment • 5) Update M to include new sensor info, then go to 3 to replan

40. References • Game AI Programming Wisdom 2, Steve Rabin, 2004 • The Quake III Arena Bot, J. P. v. Waveren • http://www.kbs.twi.tudelft.nl/Publications/MSc/2001-VanWaveren-MSc.html • Map-Based Strategies for Robot Navigation in Unknown Environments , Anthony Stentz • http://www.frc.ri.cmu.edu/~axs/doc/aaai96.pdf • A* Explorer demo • http://www.generation5.org/content/2002/ase.asp • http://www.director-online.com/buildArticle.php?id=152