[Netcode] prediction jitter

Hello,
When I run the getStarted Netcube demo, there seems some jitter movements.
Like below, when the other players move, there is no jitter in my client.
https://drive.google.com/file/d/1xpNz72p-7QdAGGD-dWZJr_wVTkSpjsM6/view?usp=sharing
But if I move my cube, the cube jitters few seconds after it stops simulation. How does this come?
https://drive.google.com/file/d/1cruv5w4bMIsAhV6uqTYBdxpjMdK5saFX/view?usp=sharing
Commenting out the prediction code in GhostPredictionSystemGroup solve the jitter. However, it seems as no prediction but only interpolation.

 

I had this as well. I don't know what's happening but I think maybe it could be the result of floating point precision issues that add up over several frames of simulation? It's probably the kind of thing that we'll need to wait for a Netcode package update in order to solve it.

 

Hi,
Thanks for your reply, that is where the problem exactly is. The implementation of CopyToSnapshot and CopyToSnapshot in Assets\NetCodeGenerated\Unity.Transforms.Generated\Unity.Transforms.TranslationSerializer.cs makes the precision to be 0.01f. Changing them or changing the precision in your prediction code solves the problem.
Now I am finding where to fix them more normally. The GhostField[Quantization=...] may solve the problem, but there seems no effect and maybe there is a template to fix the quantization...

 

The Quantization is not easy to change TranslationSerializer with Netcode generated automatically.
GhostAuthoringComponentEditor sets 100 to quantization of translation. It is possible to modify it outside like below.

However, I can not find how it makes effect before code generation. Also failed to set generation manually by using GhostCompilerService or GhostCompilerServiceWindow methods...
Is there anyway to modify the quantization offically? GhostField[Quantization=...] no effect..

 

@timjohansson Can you confirm that this assessment is indeed correct? I am not really seeing this jitter in my own personal project and thus am skeptical of the diagnosis although I am also quite surprised that the quantization used for translation is relatively low.

 

The Unity docs suggest an alternate way to override the ghost defaults here[1]. From my understanding, these take effect before your game's runtime. Here's a sample implementation:

Code (CSharp):

1. public class GhostOverrides : IGhostDefaultOverridesModifier {
2.   public void Modify(Dictionary<string, GhostAuthoringComponentEditor.GhostComponent> overrides) {
3.     overrides["Unity.Transforms.NonUniformScale"] = new GhostAuthoringComponentEditor.GhostComponent {
4.       name = "Unity.Transforms.NonUniformScale",
5.       attribute = new GhostComponentAttribute { PrefabType = GhostPrefabType.All, OwnerPredictedSendType = GhostSendType.All, SendDataForChildEntity = false },
6.       fields = new GhostComponentField[] {
7.         new GhostComponentField {
8.           name = "Value",
9.           attribute = new GhostFieldAttribute{Quantization = 100, Interpolate = true}
10.         }
11.       },
12.       entityIndex = 0
13.     };
14.   }
15.  
16.   public void ModifyAlwaysIncludedAssembly(HashSet<string> alwaysIncludedAssemblies) {
17.     alwaysIncludedAssemblies.Add("Unity.Transforms.NonUniformScale");
18.   }
19.  
20.   public void ModifyTypeRegistry(TypeRegistry typeRegistry, string netCodeGenAssemblyPath) {
21.   }
22. }

[1] https://docs.unity3d.com/Packages/com.unity.netcode@0.4/manual/ghost-snapshots.html - search for IGhostDefaultOverridesModifier

 

Thanks for your help! The problem is solved now. It needs a new asmdf file with .NetcodeGen. And a script in the same folder to override the GhostDefaultOverridesModifier.

But the origin ambition to do this is to fix the phenomenon below. Quantization can fix the lag after movement, while not fixing the lag of other players moving in your client. Even when establishing a work like NetCube, when two players move forward at the same spped, the lag/snap exists. the move and camera folllow logic have been checked carefully..
https://drive.google.com/file/d/1__K1P_8BslqpjggELMTn_bpg7TA5S0xZ/view?usp=sharing

 

Thx very much again for your reply! Sorry for describing it as a lag problem, actually，it is maybe a problem about moving unevenly. The NetCube is experimented on now. As below, the X axis is UnityEngine.Time.time, and the Y axis is the position of the cube. And the purple line is the position from server，while the red line is the one from client.
When the ghost cube is predicted,

When the ghost cube is interpolated,

The position is accumulated by deltaTime, so it should move in uniform speed.
But it moves unevenly, which may cause the problem that the shaking phenomenon is more obvious when moving forward together with other players.

 

We've been experiencing the same jitter. It's more noticeable when walking/running next to an interpolated character for us.

 

Not sure if this is related:
https://forum.unity.com/threads/netcode-interpolation-jitter.998449/#post-6481897
Observing jitter on interpolated ghosts (not predicted)

 

@timjohansson did this bug get filed / fixed in 0.5.0? I am thinking not as I am running 0.5.0 and have increased the quantization of both Translation and Rotation through the custom .NetCodeGen assembly definition but I still see the same jitter.

 

@timjohansson@anihilnine @kanesteven @Lukas_Kastern
Hi，I read the NetworkTimeSystem to research into the reasons and find some clues.
The PredictTargetTick advances by the tickrate of client, which is determinated by the commandAge or the repredict "curpredict".
The InterpolateTargetTick advances by the subInterpolateTargetTick, which is determinated by the estimateedRTT and the DeviationRTT. The advance step is determinated by the last subInterpolateTargetTick, subPredictTargetTick and the fraction part of currentInterpolationFrames.
After all, the advance steps of predict and interpolate are different, whose D-value is the interpolationDelay that may introduce uneven movement.
----
By the way, there are some unnecessary calculation of subInterpolateTargetTick. subidiff is the fraction part of currentInterpolationFrames, 0<subidiff<1. Then when subidiff -= subInterpolateTargetTick + subPredictTargetTick>0, the subidiff is also between 0 and 1. So
idiff = (uint)subidiff;
subidiff -= idiff;
interpolateTargetTick -= idiff;
do noting...

 

Today I found the my client's idea of ServerTick was getting way ahead of the Server's actual ServerTick. This was solved by actually having an ICommandData buffer somewhere eg

commandBuffer.AddBuffer<CubeInput>(player);

I didn't have a commandBuffer yet because my client can't issue commands yet. However having it somehow keeps the client and server ticks in sync. So make sure you have an ICommandData buffer somewhere.

 

I just took a look at the NetworkTimeSystem, and I don't quite understand it.
I thought the time calculation of the fps sample was complex but this just blows my mind.

Is there something I can look up to understand it better?

 

@Lukas_Kastern yes - also it's really small number of resources about game networking programming (books. net links etc) - 3 i found that are a bit more detailed but none of them explains those complex issues : 1. https://gafferongames.com/ 2. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking 3. https://www.codersblock.org/

 

@timjohansson Do you have any update on this for us?

 

I've made some modifications to the interpolation calculation of the time system. I basically took the interpolation time calculation which the FPS sample used. Here's the version for the 0.5 NetCode package https://pastie.io/uhnbtz.cs

It looks a lot smoother to me than the inbuilt interpolation

 

I believe NetCode 0.6 might have solved the Server Client Prediction errors

 

The interpolaton is "interesting" in 0.6. I put the data into csv to graph it in excel:

 

@timjohansson I see. Is that possible for u to backport the fix?

 

@timjohansson Thanks for quick response. I tried it and while it is better, I feel it should be much smoother, since this is 60 ticks per second, on same machine - directly through LoopbackIpv4. Plotting the delta exaggerates errors, so I'm also including plot of absolute position Z value. Pretty wobbly, and you notice it when playing.
edit: ok I'm not sure if you actually notice this. Difficult to compare to server's gizmo when editor does a performance spike every second.