Suboptimal Paths generated on somewhat bumpy Landscape Terrain in WP

Development Programming & Scripting
, ,
1

Hi there,

We encountered what seems to be a bug with UE’s NavigationSystemV1.

Our enemy characters use a NavMesh to find the path to their target position. When there are no obstacles or steep slopes, we expect the path to a straight line to the target position, but are finding cases where depending on the start position and target position, a less than optimal path is generated.

------

Upon further investigation, we found issues with how the navigation mesh is actually generated. There seems to be a crack in the actual navigation mesh, as demonstrated in the below figure:

2026-06-11NavMesh.png.png
2026-06-11NavMesh.png.png1484×680 41.3 KB

On the left is a path we expect; on the right is where the problem seems to occurs.

-----

Up until this point we’ve confirmed the problem via the following:

・A map with World Partition turned on

・A landscape terrain that is somewhat bumpy

-----

Please see the sample project “NavMeshTestEn.zip” we’ve attached.

It was made targeting UE 5.6.1, but should also be reproducable in UE5.7.4

-----

Reproducing via the Sample Project

Opening up the project and starting the bundled map, you’ll be able to control the camera similar to the Blank Template. WASD and Mouse input control the camera positiona nd viewpoint.

Clicking with the Left Mouse Button will place a Red Marker in the scene that represents the Target Position. A path is then generated from the camera position to the Red Marker (drawn as a green line).

In most cases the path is a simple straight line, but play around with either the Target position or Camera position will reveal sub-optimal paths are occasionally generated.

ScreenShot00000.png.png
ScreenShot00000.png.png1091×603 591 KB

If you also look closely enough, you’ll notice some cracks in the underlying navigation mesh as well.

Cheers,

2

再現手順
Attaching a Sample Project “NavMeshTestEn.zip” that reproduces the issue. Opening up the project will start you off with the test map that demonstrates the problem.

You’ll be able to control the camera similar to the Blank Template. WASD and Mouse input control the camera positiona nd viewpoint.

Clicking with the Left Mouse Button will place a Red Marker in the scene that represents the Target Position. A path is then generated from the camera position to the Red Marker (drawn as a green line).

In most cases the path is a simple straight line, but play around with either the Target position or Camera position will reveal sub-optimal paths are occasionally generated.

3

This is usually an issue with navigating through long, thin triangles in the navmesh. It also appears to be the case from your screenshot showcasing the issue. Pathfinding uses the cost from the middle of the edge, and the long thin triangles may be seen as closer than the mid point of the other tile since it is only 2 triangles. To prevent the long, thin triangles of death, we recommend using Monotone or Chunky Monotone for region and layer partitioning when possible. Watershed is the default in the engine because it fits the terrain so much better, but the other options are faster and produce more consistent tiles.

-James

4

You’re welcome! I am hopeful this is the minor change needed. I’ve seen this fix other similar issues for odd pathfinding.

5

In that particular case from the new screenshot, the issue is that there is a slight mismatch in height between the tiles that causes one tile to believe it is to far to reach due to the imprecision of the voxels used to generate it. You can see the edge of the tile that would be the direct path to the point, that it is a dark, bold green line which is used to show a navmesh edge. The tuning is usually adjusting cell size and height (here height may be the more appropriate lever) used to generate navmesh. Smaller cells are more precise, but take longer to build the tiles. It is usually acceptable in static navmesh as the cost is editor time, but it can cause longer tile build times in dynamic situations. It is a bug we are aware exists, but it is a bit lower on our priority of things to address. You can follow the progress of this bug here: Unreal Engine Bug Report UE-352459. Sometimes it can be addressed where you see it with adding nav modifiers that change the resolution of the navmesh so only that section is built with higher precision.

Another option is changing agent max step height. This should allow for larger “gaps” to be crossed in the navmesh as the edge height will be within the max step height. This needs to be tested to make sure navmesh and characters do not begin going in places that were not supposed to be accessible. Usually small changes are perfectly acceptable, but depending on the scale of the game, seemingly small changes may break other aspects. So if you go with this approach, have your designers and engineers look through the other levels to check that navmesh still looks correct.

-James

6

No worries! I understand other priorities interrupting being able to respond. If you do test and find issues, I would be curious to hear the findings. I am sure our navigation devs would also be keen to hear more about what you find as we have that open JIRA for the cracks as well.

-James

7

Thanks! I’ll forward this onto the team and let you know if it works

8

Hi James,

So I just heard back from our programmer who tried the following:

​

・Changed Region & Layer Partitioning from WaterShed → Monotone or Chunky Monotone

​

But are still encountering the same issues in terms of：

・there being holes in the underlying navmesh

・suboptimal paths being returned

Attaching a screenshot for reference:

AfterChangingPartioningMode.png
AfterChangingPartioningMode.png1433×997 843 KB

This is kinda surprising since the underlying geometry is just landscape tiles that are a bit sinusoidal/rolly in shape.

Is there another set of parameters that we should be looking at for extra tuning?

Any advice is greatly appreciated.

Sincerely,

Garrett Jones

9

Hi James,

Sorry for not responding sooner -> but thank-you for the advice!

We’ll try your advice, and if necessary ping this ticket accordingly (understand you folks are on break until the end of the week though).

Sincerely,

Garrett