Hello, we are using A* Pathfinding Project 5.3.8 in our project and Unity 2022.3.40f1
At the game scene, we have used the AStarPath “Generate cache” option to calculate the whole graph outside runtime and the graph cache file is propertly assigned and “Cache startup” is enabled. At the AStarPath Settings, we set to disable the “Scan on Awake” option and “Navmesh Cutting Update Interval” to -1.
Also we never call to AstarPath.active.Scan();
The issue is that during the gameplay we instantiate some objects that has “NavMesh Cut”, so we can update that part of the graph properly.
This “NavMesh Cut” is setup as a Box, “update distance” 0.4, “Radius Expansion” Don’t Expand and “Affected Graphs” Everything. Other options are just deactivated.
The issue is that at instantiating the first “NavMesh Cut” , the whole graph is recalculated automatically.
That takes so long and it is something that we want to avoid. We are using AstarPath.active.UpdateGraphs(scanAreaBounds); to update just specific areas of the graph.
Also I want to say, that the whole recalculation of the graph only happens with the first instantiated “NavMesh Cut”, later we can use AstarPath.active.UpdateGraphs(scanAreaBounds); as expected.
Noticed that we are using the generated cache data correctly, but for some reason the whole graph is recalculated at instantiting first “NavMesh Cut”.
We need to avoid that recalculation of the graph at instantiting first “NavMesh Cut”. How we can do that ?
A navmesh cut shouldn’t cause the whole graph to be recalculated. Are you sure that’s what’s happening? Can you use the unity profiler to determine what is using the cpu time?
Hello, I am performing several test to discover what is happening exactly.
Our map scene is really big and it contains a large amount of NavMesh Cut.
I have noticed that when I use the options “Generate cache” or “Save to file”, if I later remove the NavMesh Cut from the scene, the NavMesh Cut information is not saved or ignored after load from the cache or the file. If I don’t remove the NavMesh Cuts from the scene, it just takes so long to load. So it seems is not using the cached/saved data neither.
Can you clarify how we can speed up the loading of the scene while keep using the NavMesh Cuts ?
Our idea was to save the NavMesh Cuts data at the cache/file, but this seems to not work.
It sounds like what you are doing is loading a bunch of objects that cut the navmesh into the scene, and then they all try to cut the navmesh at once, and it causes a hitch? Is that maybe what you were interpreting as being caused by a graph recalculation?
Yes, it is exactly the amount of navmesh cuts that are at the scene initially.
Is there any way to keep the amount of navmesh cuts but reduce the time required to load the scene that contains all these navmesh cuts?
Other option that we are thiking on it is to use RecastNavmeshModifier instead navmesh cuts, but these cuts seems a lot less precise on the cuts plus we will take some time to addapt the whole scene to that.
I’m presuming the game allows for dynamic object placement, because otherwise you can just bake the mesh with whatever holes in it you want, and you wouldn’t need to cut anything at runtime.
So with that assumption, and depending on your needs, instead of using runtime cutting for everything all at once, you might be able to either -
Only cut the mesh for objects actually on screen (or within a certain radius of the player), or
Batch the cuts into smaller groups that are executed across several frames, or
As it probably happens on map instantiation, hide it behind a loading screen (which you might already have anyways), or
Actually bake a new navmesh every now and then (maybe when the player goes to save their game).
The other thing that comes to mind is using a different type of graph for this. If players are placing dynamic objects, there might already be a grid system of some sort. You could use a grid graph, and mark all the nodes under objects as unwalkable.
At the scene initially we had 357 navmesh cuts, but we will need a lot more from a second scene that is loaded additively and that we don’t even added these navmesh cuts to this second scene, mainly because we already noticed the issue related the loading time with the current amount.
The size of the Recast Graph is 1024 x 100 x 1024 and we had 2926 x 2926 voxels, divided into 85849 tiles.
Yes, most cut need to be dynamic, the initial holes may disappear at runtime and also it may generate new ones.
I think that will not help a lot at our due the game server needs to know the whole map navigation from the start
and 3. yes we had a loading screen, but the point is that it takes so long, if we batch the cuts into smaller groups at the end we will need to wait for its completion , so I guess the loading time will remain the same.
But I think the navmesh cut is not bake, at least we try and it was not possible, so this willl not help unless we use something different than navmesh cut.
Yes, probably we can try to use a different type of graph, which is the type that you recomment us to improve the calculation of the navmeshcuts ?
Is your tile size really tiny? If my calculations are correct, you are using a tile size of 10. That’s pretty small and will add some overhead just due to the high number of tiles.