It happens when we override properties of Actor in level and move it. The old collision in navigation octree would not be cleared. I can recreate this bug in official unreal version 5.5 and 5.6. Unreal5.3 works correctly. I can’t test it in 5.4 because a DDC crash always happens when Editor loading at 9%. It seems related to the 5.4 modification of UNavigationObjectRepository. When we move actors in level, the code goes a long way related to reconstuction and property serialization, so the old primitive component could use the parent property value to register in the navigation octree and use the override value to unregister. Then no way could clear the old collision in octree.
重现步骤
The video attached shows how to reproduce this bug
- create a empty project in UE5.5
- set up Navmesh bound volume to generate navmesh
- create a blueprint actor and set collision for navmesh
- put an instance of blueprint actor in level
- set the instance property “Can Ever Affect Navigation” to false
- Move instance, or rebuild path would not clean the old collision
It’s the same problem of this link .
[Content removed]
It seems that Unreal 5.6 preview doesn’t contain this fix. And the CL prodived by BaoKangChen doesn’t cover all the cases. When we set false to “Can Ever Affact Navigation”, trace_comp did clear up in navmesh. But when we set true back to “Can Ever Affect Navigation”, it won’t register collision into navmesh until you move it.
I see this happening in 5.6, but the good news is that it is not in the UE5 main stream. I believe one of the fixes committed for this missed the initial cutoff to be included in 5.6 release stream. There was a CL submitted for the NavSystem yesterday at CL 43425643 in UE5 Main. I am not sure if that is the likely cause, but will need to look more at what CLs have not been added to the 5.6 release stream from main.
-James
Thank you for bringing it to our attention that it is still in 5.6.0. I will work with others on the team to get the relevant CLs merged into 5.6 release for future hotfixes.
Thank you James. It’s not urgent for us right now. I hope the following subversion of 5.6 could solve it.