RVOControllers "pushing through" walls / non-traversable areas of AStarPath Grid

[dagerg]

Hello,

First let me say that I’m long-time Unity Developer and I recently got the A* Pathfinding project and I love it. So good! This package is been a breeze to set up and get working.

For context: I am building a game in Unity 2023.2.4f1 and using A* Pathfinding Project from Unity Asset store v5.1.2. I am using an AStarPath Graph component to identify boxes that can be traversed by RVOController agents. I have a single RVO Simulator for the RVOControllers, and the RVOController scripts are attached to the “entities” in the game. Ive figured out how to scan the graph for pathfinding, and the agents pathfind just great - that all is working as I would expect it.

One of the things Im noticing is that when I have several RVOControllers bunching up around say a doorway or so, sometimes the agents will “push through” the blocked areas. I’m using the AStarPath component to Update the grid graph to make the intersection between a door and a room impassible on the graph (the boxes between the room and the corridor show grey, not blue, which I assume means they are “impassable”), and in general a single RVOController will respect the boundary. With several RVOControllers, sometimes they “push through” and an agent or two gets through the door, which is obviously something I want to fix.

I saw a very old thread on something similar, here:

Local avoidance: RVOController push through/into obstacles

I ran into a problem where objects get pushed through obstacles or non-passable regions, caused by local avoidance. Please see the following video: The green sphere represents the target point for agents. As shown in the video, agents get pushed through the gray wall that is near the target point. I tested it with 3.5.2 and 3.5.9.1 releases using Unity 4.6.0b21, the problem occurs in both pathfinding packages. Here is the test project (you need to import your pathfinding package to make …

I guess my question is - how do I get the RVOControllers to respect the non-traversable areas of the GridGraph? I’ve tried DynamicObstacles, that doesn’t seem to matter. I’ve changed the agent radius up and down and that seems to help a little but doesn’t seem to eliminate the issue.

Do I need to change the GridGraph to a NavMesh? When I try to add a RVONavmesh component, it says its deprecated and that the RVOSimulator allows you to modify the Navmesh properties - but since Im using a GridGraph, Im not sure Im using a NavMesh? I do have “use navmesh as an obstacle” checked on my RVOSimulator, but again - not sure if thats used given Im not even sure there’s a navmesh in the scene given Im using a GridGraph on the AStarPath component in the scene.

Any advice/insight on the proper way to get RVOControllers to respect the traversable areas of the GridGraph and/or if I should use something else with an RVOController (not the AstarPath GridGraph) would be most appreciated!

[aron_granberg]

Hi

@dagerg

I do have “use navmesh as an obstacle” checked on my RVOSimulator, but again - not sure if thats used given Im not even sure there’s a navmesh in the scene given Im using a GridGraph on the AStarPath component in the scene.

This should be the solution. Even a grid graph is a navmesh of sorts.

Do you have a video of this happening? What movement script are you using?

[dagerg]

Thanks @aron_granberg for your response. I was using on my entities the following scripts:

• RVOController
• Seeker
• AIPath
• Simple Smooth Modifier

This was all on a GridGraph type of graph.

The “Entity” script (one that I wrote myself, its just a Monobehaviour - not to be confused with ECS) that is on the top line “entity” gets the AIPath in Start() and in the Update() method simply sets its target destination as the Player’s object’s transform.position.

I don’t have a picture but I suppose I could go back and create one. Basically what was happening is that other RVControllers (entities) would get close to the Player (which is the target) and would “push” the ones in front closer to the target, and it would push them off the Grid Graph, even past walls or just areas that are not traversable, so I’d have a bunch of entities piling up outside the graph with no attempt to move them back onto the graph - eg: they seemed perfectly happy to be off graph.

I have been trying other techniques, namely I reconfigured the AStarPath to be a Recast Graph instead of a GridGraph, and the “entity” prefab to instead use:

• RichAI
• Seeker
• Funnel Modifier
• Rigidbody
• Capsule collider

This seems to work for the most part, I’m assuming the Rigidbody keeps it “on the graph” mostly because the Rigidbody collides with walls that have colliders on the same layer as it, but its movements were a bit less smooth and it doesn’t seem to fully stop when it gets close to the target, it keeps fidgeting around the target. This solution “seems” to respect the boundaries of the Navmesh and obstacles, but I don’t love how “jittery” it gets. For this implementation, I’m moving the entity by setting the RichAI’s destination as the target position of the player. But Im assuming that this makes the RichAI set the position of the transform (assumption on my part), and I know that if there’s a Rigidbody you shouldn’t do that - you should say rigidbody.MovePosition(), but I don’t see any function on RichAI or AIPath that allows you to move incrementally down a path - just set target destination, so I assuming I’m using this wrong as you really shouldn’t be moving an object with a Rigidbody this way.

I feel like there’s something missing that I’m not doing in both approaches, and I’m not sure what I’m missing. I’m happy to post screen shots of components or behaviors if that helps.

Open to other ways to implement this. Basically my issue is now, if I use RVOControllers, what Im seeing in behavior is a non-starter because I cant have entities going off graph. If I use the RichAI and Rigidbodies, the amount of jitter in the movement is a non-starter.

So I guess my next questions are:

1. If we assume my implementation of GridGraph and RVOControllers with “carve navmesh” was correct, what is forcing the RVOControllers “off graph” and how do I solve for that?
2. If I went with the Recast Graph / RichAI / Rigidbody approach, how would I correctly move the entity so instead of setting target destination, move the Rigidbody with MovePosition instead of just setting the destination in the RichAI? Is it even advisable to use Rigidbodies with AI components?

Also - is there a place I can download the sample projects? For some reason I could not get them to install when I installed the A* pathfinding component from the Asset Store.

Thanks in advance!

Note: some pics for reference:

video.mp4

[dagerg]

Hi @aron_granberg,

Any thoughts on this one? I’m pretty stumped. Any advice would be welcome.

Thanks,
Greg

[aron_granberg]

Right. You are using the AIPath movement script. In that case you’ll also need to enable the “Constrain to Navmesh” option on the AIPath component.
The RichAI and FollowerEntity components do this automatically. The rigidbody doesn’t have anything to do with it.

Generally the recommended way nowadays if you have a recast graph is to use the FollowerEntity component. Its movement is more robust than AIPath and RichAI. (you can remove the RichAI, Seeker and FunnelModifier components, as the FollowerEntity replaces all of them). This is the setup in most example scenes. Though it will not interact with physics using rigidbodies at the moment, since this is kinda tricky to do performantly when using ECS behind the scenes.

@dagerg

Also - is there a place I can download the sample projects? For some reason I could not get them to install when I installed the A* pathfinding component from the Asset Store.

Check the installation guide: Installation Guide - A* Pathfinding Project