Radius and obstacle avoidance

Hi

I’ve not been able to quite work this out from the docco and demo scenes. I’m hoping to understand how agent radius works with obstacles in a little more detail.

I have in my trial scene :

  • A 2D game
  • A grid graph
  • Big wide open spaces with an obstacle in it. This is a sprite with Box Collider 2D on it. The agents mostly avoid it OK apart from the point I’ll make below :slight_smile:
  • Collision testing turned on for the graph, collider type = Point
  • Agents which use AI Path
  • The AI Path agents have a big radius e.g. 50
  • RVO turned on. Works well, agents give each other a wide berth based on their radius

What I don’t quite understand is whether the radius is just for feeding into RVO or feeds into obstacle avoidance too? When the agents avoid the obstacle their radius is well within the obstacle. I had expected the radius to just graze against the obstacle, but don’t know if that’s a correct understanding.

I saw the Radius Offset script and added it with the same radius as the agent’s radius, but doesn’t seem to have done the trick.

Just wondering if there’s anything I can do to make sure the agent’s radius stays outside obstacles? I think maybe I need to dig into recast graph?

Thanks :slight_smile:

Hi

The navmesh is defined such that it should be valid for a character’s center to be anywhere on it. So the grid graph should already account for the character’s radius. You can do this using the diameter setting on the grid graph and/or using the erosion iterations parameter.

Thanks for the reply.

So this is around switching to collider type = circle? One thing I didn’t mention is that different agents will have different radius with possible large differences. Presumably this approach would make all agents act like they have the same radius? I didn’t quite follow what you mean, not sure if there’s a particular bit of docco / example I should look at? E.g. not sure about “the grid graph should already account for the character’s radius” vs setting a single diameter for the grid graph.

Is Radius Offset script not applicable here? From the docco it seemed like it was what I was after - maybe doesn’t work with 2D?

It is applicable, but it doesn’t always work well.

Instead, I would recommend that you check out this tutorial: Multiple agent types - A* Pathfinding Project

Thanks for the pointer mate, have had a look at that. I’ve set up my grid graph to use collider type = Circle and set a diameter that mostly corresponds to the radius of my agents.

Was hoping you might be able to help me with a couple of further things? Struggling to answer these based on the docco and sample scenes.

  1. Is the diameter there the number of cells? I.e. if you want it to match 2 x the radius of the agent you’d need to convert that radius to number of cells? If I just set it to 2 x the agent radius it’s hugely bigger than expected.
  2. Even assuming it’s cells not real diameter, the diameter of the grey area it creates around my obstacles doesn’t seem to match the number of cells specified?
  3. The agent seems to be plotting some pretty weird paths in / around the untraversable area? It’s trying to follow that always-evolving green path in my screenshot which tries to take it through the area. It stops and turns around a lot and generally seems to be stuck. I notice there’s an orange path there too which seems to perfectly go around the obstacle, but the agent doesn’t seem interested in following that! Not sure if I’ve misunderstood something there?

Thanks again

Lee

Yes, a diameter of 1 corresponds to 1 node’s width.

It should be approximately correct, but note that it is a diameter, not a radius. So e.g. a diameter of 5 will be 2.5 nodes in either direction from the current node’s center.

Note also that the erosion iterations setting also affects this.

Looks like maybe you are using the radius modifier. That modifier only works well as long as your offset is smaller than the distance between your nodes (roughly).

1 Like

Thankyou, I seem to have the right diameter and erosion distance now, and removing the radius modifier fixed the weird path.