Interpolation causes collider related out-of-sync

[zachstronaut]

Interpolation on NetworkTransform in Netcode moves whatever GameObject that has the NetworkTransform component. This means that if this GameObject also has colliders it is possible for identical tick aligned collision code on host/server vs remote client can yield different results due to interpolation.

Other networking libraries sometimes address this by applying the real hard tick synced position data to an object with the colliders/rigidbody and then you define a separate interpolation target that is just visuals like mesh renderers.

Any thoughts/advice?

[NoelStephensUnity]

@zachstronaut
It really depends upon how you want to handle collision on the non-authority side of the equation for client-server.
If you are "mix-matching" owner and server authoritative motion models, then I would look into ignoring collisions on the non-authoritative side and only handling collisions on the authority side. This means MonoBehaviour CollisionEnter/Stay and (depending upon the scenario) could mean having colliders ignore one another to prevent non-kinematic to kinematic collisions.

Do you have a specific scenario you are running into?

[zachstronaut]

Sure, I just RPCed from the authoritative side for now, and luckily in this case the RPC was pretty simple.

But, sometimes you need to use context from the collision and you get yourself into things needing to be a NetworkObjectRef or NetworkBehaviourRef that otherwise wouldn't have needed to be and sending aspects of the Collision object through the RPC, too.

When the position of an object is server authoritative and you could put the position data into some sort of guaranteed delivery mode, you'd be certain on a remote client to get a perfect replication of every position the object occupied at Tick resolution. This would be sufficient to just run collision locally on both sides in many cases because the object would travel exactly the same known path.

Interpolation on the client side for both the visuals of the object AND it's colliders/rigidbodies creates an edge case where you cannot trust this sort of sync because the path on the client can be different than the server for the colliders.

That said, it may also be the case that Netcode doesn't send position data via a guaranteed delivery method on tick? Maybe it's lossy cause its a volatile piece of data?

[NoelStephensUnity]

That said, it may also be the case that Netcode doesn't send position data via a guaranteed delivery method on tick? Maybe it's lossy cause its a volatile piece of data?

Unless you have Use Unreliable Deltas checked on the NetworkTransform, everything is sent reliably so you are guaranteed delivery. The most common issue with trying to synchronize physics simulations across multiple clients has to do more with each clients' platform/hardware (i.e. frame rate/fixed update passes) and whether you are using mixed authority motion models.

The mixed authority motion models becomes a complex issue when trying to run physics on all clients due to the fact that there will always be latency involved. Also, NGO v1.x does not support using the Rigidbody for both motion and state updates and is applying updates directly to the transform...which this can cause collision issues/anomalies since the physics simulation really needs to have updates to position and rotation applied via the Rigidbody.Move, Rigidbody.MovePosition, and Rigidbody.MoveRotation.

As a side note: NGO v2.x supports using the Rigidbody for motion and allows you to enable Rigidbody interpolation with NetworkTransform interpolation...which gives a more accurate (not perfect) collision model. Of course, if using mixed motion models then there will always be the delta between where a Rigidbody was vs where a non-authority instance "thinks" it is. We will be releasing a new sample project that has a bunch of physics related examples that I think you will be interested in.

[zachstronaut]

Yes, an actual rigidbody simulation is a whole different beast! Let's set the aside for a second. I was more just referring to OnCollisionEnter/OnTriggerEnter from colliders which still requires a rigidbody somewhere in the mix in Unity. Let's just think about predictable kinematic movement.

So the problem I want to make sure you understand is that when you are interpolating the collider, the path of that collider on authority vs remote will not be the same.

However, if you send reliable position ticks and apply those directly to the collider, but separately interpolate a visual target, this means that the path of the collider will be identical on authority and remote. This allows you to do OnTriggerEnter/OnCollisionEnter on both authority and remote clients in a way which is less prone to un-sync.

[NoelStephensUnity]

However, if you send reliable position ticks and apply those directly to the collider, but separately interpolate a visual target, this means that the path of the collider will be identical on authority and remote. This allows you to do OnTriggerEnter/OnCollisionEnter on both authority and remote clients in a way which is less prone to un-sync.

Yes. That would be a split motion and visual synchronization model similar to the attached project (it is an old project).
VisualSynch.zip
On the host side, hitting the space bar changes ownership. When ownership changes you can see the NetworkObject (purple transparent) leads the visual object that interpolates towards the NetworkObject.

The same kind of separation could be achieved, but you have to remember that tick-accurate position updates (i.e. no interpolation) is not going to provide a smooth transition between deltas...of course if you have Rigidbody interpolation enabled then you would get a form of "smoothing" between the gaps... but you would most likely want your position threshold values to be super low and your tick rate at something like 60 to 90+ in order to get enough resolution to provide reasonable deltas.

This kind of thing I am fiddling with for v2.x, but there are a bunch of foundational things I am trying to get in place before I get to some of the "fun" things... 😄

But your line of thinking is valid indeed... it just requires a bit more coding with NGO today.