Improbable Icon

Slow updates on localhost, around 4-5 per second


#1

Tried to run two clients with Pirates Tutorial (part 4)

When I play with two local clients the update performance seems to be quite bad, maybe 4-5 updates are delivered to the other player each second. I would expect at least 30 updates per second on localhost, but 60 seems to be clearly doable.

The machine I used to make the recording: DXDiag output

System load was relatively low, I made sure nothing else is consuming any significant resources while I recorded the above video.

Video recording of the player ship I did not move. Movement of the other ship appears to be choppy.

Would it work the same way on a real network as well?

(I guess this is what we see while playing with Worlds Adrift, visible movement of other airships are quite sluggish.)

Are you using TCP or UDP protocol to send the updates? Does it work the same on localhost (in development setup) and on cloud (production) deployments?


#3

Hi @Viktor! The behavior you are experiencing is due to the fact that physics updates are happening only 10 times per second (every 100ms):


Position/rotation updates are sent at that rate:

In the PiratesTutorial, PlayerShip position/rotation is client-side authoritative (as seen in its entity template). The reason why your own ship is the only one that looks smooth is that Rigidbody.interpolation only works if:

  • the rigidbody is not kinematic and is moved using forces.
  • the rigidbody is kinematic and is updated using its MovePosition/MoveRotation methods

If you manually set the position/rotation, which is the case for the rest of the ships you see on the screen, it doesn’t work.

You could improve this by:

  • Increasing the physics frame-rate.
  • Adding client-side prediction, custom interpolation code, …

The better choice is the latter since you should always try to minimize bandwidth usage.

Are you using TCP or UDP protocol to send the updates?

PiratesTutorial and our starter projects are configured to use Raknet, UDP.

Messages sent between clients, workers, etc. are the same regardless of the current environment. (local vs cloud)

Let us know if anything is not clear, or if you have additional issues. Cheers!


#4

@dasilvacontin Thanks for your explanations!

I have a question :
Is it necessary to desactivate all client’s physics for doesn’t have conflicts between WorkerClient and WorkerPhysic ?

On my personal VR project, the best solution that i found for smoothMovement is : at the Start, all clients active isKinematic and desactive the BoxCollider of all gameObjects in the scene. Just WorkerPhysic build physic and send position + rotation of all entities to WorkerClients. (and use all time MovePosition/Rotation for good Lerp).

What is your opinon on this practice ?

Is this a good use of SpatialOS ?

Tanks, Maxime. (Sorry for my ugly english)


#5

Hi @Mfortin! yw!

As far as I know, there are only two cases where you’d run physics on the client:

  • your player’s position is client-side authoritative, and your player can be affected by physics. So that your player collides with walls, gets pushed by objects, falls from cliffs… I’ve never seen this case in VR because players are usually like ghosts that can move through anything.

  • you use physics as part of your client-side prediction.

If you don’t fall into either of these cases, it’s not necessary to disable physics on the client, but they’ll probably cause jitter in the objects (when getting reconciled with their server position) and objects might jump around, or just behave erratically.

all clients active isKinematic and deactivate the BoxCollider of all gameObjects in the scene

I may have understood you incorrectly, but just in case:
Kinematic Rigidbodies are not affected by colliders since they don’t participate in the physics simulation. i.e. Setting isKinematic in a Rigidbody is enough to disable physics for that object, no need to disable colliders.

What is your opinion on this practice?

The approach you described is good :). Niceties can be added on top of that.

e.g., on the VRStarterProject, when you are grabbing an object on the client, you ignore the server’s position for the object and just snap it to your hand. That way, the object’s movement is lag-less (at least from the networking part) — it feels natural, responsive!

I hope my explanation was clear — let us know otherwise! Cheers! :heart:️


#6

@dasilvacontin Thank you very much for your explanations.
I would come back to you for further details!

Cheers, Maxime! :smiley: