Updating Recast graph

General Recast graph
#1

Hi,

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?

#2

Hi

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:

  1. 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.
  2. 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: https://arongranberg.com/astar/docs/errormessages.html (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.

#3

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!

#4

As an aside, I noticed in your blog you have done some stuff with cooperative path finding. I don;t suppose this has made it into any betas has it?

#5

When you say it takes a couple of seconds. Do you mean that the game freezes for that time or that the update just shows up after a couple of seconds?

Well, you can find it in an older beta if you click on the ‘Show Older Versions’ button at https://www.arongranberg.com/astar/download (4.1.13 ‘cooperative’ branch).

#6

Brilliant, thanks.
The game freezes for that time.

#7

Do you have multithreading enabled in A* Inspector -> Settings -> Threads? (i.e. at least one thread).

Oh, and are you building for WebGL?

#8

Multi-threading is on and building for windows

#9

That’s odd.
Do you think you could post a screenshot of the profiler when this spike happens?

#10

Yep, will definitely give that a go when I get a minute. Thanks for all the help, btw, really appreciated.

1 Like
#11

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!