Godot Version
4.3
Question
Could i use a physics tickrate that depends on player’s screen refresh rate in multiplayer? Will it cause any problems?
It will cause a lot of problems. But I can’t exactly tell you which ones. 
I don’t see why you would want such thing?
moving objects jittering and i was seeking a solution, and find out that change physics tickrate can solve it. and since different people have different computers, the number of frames per second is different. if this isnt optimal, then what other variants? (sry for bad english)
The physics loop has a fixed tickrate to produce consistent and similar results on machines with different hardware configuration. A variable tickrate is not optimal for physics simulations because the variability introduces unstable behaviour.
An example of a situation in which unstable behaviour occurs
Imagine a ball moving downwards due to gravity. The ball hits the floor and bounces off of the surface thus redirecting its velocity upwards. If, during this time, the user’s machine experiences a sudden decrease in frames, the high velocity of the ball will make it move further than it otherwise would have because the current step in the simulation accounts for a much longer period of time.
In the context of networked physics simulations, physics interpolation can be used to make infrequent packets of physics snapshots appear smooth and continuous. This interpolation is based on the user’s refresh rate.
Interpolation for 3D physics is not yet implemented in Godot – it is in the works though (see Godot 4.3 blog post and PR).
I hope that makes sense. Let me know if you have any questions.
The easiest way to smooth object motion is to freeze the object on the client side (so it doesn’t desync from the server). Then, every time you update an object’s position on a client you do something like position = new_position.lerp(old_position, 0.5). There are fancier ways to smooth motion but the idea is pretty much always the same; don’t jump to updated positions instantly because there is no guarantee that they arrive smoothly.
Keep your physics code (collisions, interactions that affect gameplay) in _physics_process but feel free to do visual things under _process.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.