NavMesh

Pathfinding using Navigation Meshes
Filipe Ghesla Silvestrim
Abstract— In order to achieve accurate movement behaviors
in three dimensional environments the path planning and
locomotion with Navigation Meshes (or NavMeshes) approach is
currently the, most used - at least by game developers, answer.
This paper describes, from theory till practice, what Navigation
Meshes are, how to generate them, how to apply pathfinding
and how to enable movement on top of it . Although we’ll be
just taking a look from a virtual world perspective, the usage
of it for hardware (i.e. Robots) can be tackled with the help of
modern sensors and processors.
I. INTRODUCTION
A key feature for virtual world simulations is the ability
of an agent to move ”intelligently” around the environment
without any human interference. Therefore, a virtual agent
should be aware of it’s world and use it in favor of finding
smart locomotion routes for it’s current task (for example,
a character should avoid walls, trees and mud if he is not
in dangerous). In order to leverage intelligent motion, as
described previously, one must apply Pathfinding (a.k.a. Path
Planning) as being the logic layer that lies between the
decision making and movement logics. Ultimately, as the
result of Pathfinding algorithms we have a Path, defined by
Jeff Huang from Brown University in one of his lectures, as
being ”a list of instructions for getting from one location to
another”.
Independent of the Pathfinding algorithm used (odds-on
that you might hear a earful about A* [1] due to the fact
that it’s a really proficient and well proven algorithm) it
can’t work directly with the virtual world data; it demands
a graph data structure of traversable paths (connections or
links) between nodes as it’s input data structure. Therefore,
in order to achieve locomotion or path planning tasks we
must first, carefully, describe the world via this kind of data
structure. At the end locomotion involves much more than
just the interpolation of the Path and ”the core pathfinding
algorithm is only a small piece of the puzzle, and its actually
not the most important” Paul Tozour [2].
A virtual world is usually designed/described by either
”grids” (2D Arrays), in case of 2D worlds, or geometry data
(popularly know as the ”polygon soup”) as for 3D worlds
as seen on Figure 1. Traditionally, in forehand, this is the
only type of data available to us. In the case of a two
dimensional world we could re-use the bi-dimensional array
as a form of graph representing the virtual environment. On
the opposite, if translating the geometrical data to a graph
structure, we would end-up with with rather complex search
space what would be unfavorable to real-time simulations of
complex virtual worlds. Being so, we must find a way to
translate the geometric data in a simplified graph structure.
Fig. 1: Left image represents a 2D World representation; Right
Image shows a 3D World geometry representation
Fig. 2: Waypoints visually configured in a 3D enviroment
One really important factor of the simplification task is to
find the balance between small search space and information
loss once a really simplified graph could deliver us bad
locomotion due to the lack of encoded information (for
example, an entity must walk slower in a mud area, but if the
graph was so simplified that it missed the mud it would lead
in in a non realistic movement simulation for our agent).
Before the introduction of Navigation Meshes, the most
common type of environment graph representation was
through manually created Waypoints (also know as Path
lattice or Meadow Maps): three dimensional spheres con-
nected to each other as seen on Figure 2. Besides being
a good approach due the control given over the shape and
information contained in the Graph, it was flaw once the
optimal path would likely not be in the Graph (for precision
we must have more waypoints what would increase the
complexibility of the search space) and time consuming due
to it’s manual nature.
Snook [3], in pursuance of a better approach for the
creation of a near optimal 3D Graph, introduced Navigation
Mesh: a static geometry that represents abstractly the three
dimensional world and contains Pathfinding informations. In
other words, he proposed am auxiliary geometry (composed
of a set of connected convex polygons - see Figure 3) to
represent the ”walkable” space (does not need necessarily to

Fig. 3: In navy blue, the NavMesh geomtry
represent the visible area) of the 3D World that would than
be further translated into a Graph on which the Pathfinding
and Movement algorithms are applied on top.
II. NAVIGATION MESHES
With it’s first appearance as a publication in the Game
Programming Gems, Navigation Mesh [3] (a.k.a. NavMesh)
is a simple 3D geometry representing the ”walkable” space
of the virtual world used for Pathfinding and first seen in
action in the game Counter Strike: Source leveraging the
Pathfinding for the Bots (AI NPCs).
The NavMesh is by definition a static geometry composed
of convex polygons as being the only way to guarantee that
the agent can move in a straight line within a polygonal
node, in which relevant informations (such as the terrain
type within that polygon) can be encoded. The way that the
geometry was modeled will determine how the nodes in the
Search Graph are connected and therefore enable or disable
routes between two polygons. If the vertices of two polygons
share a common edge they are inferred to be connected in
the graph and consequently the virtual agent route can cross
(”walk”) over both polygons.
A NavMesh Graph node represents directly a polygon in
the NavMesh geometry. Therefore, the simplification in the
order of polygons, of the NavMesh geometry, influences
directly on the complexity of the search space. Conse-
quentially, this is the reason why, most real case scenario,
NavMeshes geometries are usually composed of convex
polygons with more than three sides.
In regards to the ”walkable” therm, we should acknowl-
edge the fact that static obstacles (or obstructions) should
not be part of the NavMesh and therefore their absent is
crucial for the creation of a proper search graph. Although
not serving to a collision avoidance goal, Pathfinding ap-
proaches can benefit from thee information encoded in it’s
path nodes to aid static collision avoidance by simplifying
the 3D collision to 2D edge collisions (best described in the
following section).
In theory, the same geometry used to build the ground
Fig. 4: The translation from polygons to Graph nodes from a
NavMesh
of our virtual world could also be used as the Navigation
Mesh; in practice, this mesh is usually too detailed and
encodes too much information and therefore ends-up being
performance inefficiently due to it’s complex search space
and huge amount of information that must be decoded to
prompt motion. With this in mind NavMesh geometries are
usually built manually by 3D Artists or Level Designers, or
(semi)automatically generated - having as it’s input either
the world geometry or some helper entities. The NavMesh
geometry is not intended to be visible to the end user, we
use it only as a form of data storage for our Pathfinding.
In order to be able to apply Pathfinding algorithms over
our Search Graph we first must to understand how to generate
it. From a high-level perspective the Search Graph is built by
interating through each polygon in the mesh, marking it as a
node, and checking if the polygons share any adjacent edge,
if so, their nodes ”connect” together in the graph (as seen in
Figure 4). Usually relevant informations such as the vertices
and other geometry data are stored in the nodes (either via
raw data or via reference to look-up tables) as well as some
user or custom data (such as the type of the terrain or some
similar real-time relevant data).
After acquiring the 3D Graph representation - what will be
used as the Search Graph, a Path (Figure 5) must be retrieved
by applying any sort of 2D Pathfinding algorithm (such as
A*).
Finally, in order to utilize the NavMesh at real-time
projects, developers utilize either the raw NavMesh geometry
or the Search Graph as a static pre-processed input solution
to the Pathfinding system.
III. MOVEMENT
In order to enable our virtual agent to move on the
environment we must interpolate, through time, it’s position
in relation to the next available node in the Path list. As
for maters of focus this paper will concentrate solely on
locomotion methods as the result of the NavMesh Search
Graph Path iteration. In order to understand how to use the
NavMesh geometry to control objects movement (i.e. for first

Fig. 5: The result of A* applied on the given Graph. Green means
origin, red means target
person movement control) I recommend reading Snook [3]
and Millington [4].
By noticing that the movement is generated by iterating on
the nodes of the Path list, and by knowing that each node in
the list represents a polygon in the three dimensional space,
a valid question could be raised: Regarding the next node,
where, spatially, is our agent heading to? In order to answer
this question we must further understand it’s geometry: it’s
made of Faces, Edges and Vertices. Knowing this we now
have three possible answers: the centroid of the Polygon (or
from all faces); the Polygon Vertices; and the middle of an
edge.
The decision of which spacial reference is to be used
comes down to the environment and to the agent’s ”way
of moving”. For this paper I assume that we are focusing
on Humanoid agents and intend to produce human-like
movements that are aesthetic believable. As a result of the
given statement we can straightaway discard the Polygon
Vertices as reference - as it would produce a non-human
like movement by ”surrounding” the environment (Figure
6). We could then, instead, use the polygon center, what’s
neither aesthetically good due to zigzag alike movement nor
optimal once it does not result into the shortest path, and in
the end could produce wrong paths by not acknowledging
obstructions (.a.k.a. wholes in the mesh - see Figure 7).
Eventually, it only rest to use the edge mid-points as the
most viable option by exclusion (Figure 8).
IV. MOVEMENT SMOOTHING
As seen previously, the middle-edge is the best reference
for movement. This alternative is prominent once no further
processing in the data (Path list) is needed to generate
movement. This approach is, nevertheless, neither aesthet-
ically accurate nor ”shortest path” optimal, what can be
understandable for small projects with agents moving in
a Robot alike way; but cannot be accepted once targeting
human alike movements. Accordingly, we must go one step
further and use the NavMesh Path as the input to our
Movement Smoothing algorithm what will return a new list
Fig. 6: Represented in blue arrows, the nodes of the Movement
List once using vertices as the node spacial reference
Fig. 7: Represented in blue arrows, the nodes of the Movement List
once using polygon center of mass as the node spacial reference
Fig. 8: Represented in blue arrows, the nodes of the Movement
List once using the middle-edge as the node spacial reference
(the Movement List) - replacing the Path list in matter of
movement.
A. Line of Sight
In order to smooth the Motion Path (movement projection
through the Movement List) one of the simplest techniques
is the line-of-sight approach [3] in which a line of motion
(agent’s forward vector) will be always looking at the furthest
visible middle-edge. In non-technical words, described as the
”horizon” approach, on which the destination of the next
movement point is equal to the furthest visible point in the
visible horizon.
With this method we pre-process (calculate just once -
instead of doing it iterative on real-time) our Movement List
by running a visibility-test algorithm through the NavMesh
Path. The line of sight method starts by creating an empty
Movement List on which the ﬁrst movement node is equal to
the current position of the agent (what can also be ﬁrst node

Fig. 9: The Line Of Sight Motion Path in blue arrows
in the NavMesh Path - depending on the implementation);
from this point on, on each following node in the path, a
line-of-motion algorithm (where simple Raycast can serve
the purpose) is applied in order to check for visible: in case
of a positive result the node is skipped (in order to smooth
the movement path) and the algorithm run further by iterating
through the further Path nodes until it finds either a node N
that’s not visible - so the method adds the node N − 1 as
the next in the movement list (represented by the red arrow
in the Figure 9), or the final path node.
This technique is not only limited to movement. It could
be also used in applications of agent recognition in which
one can test very quickly if two agents are seeing each
other by using this technique over a NavMesh Visibility
Path - being the polygons nodes ”connecting” both agents.
At the same time that the applicability of this example is
very narrowed this exemplification serves as an inspiration
over the possibilities that could be opened via these kind of
techniques.
B. Iterative Constraint Rays
In attempt to avoid the ”unnecessary” usage of the middle-
edges, what usually results in a longer Motion Path than
the one that would actually be required by a human-like
agent, and in order to be performance non-intensive on the
CPU, O’Neill on his publication [5] presented the Iterative
Constraint Rays technique - designed to run iteratively on
real-time.
Based on a ”Field Of View” approach O’Neill’s technique
uses the agent’s forward vector as the motion propel, the
vector is clamped to the Field Of View (or FOV) consisted
by the agent’s current position plus both vertices of the next
visible edge (as the white dashed arrows on Figure 10);
further, on a final tune, the forward vector clamped once
more, but now against the normalized od (agent’s origin -
destination point) vector represented by the green dashed
arrow on Figure 10. This define one look-ahead ”hop” on
O’Neill’s technique.
Although a single hop (iterates just over one node N on
the Path List) always provide a valid forward vector, the
algorithm was designed to run multiple iterations in order to
deliver accurate forward vectors. This technique provides a
shorter path than the Lines Of Sight approach and is pretty
straight forward to be implemented.
Fig. 10: The Iterative Constraint Rays Motion Path in blue arrows
Fig. 11: The Reactive Path Following Rays Motion Path in blue
arrows
C. Reactive Path Following
In an attempt to smooth the straight-lines robotic move-
ment as result of the Line Of Sight technique, and eager
to improving it’s performance by avoiding motion path re-
computation, Michael Booth from Valve [6] presented the
Reactive Path Following technique as a movement iterative
(real-time) approach on which the agent moves towards
a ”look-ahead” point along the NavMesh Path (just like
O’Neill’s approach) and makes uses of local obstacle avoid-
ance in order to ”react” to possible static (or dynamic) colli-
sion as the cause of the agent’s motion. In order to visualize
his technique via profane words, it could be represented as
the agent being a lego brick, on top of a skate board (being
the collision box) which has a string (or rope) attached of
length L (distance of our look-ahead) whereby we pull it in
direction to our next defined node of the NavMesh.
The low level aspects of this technique, being real-time
iterative, lies firstly on finding the look-ahead point - at
the beginning or after each time that the agent changes it’s
NavMesh node position - as being the next N + 1 non-
obstructed middle-edge node in the NavMesh Path (as the
result of the Line Of Sight technique - seen as the green
arrow on the Figure 11) which will serve as the forward
vector for it’s movement; and secondly, on the local path
avoidance, what generates a pseudo steering behavior by
calculation the reaction vector of the bounding box collision
(represented by the agent’s red bounding-box half on Figure
11) by adding this new vector to the forward movement.

Fig. 12: The Simple Stupid Funnel Motion Path in blue arrows
This technique has, one my eyes, one key advantage over
other kind of path smoothing techniques: it allows a ”cheap”
local avoidance approach for dynamic objects such as other
NPCs. As well, this technique was proofed in action once
all NPC actors in the game Left 4 Dead employ it.
D. Simple Stupid Funnel Algorithm
To finish our research over movement smoothing ap-
proaches, I’d like to introduce one of the most simple, yet
powerful solution: The Simple Stupid Funnel Algorithm.
Firstly introduced by Mononen [7] as an attempt to overcome
the standard middle-edge approach for path smoothing (what
makes him really sad), this technique can be describe as
simple as ”pulling tight a string” from the start to the
destination point (see Figure 12).
From a low-level perspective, Mononen uses, on it’s
principle, a similar approach to the one describe by O’Neill
[5] but instead having, what I called, FOV he has ”Funnels”.
By generating a Movement List, this technique can be
described (as well as the Line Of Sight) as a run once
technique. In order to generate the list Mononen’s algorithm
can be simplified to the following: An iterative algorithm
that ”walks” over all the nodes in the NavMesh Path list and
keep tracks of the leftmost (green dashed arrow on Figure
13) and rightmost (red dashed arrow on Figure 13) sides of
the funnel of the current movement node; by sequentially
iterating respectively over the left and right sides of the
following NavMesh Path nodes the funnel narrows up to
the point where the sides cross each other (second frame on
Figure 13) - at this point the last non crossed side vertex
get’s added to the movement list. After that the algorithm
iterates until it finds the final node in the NavMesh Path list.
V. MESH GENERATION
Up to this point we covered all the points to be discussed
in order to apply Navigation Meshes to Pathfinding and
Movement, but all of this was based in the assumption that
the Navigation Mesh Geometry was already there - either
created by an Artist or by a Level designer in a static way.
In this section we’ll briefly discuss about two complementary
methods of automatic generation for NavMeshes having as
it’s input the geometry of the Virtual World.
Fig. 13: Left picture: First Frame of the Algorithm iteration. Right
picture: Second Frame of the iteration showing the leftmost crossing
the rightmost resulting in a new node in the Movement List
A. Optimal Convex Partition
Inspired by Hertel-Mehlhorn algorithm (basically defined
as an iterative process of surface triangulation and removal
of non-essential edges)definition [8], Tozour [2] proposes
a technique composed of five steps: Merging Neighbor
Nodes; 3 -¿ 2 Merging; Culling Trivial Nodes; Handling
Superimposed geometry; Re-Merging.
Before starting with the process we must retrieve the
floor geometry by iterating through the entire input geometry
(usually the virtual world/level itself) and check which faces
have their normal facing up. In order to recognize slopes or
ramps we can check the angle between the normal and the
virtual horizon against a threshold to determine if the face is
a walkable surface or not. After this process we should have
our, still too high poly, geometry. In theory we could use it
as our NavMesh, but as seen in previous sections this is not
what we want due to the search space complexity.
The Merging Neighbor Nodes step consist, merely, the
application of the Hertel-Mehlhorn algorithm in which pairs
of adjacent polygons that share the same two vertices along
the shared edge are merged into one bigger convex polygon
(see 14). The 3 -¿ 2 Merging step includes the identification
of two adjacent polygons that share exactly one vertex (let’s
name them A and B for illustration) and the polygon adjacent
to both of those (let’s call C in this case), after identifying
those we must check if A and B share an parallel edge to
C sharing one vertex in common, if these conditions are
meet the merge process which consists of creating in A and
B a parallel virtual edge to C that will, first tesselate the
current geometry, and than remove C’s edge of reference
(see 15). Now, for the Culling Trivial Nodes step there’s not
much extra to say about it; we must cull geometries that are
too small in area in order to reduce the search complexity.
Almost there, with the complete NavMesh Geometry we
could, theoretically, use it for the Pathfinding, but obstacles
would still be included on it; this step is all about recursive
subdivision of a polygons that intersects with an obstacle
geometry, so after the subdivision (until certain minimum
polygon size) we check if the new polygon intersects with the
obstacle or not, in that case we simple remove the polygon
from the mesh. At the end we created a lot of unnecessary
polygons with the last step, we must than just Re-Merge by

Fig. 14: Visual representation of the Hertel-Mehlhorn algorithm
Fig. 15: Visual representation of the 3 -¿ 2 Merging algorithm
Fig. 16: On the left side a not-so-optimal automation using Tozour
[2] technique. On the right side, after the arrow, the proposed result
once applying Farnstrom [9] technique
applying the first step again.
B. Polygon Subdivision Algorithm
After analyzing and using Tozour [2] method, Fredrik
Farnstrom [9] found situations (Figure 16) on which the
previous method wouldn’t fit appropriately and with that
he proposes the Polygon Subdivision Algorithm technique
which accounts, primarily, for cutting the floor geometry
against the edges of obstructions.
In a nutshell, Farnstrom’s technique is composed of eight
main steps: (1) Separating the ground mesh (floor) and the
obstruction meshes (see Figure 17); (2) Merge all polygons
within the respected meshes in order to reduce the data; (3)
Merging (or fusing) together overlapping and nearby vertices
aligned polygons (in order to account for stairs steps, for ex-
ample); (4) Subdivide the floor mesh with its own extrusion
upwards and merge in order to account for obstacles (such as
chests, ...); (5) Extrude downwards the obstruction mesh in
order to account for too low, unreachable, places (see Figure
18); (6) Subdivide the ground mesh with the obstruction
mesh, in order to remove obstruction areas, and merge;
(7) Fuse ground mesh polygons; (8) Remove disconnected
polygons.
Fig. 17: A ground polygon being ”cut” along the obstruction
intersection with the floor
Fig. 18: Obstructions are being extruded (b) to below in order to
remove unreachable areas (d)
VI. DISCUSSION
So far in this paper we have seen all the methods and tech-
niques involved in the creation and utilization of NavMeshes.
The Pathfinding over the NavMesh nodes leverages us a
Global locomotion with static object collision; usually move-
ment approaches (with some exceptions) do not account for
local motion and dynamic collision and therefore this must
be acknowledge via other methods of steering or dynamic
collision.
In regards to the Graph Search we just discussed and
described one Graph Search per virtual world, but this is
not (and should not) always the truth. In order to reduce the
search complexity and avoid sections of the world that are
not usually accessed (i.e. some locked rooms) we can make
use of multiple interconnected Navigation Mesh Graphs on
which a node in the hierarchy would contain the ”portal”
information by referencing the next node of another Graphs.
Aside of this, in regards of motion, usually the radius of
the agent is included in the movement algorithm in order
to avoid corners by retracting (shrinking) the edges used
for motion. As well, for dynamic collision an approach that
could provide us the best results would be the application of
the Simple Stupid Funnel Track with the steering behavior
described in the Reactive Path Following technique. Another
solution for the given problem would be the creation of a
local 2D ”fine” grid that follows the agent on which an A*
algorithm would be applied.
Another important topic that wasn’t covered significantly
in this paper is the possibility of encoding information in the
NavMesh polygons. The information stored in the polygons
can differ from the kind of terrain (in order to dictate steps
sounds or animations to be played - like climb, swim, walk,
...) to gameplay informations (i.e. in this region the agent
can heal itself).
In order to all of this to work, our NavMesh geometry
must be ”optimally” created. In this paper we briefly saw
two of the main techniques applied for automated generation
of NavMesh geometry. Although this being a feature that
almost any game engine (for example) has, not all game
developers use due to the fact that it usually does not gives
enough freedom to the level designers (who usually want
to either fix corner cases or remove regions that shouldn’t

be walked). In order to avoid this we have three common
escapes: (1) the level designers could create some invisible
geometries and place on top of the world geometry; or (2)
the virtual world geometry encodes some information that
the automatic generation needs to take in account - what
usually does not work due to the fact that the level designer
would stop the 3D Designer workflow all the time to change
NavMesh encodings; and finally (3) the custom generation
of NavMesh geometry via visual helpers which could, for
example, define the boundaries of the virtual world and be
used to tessellated the navMesh geometry. At the end, this
is the part that most differ from application to application
and cannot be set in stone - just think that we could have a
game in which all agents walk on the walls and everything
discussed so far about automatic generation could be thrown
partially away.
Finally, usually though as being a ”virtual” world only
approach, NavMeshes could, theoretically, be used for vir-
tual world approaches on which we have a previously the
topological information of the place (via blue-prints, satellite
information or drones scanning the area) which we would use
to leverage path planing to our robot (for example). I could
totally see this working with Mars Rover for example after
that a Mars satellite would have scanned all Mars surface.
VII. CONCLUSIONS
Navigation Meshes are one example that three dimensional
Path Planning does not necessarily needs to involve complex
3D Math. We can achieve 3D movement in a 3D environment
by applying familiar 2D algorithms due to the 2D nature of
the Search Graphs. Not to forget, the NavMesh geometry
is just a mean to achieve the Search Graph, what’s the one
that usually used as offline input of the simulation. With this
technique we, at the same time, reduce the complexity of
the search space of 3D worlds and do not limit the freedom
of movement. As seen, the NavMesh geometry should be
generated with the approach that feats the nature of the
application being developed.
REFERENCES
[1] N. J. R. B. Hart, P. E.; Nilsson, “A formal basis for the heuristic
determination of minimum cost paths,” IEEE Transactions on Systems
Science and Cybernetics SSC4, vol. 4, no. 2, pp. 100–107, 1968.
[2] S. Rabin, Ed., AI Game Programming Wisdom. Charles River Media,
2002, vol. 1.
[3] M. A. DeLoura, Ed., Game Programming Gems. Charles River Media,
2000, vol. 1.
[4] I. Millington, Artificial Intelligence for Games. Elsevier, 2006.
[5] J. C. O’Neill, “Efficient navigation mesh implementation,” Journaal of
Game Development, vol. 939, no. 9, pp. 71–90, March 2004.
[6] V. Inc. Ai systems of l4d. [Online]. Available: https://developer.
valvesoftware.com/wiki/AI Systems of L4D
[7] M. Mononen. Simple stupid funnel algorithm.
[Online]. Available: http://digestingduck.blogspot.de/2010/03/
simple-stupid-funnel-algorithm.html
[8] J. O’Rourke, Computational Geometry in C, 2nd ed., M. A. DeLoura,
Ed. Charles River Media, 2000.
[9] S. Rabin, Ed., AI Game Programming Wisdom 3. Charles River Media,
2006, vol. 3.

NavMesh

More Related Content

Viewers also liked (20)

Similar to NavMesh (20)

Recently uploaded (20)

NavMesh