Local avoidance on a grid graph; any way to keep agents on the valid parts of the grid?

If I have a large number of agents using RVO for local avoidance, they can sometimes push each other through ‘walls’, walls being nodes disabled on the grid graph due to some physics object being there. I tried using RVO obstacles on these walls but agents just spasm when they hit them, and they still pass through. Is there some other way to make sure RVO agents stay on the valid part of the grid?

Hi

Sorry, the grid graph doesn’t have support for that yet.
You can try to fake it for common areas with square obstacles, but it will have to be all manual.

Sorry, wiped the database an hour ago or so.
DNS changes are in progress right now, so the new forum will hopefully be up in a few hours.

When are you planning to add support for it for grid graphs? I can’t use a navmesh graph since I need to be able to re-generate parts of it at runtime.

There is a version made by a member of the community. However I have not tested it on the latest version, so it may or may not work.
I could not find it using the search function on this forum, but I am in the process of moving the forum to using discourse instead, and I could find it there.
Check this link: http://104.131.28.95/t/rvonavmesh-equivalent-for-gridgraph-updated-code-inside/227

I can’t seem to find it either, and I can’t access that IP. Glad you’re moving to Discourse btw :slight_smile:

New forum is online, and here is the new URL RVONavmesh equivalent for GridGraph (updated : code inside)

Ok, I’ve used that and it creates obstacles just fine, but the agents still behave very poorly around them - about the same way they avoid RVOSquareObstacle. I’ve tried many different combinations of settings on the RVO agents and simulation, but the result is always the same - they frequently penetrate the obstacle, oscillate about a lot, and often get stuck inside the obstacles.

I’m finding the code really hard to follow, there are lots of commented out parts and parts with misleading comments. It’s understandable given how much the code has needed to chang recently I suppose, but I can’t help but feel disappointed that this doesn’t just work. Are you planning to work more on local avoidance? If so, when?

Ok, it looks like for gaps in the grid graph that are only one unwalkable cell thick, since obstacles are created on the unwalkable nodes, there are obstacles created on the same position but with opposite directions, which if the agents touch they get stuck in forever.

I reworked the code to put obstacles on the walkable nodes, but now I’m finding that the performance is terrible - around 3000 obstacles and 300 agents and it’s bringing my 40-core development machine to its knees. It seems to be OnEnable on the RVO controllers that’s taking most of the time - each call is 40-50ms, and it’s called fairly regularly in my case (agents created often, and go in and out of normal navigation states often too). Without the obstacles, it doesn’t show up on profiles.

Could you investigate RVO controller OnEnable performance in the presence of obstacles at some point?

I’ve put the code in a gist here:

Hi

I have to agree that the obstacles and local avoidance in general isn’t working as good as I would want it to.
It is really annoying because I know about better algorithms, I just cannot use them because of licensing issues (they were in the project previously, but had to be removed). So I had to replace those algorithms with the current ones, which work, but they are not as fast, nor as good as the old ones. I will continue looking for better algorithms however.

Hm, odd that the OnEnable call is taking so long. It doesn’t do much. The one real thing it does is that if you are using multithreading and double buffering, it will wait until the threads are done calculating.