RecastNavMeshModifier Behavior

1

RecastNavMeshModifier’s behavior is not working as I would expect it to.

I have a game object named “Building” which has children with non-trigger colliders. This “Building” game object has a trigger collider and a RecastNavMeshModifier.

The trigger collider at the root game object is for picking and hopefully, it is being used as the geometry source for RecastNavMeshModifier. I’m starting to think the collider is being ignored.

After initially adding this Building game object, I’d like to remove the building from the Recast graph but it is fighting me. Here is what I’ve tried:

  • Disabling the trigger collider and calling AstarPath.active.UpdateGraphs(…)
  • Modifying RecastNavMeshModifier to set Include In Scan to Always Exclude.

I don’t want to delete my game object because it further segments into parts. I just want it (and all of its children) to be ignored from the Recast graph after a graph update.

  1. What is the typical workflow for removing a game object from a graph, assuming that RecastNavMeshModifier is not it?

  2. Is RecastNavMeshModifier supposed to be hierarchical? It seems like it might be ignoring the top-level trigger collider.

  3. GraphUpdateObject.updatePhysics seriously needs to be renamed to something else. :slight_smile: The Obsolete tag may help end users migrate to a new name.

  4. Why does AstarPath.active.UpdateGraphs only accept a bounds object? Wouldn’t it be faster to have an overload that accepts a RecastNavMeshModifier instance? Alternatively, why is UpdateGraphs needed at all when a dynamic RecastNavMeshModifier instance is moved?

Thank you!

2

The RecastNavmeshModifier will apply to the current GameObject, not any children. You can add RecastNavmeshModifiers to the children as well, if you want.

Disabling/destroying the collider and calling UpdateGraphs should do it. Setting AlwaysExclude should do it as well. You can alternatively attach the DynamicObstacle component, which will automatically call UpdateGraphs with the collider bounds, if the object is destroyed or moved.

Triggers are always excluded from the graph, I believe. I’m not quite sure if setting AlwaysInclude on the RecastNavmeshModifier overrides it, though. Not at a place where I can check the code at the moment.

I agree

A bounding box is the most general type by far. For a RecastNavmeshModifier it would be essentially the same thing as calling UpdateGraphs with .collider.bounds, so it wouldn’t be a big simplification.

3

I’m definitely struggling to make this integration fully work. I’m 80% to the finish line but the remaining 20% needed for polish is blocking completion.

I’m unable to add a RecastNavMeshModifier to every game object that has a collider… A building, starship or space station in my game may have thousands of box colliders. This works fine with Unity’s built-in physics, but integration with A*Star Pathfinding presents a few challenges.

The API does not provide enough flexibility to help me identify which collider(s) in a hierarchy should be used for pathfinding.

Tags and layers do not solve the hierarchy problem. i.e. a typical workflow is to have all nested children use the same layer as the parent (i.e. all exist on the ‘building’ layer).

  • As a workaround solution, is there a way I can pass a list of input colliders to explicitly include in graph construction and updates? This would help me tremendously, as I would only supply the top level ‘building’ game object that has my trigger collider and RecastNavMeshModifier.
4

You can actually do this. I think the code below should work, but I haven’t tested it.

var graph = AstarPath.active.data.recastGraph;
graph.collectionSettings.onCollectMeshes = (gatherer) => {
    var m = gatherer.ConvertColliderToGatheredMesh(myCollider, myCollider.transform.localToWorldMatrix);
    if (m is RecastMeshGatherer.GatheredMesh gm) {
        gatherer.AddMesh(gm);
    }
});
graph.Scan();

Note that these will be added IN ADDITION to all other meshes that the recast graph would normally rasterize.

1 Like
5

Thank you, Aron!

As I was about to test this new option (thank you!), I discovered that the presence of a RecastNavMeshModifier removes the need for tag and layer filtering. My previous testing to validate this as an option was flawed because I forgot to remove layers on a secondary graph. Thank you for the awesome assistance.

1 Like