I have been playing around with this but was wondering if what I am experiencing is typical or whether I am doing something wrong.
This is in debug
I have a terrain, 1000 x 1000. This will grow to approx 4000 x 4000 so I can not really use a grid graph. So I am using a Recast graph. The problem is I want to add building and have these walkable by the enemy. It is a FPS game and for buildings think Rust/fortnite.
I can add a foundation and then call
Bounds bounds = foundation.colliderBounds.bounds;
var guo = new GraphUpdateObject(bounds);
// Set some settings
guo.updatePhysics = true;
AstarPath.active.UpdateGraphs(guo);
But this seems to add a second or 2 delay. I have removed the logging line about static meshes, as i was getting 42000 debug messages about them, and reduced my tile size down to 32, but I still get the delay. My understanding was that UpdageGraphs should merely queue the changes so should be pretty much instant, even if the calculation of the graph isn’t. Am i missing something or is this a artifact of debug mode and nothing to worry about?
When you have rasterize meshes enabled on the recast graph there is unfortunately no way for the package to find meshes within a specific bounding box (the area to update) so it has to find all of them. This can be pretty slow. If you have a large graph and you are doing frequent updates I would recommend one of two options:
Disable rasterize meshes and enable rasterize colliders. The scripts can find colliders within a bounding box much more efficiently using the unity physics api. Rasterizing colliders is usually faster anyway since colliders have fewer polygons than meshes.
Disable rasterize meshes and attach the RecastMeshObj (with dynamic=false) to all non-moving meshes you want to include and attach a RecastMeshObj with dynamic=true to all potentially moving meshes.
That message has a very good point and you should not ignore it. Scanning will fail in a standalone game with statically batched meshes. See this page for more info: Error messages - A* Pathfinding Project (near the bottom). Switching to colliders will resolve this issue in any case.
The current beta version also has some improvements for updating recast graphs. But those are mostly noticeable when you are updating very large parts of the world at the same time. Not when doing smaller updates.
Thanks for the reply. I tried option one and things are still taking a couple of seconds to update. I am guessing this is because the bounding box for the change is intersecting the terrain and therefore causing a large update? It is not impacting any other collider
Anyway, I think I have a better alternative. Since the buildings are largely self contained, I am thinking of each building having its own point graph, dynamically created and added to as the building grows. Then the recast graph can bring the AI to the building and then they can use the point graph to go from there. This way the buildings only have to cut the recast graph, which is exceptionally quick.
For what its worth, this is a multiplayer game and I use the path-finding to generate curves for my zombies, so I can have lots of them moving without killing bandwidth. Its a challenge, but good fun!
Hmmm, so with my new terrain settings, using a much smaller terrain sample size, this now seems to work absolutely fine. Will try and backtrack to see what fixed it!