Nondeterministic NavMeshAgent movement

Hello,

I am working on a simulation containing about 30 NavMeshAgent moving around. Up till now simulation was deterministic, but I noticed if I make the state of agents depend on some distance between them the simulation becomes nondeterministic.

I am moving the Agent setting the navagent.destination variable (repeatedly, I don't know if I need that actually) and change some internal state if the agents are close enough to each other

With something like

Code (CSharp):

1. float dist = Vector3.Distance(agent.transform.position, otherPosition);
2.         if (dist <= 2.0)
3.             return true;
4.         else
5.             return false;

If I remove the distance depend part, the simulation is back to deterministic behavior. So I am quite sure the different outcomes are because the NavMeshAgent Movement is slightly different between simulations.

Is this a common issue? I read multiple times about PhysX engine being nondeterministic between platforms/systems but should be deterministic for the same machine. Is the NavMeshAgent movement independent of the Physics engine? Can I seed this part of the engine somehow?

thx,
Manuel

 

Agents don't use physics.

Crowd handling uses RVO so changing the velocity of one agent will affects others in range, having a ripple effect. What you are missing here I think is the impact of time variable calculations. Every play session creates a completely different series of Update ticks, resulting in completely different calculations even if the algorithm is stable. What you are doing as a result of that check could very well be less stable then the core crowd algorithm,that would be my guess. So you took something that was relatively deterministic and made it far less so,enough to be visibly noticeable.

 

Hi @snacktime,
I have multiple questions about your reply.
What do you mean by crowd handling? and RVO?
What do you mean by multiple Update ticks?

 

Google pathfinding RVO. Navmesh agents use a form of that. https://github.com/recastnavigation/recastnavigation is specifically what the entire navmesh system is based on.

Update ticks once per frame, and frames are not deterministic, they will tick at different intervals since frame rates constantly go up and down. So different play sessions produce a different sequence of update ticks at different time intervals.

So your distance checks won't be happening at the same point on the timeline in different sessions. If you modify the behavior of an agent based on that, the ripple effect can quickly lead to large variations. WIth RVO even more so because every agent's movement is based on the movement of other agents, that's just inherently how RVO works. A fundamental part of reasoning about determinism is knowing the algorithms being used.

Likewise any calculations based on deltatime simply can't be deterministic across play sessions. And most movement uses deltatime including the navmesh system.

 

Hi,
thx for the explanation!

To be honest, I don't care too much at the moment in performing things the Update routine. I use FixedUpdate() with 1 second intervals, and run all logic there.

I tried what was recommended here: https://answers.unity.com/questions/889836/using-unity-navigation-in-a-fixed-timestep.html
Turning of the automatic Transform Position update caused by NavAgent, and instead updated the position in the FixedUpdate() routine manually (in order to avoid the litter in position updates that you mentioned, but this is still nondeterministic).

So the NavMesh Navigation system is implemented onto of Google's pathfinding RVO? I guess that by itself does not care about determinism.

Are there any alternative navigation systems that do? Or any recommendations on how to build one?
I find it kinda strange and unintuitive that one can throw a bunch of boxes at each other and their interaction is deterministic, but moving a box in a plane use navmeshagent is not.