Question on: AstarPath Max Update Frequency variable

Hopefully this is straight forward, I was wondering exactly what Max Update Frequency is doing / what it effects (I’ve read the documentation on it and it seemed simple enough). However, after trying different settings (low numbers like 0.5 and high numbers like 15) I can’t see any difference in what is happening with the graph.

In my project I’m updating various agents with a NavmeshCut script on them, and the only setting that seems to matter in how often the graph is updated is TileHandlerHelper UpdateInterval. So perhaps MUF doesn’t apply for this type of update? Or is it doing something and I just can’t tell the difference? I would expect that if I set MUF to say, 15, the graph would only update every 15 seconds, but clearly this is not the case.

Any info is appreciated, thank you for reading.

Hi

I have recently in my dev build clarified the documentation a bit

If toggled, graph updates will batched and executed less often (specified by #maxGraphUpdateFreq).

This can have a positive impact on pathfinding throughput since the pathfinding threads do not need
to be stopped as often, and it reduces the overhead per graph update.
All graph updates are still applied however, they are just batched together so that more of them are
applied at the same time.
However do not use this if you want minimal latency between a graph update being requested
and it being applied.

However this throttling currently only applies to graph updates applied using GraphUpdateObjects. Navmesh cuts are internally applied using a different mechanism (WorkItems, a lower level scheduling primitive that the A* Pathfinding Project uses) so navmesh cutting would not be affected.

One thing to note is that if it would have been affected by the throttling and you would have set it to 15 seconds, then all graph updates during those 15 seconds would be batched together and applied at once. That is probably not optimal since they would only override each other, so the setting on the TileHandlerHelper is the best place to adjust it.

1 Like

Thank you for the very quick update (and clarification)! Two related follow-up questions from your response if you don’t mind:

  1. Using my crazy 15 seconds as an example, aside from the possible override issue, would it even be a good idea to potentially apply lots of updates at one time (seems like a lot of potential work to do)? As opposed to trying to spread out updates as far apart as possible?

  2. Similarly, for NavmeshCut scripts, is there any sort of ‘coroutine’ style behavior updating when it comes to cutting geometry? Or is everything ‘done in 1 frame’? I was just wondering if there would be an advantage to allowing more time between updates (so the update could be ‘spread over some number of frames’ without being ‘forced to finish’ before the next update).

Hi

  1. Likely not. This is mostly relevant when you are applying lots and lots of updates and that has some overhead because it has to recalculate the node areas (the colors you see in the scene view) every time. But if you batch them, it only has to recalculate the node areas once for the whole batch.

  2. Not for navmesh cutting. But check if there is a performance problem first.
    If you are only updating a very small part of the graph, try making the tiles smaller since it only has to update the tile that was changed.

1 Like

Thanks again for the info, I really appreciate it.

No problem.

Btw, when you have used the project for a while, a rating and/or a review in the Unity Asset Store would be awesome :smile: