NetworkTransform Interpolation

[SamuelBellomo]

See this page for formatted view

[LukeStampfli]

I think I can agree with the overall idea behind this.

What is a bit worrying is that the Interpolator does a lot of things in addition to interpolating. It is also storing a state history and is aware of frames/ticks. I can see why we are doing it to quickly fix issues in the NetworkTransform but I think we will need get back to this and redesign it when we get snapshots.

[SamuelBellomo]

I think I can agree with the overall idea behind this.

What is a bit worrying is that the Interpolator does a lot of things in addition to interpolating. It is also storing a state history and is aware of frames/ticks. I can see why we are doing it to quickly fix issues in the NetworkTransform but I think we will need get back to this and redesign it when we get snapshots.

It's very possible we'll need to break the API with snapshot, but I'm not sure. Passing a Vector3 for position to AddMeasurement would still happen, snapshot or no snapshot. Passing a NetworkTime would still happen snapshot or no snapshot.
I would imagine the snapshot system would still be available statically from the interpolator, without needing to inject snapshots through the interface. If there's any need for rewinding things, interpolators could still have access to that information.
Our usage of the interpolator might change, but I think the interface is flexible enough to give us some leeway once we add snapshots later? Unless you have some other ideas of things we could work into the interface?

[jeffreyrainy]

I think I can agree with the overall idea behind this.
What is a bit worrying is that the Interpolator does a lot of things in addition to interpolating. It is also storing a state history and is aware of frames/ticks. I can see why we are doing it to quickly fix issues in the NetworkTransform but I think we will need get back to this and redesign it when we get snapshots.

It's very possible we'll need to break the API with snapshot, but I'm not sure. Passing a Vector3 for position to AddMeasurement would still happen, snapshot or no snapshot. Passing a NetworkTime would still happen snapshot or no snapshot.
I would imagine the snapshot system would still be available statically from the interpolator, without needing to inject snapshots through the interface. If there's any need for rewinding things, interpolators could still have access to that information.
Our usage of the interpolator might change, but I think the interface is flexible enough to give us some leeway once we add snapshots later? Unless you have some other ideas of things we could work into the interface?

What I hope happens is, once Snapshot is there and works, for the interpolator to attach to the NetworkVariable directly. Then the NetworkTransform responsibility becomes ones of integrating with the Unity's transforms and integration with UI, surfacing parameters type stuff. But I hope the interpolation to eventually go down into NetworkVariables. Would still use the/an interpolator, but just not tied to NetworkTransform, if that makes sense.

[SamuelBellomo]

I think I can agree with the overall idea behind this.
What is a bit worrying is that the Interpolator does a lot of things in addition to interpolating. It is also storing a state history and is aware of frames/ticks. I can see why we are doing it to quickly fix issues in the NetworkTransform but I think we will need get back to this and redesign it when we get snapshots.

It's very possible we'll need to break the API with snapshot, but I'm not sure. Passing a Vector3 for position to AddMeasurement would still happen, snapshot or no snapshot. Passing a NetworkTime would still happen snapshot or no snapshot.
I would imagine the snapshot system would still be available statically from the interpolator, without needing to inject snapshots through the interface. If there's any need for rewinding things, interpolators could still have access to that information.
Our usage of the interpolator might change, but I think the interface is flexible enough to give us some leeway once we add snapshots later? Unless you have some other ideas of things we could work into the interface?

What I hope happens is, once Snapshot is there and works, for the interpolator to attach to the NetworkVariable directly. Then the NetworkTransform responsibility becomes ones of integrating with the Unity's transforms and integration with UI, surfacing parameters type stuff. But I hope the interpolation to eventually go down into NetworkVariables. Would still use the/an interpolator, but just not tied to NetworkTransform, if that makes sense.

I'm still not convinced about moving this in NetVar. I had to move transform state sending to NetworkTick in NetworkTransform in order to make this fit with BufferedInterpolation. I'm pretty sure we can't impose this on NetVar update call sites.
Do you have use cases for interpolation at the NetVar level beside transform related ones?

[LukeStampfli]

No more scriptable objects yay 😄

[andrews-unity]

Just so I understand we are still purposing the addition of an interface ? And the ability to set per object different interp algorithms? If so I am going to want to understand why we need this. I truely believe 90% of the time most devs won't change it beyond the default one. So to me we should make that the best possible algorithm and say if you want something special there is the code write it yourself.

We constantly try to provide this plug and play swap this and that model and I just don't see the argument for it. You mentioned several other engine all of which have one path maybe with some nobs and dials and 100s and 100s of multiplayer games have shipped on them. We don't need to solve for everyone we need to solve for the majority.

[SamuelBellomo]

Just so I understand we are still purposing the addition of an interface ? And the ability to set per object different interp algorithms? If so I am going to want to understand why we need this. I truely believe 90% of the time most devs won't change it beyond the default one. So to me we should make that the best possible algorithm and say if you want something special there is the code write it yourself.

We constantly try to provide this plug and play swap this and that model and I just don't see the argument for it. You mentioned several other engine all of which have one path maybe with some nobs and dials and 100s and 100s of multiplayer games have shipped on them. We don't need to solve for everyone we need to solve for the majority.

@andrews-unity
I'm still suggesting an interface, but I'm not suggesting the way it's going to be exposed to users in inspector anymore. The interface would be to serve as a contract for users that do want to extend it.
One near-term use case I can see for a new interpolator would be with Luke's network physics work. There's potential for linear interpolation to not be enough and a need for syncing more data (velocity for example). Having that contract would help extending current interpolation for a physics based one for example, but still keep default linear interpolation for when we want to save on bandwidth.
Unreal teleports character capsules but interpolates graphics. It's great for predicted characters, but not that great for a self contained component like we're trying to build here.
Hermite interpolation uses more bandwidth, but has less wobble.
Kalman Filtering is more physics based and less noisy, but can show transform updates that are not true, with an inertia client side that wouldn't be there server side.
Buffered Linear interpolation would still remain the default. It's smooth even with bad jitter and only uses a float for extra bandwidth to track the time the value was updated.