AI_ Fixing Pathfinding Once and For All

8/7/2019 AI_ Fixing Pathfinding Once and For All

http://slidepdf.com/reader/full/ai-fixing-pathfinding-once-and-for-all 1/36

Game/AI

« Collaboration | Main | Why "AI Accelerators" Will Never Happen »

July 26, 2008

Fixing Pathfinding Once and For All

I normally do everything I can to avoid saying things that could be interpreted as a criticism of other games or developers

in the industry.

But in this case, I had to make a bit of an exception.

I need to talk about some problems we face with pathfinding. In order to prove that these problems still exist, I felt the

need to make this video ... which will hopefully be taken in the humorous and lighthearted spirit in which it was intended

All of these clips were rec orded over the last week with the latest, most-recently-patched version of each game.

As you can see, we're still a long way from having robust pathfinding across the

board ... and it's even a problem in some million-unit-selling, AAA-quality titles.

It's not necessarily a universal problem. Many modern games do have high-quality pathfinding, and pathfinding often works

well in some of the games shown here.

But there are still too many games that do pathfinding the same way that games did in the 1990s.

(Note: The only reason you see lots of PC role-playing games here just comes down to convenience. These are the games I

had installed at the time. The problem isn't specific to any genre or platform by any stretch of the imagination; there are

plenty of console games with sim ilar issues.)

To the best of my knowledge, most of these games use waypoint graphs for pathfinding. I think that's the reason for

several of the pathfinding issues you see in this video, and many of the pathfinding problems we face in the industry as a

whole.

3/22/2011 Game/AI: Fixing Pathfinding Once and…

www.ai-blog.net/archives/000152.html 1/



I believe waypoint graphs are now obsolete. This article explains the limitations of the waypoint graph approach and lays

out a five-point argument for a better approach.

There was a time when it made sense to use waypoints for pathfinding. Back in the 1980s and 1990s, we were working

under serious technical constraints and we had to cut a lot of corners.

But we're a multi-billion-dollar industry now. Our target platforms have multiple cores and ever-increasing amounts of

memory, and we can afford to do pathfinding correctly.

There's a saying among AI developers in the industry: "pathfinding is solved." We have good approaches to every

pathfinding problem modern games face. We just don't always use them.

There's no reason not to have pathfinding that works in every game, every time.

Hit the jump for a detailed explanation.

Why Waypoints Aren't For PathfindingLet me show you what a typical waypoint graph looks like. Here's a small piece of Stormwind City in World of WarCraft:

Figure 1. Part of Stormwind City in World of WarCraft

Here's what a typical waypoint graph might look like in that area.





Figure 2. The same area annotated with a waypoint graph

There's another way to do it, and it involves using convex polygons to desc ribe where AI characters can travel. This

representation gives AIs a lot more information about the world around them and supports much more intelligent

decision-making.

Here's what a navigation mesh looks like:

Figure 3. The same area annotated with a navigation mesh

Here, then are the five big reasons why waypoint networks fall short.

1. Some kinds of game worlds require a ridiculous number of waypoints.

Large, open areas usually require tons of waypoints sprinkled liberally throughout the game world to achieve adequate

movement.

A navigation mesh, on the other hand, usually only requires a couple of big polygons for these kinds of areas ... which

you can pathfind through that much more quickly.





Here's an example.

The image below shows a town in World of WarCraft called "Halaa." This is a relatively large, mostly open area that NPCs

need to be able to navigate through. I've edited out a few details, such as the flag and the fountain in town, for the sake

of this example.

Figure 4. The town of Halaa in World of WarCraft, seen from above (slightly modified)

With a waypoint-based system, we need to place a lot of waypoints to get full coverage. Even then, our NPCs will end updoing a lot of zigzags during movement unless we specify a lot more waypoints than I've shown here.





Figure 5. Halaa with a waypoint graph

With a navigation mesh, on the other hand, we can describe the same area with a handful of convex polygons:

Figure 6. Halaa with a navigation mesh





The simplicity of the navigation mesh means we don't have to search as many nodes when we call our pathfinding

algorithm at runtime, and pathfinding will be faster as a result.

2. They make characters "zig-zag" as they move.

Waypoint graphs force your characters to stick to the graphs you create. This means that your characters are effectively

on rails, and will almost never take the optimal path from A to B ... because the most direct path will almost never match

the graph.

That causes unnatural pathfinding artifacts -- in particular, characters artificially "zig-zagging" left and right as they walk.

Here's an example. Let's say we want a character to walk from A to B:

Figure 7. Two points in Halaa

Here's what the path would look like with the waypoint graph I showed you earlier.





Figure 8. Navigating from A to B using the waypoint graph

As you can see, our AIs will be turning a lot while they walk along the yellow path.

Ideally, after we c reated the path, we could somehow adjust it to make it smoother ... perhaps by creating a Catmull-

Rom spline along the path points.

The problem is, waypoint networks don't have any information about anything outside the network, and that makes it

impossible to do path-smoothing and adjustment safely and reliably.

How can you create a spline if the spline is outside of the waypoint graph, and actually following its curves might make

you fall off a bridge?

You might think there has to be some simpler way to make a path. Unfortunately, with waypoint graphs, there isn't.

Again, if we deviate outside of the waypoint graph even a little bit, we could easily end up falling off a cliff or bumping

into a wall. We just don't have any way of knowing, since the graph doesn't have any of that data.

So in order to stay safe, we have to take the most pessimistic view possible, and stay on the graph at all times.

The navigation mesh path, on the other hand, would look like this:





Figure 9. Navigating from A to B on the navigation mesh

Since we know where a character can safely walk, we can smooth out the path in any way we like, so long as the

smoothing keeps the path on the navigation mesh.

("Oh," I hear you say, "but I can just add more links to my waypoint graph to smooth everything out! I'll connect all the

nodes in the whole town if I know an NPC can walk between them in a straight line."

"But that gives you exponential explosion," I reply ... "You're talking about 40 or 50 extra links in this example alone. Thenumber of connections you'll need between all the nodes approaches O(N^2) as the size of the area increases."

"OK," I hear you say, "In that case, I'll just mark each area between any set of 3 mutually adjacent waypoints as 'open' so I

know my AIs can walk anywhere in that area."

"That makes a polygon ... and you've just created a navigation mesh," say I).

The fact that navigation meshes tell us exactly where our characters are allowed to travel means we can easily use

splines to smooth our paths. All we need to do is make sure our splines stay inside the navigation mesh.

Going back to our Stormwind City example, here's a waypoint path (red) and a smoothed path on a navigation mesh

(blue).





Figure 10. A waypoint path (red) and a smoothed navigation mesh path (blue)

3. They don't allow path correction. That makes robust dynamic obstacle avoidance

difficult, if not impossible.

Waypoint graphs don't have any data about anything outside the graph. They don't know which areas characters can

legally walk on even one inch outside the graph.

That makes it impossible for pathfinding systems to modify waypoint paths to deal with dynamic obstacles robustly.

Let's imagine there's a large, heavy crate on the bridge in Stormwind City.

With a waypoint graph, we're sc rewed -- if the crate overlaps the waypoint graph, we have no idea whether to go around

it to the left or the right, or if our path is blocked completely and we need to take a major detour. We could always

guess, but if we make the wrong guess, we'll fall off the bridge and end up in the water.





Figure 11. A large, immovable crate on the bridge

With a navigation mesh, though, it's a lot easier, since we know what areas we're allowed to walk in. We do a bit of

raycasting against the barrel and adjust our path around it, keeping our path (and ourselves) safely on the navigation

mesh.

Figure 12. Navigating around the crate

Sure, you can address this in a waypoint graph, too, by dropping down tons and tons of waypoints until your waypoint

graph is as thick as grass (and your pathfinding as slow as molasses).

I don't know about you, but I'd rather run my A* search over one big polygon than several hundred waypoints.

4. They don't work robustly for characters that move differently.

Waypoint graphs tend to work poorly for c haracters with different heights, widths, turn rates, and other pathfinding

parameters. This means it's usually impossible to use a single, unified waypoint graph for all the different types of units in

your game.

When we think about AI pathfinding, we tend to think in terms of humans navigating around in a game world.

But AI systems need to control lots of different kinds of units -- tanks, planes, ships, hovercraft, motorc ycles, orc s,

goblins, dragons, lumbering giants, flying and hovering creatures, and so on. In many cases, units need to do pathfinding

differently depending on their size, shape, and movement capabilities. A good pathfinding representation should handle

all of them.

Here's an example. Let's say we have a conc rete bunker out in the desert with a few sandbags around it.





Figure 13. A bunker in the desert

If we have a human soldier, he can run along right next to the sandbags (the red arrow in the image below).

A Panzer tank, on the other hand, has to drive much farther away from the sandbags to avoid a collision (blue arrow).

Figure 14. The closest possible paths that a human soldier (red) and a tank (blue) can take around the sandbags

With a waypoint approach, you can't handle this robustly with a single representation. You need to use totally separate

waypoint networks for the tanks and the soldiers. Add a new "motorcycle" unit, and now you need a third network. And

so on for every different type of unit that has different movement capabilities.

With a navigation mesh, on the other hand, it becomes much easier.





Figure 15. Part of a navigation mesh around the outside of the bunker

Notice the two light green edges emanating from the c orner of the sandbags in the image above. Since we know that a

soldier has a collision radius of 1 meter, and a Panzer tank has a radius of 5 meters, it becomes trivial for us to build two

different paths using the same mesh. We just compute the path along the sandbags, and then push it either 1 meter or 5

meters away from the corner, respectively, depending on whether we're doing pathfinding for a soldier or a tank.

Figure 16. Part of a navigation mesh around the outside of the bunker

Here's another example. Let's say we have a soldier on a motorcycle. Unlike human soldiers, motorc ycles can't turn on a

dime while they're moving.

In the example below, it's obvious that the motorc ycle rider can drive safely from his current position to the room at the

top (red line), but cannot turn into the hallway on the r ight since the angle is too sharp (orange line). Whatever

pathfinding representation we choose should be able to figure this out, too.

Figure 17. A motorcyclist can go into the room at the top (red) but not the room on the right (orange)

With a navigation mesh, this is relatively easy to do. We just test the turn angles and distances as we're doing the





pathfinding and reject any paths that require steep turns over short distances.

With a waypoint approach, on the other hand, it's essentially impossible. At a minimum, we'd need a completely separate

waypoint graph for soldiers on motorcycles, since we can't use the same graph that soldiers on foot are using. Adding an

entirely new graph like that for every unit with different pathfinding capabilities gets very cumbersome.

5. They don't have enough data to support what your AI needs beyond pathfinding.

AI search spaces aren't just for navigation. AIs need to be able to use the pathfinding data to tell them how to move in

the world.

A game character needs to c onstantly query the pathfinding system and ask: is it OK if I move here? How about over

here?

Games are increasingly moving to animation-driven movement systems that give animators control over the position of

game characters. That means that in order to know what the results will be if we play animation X, we need to figure out

where the character will be when X is finished, and whether that location is inside a wall, hanging over a cliff, or in some

other location the level designers don't want him to be.

Here's an example. The swordsman below has four moves: a left strafe, a right strafe, a backstep, and a big flying leap

into the air that sends him up 20 feet and then has him land 8 feet in front of where he started.

Figure 18. A swordsman with four animations that contain translation

In order to make sure my swordsman doesn't end up slamming into a brick wall when he leaps or strafes or backsteps, I

need to test the predicted end position of each of these animations against the navigation mesh.

Yes, it's possible to use your collision system to do raycasting. That will often give you useful information, and for

dynamic physics objects in the game world, it's usually the only way for AIs to find out about them.

But raycasting can be expensive, and when you only care about the static game world and not the dynamic physics

objects, it's faster and easier to query a navigation mesh.

Although I can use raycasting to tell me if there's a wall between me and point (X,Y,Z), the collision system can't tell me





if the swordsman will land in a position that the level designers actually want characters to walk in ... only a navigation

mesh can tell me that.

If you're still not convinced after all of that, let me try to address any remaining concerns you might have by answering

common questions about waypoint graphs and navigation meshes.

Q & A

But isn't it slower to do pathfinding on a navigation mesh?

Not at all. A navigation mesh is a graph, just like a waypoint graph is, and the core pathfinding routines are very similar.

The differenc e is that a navigation mesh has a polygon associated with each graph node.

The image below shows the graph connecting the nav mesh polygons.

Figure 19. An illustration of the graph (red) underlying a navigation mesh

Whenever you run the A* algorithm for pathfinding, you're always running it on some kind of a graph, whether it's a

square grid, a waypoint graph, a navigation mesh, or what have you.

In most cases, navigation meshes have performance similar to waypoint graphs. In cases where they cover the same area

with fewer nodes (such as Figure 6), a navigation mesh can actually be significantly faster.

But don't navigation meshes take a lot more memory than waypoints?

If done correc tly, no.

Navigation meshes are a very simple and compact representation. In general, a nav mesh will only require a tiny fraction

of the memory required by the underlying rendering geometry for the static game world. A navigation mesh is much

smaller than a collision mesh, since it cares about fewer surfaces (it ignores walls, ceilings, and other unwalkable

surfaces) and uses a smaller number of much larger polygons to cover a given area.





A navigation mesh tends to use a few more points for each graph node than a waypoint graph in the worst case. And in

some cases, such as the town in Figure 6, a navigation mesh can actually be smaller because it's a simpler representation.

Most of the examples you showed were role-playing games. Why don't I see the same

kinds of problems in first-person shooters?

The problems are still there in many first-person shooters, but they're harder to spot due to the nature of the gameplay.

- Most AIs don 't live long enough to let you spot the flaws in their pathfinding.

- AIs will usually stop and shoot the moment they have line-of-sight to you, so their paths are a lot shorter.

- In many single-player FPS games, AIs don't move very much, and will attempt to snipe you from a relatively fixed position.

- A lot of modern FPS games provide AI sidekicks who will kill the enemy AIs so quickly they don't have time to move very

far.

Here's an example from Half-Life 2. With a little bit of experimentation, it's easy to see that the guard on the stairs is

locked to a single, linear waypoint path that runs direc tly up and down the center of the stairs. The guard still ends up

looking competent since he can shoot at you whenever he can see you.

When you take away ranged weapons and force characters to use melee weapons -- as with some of the Covenant

soldiers in Halo, the Icarus stealth assassins in F.E.A.R., or the Metroids in a Metroid Prime game -- waypoint graphs are

suddenly a much less attractive option (which is part of the reason all three of those games used navigation meshes

instead ...)

Look, I understand everything you said, but designers need to be able to put down

cover points, patrol paths, and so on. That's just essential for creating the AI in our

games.

Of course! You can still do that, even if you're using a navigation mesh.

The key is to separate the two representations. You use one representation (a nav mesh) for the pathfinding and





navigation, and another (designer-placed points) tell the AI how to use the world.

A navigation mesh doesn't prevent you from doing any scripting. It simply provides extra information for your AIs for when

they need to navigate more autonomously.

Here's an example. We have a patrol path (purple) for some guards patrolling around town and a special marker for an old

man who likes to fish in the moat a few times a day (red). The cover points (yellow) represent points where characters

could take cover around corners in FPS-style magic duels between the mages and warlocks of Stormwind City.

Figure 20. Various terrain markers (AI hints) and a navigation mesh

OK, but isn't it a lot of work to place a navigation mesh?

In general, placing a navigation mesh by hand is not much more labor-intensive than placing a waypoint graph. In both

techniques, the amount of time you spend creating the search space representation is a fraction of the time you spend

testing it in-game.

From my experience, it takes 1-3 hours to create a navigation mesh for a medium-sized level in an FPS game.

Creating a navigation mesh editor is relatively simple. All you need is the ability to drop vertices into the game world,

select them, and specify that they represent a polygon in the navigation mesh. You c an determine the connectivity of

the navigation mesh based on which vertices are shared between adjacent polygons.

Also, there are some middleware solutions, such as xaitment, NavPower, PathEngine and Kynapse, that can handle both

the nav mesh construction and runtime pathfinding aspects for you. All of these are becoming increasingly robust and

viable solutions.

What if I want to have AIs walk up and down stairs? My designers don't want to have

to lay down a nav mesh polygon for every single step in the staircase.

A navigation mesh just represents an area that an AI can walk in. It doesn't replace a collision mesh -- your NPCs will still

use the underlying collision system for all their in-game collision.

You should be able to safely cover the entire stairway in a single rectangular navigation mesh polygon.





Can't I just give each point in my waypoint graph a radius, so I have circles instead

of points? That gives me a representation of what areas are walkable. That's how

they do it in robotics, too ...

That approach can work in some cases, but most areas in videogames have a lot of human architecture, full of angular

streets and buildings. Circles don't represent these kinds of spaces very well, and it's difficult to achieve the same level

of coverage that you can get with polygons.

Here's an example of the circle-based approach in Stormwind City:

Figure 21. Extending the waypoint approach with circles

(Quick anecdote: When I worked on the MechWarrior 4: Vengeance team, we found out the hard way that the circle-based system that worked so well in outdoor areas really didn't work so well when we suddenly tried to put it to use in

urban areas. The team eventually made it work, but a lesson was learned: circles and urban environments don't mix!)

Also, having corners is important. In the case of the desert bunker Figure 16, we can use the corner of the navigation

mesh to create different paths for units with different shapes, sizes, and movement capabilities, such as a soldier and a

tank. Circle graphs don't have "corners," so it becomes much more difficult to c reate correc t paths for different kinds of

units.

My game already has a collision mesh. Can't I just use that for pathfinding?You can try, but it's not a good idea.

A collision mesh is optimized for collision, not for pathfinding. As a result, it's going to have a lot more polygons than you

need for pathfinding, and your search function is going to be slower.

For example, your collision mesh might have 1000 polygons on a cobblestone street that a navigation mesh would

represent with 1 rectangle, and 50 polygons on the roof of a building that a navigation mesh might not include at all

(since our characters would presumably never walk on the roof).

Also, part of the advantage of a navigation mesh (as with any search space representation) is that it doesn't just tell you

where your characters can travel; it also tells you where designers want them to travel.





If you let your designers create navigation meshes by hand, you give them the ability to tell the game "don't ever send AIs

here. I just don't want them to go there because it's not appropriate for this game." That's not the kind of information

you can ever get from a collision mesh.

All the examples as presented show the nav mesh as a 2D projection onto the space.

How would you handle a case like a bridge over a road, wherein you could go over

or under. Or a building with multiple floors?

Navigation meshes handle those cases very elegantly. Here's an example of what part of a nav mesh in Shattrath City in

World of WarCraft might look like (for simplicity, I've omitted the parts of the nav mesh on the far side of the bridge).

Figure 22. Part of a navigation mesh over and under a bridge in Shattrath City

In a navigation mesh, each polygon also typically stores a "height" parameter indicating how much vertical clearance that

is available for that polygon. So the polygon that you see passing under the bridge would know that it only has 7 feet of

clearance, and units more than 7 feet tall would know that they c annot use those polygons.

In the case of a multi-storey building, each floor can have its own navigation mesh polygons, connected with additional

polygons in the stairwells (elevators are a bit trickier, of course).

I don't believe in a one-size-fits-all approach. Different games require different

representations for pathfinding.

If you're making a strategy game that's entirely 2D, then an approach based on a grid is usually better, since grids give you

fast random access to any cell.

Otherwise, the navigation mesh really is the best approach we've found for robust pathfinding and terrain reasoning in

truly 3D worlds.





Suppose I were interested in implementing navigation meshes in my game. Has

anything been published to help me figure out how to build the meshes, do

pathfinding on them, and optimize them for my game?

Here are the ones I'm aware of:

"Simplified 3D Movement and Pathfinding Using Navigation Meshes" by Greg Snook (Game Programming Gems)

"Polygon Soup for the Programmer's Soul: 3D Pathfinding" by Greg Hjelstrom and Patrick Smith (GamaSutra.com)

"Building a Near-Optimal Navigation Mesh" by Paul Tozour (AI Game Programming Wisdom)

"Efficient Navigation Mesh Implementation" by John C. O'Neill (Journal of Game Development, March 2004)

"Search Space Representations" by Paul Tozour (AI Game Programming Wisdom 2)

"A Fast Approach To Navigation M eshes" by Stephen White and Christopher Christensen (Game Programming Gems 3)

"Choosing a Relationship Between Path-Finding and Collision" by Thomas Young (Game Programming Gems 3)

"Improving on Near-Optimality: More Techniques for Building Navigation Meshes" by Fredrik Farnstrom (AI Game

Programming Wisdom 3)

"Smoothing a Navigation Mesh Path" by Geraint Johnson (AI Game Programming Wisdom 3)

"Dynamically Updating a Navigation Mesh via Efficient Polygon Subdivision" by Paul Marden and Forrest Smith (AI Game

Programming Wisdom 4)

"Intrinsic Detail in Navigation Mesh Generation" by Colt McAnlis and James Stewart (AI Game Programming Wisdom 4)

"Navigation Mesh Generation: An Empirical Approach" by David Hamm (AI Game Programming Wisdom 4)

"Navigation Mesh Generation in Highly Dynamic Worlds" by Ramon Axelrod (AI Game Programming Wisdom 4)

"Crowds in a Polygon Soup: Next-Gen Path Planning" by David Miles

(http://www.navpower.com/gdc2006_miles_david_pathplanning.ppt)

Note: Please e-mail me if you're aware of any other articles that should be on this list.

How many games have actually used navigation meshes successfully?

Here's a short list:

Halo 2

Halo 3

First Encounter Assault Recon (F.E.A.R.)

Counter-Strike: Source

Metroid Prime

Metroid Prime 2: Echoes

Metroid Prime 3: Corruption

Jak and Daxter: The Precursor Legacy

Jak II

Jak 3

Uncharted: Drake's Fortune

Scarface: The World is Yours





... and many more.

So there you have it: all the cool kids are doing it.

OK, maybe it works for you, but we used waypoints in all of our previous games, and

they worked fine.

Like they say, if it ain't broke, don't fix it ... and we haven't run into any of the

problems you're talking about.

Look at the big picture. Think 10 or 20 years down the road.

In that kind of time frame, do you think your games might have lots of different types of AI-controlled characters with

different shapes, sizes, and movement capabilities?

Will players have AI henchmen that they expect to be just as intelligent as themselves?

Will your game worlds be significantly larger, more complex, and more dynamic than they are today?

Will you have huge crowds of AI characters -- so many that just using simple steering and obstacle avoidance are no

longer adequate to make them coordinate with each other effectively?

Will your games have realistic physics and huge amounts of physically-simulated objects, and will players be able to use

the physics to mess with the AI characters in every way imaginable?

Will players be able to change the game world until it's virtually unrecognizable?

Will there be AIs in multiplayer that are expected to pass for human players?

There's no way to know what games will look like decades in the future, but it's clear that we're going to need much

more advanced AI. Part of that will require us to give game characters the data they need to reason about theirenvironment, find optimal paths, and deal robustly with complex, ever-changing game worlds.

Posted by PaulT at July 26, 2008 01:00 PM | TrackBack

Comments

Wow, great article! It was worth the wait :-)

To be fair, while the problem is technically solved, WoW has never really made it a priority to ship solid AI -- so it's almost

a bit unfair to pick on it. Sure, it'd be cool if Blizzard hired an experienced navigation mesh programmer, but would the

different show in the average case?

If anything, WoW is a rather depressing example that games can make huge amounts of money without good pathfinding.





alexjc

AiGameDev.com

Posted by: alexjc at July 26, 2008 11:08 AM

What game is that with the shotgun and the enemy stuck by the crate? (The 2nd clip in...)

Thanks! =)

Posted by: Eric at July 26, 2008 03:09 PM

Eric, I'd prefer not to mention any of these specific games by name, since I want the emphasis to be on the AI

pathfinding problem across the industry, rather than picking out the flaws in specific games (P.S. check your e-mail).

Posted by: Paul T at July 26, 2008 03:40 PM

All the examples as presented show the nav-mesh as a 2d projection onto the space. How would you handle a case like a

bridge over a road, where in you could go over or under. Or a building with multiple floors?

Posted by: PaulB at July 26, 2008 03:59 PM

Wonderful article. Really nailed it into me that Navmeshes are great. I now know more about them then I did before, and

I thought I knew how they fully worked :)

Now I wait for the article in 10+ years decrying navmeshes and a inevitable need for something better (or simply improved

navmeshes!). Hopefully, however, Navmeshes are a good solution for a long while, much more so then waypoints at least

:D

Posted by: Andrew at July 26, 2008 05:07 PM

[PaulB]

> All the examples as presented show the nav-mesh

> as a 2d projection onto the space. How would you

> handle a case like a bridge over a road, where in

> you could go over or under. Or a building with

> multiple floors?

Thank you, Paul; good question!

Scroll up a bit -- I've added this question to the list and answered it with an example image.

Posted by: PaulT at July 26, 2008 05:41 PM

> [Andrew] Wonderful article.

Thanks, Andrew! :)


Seems to me waypoints aren't in conflict with navigation mesh, they're just an alternative or simplication to raycasting.

Also, in both cases you would need a solution for points that you have to jump or climb or fall (or give up) to intelligently

follow the player, which you seem to have exploited in a couple examples.

Posted by: Henrik at July 27, 2008 12:24 AM





This is mostly why I no longer play against AI's. Its just so frustrating when they are incapable of handling the

environment. I now play TeamFortress2 almost exclusively since humans at least look convincing when navigating the

maps. Its honestly quite depressing.

Posted by: Ian at July 27, 2008 04:23 AM

> [Henrik]

> Seems to me waypoints aren't in conflict with

> navigation mesh, they're just an alternative or

> simplication to raycasting.

You can always use waypoints for giving AIs explicit paths -- for example, scripting an AI's movement during a cinematic

sequenc e. That's possible (and often necessary) regardless of what pathfinding representation you use, and it's not what

I'm discussing in my article.

What I'm criticizing is the use of waypoints for pathfinding. Technically, yes, it's "just an alternative," but it's generally an

inferior alternative, since it's not a robust approach to pathfinding and causes all the problems I discuss above.

> [Henrik]

> Also, in both cases you would need a solution

> for points that you have to jump or climb or

> fall (or give up) to intelligently follow the

> player ...

Yes, that's true regardless of what representation you use for pathfinding.

Posted by: PaulT at July 27, 2008 08:22 AM

Excellent article and great video Paul.

Posted by: RCornelius at July 27, 2008 11:34 AM

I too would like to know what game is in the stuck on c rate clip.

Posted by: Balder at July 27, 2008 12:26 PM

I'm working on my first 2D web based action RPG.

I'll probably be using a waypoint system for pathing because it's easier to program.

What level of math is required to implement something like this? Calculus?

I'm thinking of some type of grid-based waypoint system for my simple flash based game.

Posted by: micsun at July 27, 2008 01:13 PM

A good number of the problems with waypoints that you've shown are due to programmer and/or designer error; many of

them aren't even that difficult to fix.

Having worked on games that use both, I can safely say that (much like any feature in games) it ultimately comes down to

how well the system is implemented.

I've worked with mesh system where the AI pathed unnaturally, cutting all corners as close as possible, generally running

in a straight line between them. I've also has to deal with breaking up the mesh appropriately any time a table, chair,

crate or other obstacle was placed or moved. In complex obstacle filled environments, like building interiors, a mesh

based system starts to become unwieldy. You may even end up with a separate avoidance system within the system to





avoid needing the create "islands" around these obstacles.

I've also worked with a waypoint/node based system that handles nearly every bug you mentioned above, including

smooth pathing between distant nodes. It doesn't handle every case (nor does the navigation mesh system); but it does

handle all of the cases that it needs to.

In short, use the right tool for job and heed the fact that navigation meshes are not always the right tool, even in fully

interactive 3D environments.

Posted by: Dreyruugr at July 27, 2008 01:27 PM

The majority of issues you seem to point out as issues in waypoint systems are issues in Navigation Meshes as well.

AI doesn't have to zig zag with a waypoint system and any good implemented systems it doesn't.

For AI to handle flying over ledges like you shown requires a spec ial case for your navigation mesh (which can be added

just as fine to a waypoint system).

The advantage of a navigation mesh is purely it can requires less data to describe the same thing in waypoints. Which can

simply be shown by as the density of your waypoints approaches infinity your waypoints get closer and closer to

describing your navigation mesh. This is due to navigation meshes are just closed waypoints. As a result, any additional

issues in a waypoint system over a navigation is either due to density or implementation issues.

Density can be handled by a hierarchical system. Also waypoints handle adding of dynamic blockers can be simpler than

navigation meshes.

BTW I do prefer navigation meshes in general, but they aren't some magical solution since the properties are essentially

the same except with some slightly different handling of situations.

Posted by: Cryect at July 27, 2008 03:11 PM

I think that at least for anything with NPC's trying to engage the player (pretty much anything that is not a strategy game)

extra navigation maps for the AI will fall by the wayside. Wether or not the AI can walk there/take cover (and against

what) will be handled by the AI analyzing it's surroundings.

An AI would be prepped with data about it's model (height, width, length, mass, appendages, weapons (if applicable also

data about it or methods to determine weapon characteristics), what have you), it's objective (flee in terror, guard,

engage on sight etc), characteristics (ie use cover, spray and pray, take aim, feint, sneak) and data abouts its (or as for

weapons methods to gain data by trial and error) surroundings (Tiny bridges out of teakwood have a weight capacity of x,

Cover out wood are useless against my weapons, mist disables my weapons (That's somethings the AI should notice after

thr first shots and avoid after that)

Posted by: Bleh at July 27, 2008 03:57 PM

I hear what he is saying, and navigation meshes are a superior solution, but most of the problems he shows in the video

can just as easily happen in games that use navigation meshes.

Posted by: LittleBrain at July 27, 2008 04:52 PM

Navmesh is definitely another solution but it comes with its own problems. Having worked on a large GTA scale game that

used navmesh that got so complicated it was almost like building the world twice. Once for the visibile geometry and

then almost as long again to clean up the navmesh around it.

I still think there's a better solution than either of them... course if I knew what it was I'd be a rich man :P

Posted by: Jasta at July 27, 2008 05:00 PM





Fantastic article. I know only basic programming yet everything made perfect sense. Thanks for enlightening us all, the

field needs more people like you.

Posted by: Jon at July 27, 2008 05:43 PM

I for one think the Navigation M esh is superior to the traditional waypoint method. Is it the end of the line? No, the nav.

mesh has it still has it's on inherent problems, but overall it is the better system for the time being.

Posted by: Free Xbox 360 Elite at July 27, 2008 06:51 PM

That's a really good article. We chose to use Navmeshes because each character can quickly determine the amount of

free space around them in any direction. This is useful when coordinating large numbers of characters without having

one character push another character into a wall or off of a ledge. Typically collision probes are too expensive for every

AI character to use, but with the Navmesh it's very fast to get this information given the polygon that the character is

starting in.

One of our GDC talks (http://www.navpower.com/gdc2006_miles_david_pathplanning.ppt) from a few years back also gives

some approaches for automatically generating Navmeshes and modifying them at runtime (no audio with the slides, but

hopefully somewhat useful).

Posted by: DavidM at July 27, 2008 10:47 PM

A great article, I wish the gaming industry would take this with open arms, rather than keeping them shut on these

things.

One question tho, how would path-finding mesh work on enviroments where you and AI can move in 3 dimensions? (For

example a space-ship-shooter type of game.)

PS.

Second game in the clip I haven't seen, interested a bit. What's the name?

Posted by: DF at July 28, 2008 12:23 AM

Out of curiosity, what is the possibility of doing real time line of sight based navigation on today's platforms?

It was possible but very slow 10 years ago, however this makes intelligent characters independent of the environment

which is a big win for production time and decouples character tec hnology from environment building.

If you are looking 10 - 20 years down the road is this something you are also thinking about perhaps?

Posted by: Ian Wilson at July 28, 2008 01:23 AM

> [LittleBrain]

> I hear what he is saying, and navigation meshes

> are a superior solution, but most of the

> problems he shows in the video c an just as

> easily happen in games that use navigation

> meshes.

True -- some of the problems in the video are not specifically related to waypoint graphs; they were more intended to

show that the industry as a whole still doesn't always take pathfinding seriously.

And yes, navigation meshes are not a panacea; there have been some games that have used navigation meshes but still

had pathfinding issues.






> [DavidM]

> One of our GDC talks

>(http://www.navpower.com/gdc2006_miles_david_pathplanning.ppt)

> from a few years back also gives some

> approaches for automatically generating

> Navmeshes and modifying them at runtime (no

> audio with the slides, but hopefully somewhat

> useful).

Thanks, David! I've added this to the article.

EDIT: I've also added you to the list of middleware vendors mentioned in the article. Cool stuff! Looks like exactly the

approach I've found to work.


Looks like kotaku took notice.

Some *interesting* comments there. Gives a bit of insight on what players really think/understand about AI and

pathfinding. Here are a couple of the highlights...

"Really all AI is designed to do these days is put up a bit of a fight and then die. Don't see that changing much for awhile."

"ive recently been playing alot of snes games, and the AI hasnt seemed to have improved from then to now."

"But like a few of you have said, why bother when in general the gaming public isn't going to notice or c are?"

"i havent seen ai really improve in 10 years, and at that time the only improvement i saw was in half life, with ai that used

cover, some of the time, in principle."

http://kotaku.com/5029669/the-problems-with-pathfinding

Also, not that it hasn't been said already, but nice article, the video was great. It seems like it really comes down to

whether a company really cares and/or has budgeted the time and money to reflect their decision (but that really

applies to AI in general).

Posted by: thaspius at July 28, 2008 07:46 AM

How about the AI in Assassin's Creed folks? The guards that are following the assassin throughout the rooftops of the

entire cities, jumping and running everywhere?

Posted by: julius at July 28, 2008 08:20 AM

I totally agree with you julius, there are some great games out there that do some amazing pathfinding, I just wonderhow much an average gamer really thinks about it when he sees it. I've got a sneaking suspicion that a lot of them just

take it for granted and complain when it misbehaves.

Posted by: thaspius at July 28, 2008 10:41 AM

Great article! I generally agree with everything said. My only complaint is the video early in the article shows a myriad of

navigation bugs, not necessarily related to the navigation network or its representation.

The spirit of the article is spot on - Modern AI calls for a number of features that become very difficult to manage with

waypoints (obstacle avoidance, smoother/more natural movement, group navigation or formations, the list goes on).





Our old system here used waypoints. Some complain about the navmesh pipeline being more of a hassle, but that's a tolls

problem, and a much easier problem to solve than fixing all the downfalls of waypoints in games employing modern AI

features.

Posted by: Bill at July 28, 2008 11:32 AM

Wow, men, pretty nice

This made remember i talked of something like this when I was on a Genetic Algorithm class where the npc would

navigate the whole map using a collision mesh, create a couple of paths and from those path start optimizing until a

shortest path was decided.

Posted by: CJLopez at July 28, 2008 01:26 PM

Great post Paul.

I also enjoyed your article on the AI Wisdom books. I read almost all of the articles you mention in preparation for my

GSoC project. I am implementing an open soruce navmesh generator for the open sourced game engine Crystal

Space/CEL.

The code is a bit behind schedule, due mostly to my indecision in what algorithms to use to optimize the navigation

mesh. The original plan is to use Hertel-Mehlron to do the triangulation and then pass the result mesh for simplification

to some merging algorithms, and do some culling of unusable or isolated fragments. Do you think this is a good approach?

What is the fastest/optimal algorithm to handle this sort of task? (but relatively simple to implement).

I am putting off some of the more advanced features for a second phase of the project, stuff like dynamic navmesh

generation (for destructible environments), solving jumps, doors, elevators, ladders links, handling tunnels/crawl spaces,

etc... however there really isn't that much information on strategies to implement these features (even in the articles

you appended to your post).

I was thinking about jumping cells(polygons), my idea is that if we calculate the relative height between adjacent cells, if

the cell is at 0.5m high he can jump, if the cell is at [0.0, 0.2]m high he can walk, if the cell is at 2.0m high he can hang

and climb, if the cell is at -2.0m he can jump and roll, etc... Adding this field would add more memory requirements, thisis just a naive approach to the problem but do you think it could work?

Any pointers by Paul or any other of the hundreds of AI experts that read this blog would be very helpful to create a

good, flexible and open sourced implementation of a navigation mesh.

TIA.

Thanks for the article, it is a great "sales pitch" for the use of navigation meshes.

Posted by: dannyBlue at July 28, 2008 03:02 PM

> [DannyBlue]

> The code is a bit behind schedule, due mostly

> to my indecision in what algorithms to use to

> optimize the navigation mesh. The original plan

> is to use Hertel-Mehlron to do the

> triangulation and then pass the result mesh for

> simplification to some merging algorithms, and

> do some culling of unusable or isolated

> fragments. Do you think this is a good

> approach?

Yes, I do; that's an approach I've used with some success in the past (though in retrospect it would have been a good





idea for me to have added more support for more designer control, if I'd had the time to implement that sort of thing).

> What is the fastest/optimal algorithm to handle

> this sort of task? (but relatively simple to

> implement).

Hard to say. I'd recommend checking out all the articles I link to above. My approach was essentially just a greedy

merging algorithm, and it rejected any remaining polygons based on various factors: the Z values of their normals (i.e. the

poly faces sideways or downwards), surface area (throw out polys that are too small), and connectivity (toss any polys

that aren't connected to other nav mesh polys).

Posted by: Paul T at July 28, 2008 06:12 PM

As others have already mentioned, using a nav mesh wouldn’t automatically fix these problems. Another point is that in

some of the cases the issue may be with the capabilities of the object doing the search as opposed to the pathing logic

itself. If you look closely at the segment with the panthers you’ll notice that the Player jumps to get up and down that

one area. There’s possibly a break in the mesh there and if so then their pathing code might not take jumps into

consideration but I’ve seen the same thing when the NPCs weren’t set up the with ability to jump, either by design, lack

of animation or omission. Along the same lines the pathing in the river could be due to the monster not having the ability

to swim, which you’ll notice the Player does. Sure, it doesn’t look good but the issue may not be with the pathing code

or the search space.

Someone had asked about jumping so I thought I’d pass along some of what we did. To improve load speed we preprocess

the cell linkages and other related data. Part of this is determining all the potential jump cells. When something tries to

jump off the mesh we’ll check the list of potential jump cells and see if there’s one in line that the avatar could actually

jump to. Since you could have different guys with different sizes and abilities we’ll determine this when jumping or

searching for a path. Other factors like if you c an hang from the cell and the hang height of the avatar would be

factored in as well. Assuming your avatars have standard jump abilities you could factor these jump cells into your

pathing. Since there was the potential for avatars to make great leaps in what we were working on we took a different

path to reduce the search space. What we did instead was set down “breadcrumbs” every time the Player would jump

off of one part of the mesh onto another and we’d factor those into the search. These could also be preplaced in the

mission as needed.

Regarding physical objects in the mesh one thing you can do is weight any cell with objects in it higher so the search

will prefer to use other cells. When objects are added or removed you update the cell information accordingly. If you

still need to go into or through that cell then, as someone else mentioned, you may need to come up with another

alternative. For one game we came up with a supplemental LoS pathing solution. In another our solution was much

simpler. Anything that wasn’t cut out of the mesh was an object that could be destroyed so anytime an NPC would bump

into one they’d just do a melee attack, destroy it and keep moving on.

Posted by: ScottE at July 29, 2008 09:03 AM

If the problem with using the collision mesh for a navigation mesh is the number of collision polygons, you could have a

compile time tool that takes the collision mesh and outputs a navigation mesh of the collision mesh's perimeter.

Posted by: Chris Peterson at July 29, 2008 09:43 AM

I just wanted to alert you to some of the cutting edge research being done on pathfinding, particularly a dynamic

lookahead heuristic thats been worked on, that I think you may find interesting. I've got most of the details here at my

blog:

http://www.oddco.ca/zeroth/zblog/2008/07/29/dynamic-pathfindingcutting-edge-research/

I attended the presentation, thought it was a pretty awesome algorithm. It certainly shares a lot of similarities with

navigation meshes.







target, it will "evade", resetting its health and returning back to its start location. Since the player was presumably trying

to kill the monster, this forces them to choose not to stand on special rocks and cliffs and other places that cause

pathfinding failures.

This is horrible from an "AI should make the monsters behave realistically" perspective, but brilliant from an "AI should

never let the monsters be pushovers" perspective.

Basically, if you're going to have an AI failure, err on the side of preventing exploits.

Posted by: Jason at July 30, 2008 04:33 PM

Wouldn't it make more sense to use a negative nav mesh, i.e. a map of places the AI can't pass trough?

Posted by: MichalT at July 30, 2008 09:36 PM

> [Jason]

> Whatever navigation system it's using, it's not

> a waypoint graph

That's why I said "most" of these games use waypoint graphs for pathfinding, rather than "all" :)

In any event, the video was more a demonstration of some of the pathfinding issues modern games still face, and wasintended to motivate the discussion. Some of the bugs are c learly unrelated to the pathfinding representation.


> [Michael]

> Wouldn't it make more sense to use a negative nav

> mesh, i.e. a map of places the AI can't pass

> trough?

The "points-of-visibility" approach does this. That approach can work, but I find it's generally easier to run a search

algorithm (such as "A*") on spaces you *can* walk on than spaces you can't. The navigation mesh approach also lets you

mark areas with flags to indicate what kinds of c reatures c an move through there and how they should do so; it's a bit

more difficult to do that with a points-of-visibility approach.


Thank you Paul for this great Post !

There have been a lot of good articles in the past Gems/AI Wisdom books, however they're mostly addressing the low-

level CSG Operations. What I found to be the most difficult is the handling of non-blocking dynamic objects and tricky

movement capabilities. Three examples here:

1. How to handle partially overlapping areas, 1 above and 1 down below, where the lower one is filled with water and the

upper is some sort of bridge. This means you could do a "waterjump" to reach the upper one, but there is no real edgegenerated from the base geometry.

2. Floating Objects. In a Quake-Style Game Items like Armors are sometimes found floating between 2 Jumppads. I can't

assign this item to an area and detecting the nearest "best" one is tricky.

3. Dynamic Objects which can be moved e.a. a winding bridge or a latter. Or even a sequence of jumppads.

So far the only solution I've seen is to get rid of the 2.5D Represention and switch over to using simplified BSP-Trees like

JP van Waveren did since Quake III. Am I wrong ? Are there any good lectures on this topic ?

Posted by: MarkusK at July 31, 2008 12:10 AM

[MarkusK]





> 1. How to handle partially overlapping areas, 1

> above and 1 down below, where the lower one is

> filled with water and the upper is some sort of

> bridge. This means you could do a "waterjump"

> to reach the upper one, but there is no real

> edge generated from the base geometry.

Yes, in this case, it may be difficult to get the results you need from an approach based on automatically generating a

nav mesh from the base geometry.

> 2. Floating Objects. In a Quake-Style Game

> Items like Armors are sometimes found floating

> between 2 Jumppads. I can't assign this item to

> an area and detecting the nearest "best" one is

> tricky.

I'm not sure I understand; what is the need to assign it to any navigation mesh regions at all? If the question is how bots

should be able to plan a path to jump and get the armor, it should be possible to either do this dynamically (by testing

various jump arcs that intersect the armor, and making sure they land on the navigation mesh somewhere), or by setting

up some number of scripted jump trajectories.

> 3. Dynamic Objects which can be moved e.a. a> winding bridge or a latter. Or even a sequence

> of jumppads.

Yes, in this case, parts of your navigation mesh need to move. The only tricky part is updating the connectivity data

when your polys become adjacent to existing nav mesh polys; there are lots of ways to handle this, including scripting.


> [Michael Leza]

> Just curious, wouldn't it be easy to simply add

> the ability to stick an invisible "navmesh"

> attribute on any given surface, as simple as

> adding textures? Like, if I was using Hammer to

> work up a new map for HL2 as I was building I

> would do a pass where I marked all the surfaces

> where people could move around and run as

> navigable? Then just hit compile and let el

> computadora do all the hard work.

Potentially, yes, though you could also end up with a lot more polys than you actually need for navigation. You also run

into issues in cases where you want to tweak the nav mesh separately from the geometry -- for example, you want units

to walk at least 3 meters from a wall for reasons specific to your game design. It's easiest to do this with a separate mesh;

with the approach you describe, you'd probably need to subdivide a lot of existing polys so you could mark them as"navmesh" on one side and not the other.


I think at least two of the games you pick on are MMO's, World of Warcraft and Age of Conan? I remember a time when

path finding in MM Os were just straight linear pathing. The question is if correct pathing is even possible under the

requirements of the massive multiplayer environment. There's a lot more to pick on in these types of games but they're

so easy to fix that it's obviously a resource versus correctness compromise. Good article though.

Posted by: Peter at August 1, 2008 09:11 AM





>Now I wait for the article in 10+ years decrying navmeshes and a >inevitable need for something better (or simply

improved ?>navmeshes!). Hopefully, however, Navmeshes are a good solution >for a long while, much more so then

waypoints at least :D

I quote this because I would expect that demand to come from games with 3-D nav requirements (more than

Mesh+height) as in underwater, air, or space based environments (my video game wet dream is the battle room from

Ender's Game).

I am not well versed in the issue so perhaps there is already something for 3 Space pathing that works well but is difficult

to apply to surface based environments. Either way this article is a great example of what time and knowledge can

provide, rather than just making fun of something or whining about it. Thanks.

P.S.

>Anything that wasn’t cut out of the mesh was an object that >could be destroyed so anytime an NPC would bump into

one >they’d just do a melee attack, destroy it and keep moving on.

I found incredibly comic. Think of traffic jams, long lines, or that corner you always bang into.

Posted by: Indu at August 1, 2008 11:53 AM

Are there instances where you'd need a "navigation volume"? i can see where you might have a flying unit in your bridge

example who wants to fly up from under the bridge to on top of it. is there any way you've seen to extend your mesh

idea to cover more "space" or at the point you need that are you back to setting "flyer waypoints" in space and just

using your the mesh to find landing points? (i think that's how the FAA operates, so maybe it's not such a bad model)

I can imagine with a sense of volume, you might find it easier to reason that the tank wanting to path around the

sandbags has a "step height" tall enough to go straight over them (not even considering deformable terrain or the

laughability of sandbags being a deterrent to tanks IRL), essentially treating the wall as if it were part of the ground

mesh. Otherwise, how c an you fix the issue with hovering units/flyers/etc. without writing it off to a collision detec tion

problem or making different meshes for each type just like you'd have to with waypoints?

My opinion:

Meshes > Waypoints. Got it.

Meshes > *. Not so sure.

Posted by: ifatree at August 1, 2008 02:33 PM

> Are there instances where you'd need

> a "navigation volume"? i can see where you

> might have a flying unit in your bridge example

> who wants to fly up from under the bridge to on

> top of it.

Yes. Again, you usually want every polygon in your navigation mesh to have an associated "height" value that indicates

how much open space is available above the polygon (where your definition of "above" is either directly vertical or in the

direction of the polygon's plane normal, depending on the needs of your game).

If you do it correctly, you should have no problem setting up a mesh to allow a flier to move from below the bridge to

over top of it.

All you're doing is using A* to find the list of navigation mesh polygons that will get the flier from one point to another,

and once you know that, you can much more easily figure out a path in terms of actual vertices.

> I can imagine with a sense of volume, you might

> find it easier to reason that the tank wanting

> to path around the sandbags has a "step height"

> tall enough to go straight over them ...





Yes, having a "step height" for each character is definitely recommended; that will help ensure that your characters

know how to do pathfinding in a way that corresponds to their movement capabilities.

Posted by: PaulT at August 2, 2008 07:55 AM

You might have to consider with the step height of that tank going over the sandbags whether this is an efficient

dec ision as this might unnecessarily slow down the tank and the cost to this climb-step has to be considered in the A*

costs.

Posted by: Nexii Malthus at August 2, 2008 07:04 PM

An incredible article. Thank you!

Posted by: Michael Kofman at August 4, 2008 01:15 AM

I think, that the simplest way to generate navmesh - is on "Figure 21. Extending the waypoint approach with circles" with

extension like...

Then 2 circles intersect, you can place portal \ graph node at this intersection and think about area inside this circle

amidst neighbour portal \ graph node as a navimesh poly. You make connected graph this way.

Then graph is done, you make postporc ess - eleminate nodes that are formed a straight poly and merge them.

sorry for tangled story, i made some explanatory pics

pic1 - make graph node from circles intersections

https://reader009.{domain}/reader009/html5/0521/5b02cd7e3ec94/5b02cd8d2388c.jpg

pic2 - form navimesh polys

https://reader009.{domain}/reader009/html5/0521/5b02cd7e3ec94/5b02cd8e1cd41.jpg

pic3 - optimize by merge postprocess

https://reader009.{domain}/reader009/html5/0521/5b02cd7e3ec94/5b02cd8ecd917.jpg

Posted by: Tomat at August 4, 2008 03:30 PM

Hello,

Great article, wow! lots of comments!...

well, I have some questions:

- Is it worth to use polyhedron-based navigation mesh for flying creatures, maybe in a 3D labyrinth? and how may I create

an editor for that kind of mesh?

- How can I say that is it posible to jump from a polygon to another? Considering jumping down of the bridge or jumping

across a fissure? [I think my idea (I didn't read it anywhere else) of the polyhedron-based navigation mesh may solve it]

I'll read the references ^_^

Thanks a lot!!!

~ Alfonso J. Ramos - [email protected]

Posted by: Alfonso J. Ramos at August 4, 2008 11:17 PM

Oh, sorry, sorry, It has been a serius subject of study (I think) to create the polyhedrical approach [has been

implemented perhaps?], I will be looking forward for the next solution for pathfinding, I am sure that this is not fully

solved.

- Alfonso J. Ramos - [email protected]





Posted by: Alfonso J. Ramos at August 4, 2008 11:24 PM

Great article! Really a nice, comprehensive and complete comparison of Way-Point-Graphs and NavMeshes. We try to

convince game studios of the same thing, and your article really helps to find great arguments.

We also provide a solution for automated NavMesh generation including several classifiers for Bots influencing the

NavMesh generation (falling and jump heights, max slopes, size classifiers etc ).

It would be great if you could add our company to the above mentioned middleware solutions, as well.

Posted by: Thorsten at August 5, 2008 12:27 AM

> [Thorsten]

> It would be great if you could add our company

> (Xaitment) to the above mentioned middleware

> solutions, as well.

Done!


> [Alfonso J. Ramos]> Great article, wow! lots of comments!...

> well, I have some questions:

>- Is it worth to use polyhedron-based navigation

> mesh for flying creatures, maybe in a 3D

> labyrinth? and how may I create an editor for

> that kind of mesh?

All you need to do in most c ases is add a "height" parameter to each navigation mesh poly to extrude it upwards. There's

a bit of discussion of this in the section that contains Figure 22.

For some games that are *truly* 3D and have no fixed up and down, such as "Descent," you can use convex polyhedra

instead of 2D polygons with heights.

>How can I say that is it posible to jump from a

> polygon to another? Considering jumping down of

> the bridge or jumping across a fissure? [I

> think my idea (I didn't read it anywhere else)

> of the polyhedron-based navigation mesh may

> solve it]

There are several ways to handle this. The most robust solution is to c reate a spec ial nav mesh polygon hanging down off

both sides of the bridge you mention, and across the fissure, and mark it as a "jump" region. Then your pathfinding

system needs to know that creatures should jump whenever they cross a "jump" region.

You could also do it in a more traditional way, and drop markers/annotations/hints into the world with start and end

points for each possible jump. This gives you a bit more control over the exact start and end locations of each jump, and

possibly the trajectories as well, but I prefer the first solution since it's integrated into the navigation mesh.


> [Tomat]

> I think, that the simplest way to generate

> navmesh - is on "Figure 21. Extending the

> waypoint approach with circles" with extension





> like...

I think that's a good approach, but I'm not sure it's much simpler than dropping vertices into the world and connecting

them.

If you imagine a case where you have a sequence of rectangular polygons, a manual nav mesh editor like the one I've

described requires you to drop 2 vertices plus 2 more for each polygon (since each neighboring pair of polys shares 2

vertices). With the approach you desc ribe, you still have to place 1 vertex for each of the c ircles, and you also have to

allow the user to specify a radius for each c ircle as well as the direction of the circle's surface normal (since many

navigation mesh polygons will be on sloped surfaces).

So it's basically an equivalent amount of work.

In the c ase where your nav mesh consists of triangles connected in more of a random mesh, a vertex-based approach is

simplest; in that c ase, triangles often share 2 or 3 of their vertices with their neighbors, and desc ribing them with center

points plus a radius and a normal probably wouldn't get you anything.


After over 8 years in the game AI world, this is the best article I have ever read on navmeshes. Bravo!

Posted by: Dr Paul Kruszewski at August 5, 2008 08:40 AM

Awww, shucks :)

Thanks, Paul!


why not scrap them both and start with a floor that is, essentially, a nav mesh? That way there need be no polygons to

describe anything and collisions could be detected by setting up objects like walls --which would seem to need polygons

and coordinates anyway.

Posted by: shandooga at August 7, 2008 11:43 AM

> [shandooga]

> why not sc rap them both and start with a floor

> that is, essentially, a nav mesh?

If you do that, you're tying the hands of your artists and level designers by forcing them to fit into the needs of your

pathfinding system.

Artists and level designers need to be able to build the geometry of the game world using a potentially very large number

of polygons to represent the game world ... while you want a navigation mesh to be as simple as possible for the sake of

efficient pathfinding and easy editing.

Again, a cobblestone street on a c urved road is a good example. You can usually represent the navigation mesh for a

road like that with one big rectangle, but you don't want to go to your artists and say, "Make this all one big rec tangle."

If you do that, there's no way for them to do the cobblestones (assuming you want real, bumpy stones and not just fake

it with normal-mapped cobblestones), and there 's no way to make the road curved.

You really need to use separate representations for the render geometry, the collision geometry, and the pathfinding.

Keep in mind that you'll often want to tweak both the collision geometry and the pathfinding to be different from the

render mesh -- in the case of the collision mesh, this includes things like adding invisible walls to prevent the player from

going into certain areas or simplifying complex areas of collision for better collision performance; in the case of





pathfinding, this includes being able to tell your AIs "keep more distance from this wall when you're walking down this

hallway" or "don't go down this street, even though there's a render mesh and a collision mesh there."

Posted by: PaulT at August 7, 2008 01:17 PM

I think I may have an idea about jumping and stepping off things.

Ether a programmed side to the poligon or another poligon block to signal that another type of behaviour c an be used.

Useing the bridge and road in Stormwind as an example the edges of the poligons next to the water would be

programmed to let the NPC know that at a sertain ammount of life the NPC can perform another action and jump to the

side at the line then end up in the waterand hopefuly safe. It could be adjusted for just about anything even marking

obsitcles in the mesh as hidable behind and others as just off the edge as walls and huge drops. Another fun thing it

might alow is for an NPC to make what might seem like a risk assesment alowing the NPC to only jump off cliffs if thay will

have a sertain amount of life left at the end of the fall so the fall risk is programmed at the top of the cliff and ledge. The

NPC would then step off to chase the player if thay will survive the fall. Hopefuly this wont be implemented on the

scryers or aldor lifts in warcraft though for anyone that has badly timed the aldor lift you'll know why.

If you alow for more layers of polygons you could have some programmed to overide the walking space mechanic and let

the NPC know theres an object that it can jump on if need be.

Jumping mechanics would probably be handled by three types of jump lines. One thats a one way jump and c ant go

back, one that alows falling off a small ledge if you back track and the other that alows for turning around and jumping

back the way the NPC jumpecd in the first place.

I tend to visualise stuff like this and its hard to describe so i'm sorry if you cant pick though what i'm trying to say. If you

can I hop e it helps.

Posted by: Krysta at August 9, 2008 03:15 AM

Jumping is more or less a solved problem. In the past, I've seen it done either via connected pairs of annotations, or by

special "jump"-type navigation mesh polygons marking regions that creatures can jump across.

I also recommend checking out these two articles:

"Jumping, Climbing, and Tactical Reasoning: How to Get More Out of a Navigation System" -- Christopher Reed, Benjamin

Geisler (AI Game Programming Wisdom 2, 2003)

"Navigating Doors, Elevators, Ledges, and Other Obstacles" -- John Hancock (AI Game Programming Wisdom, 2002)

Posted by: PaulT at August 9, 2008 04:22 PM

Thanks!

Posted by: Thorsten at August 11, 2008 03:11 AM

The whole nav-mesh idea is great. In a limited way, it was done for Kratos in the God of War series. What they did is have

the map rendered in 2 strokes, the viewable map, and the playable map (userland).

Userland is where the character lives and c an interact in. Which is why you cant jump off that big crate, or take a dive

off a ledge.

The viewable map is all the fancy architecture that you can see, but not interact with. The objec ts were placed in the

userland,

you could probably engineer something similar for the ai, using a raycast to determine accurate paths, and use simple

heights to see if the AI can hide behind it*. That'd take care of flying enemies, tanks, motorcycles, humans, etc.





of course, It's a tad more complicated than simply rendering only a flat 2d mesh, but it'd provide more accurate results,

especially if you have a very large group of various monsters/enemies attacking.

This approach would be a lot more complex, and the trade off would be CPU power. but then again, you could just have

the player live in this space as well, and just have the AI aware of what's going on.

plus, some games could use some better optimization. If I recall correctly, F.E.A.R. ran like crud for the same visual

effects of games in the same class.

Posted by: Chris Kalani at August 16, 2008 09:20 PM


Documents

AI_ Fixing Pathfinding Once and For All