NavigationAgent doesn't seem to take radius into account until some agent gets freed

[viksl]

Godot version

3.5rc5

System information

Windows 10, Nvidia gtx 1660Ti, latest drivers, GLES3

Issue description

Check the test scene, the agents easily cluster without taking any radius into account for the collision avoidance but the moment any agent is freed (I think after you set the target location) - in this case when the target reaches the target position something gets recalculated and suddenly agents take radius into account but also jitter around (possible because they are clustered inside the collision radii of other agents? Some agents get randomly stuck too.

If you increase/decrease NavigationAgent radius in the Agent.tscn you will see it correlates with the distance for collision avoidance around agents when an agent is freed.

This is not related to target_reached signal itself, you can bind a deferred call to a button and free an agent mid navigation, anytime you do so the agents or navigation server will recalculate something and agents spread out to account for the radius (I assume), you can do it any number of times you want they will always collapse after a while and then spread out again, it seems radius is taken into accountat only for a while or some other reason?

You can play around with NavigationAgent settings to have less twitchy results but still the radius doesn't seem to have any influence until you start freeing agents.

This behaviour is not new to 3.5RC5, it's been around for a while, I've been testing navigation since beta releases and I think it worked like this at that time too.

Video: https://youtu.be/EooLuz_56T8 I've made a few videos of this, the minimal reproduction scene is simpler than the one in the video but issue is the same.

Steps to reproduce

When you play the minimal reproduction project just press mouse button right click to start the navigation and wait until first agent reaches target position and observe what agents at the beginning and around the gate do (sudddenly spread) and how they start avoiding each other.

Minimal reproduction project

Navigation agent free and radius issue.zip

[viksl]

@smix8 I hope it's ok like this as discussed previously, I pushed it a little to make it more prominent. Simplified the scene and made it in the latest RC5.

[smix8]

The issues are the settings on the NavigationAgent. The movement bugs are just the result and disappear with corrected properties.

The first issue is the NavigationAgent radius. It is to large. The actor and the physics body are both 1 unit in size but the rvo_agent radius is 2.5 units. Together with the very low neighbor_dist value this creates such a short response time for the avoidance that it creates erratic movement with each update as soon as enough other agents are nearby.

The second is that the path_max_distances and path_desired_distance are to small for the chaos that the physics sliding creates. The actors constantly try to move back to an old position because the collision slides pushed them to far away from their paths.

The third is that with such a low neighbor_dist and max_neighbors number but so many actors the simulation is unstable to begin with. Predicting a safe_velocity that works for the next 20 seconds time_horizon is impossible under this settings.

[viksl]

I understand that parameters are tight, as I mentioned above I purposely pushed them to bring the issues to light. My question here is why is there the suddent change of the behaviour after freeing an agent. Parameters being tight might be a problem but they don't change so why freeing an agent across the entire map has such a dramatic influence on the agents at the beginning? If just the parameters were a problem shouldn't this behaviour exist from the very beginning?

I might be missing something here sorry about that I just don't understand the shift. Even if I tone the parameters to get a decent result as you suggest freeing an agent still makes a difference for agents "miles" away. This inconsistency is what I find strange and I also pointed out the radius because clearly the before and after are influenced by it, feel free to change the radius up and down and see that it corresponds to how agents behave. Forget the jitter itself that's clearly a byproduct of this as you mentioned I get it but what exactly is the reason for such a big sudden change, parameters can be the reason since none of them changes over the simulation. I can even use decent parameters and still have agents act on freeing an agent sure it won't be so dramatic but it still does happen.

It looks like on freeing some part of navigaiton gets updated which wasn't updated on start maybe? (I have no idea xDDD).

I hope I clarified myself here better? If it's not an issues we can close this I guess.

[smix8]

It is an issue that needs solving as other users report similar stuff just different. Some propertie combinations create unstable simulations and a RVOTree reset goes off like a bomb when the simulation is already unstable.

E.g. I often see users with neighbor distance set to a lower value than the agent radius. That does not work, maybe need to add a clamp to some values depending on other settings because some value combinations are just a lost cause.

[viksl]

To be honest I get strange results even if I up the parameters or go towards default settings. I removed all the walls and rebaked the navmesh to get just a plane, set default navagent settings and the results are well weird, Freeing an agent still causes something. I again tried to play just with the radius to see if agents avoid each other based on that as you mentioned previously but again even with these settings it seems freeing an agent makes all the agents recalculate something but this time with the radius or they lose something maybe?

At this point I'm just playing with individual settings to see how they influence agents one by one. Sometimes I get closer to the behaviour after freeing but mostly not xD.

Frankly the inconsistency is bothering me the most at this point. I mean I even managed to get 6 agents stuck on a plan while the remaining 100 reached their target just fine. :0

I've been in this for past couple weeks and I can see this taking me quite more time just figuring out what to do not to break everything hehe.

[Scony]

I have quite a lot of similar problems even when using reasonable properties. Something is seriously broken either in Godot's code feeding parameters to RVO2 or in RVO2 itself. Unfortunately, I'm unable to create a small repro case nor I do have time to investigate it. Anyway, that's definitely the area that needs some extra testing.

[smix8]

While working on the rvo rework proposal https://github.com/godotengine/godot-proposals/issues/4522 I noticed this issue did not appear and seems fixed. I can add or delete agents in very large numbers at will without any visible negativ effect on the avoidance behavior of other agents. I guess this issue does not happen in the rework cause in the rework the agents keep a stable internal velocity.

[viksl]

That's cool, @smix8 do you have even just a rough idea at which beta version this could come for testing? :)