Adding a level instance to the persistent level puts its navmesh in the wrong place

Development World Creation
, ,
1

The root of the problem occurs in Step 6. ARecastNavMesh::OnNavMeshGenerationFinished() gets called, and gets to the line:

Level->NavDataChunks.Add(NavDataChunk);From now on, every time you add this level as a level instance, whatever is in NavDataChunks is going to show up because of ARecastNavMesh::OnStreamingLevelAdded, where it reads the NavDataChunks and attaches them.

The data saved in there is not spatially localized to the level instance level you are working in, but rather to the persistent level said level instance was in when you did Build Paths.

For my particular project case, I am able to work around this because I don’t actually want the level instances to bring in their own navmesh data. I do Build Paths in the persistent level. I am not using World Partition.

My first workaround approach was simply to delete the data out of NavDataChunks, which I did by opening the corrupted level and changing the Navigation System Config in the World Settings to the Null Nav Sys Config, which would call DiscardNavigationDataChunks from AddNavigationSystemToWorld.

But this wasn’t a good solution, because even though the level had a Null Nav Sys Config, the same repro steps above will still end up adding data to the level. So you tediously have to clear out the NavDataChunks again.

Of course, I could also simply delete the NavMeshBoundsVolume in the level, which would prevent ARecastNavMesh::OnNavMeshGenerationFinished() from adding to NavDataChunks.

But I would prefer the NavMeshBoundsVolume to stay, because it is valuable when the level is being edited (just by itself, not as a level instance) to be able to build navmesh data and view it. It’s just I don’t want that navmesh data to come in anytime I use the level as a level instance.

So for my case, I am going to add a new field to the RecastNavmesh class: bSupportsStreaming

This will get read in SupportsStreaming() and if false, make the function return false, thus preventing any data from streaming level instances from being brought into the persistent level. I will set this new flag to false on the RecastNavmesh in the persistent level.

But seems like there is a bug here in general.

[Attachment Removed]

2

Steps to Reproduce

  1. Make a level and add a NavMeshBoundsVolume to it. Call this Level A.
  2. Make another level. Call it Level B. Give it a NavMeshBoundsVolume as well.
  3. Open Level B. Add Level A as a level instance to Level B.
  4. Move Level A away from its default position but still within Level B’s NavMeshBoundsVolume.
  5. Right click on Level A, select Edit Level A, thus drilling down into within Level A as a level instance.
  6. Do Build Paths from the Build dropdown menu. This will build a navmesh on Level A.
  7. Save Level A using the button at the bottom of the level viewport, thus exiting the level instance edit mode and returning to the persistent level (Level B).
  8. Delete the Level A level instance. You will notice the navmesh associated with it also disappears.
  9. Add Level A as a level instance again. Make sure its position is not the same as it was when you built the navmesh.
  10. Observe the navmesh that was created on step 6 returns, and it returns in the old position of the Level A level instance from before you deleted it in Step 8.

You can also add Level A as a level instance to other levels you have, and the navmesh will still spawn in that same position as it was in Step 6 even in those other levels.

[Attachment Removed]

3

Hi there,

Thank you for your detailed information & repro steps. I was able to reproduce this quite easily and I have created a bug report for it which you can track here once it is publicly visible.

Cheers,

Louis

[Attachment Removed]