Hi,
I have supposedly enabled Detour Crowds with the MieszkoZ’s short tutorial, but it does not have any effect on the navigation. Should I do something more so that the Detour Crowds function fully? Should the NavMesh be modified somehow to adapt to DetourCrowds’ needs?
What do you mean by “no effect”? You mean AIs are bumping into each other? Can you share a stripped-down version of your project so that I can have a look at it?
Yes, I mean that very often the paths created by the AI lead through another objects affecting the NavMesh.
I will upload a stripped-down version of my project in a moment.
Just to be specific here, detour crowds do not affect navigation paths generated, only the way those paths are being followed.
I am aware of that, but I thought some changes would be noticable.
Here is the stripped-down project: MEGA LINK
With WASD the camera is moved, EQ rotates the view and with the mouse wheel you zoom in and out.
Selecting and deselecting units is done by left-clicking (no multi-selection for now) and the movement command is given by right-clicking.
The main unit is the CubeUnitBlue character (ingore the red ones) and I use it as a subject for the navigation tests. I did not have time to make the blueprint event graph look clear, but the short movement script is currently located in the “Movement” comment.
just enabling detour crowds doesn’t automatically make them work in a noticeable way. I’ve been working with them a bit now and @Lukaz Furman has pointed out a few things to tweak that helps the avoidance become more noticeable as well as a way to debug detour crowds. You can check out my thread here:
Thanks for the link.
However, I am struggling here with something that should work properly even without detour crowds (I just wanted to implement it in advance, so that I won’t have to do that later). For now, two characters are frequently not able to avoid each other. Maybe checking out the above project .zip would help understand my problem better.
So a few things that look a little off in the project.
The capsule component is set to a size of 5. I increased it to 30
The result is the characters “sliding” around each other if they collide.
Thank you very much for the insight 
I have changed everything accordingly and it works much more conveniently. But there is one thing that actually is supposed to be the core of the gameplay, which I still do not now how to resolve. That is, static meshes will be added to characters during runtime making them larger. Since the capsule component remains the same size, the units will start to overlap when sliding against each other. Making the capsule larger will not work properly as the characters will most often be irregular shapes.
Would there be any solution to that?
recast nav mesh doesn’t currently support this if I recall. Maybe @mieszkoZ can correct me but I believe the closest you can get is setting up additional nav meshes. But that only solves 1/2 the problem.
To do that, you need to create different sized agents in your project settings under Nav Mesh Generation (I think, but I don’t have the editor open right now). The result is that it created multiple different nav meshes for different sized agents. The engine then does some black magic to figure out what navmesh the agent should use (I think but am not sure it’s based on the capsule component).
The odd shape thing is different. You may need to set up your own override for the crowd agents that use something other than a radiusOR change the up vector on the capsule somehow and have it be longer than it is tall. That’s a tricky one really. Not completely sure myself.
The problem, @DarkLiquidus, is that your idea is quite unique and we don’t have anything that will support it out of the box. The best fit from what I see would be making characters navigation obstacles. I remember I discouraged you from using it, but in your specific case you don’t have much of a choice.
In another thread you mentioned navmesh is not generating fast enough - try tweaking navmesh generation properties towards best runtime navmesh generation performance. There should be enough data on the internet on the topic, or look at this video where I talk about this, but in short keep your tile size as small as possible and voxels (cell size and height) as big as possible.
I am also leaning towards the navigation obstacles idea.
In the thread you are talking about, Lukasz Furman concluded that there are no issues caused by the navmesh update speed. From my insight, the main problem is caused by the NavArea modifications (with more expensive path costs) not working properly. I think I explained what I mean in that thread in one of the comments.
Ok, in general I don’t want to create a new thread (it would be the fourth one regarding navigation) considering the “characters as navigation obstacles idea”, so I wanted to know whether the approach I describe below is proper.
In the Navigation tab of my StaticMesh asset I add a cylinder collision mask.
I set the AreaClass for this collision mask to a blueprint NavAreaForPaths I have created.
I set the radius of the cylindrical mesh to 15 (50 is the length and width of the StaticMesh)
In the NavAreaForPaths blueprint I set the default cost value to 5 and the entry cost to 2.
In the StaticMeshComponent of my character’ blueprint I change the CanEverAffectNavigation Property to true, so that the character is affecting the NavMesh increasing the path cost around itself.
And all of this sometimes works and sometimes does not. The characters clearly want to avoid one another. Nevertheless, they often follow a path which leads through the expensive NavArea, thus when a character reaches a path point located in such Area and consequently the NavAreaForPaths of one character starts to overlap with NavAreaForPaths of the other character, the character that is being navigated becomes enclosed in the expensive NavArea. Therefore, it no longer cares if the path leads through the costly area or not. It then wants to shorten its movement distance, which frequently results in a collision of the characters.