NavmeshCut vs UpdateGraphs() at runtime

EDIT: nevermind figured it out

Hello, I’m using the grid graph, and looking to carve out pieces of the navmesh at run time, and then fill them back in, on a somewhat regular basis. It is for, when two units/formations of men are in combat, a rectangular carve is made around them so other units don’t path through them, and then it is removed. I’ve tried two solutions. One is to call:

AstarPath.active.UpdateGraphs (unit.collider.bounds);

where the collider bounds is the unit in combat bounds, and that seems to work and is performant, except it just keeps accruing new carves out of the navmesh every time I call it, with no way to find and fill back in the old carved out spot once it is no longer needed, which eventually just makes the map unusable. Is there a way to track every call to update graphs and undo the unneeded carves and keep the still needed ones?

The alternative is to spawn a simple game object prefab for each unit at start that just has the NavmeshCut script on it, is sized to the unit size, and moves down into the graph on moving into combat, and then on moving out of it moves up into the air out of the graph. This works and does not have the above issues, as it only carves when moved into place and un-carves when moves out of place, but it is not very performant. Are there some recommended performance improvements for this type of navmesh cutting? Chnaging the shape, radius expansion, or some such? The update distance shouldn’t make that much of a difference, as I do not move it continuously, but just into place once, and then out of place a long distance maybe 30 seconds later. Would settings on the grid graph make it faster? bigger nodes? Using multiple smaller graphs to cover the map (it’s one big terrain with few features)?

Any recommendations on how you would approach this?

Thanks!

actually to update, the navmeshcut doesn’t work on the grid graph, and I only thought it did because I still had a recast graph cached and in the scene. I can use obstacle tagged colliders instead? and update the graph every time they are moved in or out of the graph? Would that be de facto like a navmesh cut for the grid graph?

Also, does caching the graph prevent any runtime updates like this?

further update to this question is that because it’s a grid graph, dynamic grid obstacle works, just found that one. I’m wondering if this is optimally performant, or would I be better off using a GraphUpdateObject with custom settings, set pass in unwalkable for when activate, cache the values with trackChangedNodes, and then restore them when I want to turn it off (perhaps just increasing the move cost instead of making it outright unwalkable), as I don’t really need to update it constantly.

Although, looking at the code for dynamic obstacle it calls DoUpdateGraphs() only if the extents change, so if it stays in place, only moves rarely, and keeps it size the same the whole time, it should still be pretty performant?

ah it was GraphUpdateScene component I wanted after all. Thanks internet for being my rubber ducky.

1 Like