Download Navigation Set Hierarchy

Navigation Set
Hierarchy
Tom Gianos
Chapter 2.2
Mike Dickheiser

Works (worked?) for Red Storm Entertainment
Part of Ubisoft
 Developer of Tom Clancy Games like Ghost Recon
and Rainbow Six


His work focuses on efficient AI systems for
games and AI control of highly realistic vehicles
Problem With Dynamic Pathfinding

Dynamic pathfinding acts as CPU hog

Blocks the development of more exciting AI
features by wasting CPU cycles

Solution:

Precompute navigation information
Issues with Precomputation




Levels/maps of games today are massive
Could contain thousands of nodes
Precomputed navigation information could take
up massive amounts of memory
Solution:

Navigation Set Hierarchy
What is Navigation Set Hierarchy?

A multitier extension of the basic preprocessed
navigation solution with comparable speed and
considerably less memory overhead
What is the basic precomputed
solution?

Basic component is a lookup table (called a
transition or solution table) where each entry
represents the next step between a source node
and a goal node

In other words, for every pair of nodes Source
and Goal, the entry [S][G] represents the node
that should be visited next
A Simple Example
Table Size = n2
Simple Code
Void buildBestPath(int source, int goal, list<int>& path)
{
path.push_back(source);
while(source != goal)
{
source = _transitionTable[source][goal];
path.push_back(source);
}
}
Navigation Sets


Transform the single monolithic navigation map
into a hierarchy of several smaller sub-maps
called navigation sets
Navigation Set:
A self contained collection of nodes that requires no
links to external nodes in order to complete a path
from one internal node to another
 A complete precomputed transition table can be
constructed for each navigation set

Interface Nodes and the Interface
Navigation Set



Once the monolithic map is broken up into navigation
sets a problem that arises is cross set navigation
To solve this, identify all nodes in the navigation sets
that connect to nodes in other navigation sets (Interface
Nodes)
These navigation nodes together create their own
second level navigation set called an Interface Set
Transition table and hence the Navigation Set
Hierarchy
Navigation Set Hierarchy Example
Monolithic Map = 441 transition table entries (212), 21 Nodes, 1 Navigation Set
Hierarchical Map = 183 transition table entries (72 + 72 + 72 + 62)
Memory overhead reduced 60%
Constructing the Hierarchy

Key goals for deconstructing single large
transition table into navigation sets:
Determining the number of smaller tables to create
 Intelligently choosing where to partition to minimize
number of interface nodes

Selecting the Number of Navigation
Sets




Depends on the resources of the project
In breaking up a monolithic map into n equal-sized
partitions, reduce data size to 1/n of the original size
plus the interface set
Once size of partition is chosen designers can control
the number of interface nodes and thus the size of the
interface set
If the interface nodes are chosen wisely navigation sets
can become larger and the relative cost of the interface
sets will become smaller
Partitioning a 1000-node Map
Partitions
Transition Table
Entries
Interface
Nodes
Interface
Table
Entries
Total Table Entries
1
10002 = 1,000,000
0
0
1,000,000
2
2*5002 = 500,000
10
100
500,100
5
5*2002 = 200,000
25
625
200,625
10
10*1002 = 100,000
50
2500
102,500
50
50*202 = 20,000
250
62,500
82,500
Selecting the Partition Boundaries

Keeping the number of interface nodes as low as
possible is the number one goal for two reasons:




Fewer interface nodes results in a smaller interface table size,
saving memory
Fewer interface nodes there are per set the faster the
pathfinding process will be
Identify natural choke points in navigation data, a small
collection of nodes that single-handedly connect to
larger collection of nodes
If natural choke points do not present themselves then
modify the map
Choke Point Demo
The Complete Pathfinding Solution

If source and goal nodes are in the same
navigation set, the process is the same as before

Inter-set pathfinding requires more work

4 step process
The 4 Steps




1) Determine the best paths leading from the source
node to the boundary of the source set (interface
nodes)
2) Determine the best path from the source set
boundary to the goal set boundary
3) Determine the best paths from the goal set boundary
(interface nodes) to the goal node
4) create a list of complete paths assembled from the
first three steps and chose path with the least cost
Example going from A3 to C7
Transition Tables
Example Step 1

Source
Goal
Sub-path
Cost
A3
A6
A3, A6
10
A3
A7
A3, A6, A7
20
Using transition table for set A, find the best paths
leading from A3 to the boundary set of A (A6 and A7).
Example Step 2


Source
Goal
Sub-Path
Cost
A6
C3
A6, A7, C3
20
A6
C5
A6, B2, C5
22
A7
C3
A7, C3
10
A7
C5
A7, C3, C5
20
Using the interface node transition table, find the best paths
leading from the boundary set of A (A6 and A7) to the
boundary set of C (C3 and C5)
In other words, the best path from each interface node in one set
to each interface node in the other set
Example Step 3


Source
Goal
Sub-path
Cost
C3
C7
C3, C5, C7
20
C5
C7
C5, C7
10
Best path from boundary set of C to goal node C7
Opposite of Step 1
Example Step 4
Path
Cost
A3, A6, A7, C3, C5, C7
50
A3, A6, B2, C5, C7
42

Determine all distinct paths that can be generated from
source to goal by combining results of steps 1-3 and
choose path with the least cost
Possible Performance Issues?

Does 4 step process return us to expensive runtime
computation we were trying to escape to begin with?

The amount of searching is dependent only on the
amount of interface nodes in source and goal sets only
and not the actual number of nodes in the navigation
sets themselves
The cost of the inter-set path search does not scale up
with navigation set size, number or complexity

Conclusion

Attempting to give best of both worlds:
Extremely fast pathfinding
 Relatively low memory cost



Easy to implement since navigation sets and
tables sit on top of existing underlying data
structures of nodes and edges
Allows for more creative use of gained CPU
cycles not spent on A* or other dynamic
methods