During what frames does pathfinding run: FixedUpdate, Update, a coroutine, etc.?

When do the pathfinding calculations and agents do their magic? This is very important for certain pieces of my code.

Is it possible to control the frequency of NavmeshAgent calculations for movement? I want them to be in sync with physics.

 

After some testing, I found out that it runs with every Update frame. Is there a way to coerce the Navmesh Agent to run with FixedUpdate so it can interact with physics more reliably?

 

That sounds like a neat method but the gizmo for some reason shows the navmesh agent move anyways, just the transform is not updated. Is there a way to stop the navmesh agent from moving?

 

This does not seem to address the core problem, and that's that the navigation needs to update it's data with FixedUpdate in some cases, since the physics update is the de facto game logic update. AI, which includes pathfinding, is not an aesthetic element, and sometimes needs the ability to be evaluated in a more deterministic way than a variable timestep will allow, just like physics. For instance, how would you ensure you could speed up time in an RTS and have same behavior with navigation's desired movement updating at an undefined frequency?

 

Sorry to resurrect this thread, but it would really be amazing if it were possible to change this behavior. Does anyone know if anything is currently in the works to possibly be able to run navigation updates in FixedUpdate optionally?

 

I would also like to know an answer to this question. Same as @Multithreaded_Games

 

Me too. My agents are a big vehicles and I need friction working correctly on them. Current update frequency which is obviously out of sync with the physics update frequency causes erratic behavior when my agents interact with any non-kinematic rigidbodies. Also, they seem to stutter when moving close to something that properly moves using the FixedUpdate method.

Unity please... we need to know and we need you to add some project setting so that we can choose whether we want to use an Update, or FixedUpdate frequency for the Navigation system.
This small change would help us greatly improve our game.

Btw sorry for the thread resurrection.

 

Don't apologize! It's pretty ridiculous honestly. It seems like it'd be an incredibly easy change to implement--we've had to do some pretty ridiculous things to work around it and there are still rare instances of jitter. Don't even get me started on how the camera plays into all of this...

 

Look at the API and you'll see that it's trivial to handle the movement yourself in any function you prefer.

https://docs.unity3d.com/ScriptReference/AI.NavMeshAgent-updatePosition.html
https://docs.unity3d.com/ScriptReference/AI.NavMeshAgent-updateRotation.html
https://docs.unity3d.com/ScriptReference/AI.NavMeshAgent-desiredVelocity.html

 

I am well aware of all of those. However, the question is more a "how trivial would it be for Unity to add support for navigation updates in FixedUpdate", not "How can I work around this?" Not to mention this response from an earlier post:

Frankly, I would think Unity could make this change rather easily and it would make many developers' (including myself) lives a lot easier.

 

Navigation is not part of the physics loop so it doesn't make sense to always update it in FixedUpdate(). Also, FixedUpdate() is definitely not the defacto game logic update, not even remotely.

The question is "How can I work around this" in the sense that a non-essential feature that isn't a feature anywhere else in the entire program unsurprisingly doesn't exist for this component and as with pretty much everything, you have to make something work to circumvent an issue which is specific to some design paths you have chosen. Fortunately, this component has very convenient hooks that allow you to strip control from the built in system as needed and easily manage the Agent's position - which is something you will be doing with any long term project anyway.

 

No one is saying it should always be updated in FixedUpdate, merely that the option could exist. And you are incorrect--camera systems, in particular, can be quite sensitive to when the update is performed. In fact, the option to change the update mode exists on Cinemachine cameras, which is a Unity component.

That being said, my use case is probably way different than most--I would like my physics-driven player character to be constrained to the ground and the NavMesh, but it also needs to collide properly with Rigidbodies, some stationary and some not. Also, this character is player controlled, so really, the NavMeshAgent only exists on the character to try to constrain it to the NavMesh. Unfortunately, these two do not mix well (and of course, this wasn't noticed until specific instances where the character would jitter--duh, this is because the NavMeshAgent is trying to control the character at the same time as physics.)

So I decided to take the NavAgent off completely and use SamplePosition to figure out where the NavMeshAgent would be constrained and then move the character to that specific position after updating the character's velocity based on user input. This works amazingly well--except in rare cases where the character is colliding with both a moving body AND a NavMesh boundary. Honestly, this is a solution that has been built up over the course of two years (I'm sure you know how much cruft can accumulate in that time) and if there is an easier way to handle this, I'd love to hear it.

PS: Yes, I know that I could go the full physics route, but we don't need our character to jump/fall/push or be pushed--Our levels are quite mature at this point and it'd be practically impossible to switch over to a fully-based physics system while ensuring that all of the previous inaccessible locations (very clearly delineated by the NavMesh, as another nice bonus) still remain inaccessible.

 

@LaneFox is correct. Navmesh agents are not physics based it makes zero sense for them to be updated in FixedUpdate. Even if they were it wouldn't solve the issues listed. The main issue here is a fundamental misunderstanding of the core problem.

The core problem is that the built in unity controllers, navmesh or otherwise, are not proper physics based controllers. No amount of messing around with when navmesh updates are done will fix that.

The correct solution for a stable character controller using the navmesh is a kinematic controller combined with doing navmesh queries manually.

In addition, you often need to time all of this yourself to get correct interactions. Like a good kinematic controller for example needs to update all rigidbodies in a single FIxedUpdate in a global manager. And in that same manager you handle navmesh queries also so the timing is all correct.

That is the kind of thing you have no choice but to do especially if you mix stable kinematic controllers with non kinematic rigidbodies. None of this is really even directly related to the navmesh system itself.

 

But there is an additional use-case, too. Sometimes you want not only paths from the NavMesh, which are easy enough to get and then follow manually - but also the local obstacle avoidance and crowd behaviours of the agents. These are much more subtle than path following on its own. We use kinematic rigidbodies with manual control, with updatePosition and updateRotation set to false on the NavMeshAgent, etc. However, we allow the NavMeshAgent to do its regular work and we "follow" it with our manual rigs for our vehicles, occasionally snapping it back into position when it strays too far from the physical entity. This is the only way to capture all of the nice behavior that NavMeshAgent offers beyond simply following paths.

The problem with this is that the NavMeshAgent always does its work on *every* frame. We would like to be able to manually update the agent ourselves because we simply don't need it to run that often and it eats up valuable frame time. So there *is* a strong and useful case for Unity allowing us to manually "tick" our agents instead of hardwiring it to happen every frame - even when you are already using "a kinematic controller combined with doing navmesh queries manually" as you say.

I've explained even more over here.

 

I agree, I myself ended up setting 'updatePosition' and 'updateRotation' to false and using 'desiredVelocity' in FixedUpdate (as suggested by @superpig above) to still be able to benefit from the native agent avoidance etc. This made agent interactions with non-kinematic rigidbodies finally beautiful and stable (such as a box falling on a moving vehicle's roof). Also, they move when they should - as everything that moves - in FixedUpdate. So they don't make anything look choppy, or look choppy themselves anymore.
But it's just a workaround... under some circumstance, agents behave weirdly when trying to avoid each other.

What you do, smoothly following the agent, is also a workaround, just as you said. They will not move with a stable speed, because the agent updates are not synced with the follow updates (if you do the follow updates in the FixedUpdate) So it's a no-no for me at least.

Well... all these "solutions" are just a cheap charade.
I am afraid this will not be fixed without help from Unity. The Unity navigation guru (and employee) @Jakob_Unity was there, helping folks few months back. But he went missing since... and now, no one from Unity writes here... at all (AFAIK, sry if I'm wrong)

Does anyone have more ideas?