Hey, just reaching out to see if the current RVO system in 4.2.19 supports the generated RVO walls created by the RVONavmesh component. I have a custom PID system linked up to a vehicle controller that works perfectly with the traditional RVO Controller. If I set up an obstacle to have an RVO Controller or the Square RVO Obstacle, any agents will have the correct RVO signals be outputted. i.e. I’m getting a RVO direction when a collision is predicted.
This however does not seem to work with the RVONavmesh component. I can visually see the generated obstacles in red when Draw Obstacles in the RVO Simulator is enabled, however they do not seem to have any affect on RVO agents. An RVO Agent on a collision course with a RVONavmesh Obstacle will never generate a new target direction through CalculateMovementDelta.
Is there something I’m missing or have incorrectly configured or does 4.2.19 not support RVO Navmesh Obstacles with the RVO Controller?
I don’t remember exactly how it is set up in 4.2.19, but I know that the RVONavmesh component had various issues in 4.2.x. In the beta version, this has been improved.
Following up on this, I’ve switched the project over to 5.0.2. I’m handling navigation using a custom controller and the RVO Controller component. It does not seem like RVO is taking into account the Navmesh for avoidance. Is there a setting or some configuration that I missed that I need to set up? RVO works between agents, just not with the terrain.
Other notes, I have “Use Navmesh as an Obstacle” enabled in my RVO Simulator. With the removal of the RVONavmesh obstacle, is there any way to debug or view the RVO bounds and debug if the navmesh is actually impacting RVO navigation?
Thanks. This was indeed an issue. This feature had gotten lost for the AIPath/RichAI movement scripts during a refactoring.
I’ll include a fix in the next update.
You can enable various debugging options on the RVOController component.
Oh, awesome! Did not realize that. Tried 5.03, the RVOController component still does not seem to be taking into account navmesh edges. Does RVOController not support this, or did this also end up getting missed like with the AIPath/RichAI movement script refactoring?
I’ll look into how the other scripts are implementing this and see if maybe I’m missing something. If I’m correct, I should just need to pass in the target using SetTarget and CalculateMovementDelta to get the RVO movement, but CalculateMovementDelta doesn’t seem to be returning any impact from navmesh, only other RVOControllers.
Edit:
What is the intended behavior of RVOSimulator.useNavmeshAsObstacle? It seems like it doesn’t work in 5.03 for any of the controllers including Follower Entity.
I’m testing inside of the Recast 3D demoscene and setting the Bot Entity Radius to a large number like 2 (wider than the visual width of the bot). RVO seems to work between bots, but it does not seem to avoid the edges of the navmesh in the scene and moves right up to it.
I’ve been interpreting useNavmeshAsObstacle as a way to adjust the RVO control based on the entity radius, so the agent will not navigate off of the navmesh. Is this incorrect?
In the following imgur video, I have the bots set up with local avoidance enabled, a radius of 2, and RVOSimulator.useNavmeshAsObstacle enabled. It seems like they’re still hugging the navmesh and not taking the navmesh into account for RVO.
The navmesh is defined as all points where the agent’s center is allowed to be. I.e. it is already assumed to be shrunk by the agent’s radius. Therefore, the local avoidance system will also allow the agents to move right up to the border of the navmesh. If you want to increase the radius of the agents, you should also increase the agent diameter setting in the recast graph settings.
You’ll also need to call rvoController.rvoAgent.SetObstacleQuery(currentNode), if you are writing your own movement script.
In the next update, this will be just rvoController.SetObstacleQuery(currentNode).
This is necessary for the agent to figure out where to start searching for obstacles (there may be multiple overlapping graphs in the scene and so on).
Ah ha! I see, rvoController.rvoAgent.SetObstacleQuery(currentNode) seems to be what I was looking for. I can now visualize the navmesh obstacles in debug. Unfortunately my agents still don’t seem to be reacting to navmesh edges and are still able to be forced off of them by other navmesh agents (I’m not seeing any change in the output of rvoController.CalculateMovementDelta() when I debug it out. When I call SetObstacleQuery(), I’m also getting an Invalid allocation error for the jobs system.
System.IndexOutOfRangeException: Invalid allocation -2
This Exception was thrown from a job compiled with Burst, which has limited exception support.
0x00007ff8779e0c5e (32d7499ca62292c42dfe40901677ec0) burst_Abort_Trampoline
Also in reference to RVO navmesh obstacles, what is the purpose of Navmesh obstacles? It’s to keep in mind the navmesh when doing RVO avoidance i.e. keeping the agent from navigating off the navmesh from RVO inputs right? If increasing the radius of the agent isn’t a good way to do the testing for if RVO navmesh is being properly applied, is there a better way to test this? I guess I could set up a crowding scenario with a bunch of RVO agents on a navmesh.
Edit: Never mind, outputting the AvoidingAnyAgents bool seems to be also returning false for navmesh considerations. Seems like I can just use this bool to test if its working. If my agent is completely off the navmesh, is there a reason that AvoidingAnyAgents is returning false here? Shouldn’t it be attempting to RVO back to the navmesh?
Yeah, sorry. I was a bit quick in implementing that. If you don’t call it at the right time during the update loop, it can error out. I have a fix ready for the next update.
The purpose is that if an agent is pushed against the navmesh border, the RVO system should realize this, and apply back pressure to keep the agents from being pushed too much in that direction.
Otherwise, the rvo system will think that the agent can just continue walking off the navmesh, even if this is not actually possible.
The RVO system only considers the navmesh border. So if it’s off the navmesh and far away from it, it will not have any effect. However, I recommend that you also enable the Constrain Inside Navmesh option on your movement script (or if you are using your own movement script, that you clamp the agent to the navmesh in some other way too).
Thank you so much for the answers to my questions, clears a ton up. Noticed that the errors were fixed on the latest update too!
Still can’t for the life of me figure out why my agents aren’t considering the navmesh. I have agents that are clearly pathing towards the edge of the navmesh and will move off as they’re forced by other rvo agents, and the visual debug shows that the agents are aware of the navmesh edge, but for some reason they never consider the navmesh in the avoidance output and AvoidingAnyAgents is outputting false for the navmesh edges (it returns true when avoiding other agents).
