[UE5] NavMesh Basics: Seeing the Walkable Area and Finding Why Your AI Won't Move

"I ordered the enemy to move but it stays put." When that happens, there is something to look at before the Blueprint: the NavMesh, the map AI uses to find its way.

Even with an impressive-looking floor, if it is not on the map the AI uses, no path to the destination can be found. First press P to show the map and compare the enemy's feet against the destination.

What You'll Learn

• That NavMesh and collision are different things
• How to visually confirm the walkable area with the P key
• How to decide passable width and step height from the AI's build
• Designating moving obstacles and places to avoid

In this article we use UE5's Third Person template to build an experiment where pressing N makes an enemy walk around an obstacle. After confirming it works, we move on to settings for different builds and changing terrain.

NavMesh is "the map for finding a route"

For an enemy to go around a wall, it needs more than knowing "there is a wall" — it needs to work out which way leads to the other side. That work of finding a route is pathfinding.

A NavMesh records "the area a character of this build can walk through," derived from the shapes of floors and obstacles. The AI selects a route with that information, and Character Movement, the component responsible for movement, drives the character.

Note here that NavMesh and collision have different roles. Collision is the hit test. An AI character, like the player, is supported by the floor's collision. Displaying the NavMesh does not create new floor in mid-air.

What we cover here is the basic usage of walking on the ground with AI MoveTo. Movement such as jumping across separated platforms needs additional systems like Nav Links.

Press P first

A Nav Mesh Bounds Volume is a box enclosing the area where a NavMesh is built. The name is long, but for now think of it as saying "please map the floors inside this box."

1. Open the Third Person template level and save it under another name for your work.
2. Search Nav Mesh Bounds Volume in "Place Actors" and place it in the level. If one already exists, check its extent.
3. Adjust the volume's position and size to enclose the whole floor you want to test. Beyond the footprint seen from above, make sure the floor falls within the box's height too.
4. Click the editor viewport and press P.

If a green area overlays the floor, the NavMesh has been generated. Press P again to hide it. This is a display for confirmation in the editor.

The three places to look are the enemy's feet, the destination, and the route between them. Even with both ends green, a break in the middle means it cannot walk across with this basic setup.

If no green appears at all, check in this order.

What to check	Where to look
The volume	Whether it encloses the test floor, vertically included
The floor's collision	Whether it is a visual-only plane. Testing on the template's floor first makes isolation easier
Map updates	Whether post-edit shapes are reflected. Search "Update Navigation Automatically" in Editor Preferences
The generation build	Whether an extreme Agent setting left no walkable area

Hands-On: moving an enemy with the N key

Without adding decision-making, we simply try walking a placed enemy to a placed marker. We do not use a Behavior Tree yet. Confirming the movement foundation works makes later problems easier to find.

1. Place the enemy and the destination

Duplicate BP_ThirdPersonCharacter in the content browser and name it BP_NavTestEnemy. Delete the logic in the duplicate's Event Graph, leaving components and visuals.

Set the following in BP_NavTestEnemy's "Class Defaults."

Setting	Value	What it is for
AI Controller Class	AIController	Lets AI control the enemy
Auto Possess AI	Placed in World or Spawned	Attaches an AI Controller to placed enemies at runtime
Auto Possess Player	Disabled	Keeps it out of player control
Use Controller Rotation Yaw	Off	Leaves rotation control to Character Movement

A Controller is the side that controls a character, and Possess is being bound as "I am handling this character." Even with something to send move commands to, without a controlling AI Controller this experiment's enemy will not walk.

Next select the "Character Movement" component, turn "Orient Rotation to Movement" on, and set "Max Walk Speed" to 300. That faces the movement direction and caps speed at 300 cm/s (3 m). Compile and save.

Place these two in the level and rename them in the Outliner.

• Place one BP_NavTestEnemy and name it NavTestEnemy.
• Find and place a Target Point from "Place Actors" and name it NavGoal. A Target Point is a marker for designating a position.

Put them about 5 m apart on the same flat floor. Confirm with P that the enemy's feet and NavGoal's position are on the NavMesh and connected. If you put a box between them, leave enough width to go around either side.

2. Pass the two placed objects into the move command

Open "Open Level Blueprint" from "Blueprints" at the top of the level. A Level Blueprint is where you write logic for that level alone. Here we build the key-input experiment.

Select NavTestEnemy in the Outliner, right-click in the Level Blueprint graph, and choose "Create a Reference to NavTestEnemy." Do the same for NavGoal. These reference the objects actually placed in the level, not the plans in the content browser.

Connect the nodes in this order.

White triangle pins carry the order logic runs, and blue round pins pass target references. The diagram shows only the necessary connections.

1. Right-click and add a keyboard N event. From "Pressed," connect a Print String with "In String" set to Move requested.
2. Connect Print String's exec output to AI MoveTo's exec input.
3. Connect the NavTestEnemy reference to Pawn and the NavGoal reference to Target Actor.
4. Set "Acceptance Radius" to 100 and turn "Stop on Overlap" off.

Pawn is "who to move" and Target Actor is "where to go." Not swapping those two is the key to the wiring. Since we pass the destination via Target Actor, we do not use the "Destination" coordinate input.

Acceptance Radius is the tolerance for "how many cm from the destination counts as arrived." Here 100 means getting within 1 m is enough. We turned "Stop on Overlap" off so the enemy's own radius is not added to this tolerance, keeping the setting's meaning easy to follow.

3. Display whether it arrived or failed

Connect a Print String from AI MoveTo's On Success showing Arrived. Connect another Print String from On Fail showing Move failed.

AI MoveTo's ordinary exec output is not an output that waits for arrival. Remembering that movement results come from On Success / On Fail prevents the mistake of "arrival logic running the instant it starts walking."

Compile, save, and start the game with "Play." Click the game view and press N once. Success is "Move requested" appearing, the enemy walking to NavGoal, and "Arrived" appearing as it gets close. With a box between them, you can watch it go around.

The Target Point marker is for editing and is not shown during Play. Confirm where the enemy is heading beforehand. Also, mashing N during movement overwrites the move request, so wait for the result first.

4. When it does not move, trace back from the display

What you observed	What to check next
Not even "Move requested" appears	Whether you are in Play, whether input focus is on the game view, whether N's Pressed is connected
"Move failed" right after "Move requested"	The Pawn and Target Actor references, the AI Controller settings, and the NavMesh at both ends and along the route
It starts walking but stops partway	Whether collision blocks the route, and whether the enemy's build matches the map
"Arrived" slightly before the marker	Correct here, since Acceptance Radius is 100. It need not overlap exactly

Once it works, stop Play, move the Bounds Volume off the test area to update the map, and try the same operation. Somewhere no other volume covers, the green disappears, no route can be built, and you get "Move failed." Put it back and it walks again.

Same floor, same Blueprint, but the result changes with the map's presence. Being able to make that comparison narrows down where to investigate the next time an enemy stops moving.

Matching the AI's build

There are corridors a human passes but a large boss cannot. The NavMesh also needs to be told what size of character will pass through. A pathfinding character is called an Agent in the settings.

First select the character's "Capsule Component." A capsule is the hit volume wrapping the body; "Capsule Radius" is its radius and "Capsule Half Height" is half its height. At scale 1, total height is twice the Half Height.

Next check the build the map is generated for under "Navigation Mesh" in "Project Settings."

Setting	What it tells the map
Agent Radius	The body's radius. How far from a wall the body fits
Agent Height	The body's full height. How much clearance to the ceiling
Agent Max Slope	The slope angle it can walk up
Agent Max Step Height	The step height it can walk over

Depending on the UE version, the step setting is split per resolution inside "Nav Mesh Resolution Params." On projects registering several builds, also check "Supported Agents" under "Navigation System." Align which build the map you are looking at is for before adjusting.

The green eaten away at walls is the body's margin

A NavMesh shows where the character's center can go. Bring the center right up to a wall and half the body clips into it, so it is generated offset from walls by the Agent Radius.

Too large a radius means no route through corridors that are actually passable. Too small and the map says passable while the actual capsule catches on the wall. Rather than shrinking it just to grow the green, base it on a value matching the character's collision.

After changing settings, wait for regeneration to finish, review the corridor width with P, and try the N key experiment again. Do not stop at the visual green growing; confirm the enemy's body passes without catching.

Slopes and steps are not decided by the map alone either. "Character Movement" also has "Walkable Floor Angle" and "Max Step Height." Even when the map judges it passable, the movement side stops partway if it cannot clear that slope or step.

In games where terrain changes, update the map too

Doors open, bridges extend, walls break. If where you can walk changes during the game, tell the AI's map about it. Runtime Generation is the setting choosing how it updates: "how much of the map is rebuilt at runtime."

Check it under "Project Settings" → "Navigation Mesh."

Setting	What can change at runtime	Example use
Static	No regeneration at runtime	A small fixed map where terrain and passability never change
Dynamic Modifiers Only	Passability and cost on the existing map	Build the map ahead and mark specific areas no-entry
Dynamic	Generation of walkable surfaces from shape changes	Reflect moving obstacles, add new floor at runtime

A Modifier designates treatment such as "no entry here" for a specific range of the map. Dynamic Modifiers Only can update that designation, but it cannot create walkable surfaces where the map had none.

For doors, there are two approaches.

• Reflect the moving door itself in the map with Dynamic. It updates the walkable area around it as the door opens and closes.
• Build the corridor's map ahead and block it with a Modifier only while closed with Dynamic Modifiers Only. This method requires that the closed door's shape not be baked as a hole in the map.

With the latter, lifting the block reveals no route if there was never a map to begin with. Also, a Modifier changes pathfinding information. The logic that moves the door and toggles its real collision is prepared separately.

Even with Dynamic, it does not rebuild the whole map each time. A NavMesh is split into small blocks called tiles and updates the parts that changed. But more update range and frequency means more cost. Static is plenty for the first fixed-floor experiment.

No-entry areas and places to avoid if possible

You do not want them near the cliff edge. Meanwhile, you want them to avoid the poison swamp if a detour exists. Those two can be distinguished on the map too.

Place a Nav Modifier Volume from "Place Actors" and enclose the target floor. Choose how that range is treated in "Area Class."

Placed at edit time alone, it applies even with Static. To change the range or treatment during Play, also choose an update method from the previous section.

Area Class	Meaning
NavArea_Default	A normal walkable area
NavArea_Null	An area unusable for routes. For places you want off-limits
NavArea_Obstacle	A high-cost area. For places you would rather they avoid

Cost is a "difficulty score" for choosing routes. Pathfinding picks the route whose total score, derived from distance and per-area settings, is smallest.

So NavArea_Obstacle does not mean "always avoid it if another route exists." If the detour costs more, it may go through that area. For places that must never be crossed, use NavArea_Null.

Note that setting an Area does not itself cause poison damage or slow walking speed. How a route is chosen and what happens when you cross it are separate settings.

Before making it heavy, consider the range you need

The first step of optimization is less about touching fine numbers and more about deciding where the map is needed and when updates are needed.

• The Bounds Volume encloses the range the AI moves in. There is no need to unconditionally include background mountains.
• For fixed terrain, build with Static first. Choose an update method matching the content once change becomes necessary.
• With Dynamic, check whether moving things constantly trigger map updates. Reflecting decorations irrelevant to pathfinding adds pointless updates.

"Cell Size" and "Cell Height" relate to how finely terrain is examined. Smaller makes fine shapes easier to handle but increases generation and memory cost. Run with the defaults first and revisit once you find that a needed narrow path or step cannot be represented.

Use "a point reachable from where you are" for patrol destinations

To make an enemy patrol next, Get Random Reachable Point in Radius works. It is a node that searches around a specified position for a random point that a route connects to.

The similar Get Random Location in Navigable Radius finds a point on the NavMesh, but not necessarily one reachable from the original position. When the map is split into islands, that difference leads to failed movement.

Once movement works, combine choosing patrol destinations with chase decisions in Behavior Tree Basics: a patrolling enemy that spots the player and gives chase. To tune build and step handling in detail, Character Movement basics also helps.

Bonus: Good to Know Up Front

• They cannot go where there is no green: if you see no green with the P key, check the NavMesh Bounds Volume's range, the floor's Collision, and the build state, in that order
• A mismatched build produces strange routes: if Agent Radius and Height do not match the character's capsule, it avoids gaps it could pass and routes through places it cannot. Change an enemy's build and rebuild the NavMesh
• Moving obstacles are a separate setting: to reflect opening doors and moving platforms in routes, Runtime Generation and Dynamic Obstacle settings are involved
• Nav Modifier is not only "forbidden": you can also designate "passable, but preferably avoided." Useful for representing lava and puddles

Summary

When AI will not move, first display the NavMesh with P and see whether a route connects from the enemy's feet to the destination. If the map is there, investigate the move request, the controlling AI Controller, and the actual collision in order.

The map chooses routes and collision supports the body. Grasping that difference in roles lets you treat "it is green but it catches" and "I added floor but it will not walk" as separate problems.

Further Reading

• Epic Games: How to modify the navigation mesh
• Epic Games: Navigation Mesh project settings
• Epic Games: AI MoveTo
• Epic Games: Level Blueprints and references to placed Actors