NetworkTransform Rotation Mismatch Issues (Possibly Due to Interpolation)

[RahulJoshi1997]

Description

In cases where the server's NetworkTransfom rotates rapidly, and somewhat haphazardly, before coming to a rest, sometimes the Client seems to come at a rest at the wrong rotation, with a delta much larger than the Rot Angle Threshold. It visually looks like maybe the clients final position is a frame or two old.

I haven't been able to recreate this issue with interpolation turned off. So it seems edge cases with maybe how the interpolation buffer is fed and consumed.

Reproduce Steps

Here's a repo where I've done my best to recreate the issue: https://github.com/RahulJoshi1997/NetworkTransform-Rotation-Lerp-Issue
Unfortunately, the issue is difficult to reproduce, especially in this fresh project. You often just have to keep trying to see it.

Here's steps to recreate the issue on your own:

1. Create a cube Prefab with a NetworkTransform and register it with the NetworkManager.
2. Set the Rot Angle Threshold in the NetworkTransform to 1. Generally it looks like this edge case happens more easily when the threshold is higher.
3. Optional: You can add this script to the cube prefab to make it display its position and rotation: https://github.com/RahulJoshi1997/NetworkTransform-Rotation-Lerp-Issue/blob/main/Assets/Samples/CubeInfoDisplay.cs
4. Add this script to the scene, and assign it the prefab, and two empty transforms indicating the position and rotation the cube should start and end at: https://github.com/RahulJoshi1997/NetworkTransform-Rotation-Lerp-Issue/blob/main/Assets/Samples/CubeLerpDemo.cs
5. Start a server and a client instance, both connected to the loopback ip address.
6. On the server, click "Lerp Cube"
7. You will see that sometimes the client cubes settles on a rotation with a delta much greater than the Rot Angle Threshold you set.

Actual Outcome

Sometimes the client cube comes to rest at a rotation that's too different from the server's rotation. With a delta > Rot Angle Threshold.

Expected Outcome

The client cube should always come to rest at a rotation delta < Rot Angle Threshold.

Screenshots

In all these instances, the Rot Angle Threshold is 1. Smaller Rot Angle Thresholds make this issue less likely but they do happen. And for some reason it happens much more easily in our working project.

From the Repo I linked:

From our actual project. You can see here that the discrepancy doesn't always just happen in the axes which are supposed to be zero:

From our actual project. Here the issue happens on an axis which should be zero, which seems to happen more often.

Environment

• OS: Windows 11
• Unity Version: 2021.2.2f1 (our actual project) and 2021.3.4f1 (the clean project)
• Netcode Version: 1.1.0

Additional Context

https://github.com/RahulJoshi1997/NetworkTransform-Rotation-Lerp-Issue
Here I've done my best to recreate all the relevant factors which might be exacerbating this issue. This comes form us having a snap point system which pull objects into place Server / Host Side.

Also, whenever these issues happen, if on the server side I slowly decrease the Rot Angle Threshold, at some point the client does change to match the latest rotation. I'm guessing this is simply because this triggers the server to send a fresh value which the client can use.

Here's the conversation in the Discord if it helps:
https://discord.com/channels/449263083769036810/563033158480691211/1038452837400711269

Me:
Hi, my question got a bit buried last time so I wanted re-ask: I'm having problems with the NetworkTransform, and was looking for some insight.

Server side, I have transforms lerp to a snap point fairly quickly (0.25 seconds) and then stay there. But on the client side, the transform might end up stopping at a position & rotation that's a bit off / out of date. The discrepancy between server and client are often much larger than thresholds in the NetworkTransform. Like 10 to 15 degrees of rotation difference when the threshold is 0.1.

It seems like the latest info the client got was maybe a frame or two before the server's final resting position. And then the client just stays there. In those situations, it turns out if I tweak something even just a little bit server side in the editor, the client cube will then go to the latest position.

So I was wondering what could be causing the issue, and what I could to to maybe ensure that a certain final resting position is synched over to the client.

evilotaku:
Sounds like it could be a bug in the interpolation. Are you on the latest version of NGO?

Me:
I think so I'll double check real quick in case there've been updates I missed
ah ok I'm on the version just before the latest one. I'll try again with the update, and see if the problem is resolved
I've tested it out and the issue still persists unfortunately

evilotaku:
OK, open a issue over on the github for this with the repo steps so the team can look into it

[NoelStephensUnity]

Hello @RahulJoshi1997!
Thank you for creating the replication project branch, that will help expedite the time it takes me to narrow down the issue at hand.
Will look into this and report back with my findings! 👍

[NoelStephensUnity]

@RahulJoshi1997,
Ok, I have verified that the issue you are experiencing has to do with how we synchronize Euler angles vs using a full quaternion. If this is blocking you currently, then you can use a branch where this issue is resolved but all of the changes will be rolled out over the next few updates (2 maybe 3) in order to be sure that we have full test coverage for the changes required.

If you wanted to test/use this with your project until these fixes make it into the package, feel free to replace your project's com.unity.netcode.gameobjects manifest file entry with this:
"com.unity.netcode.gameobjects": "https://github.com/Unity-Technologies/com.unity.netcode.gameobjects.git?path=com.unity.netcode.gameobjects#experimental/networktransform-quaternion-and-position-compression",
Using that branch and your provided project the client consistently gets within the threshold tolerance values:

Due to the compression of the quaternion, the 160.56 value is a rounding artifact (trade off for sending a full quaternion compressed into a single unsigned integer).

Here are a few runs where I got a delta difference that was > 0.01f (but decreasing the threshold to like 0.5f would help reduce that)
Almost beyond the 1.0f threshold range (worst I have seen):

These are all some variations of mild deviations:

[RahulJoshi1997]

Awesome! Thanks for that link. I'll definitely try it out on our project and let you know if that fixes these issues for us.

[RahulJoshi1997]

Yup I did my best trying to recreate the issue with the linked version of Netcode, and I wasn't able to. So I think the problem is solved!

[NoelStephensUnity]

Good to hear.
Feel free to continue to use that branch unless you run across other blockers until quaternion synch has made it into an update. I am going to keep this issue open until then.
(FYI: I periodically synchronize that branch with the develop branch)

[ashwinimurt]

MTT-5082