PredictionRigidbody sync issues

[naive radish]

Hello, we've been facing some issues when trying to sync some rigid bodies using PredictionRigidbody. We've tried various approaches but we're currently trying the code from https://fish-networking.gitbook.io/docs/guides/features/prediction/creating-code/controlling-an-object.

In the game the players are able to pick some physics objects and throw them around - for simplicity, in this test scene we're just applying a force to a networked rigid body cube when I press a key, which is what we want to replicate on the client.

In the video you can see a few child objects we've added to compare different ways to sync them.

• on the video: left = host, right = client (both running on the same PC)
• grey = root rigidbody object (the only one with a collider, others are just visuals)
• blue = root NetworkObject's prediction target
• green = child NetworkTransform
• red = manually synced rigidbody state (basically sending PredictionRigidbody.Rigidbody.GetState() via Rpcs)

This approach is working in broad terms, with some caveats we haven't been able to fix yet. The main issue is a very noticeable state jump on the client when the client starts to replicate the state updates instead of a smooth interpolation. From then on they move a lot more smoothly until they get to the same state seen on the host.

Here's our test script and prefab setup. Is there anything wrong or missing there? We've tried various combinations here and these are the best results we've got so far when trying to use as much of what FishNet offers out of the box as possible (i.e. without writing a lot of separate logic to sync/lerp things).

Thanks in advance!

A couple screenshots I sent indicate what gets logged on both host and client on a single "cube jump" - while the host only logs it once with the force values we're applying, the client receives a lot of data with a zeroed-out force, is that expected?

[naive radish]

Definitely worth mentioning that these tests are using network emulation. In any case, disabling that doesn't seem to make any noticeable difference
Changing Physics Mode to Unity makes it usually smoother and more responsive, but sometimes the force seems to not be applied at all, and some other quirks come up (which is actually mentioned in the tooltip, but it was worth testing as well)

I tried a similar approach (with the same prefab setup), but syncing the RigidbodyState using RPCs

public void ApplyForce(Vector3 force)
{
    SyncForce(force, new RigidbodyState(PredictionRigidbody.Rigidbody));
}


[ ObserversRpc ]
private void SyncForce( Vector3 force, RigidbodyState rigidbodyState )
{
    _desyncPreviewTransform.position = rigidbodyState.Position;
    _desyncPreviewTransform.rotation = rigidbodyState.Rotation;

    PredictionRigidbody.Rigidbody.SetState(rigidbodyState);
    PredictionRigidbody.AddForce(force, ForceMode.VelocityChange);
    PredictionRigidbody.Simulate();
}

[real narwhal]

Hey there, that's a lot of different things in the same object, which I assume is just for testing. What does the NetworkTransform part do?

[naive radish]

yeah it started with a very basic but as I had issues getting it to work smoothly I started trying alternative approaches to check if they would work better

the NetworkTransform is there for comparison as well
these extra components shouldn't be interfering with the main setup though - I tried removing them all again but that hasn't helped

it seems to be something to do with the prediction methods or setup - we tried not using prediction but just catching up (lerping) with the latest state sent by the host via Rpc and it produces smooth results

things do look a lot better (although there's still some jitter at the start of the movement) if we disable the network simulation and increase the tick rate to 100, but that feels like cheating as we won't have those conditions in real life scenarios

[real narwhal]

Would you be able to try this little example, it's basically the one from the docs.

[naive radish]

Hi @real narwhal I'm trying that now, just a min...

[naive radish]

hello - sorry it took a bit longer than a minute to gather some proper info 😅

so, it does work better than in our internal cases - we'll dig deeper to identify why

we do face similar jitter to our test when we have 2 stacked objects, even with ideal network conditions though (both players on the same PC), and can get much worse if we use the latency simulator

in our game we expect similar cases of objects stacked or leaning against each other, as players are able to pick several physics objects and throw them around - is there anything that can be done to improve that?

this is the same test, just with latency=50ms and 2% of packets out of order or lost

[real narwhal]

Not really sure, I'll ask FirstGearGames if there's a way to reduce that desync movement

[naive radish]

thanks!

in scenarios closer to what we need to handle, there are some more extreme de-syncs that are not only jittery, but can also lead to temporary invalid states and lead to gameplay inconsistencies

on frame 44 (I've marked the sphere positions as it's not easy to see) they're mostly in sync
on frame 45 the client skips far ahead and collides with a cube
on frame 74 we can see the false collision pushed that cube far apart, roughly at the same time where the actual collision should've happened (but with a much smaller force)
on frame 75 we can see the cube is correctly adjusted to its position

this is a slightly modified version of the DocsCSP template
the cubes are a copy of the PlayerSphere prefab, with only its SphereCollider replaced with a BoxCollider, and its sphere mesh is now a cube (otherwise they're identical)

there's a relatively small latency there as well, which isn't enabled in the original demo

[real narwhal]

We're currently looking into a potential community patch for prediction that may improve/fix this

Will try to keep you updated as I get more info about it

[real narwhal]

Hey, so the latest regarding the CSP update I know is one issue has been confirmed as resolved and the other one is failing a test so that part is being looked into

[real narwhal]

Another update here: #chatting message