NavMesh does not update fast enough


I am making an RTS game where each unit is a character. The Character blueprint has a static mesh with a navigation box collision. The AreaClass of this collision mask is set to NavArea with a high default cost, so that the characters try to avoid one another. The problem is that sometimes they do that and sometimes they don’t. Using the console command Show Navigation during runtime, I can see that this occurs when the NavMesh cannot keep up with updating itself (is red when the character is moving). But this is really weird, because I tried it with only two characters with various settings of dynamic NavMesh updating and it seems like the engine can’t cope with it. Am I doing something wrong, or should try a different approach?

Red color of navmesh tiles persist for a short time after rebuild has finished. However, navmesh rebuilds are still expensive and you should avoid forcing them constantly when characters are moving around. Additionally each rebuild affects currently followed paths - invalidated and recalculated if they happen to lead through modified tiles (which is your case).

Have you tried using built in avoidance for characters? There are two different ways of enabling it:

  1. Purely blueprint - check “Use RVO Avoidance” flag in pawn’s blueprint. You can specify which agents will avoid each other by setting AvoidanceGroup, GroupsToAvoid and GroupsToIgnore flags.
  2. Requires small amount of c++ code - add new AIController class and switch path following component for UCrowdFollowingComponent. Check comment in CrowdManager.h for details.

If you wait for 4.7, or you’re willing to use 4.7 preview build, you’ll also a blueprint way of using detour crowds - you just need to derive your AI controller classes from DetourCrowdAIController.

I tried using the RVO Avoidance with a few settings combinations, but it resulted in really weird paths, shaking of my characters and other issues.
As for the second option, is that generally Detour Crowd implementation or yet another navigation solution?

Would DetourCrowds work with numerous RTS characters, so that they effectively avoid each other?

I am currently using UE 4.5, so I need to implement the DetourCrowds through c++.
As mostly I have worked in BPs I have a question regarding the c++ implementation.
I am creating an AIController class and change this:

AMyAIControllerCrowds::AMyAIControllerCrowds(const class FPostConstructInitializeProperties& PCIP)
	: Super(PCIP)


to that:

AMyAIControllerCrowds::AMyAIControllerCrowds(const FPostConstructInitializeProperties& PCIP)
: Super(PCIP.SetDefaultSubobjectClass<UCrowdFollowingComponent>(TEXT("PathFollowingComponent")))


And after that I would need to assign the MyAIControllerCrowds to the characters, right? And would that mean that any scripts which I had in my previous blueprint AIController would have to be implemented in the c++ code?

Should be fine up to 100 units, I don’t have any real test scenario for higher numbers. Default limit is set to 50 though, so you would have to increase it in project settings (Engine > CrowdManager > MaxAgents).

Just reparent your blueprint controller to new base class: MyAIControllerCrowds. It’s in File menu when you open blueprint editor.

I got this error when building my project with the new AIController class:

Error	1	error C2065: 'UCrowdFollowingComponent' : undeclared identifier

add include for “Navigation/CrowdFollowingComponent.h”

Ok, so the AIController has been successfully compiled and I reparented the AIController to the new one. What should be done next? The navigation does not seem to differ at all right now.
Do I need to change something in the AIController settings or maybe there is something in the Project Settings to alter?

The problem basically still persists. I think that partially I know what might cause it. As I made a cylindrical NavArea (in the navigation settings of the character’s static mesh) of Default Cost 5 and Fixed Area Entering Cost of 2, when two of these areas overlap the character is in a closed, more expensive NavArea of itself and of the other character, thus the path may be now freely created in this Area. Therefore it may often lead through the other character’s position.
But how to resolve this problem then if not by making expensive NavAreas? Null NavAreas mess things up even more…