Navmesh on a Partitioned World does not Work

This question was created in reference to: [Partitioned Navmesh - Unable to make it work on a [Content removed]

Hello,

I have asked a question a month ago about the navmesh on a partitionned world. We haven’t found a solution yet.

We have explored multiple path but we have a problem on each one.

  • First we have tryed to have a static navmesh on the partitioned world. It works well on editor (we can see it with P), it’s still fine in play in editor, the npc react correctly with the navmesh. But when the game is cook, the navmesh disappear and our NPC stay static. In the next linked article, we saw that it’s impossible to use this solution with a partitioned World. Is it exact ?

  • We tryed to add a partitioned navmesh on the world, like explained here.

https://dev.epicgames.com/documentation/en\-us/unreal\-engine/world\-partitioned\-navigation\-mesh

After a relatively longue time (around 10min, why it’s so long compared to a static navmesh ?), something is generated. We have our 4 chunks, but the navmesh is not visible, and does not works with NPC. If we look to the saved chunks assets in the file explorer, the files are not empty (around 16mb each for our map size). If i reduce the chunk size, the file size reduction is coherent (with 16 chunks instead of 4, the file size is around 4mb).

  • If we clone the partitioned world, and build a partitioned navmesh on it, the navmesh work well in play in editor. We haven’t tested this solution in a cooked build because it doesn’t looks viable, and the clonned level have some others problems (some PCG have a wrong position for exemple), we haven’t explored more in this direction

  • We tryed a simpler exemple, and created the same level as the linked article, a partitionned navmesh and an npc. The chunks are here and the navmesh visible. The npc can move in a play in editor and in a cooked build.

  • If we change the non partitioned navmesh to the dynamic mode, it works in a cooked build, but with a lot of performances loss, and framerate spike when the player or a dynamic object move.

For more informations, and some answer to your last reply on the other question:

  • During the navmesh build, we have a lot of warnings (mainly about materials and nanite compatibility, it must not be a problem for the navmesh), but there are no error. I found nothing linked to the navmesh on the warnings on the log. Do you have some keywords to search to confirm this ? The log is very long and i may have missed something.

  • The Navmesh builder look to have some problems to find the bound of some assets. The old water had this problem (now we use something else), but we have the same problem with an asset somewhere, i haven’t found yet a way to pinepoint efficiently what asset cause the probem. On this log snippet we have an absurde amount of cells, but without the problematic asset we have 128 cells.

[2026.03.13-14.18.34:858][647]LogWorldPartitionBuilder: Display: [105648 / 4503599627370496] Processing cells...
[2026.03.13-14.18.34:858][647]LogWorldPartitionBuilder: Verbose: Loading Bounds: Min X=-13700622337000.000 Y=-13743895348200.000 Z=-13743895348200.000, Max X=-13700621925400.000 Y=-13743894936600.000 Z=13743895348200.000
[2026.03.13-14.18.34:858][648]LogWorldPartitionNavigationDataBuilder: Iteration 105648. GenerateNavigationData for LoadedBounds IsValid=true, Min=(X=-13700622337000.000 Y=-13743895348200.000 Z=-13743895348200.000), Max=(X=-13700621925400.000 Y=-13743894936600.000 Z=13743895348200.000)
[2026.03.13-14.18.34:859][648]LogWorldPartitionNavigationDataBuilder: GenerateNavigationData finished (no intersection with nav bounds).

  • We tested the problem on 3 differents computers and is not dependant to a local config nor files that is not exported from one user.

Do you have a solution to fix this problem ?

[Attachment Removed]

It seems that there is an issue in the level. Without having access to a reproduction, it is hard to debug. When you attempt to build WP navmesh in the problem, what happens when you attempt to display navmesh in the level by pressing P? Is there any info in the on-screen display in the top left corner? Does it show any warnings, errors, or large number of tile jobs that need to process? Do you have multiple navmeshes for your level? Is the Recast actor in the level have the Enable Drawing option enabled? If you check the World Settings, is there anything different in that level’s navigation system config and navigation system class options?

If a duplicated level builds the WP navmesh correctly, it seems there is likely a config or zombie data in the original level that is preventing the navmesh from building/loading properly. If you completely remove the navmesh, nav bounds, and any NavDataChunk actors, then save the level and attempt to rebuild things, does it do anything different?

As for the long time spent building, we found in our testing that loading the cells is the majority of the time building the WP navmesh. Have you tried increasing the Navigation Data Builder Loading Cell Size to be a larger value? It will still build the data chunks for their grid size, but it can load more of the world over each iteration in the builder. I believe some of the verbose logging for the builder has a breakdown for how long is spent in the various stages of the process.

Most of those warnings for non-navigation things are benign. Mainly concerned with any that would cause a navigation build failure such as failing to initialize the navigation system, asset registry issues, etc. I know there was an issue a while back where the builder iterated over the whole world bounds rather than the navigable world bounds. I think we had a PR to correct it, but I am not 100% sure if it made its way into the engine. From the number of cells in your log, it seems you may be experiencing a similar issue.

-James

[Attachment Removed]

Yesterday, we found that we had many ghost recast navmesh that are not displayed in the level actor list, and one of theses unwanted navmesh was set as default by the subsystem.

We don’t know why they got here but we managed to remove them.

Now the navmesh works well as a static navmesh, even with a cooked build, we haven’t tryed yet with a partitionned navmesh since we found this fix.

We still have the issue with the iterated bounds, we managed to isolate a sublevel, but it still have thousands of actors, and the displayed bounds of the sublevel looks fine.

[Attachment Removed]

I thought we had solved the ghost Recast navmesh actor issue in a previous engine version, but perhaps it does not fix-up levels where they already existed. Have you upgraded this particular project from a previous engine version? This may also explain why the new duplicated level was working as the fix removed those ghost actors.

As for limiting the bounds of the world for the builder, I know of at least one licensee (but I remember multiple doing this but cannot find relevant EPS threads) who changed UWorldPartitionNavigationDataBuilder::PreRun to set IterativeBounds = NavSystem->GetNavigableWorldBounds() after adding the navigation system to the world and a branch to ensure it happened properly. This should change from using the Editor bounds which can be far greater than that of the navigable world. I would certainly A/B test this change to check that the navmesh is the same and covers the area you need. The WP navigation builder has a check that cells overlap the navigable bounds, but it does not stop the builder from loading many unnecessary cells which is what takes the most amount of time.

-James

[Attachment Removed]

Yes, we have upgraded the engine and the map existed before 5.7.

The static navmesh work well (without partition), and i don’t think we are going to use partitionned navmesh for now.

I keep this solution for later.

Thanks

[Attachment Removed]