World partition navmesh building

Greetings,

I think we found some issues with navigation building with a world partition level. I’ll try to sum up as clearly as possible. We have a world partition enabled level where we use “non streaming” navigation.

1 - I noticed that when an object (static mesh for instance) is contributing to the navigation but is spatially loaded, despite “build paths” force loading the world region corresponding to the bounding area of all navmeshbounds, this object will not contribute. (Plane is acting as a ground and is not spatially loaded)

[Image Removed]

Here is the result after building paths, Cube did not contribute despite being loaded automatically by Build Paths routine

[Image Removed]

If loading manually the appropriate region from World Partition window before, this will work as I expect

[Image Removed]

2 - Our designers were missing “organization” when using OFPA, so they use editor data layers to categorize and separate their work, allowing them to quickly remove / add actors for clarity when editing. I think this is a bad idea because from my point of view data layers are for streaming and not for edition/layout, but then I’m not still sure what’s the meaning of the data layer type “Editor”, they are still packaged even if using -SkipCookingEditorContent, can you please describe here what the purpose of Editor Data Leyer kind?

That being said, we noticed another issue, in our project we have multiple agents - 3 only ATM, and we had issue with empty navmesh in packaged builds, I finally found that we had ghost navmeshes not showing in outliner but they still request registration to the NavigationSystem when the map is loaded. Then they overload the queue causing the legit navmeshes being discarded because the 16 limit was reached here.[Image Removed]

After investigation, I found that we had all of our navmeshbounds/modifiers in a nested datalayer like LD->LD_Navmesh both of type editor. If the nested layer is not loaded when opening the map, toggling this layer will result in a ghost navmesh being generated silently and marked for add in perforce. Since the OFPA files are only IDs artists / designers are submitting them to the source control without noticing a problem. To avoid this issue we end up moving navmeshbounds/modifier to an outliner folder without using data layer. Is this the way to go or using datalayers might be an option here?

3 - Disabling Auto Create Navigation Data in project settings is overridden and set enabled without any NavigationSystemConfigActor existing in the map. It was confusing but adding the configuration actor will act as a workaround

[Image Removed]

[Image Removed]

I linked a repro project, but it’s only for issue 1 since we have workaround the others. In the end what is the recommended way to work with world partition map and navmesh, should we also opt in to world partition navmesh, would it help to avoid those quirks?

Best

Julien

Steps to Reproduce

  • Load LVL_Navigation
  • From World Partition window, unload any content
  • From Build menu, click “Build Paths”
  • Type P in level viewport or use “show navigation” console command
  • Observe navmesh is generated but is missing Cube contribution

Hi Julien,

My apologies for the delay in responding to this.

I opened the attached project, but I do not see the issue in 5.5.4 that you are referencing with the cube not influencing the navmesh. With everything unloaded from the World Partition panel (cube is hidden even in viewport and shows Unloaded in the Outliner), I built the navmesh, and the resulting navmesh has a cutout for the cube. The cube is also loaded into the level after the navmesh is built. You can also stop the navmesh rebuild when loading by disabling Update Navigation Automatically in Editor Preferences->Level Editor->Miscellaneous. It does not use the full rebuild code path that Build Paths uses, but rather tries to update tiles based on what is loaded in the editor for faster navmesh updates.

what is the recommended way to work with world partition map and navmesh, should we also opt in to world partition navmesh, would it help to avoid those quirks

WP navmesh is still experimental and has its own drawbacks. The decision to use it is project dependent. You can have less active tiles for static WP navmesh as it only loads the tiles saved for the currently loaded cells, but building WP navmesh is a longer process. We do not currently use WP navmesh internally for FNBR or Lego FN.

For the outdated navmesh actors showing up, we had a change go in to address a similar issue of the actors showing as (Unloaded) in the Outliner and unable to delete them from the editor. If you still see them, you can navigate to the folder path for the actor and manually delete it from the system. Navigation only minimally supports data layers in that WP navmesh can specify data layers to load when building navmesh. The navmesh actor is usually saved at the root level and may be why it is attempting to build other navmesh actors.

Auto Create Navigation Data should be working from Project Settings. If you have Update Navigation Automatically enabled. it will create the navmesh actor if one is needed in the scene. There are multiple things that can interact inside the editor to do this. Having the Project Settings option disabled, should prevent navigation from being built in a game, but the Editor world is treated differently by the navigation system.

-James

Hi James,

Thank you for answering, indeed I reopened the project and was not able to reproduce…

Until I changed my editor preferences to set Update Navigation Automatically OFF, that part is missing from my steps to reproduce, once you turn it off and build using only “Build Path” from Build menu the issue appears.

Best

Julien

Thank you for that info! I can get this to repro in 5.5.4 and 5.6. Did you have this issue in previous versions from 5.5? If you have not used previous versions, that is fine. We had a navigation refactor in 5.5, and I am curious if this is potentially fallout from that. With verbose logging, the cube is registered with the navigation object repository prior to the rebuild of the navmesh starting. There is a chance we have just missed this internally as FN uses bAutoCreateNavigationData=true even though it has WP map and regular navmesh.

Hi James,

Sorry I can’t tell if we had this particular issue before 5.5. Out of curiosity I thought that bAutoCreateNavigationData would build at runtime only when the navmesh is missing. Would it means FN ships without any prebuilt navigation?

Hi Julien,

No worries on not knowing about previous versions. I was curious if there was a regression as well as being able to more easily find what change may have caused this. I did file a bug report in our JIRA, and here is a link to the report on the public issue tracker: https://issues.unrealengine.com/issue/UE-298038. It can take a couple days for everything to update, but it will stay in sync with any updates once it has been mirrored.

I noticed that difference in the config files for FN while looking at this, but I do not think it is all that relevant. That is my mistake as it is not involved with automatically rebuilding navmesh as tiles are dirtied in Editor. In Lego FN, we use invokers for navigation so there is no loaded navmesh, but in FNBR, there is a loaded navmesh for the initial island with dynamic updates as things are built/destroyed. I do not know all the ins-and-outs of our FN nav building as most of it is handled by automatic overnight builds.

-James