[BUG] Navigation dirty state even when bCanEverAffectNavigation is disabled

Development Programming & Scripting
, ,
1

Some components continue to dirty the navigation state even if bCanEverAffectNavigation is unchecked. Behavior appears very similar to an existing bug, UE-251496 (https://issues.unrealengine.com/issue/UE-251496), which involves a StaticMeshComponent, but in this case it’s reproducible using a BoxCollisionComponent instead.

Steps to Reproduce

  1. Create an empty level with a Plane and a NavMeshBoundsVolume covering the plane.
  2. Create a Blueprint derived from Actor.
  3. Add a BoxCollisionComponent to the Blueprint.
  4. Set the component’s collision preset to BlockAll.
  5. Place an instance of this Blueprint in the level and uncheck bCanEverAffectNavigation on the instance.
  6. Move the object around.
  7. Rebuild the navmesh and enable navigation debug.

Expected Behavior

The NavMesh should generate across the entire plane without any gaps.

Actual Behavior

The NavMesh is generated with holes, and navigation debug shows “fake” blocking objects, even though bCanEverAffectNavigation is disabled.

2

In the attached screenshot from navigation debug, you can clearly see ghost collision shapes (“fake” objects) appearing in the NavMesh generation. These objects persist even though the corresponding actor has

bCanEverAffectNavigation

unchecked, and they cause the holes in the NavMesh.[Image Removed]

3

This does look like the bug that you linked in your post. If you run ai.debug.nav.dumprepositoryelements with this issue happening, what are the results? I tried to repro this in our latest on Main, but cannot reproduce the problem. I also attempted it in 5.6, but I do not see the same results. The box does fail to immediately be removed when toggling off the navigation relevancy, but it does not create ghost objects or entries in the repository. And if I toggle the flag on/off again, it behaves as I would normally expect.

-James

4

Hi James, thanks for the reply.

I ran the command ai.debug.nav.DumpRepositoryElements while the issue was happening, and here are the results I got:

Cmd: ai.debug.nav.DumpRepositoryElements 
/Game/Sandbox/a_udalov/SPN-26272_NavAgentSize/L_NavGenTest.L_NavGenTest:PersistentLevel.StaticMeshActor_1.StaticMeshComponent0 bounds: [IsValid=true, Min=(X=-500.000 Y=-500.000 Z=0.000), Max=(X=500.000 Y=500.000 Z=0.000)] parent:'None'
None bounds: [IsValid=true, Min=(X=88.000 Y=188.000 Z=-2.000), Max=(X=152.000 Y=252.000 Z=62.000)] parent:'None'
None bounds: [IsValid=true, Min=(X=88.000 Y=178.000 Z=-2.000), Max=(X=152.000 Y=242.000 Z=62.000)] parent:'None'
None bounds: [IsValid=true, Min=(X=88.000 Y=168.000 Z=-2.000), Max=(X=152.000 Y=232.000 Z=62.000)] parent:'None'
...
None bounds: [IsValid=true, Min=(X=88.000 Y=-72.000 Z=-2.000), Max=(X=152.000 Y=-8.000 Z=62.000)] parent:'None'
Total: 28 elements

So it looks like in addition to the expected StaticMeshComponent, there are 27 extra None entries being generated.

5

I am not seeing this behavior in a test project using 5.6 at CL 45721919. I still only see the initial failure to stop affecting navmesh that corrects when it is further toggled. What CL are you building from? It may be that there is a CL missing between the two that contains the partial fix. I can try to track down what other CLs were made for nav since then to get the CL(s) from Main that fully address the issue.

-James

6

I don’t know the exact CL number, but we are using the latest 5.6.1 build from the Release-Latest branch as of August 12th.

7

That is very odd. Would you be able to set this up in a small repro project so we can see what is happening? It will also help us test any fixes as I am unable to trigger this more than the initial toggle.

8

Hi James,

I was able to narrow this down to a more precise repro case, which also reproduces in the stock UE 5.6.1 from Epic Games Launcher.

In addition to the steps I originally listed, there’s an extra condition that makes the issue consistent:

  • After step 5 (placing the Blueprint instance and unchecking bCanEverAffectNavigation), save the level.
  • Then rebuild the NavMesh (without even moving the object).
  • At this point, you will already see the “fake” blocking instances in the navigation debug view.
  • If you move the actor around and rebuild again, more of these ghost entries appear.

I’ve attached a small repro project that demonstrates the issue.

9

Thank you for the repro project. I see the issue happening with the “None” entries into the repository that are blocking nav. We will have to look into why something marked not as affecting navigation is still being considered. I created a report for this in our JIRA. Here is a link to the issue on our public issue tracker: https://issues.unrealengine.com/issue/UE-350551. This will update with the status as the issue is worked. It can take a couple days to update and mirror, but it will mirror eventually.

-James