AstarPath.Update() / TileHandler.CutPoly() Frame Time Spikes

General
#21

Update:

So the idea this time is to:

-Create the ‘final graph setup’ in the editor.

-Capture the node data and assign a ‘baseTag’ (a field I added to the GraphNode class) marking what the node tag should be in a clean state.

-After any change is made to the navmesh through cutting after it is no longer needed and the ‘cutter’ is turned off, the navmesh ‘goes back to its original state’ (as it was before any cutting was done, just with no tag info).

-At this point, I tried to go through all the nodes to determine which ones no longer had their baseTag set properly against a list of the original base tags (using the nodeIndex to determine matches) to see what needs re-setting.

So the hang up I’m having is on how nodeIndex is determined. It looks like:
If you had 100 nodes, and you changed nodes 3 and 4, your index list would be 1,2,5-100, ~101, ~102 (not necessarily that, but with the 2 nodes using new numbers) with index positions never being re-used? So at this point it is a matter of matching up new node

#22

Hi

Just a question. Have you considered using grid graphs? It seems like they would be vastly easier to work with given your requirements.

#23

Have you considered using grid graphs?
-Yes, but unfortunately due to the size of the areas (up to x1.5km) and still needing a relatively high level of accuracy around terrain, the total numbers of grid nodes needed were well in excess of 1 million+. Even on my strong PC generation time was nasty, and eventually porting this to a less strong MAC prior to iOS deployment probably would end up crashing the program if I needed to make any changes.

As far as the navmesh goes, it only takes ~4.5k nodes to accomplish the same / better accuracy for that space. Even if I increased the number of nodes ten times, it still would be a drop in the bucket compared to the grid setup.