yes, I can confirm that RecastNavMesh actor doesn’t support being streamed in at different locations. I’ll have to look into it, but for now I can only suggest either adjusting your levels so that they don’t require offsetting while streaming, or applying a kind of a hack that will force RecastNavMesh to offset.
As a result of a brain fart, I think I’ve found a solution that’s only a bit hacky. Here’s what I did: I’ve added a root component to the ANavigationData by adding following to the constructor (will work if added to ARecastNavMesh instead):
USceneComponent* SceneComponent = CreateDefaultSubobject(TEXT("SceneComp"));
RootComponent = SceneComponent;
RootComponent->Mobility = EComponentMobility::Static;
Also, I’ve commented out RootComponent = RenderingComp; line.
Then I’ve added following function to ARecastNavMesh:
void ARecastNavMesh::PostRegisterAllComponents()
{
Super::PostRegisterAllComponents();
if (GetActorLocation().IsNearlyZero() == false)
{
ApplyWorldOffset(GetActorLocation(), /*unused*/false);
}
}
It works, but required me to go to the levels I stream in and delete the old RecastNavMesh instances and create new ones by building navigation.
Let me know if it addresses the issues you see.
Hey Nicholas,
Have you tried out the code change I’ve included in this threat (this one)? The new approach will be similar in concept - supporting multiple navigation data instances for a single navigation agent type (now there’s only one per agent).
Regarding the timeline, I’ve started working on it, but I’m doing the ground work first (finally ripping out AI navigation code fully out of the engine code). I estimate that the new approach will be ready to use in about two months (provided nothing high priority pops up).
Cheers,
–mieszko
We have not tried out that code change since we need support for navigation data from multiple active sub-levels at a time.
Right, so this won’t help. The final solution will have a tool for that - a navigation datas’ graph that will be used to find meta paths. Pathfollowing component already handles those. I guess you need to wait for my change then.
Sounds good, thanks!
It doesn’t look like this important functionality is available in 4.21.2 in a “drag-n-drop” fashion (referring to the pre-existing workflow of adding a NAV mesh bounds volume and building it). Mieszko, is there an update in 4.21.2 for this topic?