-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NavigationAgent doesn't seem to take radius into account until some agent gets freed #62469
Comments
@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. |
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 The second is that the The third is that with such a low |
I understand that parameters are tight, as I mentioned above I purposely pushed them to bring the issues to light. 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. 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. |
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. |
To be honest I get strange results even if I up the parameters or go towards default settings. At this point I'm just playing with individual settings to see how they influence agents one by one. 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. |
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. |
While working on the rvo rework proposal godotengine/godot-proposals#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. |
That's cool, @smix8 do you have even just a rough idea at which beta version this could come for testing? :) |
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
The text was updated successfully, but these errors were encountered: