When an object or a BasePart attains higher velocities due to forces being applied, especially by VectorForce instance, the BasePart starts to vibrate up and down, its not too much, but still noticeable.
And when the shape of the BasePart is cylinder with the circular face facing the ground, that BasePart vibrates more violently and even starts to oscillate on the axis its moving in.
If the intention of the physics engine was to roll the object forward by applying the frictional force on the surfaces causing a torque to be applied on the centre of mass rolling the object forward, that is certainly not happening in this case.
Visual description (contains both, a block and cylinder moving with force):
Make a Part of the size and shape approximately of the one shown in video.
I use this code to set the force: workspace.Test.VectorForce.Force = ((Vector3.new(0,0,7.5) * workspace.Test.Mass) + Vector3.new(0,0,1) * 0.3 * workspace.Test.Mass * workspace.Gravity)
The second force added in the above code is just the frictional force being applied between the two surfaces (baseplate and test part) so that the frictional force doesnt hold back the part from moving.
Make the camera focus on the part and you will see it jittering up and down, and more if its a cylinder.
Expected behavior
I am expecting the part to glide smoothly on the baseplate instead of vibrating in the video.
After reading through the docs and doing more experiments, it seems that this behaviour is occurring because the engine is assigning it the 60 hz timestep.
I’ve confirmed it by enabling Are Timesteps Shown in studio, the engine should assign it the timestep of at least 120hz or above, because in the 60hz timestep, its not stable.
Thank you for the report. I will take a look at this to see what we can do to either stabilize the 60 Hz result or ensure the simulation frequency increases for these situations. In the meantime, to mitigate this issue, you can set Workspace.PhysicsSteppingMethod to fixed to ensure a 240 Hz simulation frequency.
Hi @LakshyaK2011. I’m getting caught up on your bug report. Can you send a minimal repro file? Following your instructions, I’m able to produce a setup where I don’t see jittering, or perhaps the jittering is far less noticeable than what you showed. That being the case, I’d like to see exactly how you’re setting it up.
Jittering.rbxlx (98.3 KB)
Currently the camera will follow the block part, to set it to the cylinder one, set workspace.Focus.Value to the cylinder present.
I believe replication between the server and client and interpolation is causing what you’re seeing. In your setup, the cylinder part is owned by the server, and thus simulated by the server, and we’re visualizing what the simulation looks like when it’s replicated back to the client and interpolated. This is causing the jitter because we’re only receiving “true” simulation data every time replication happens, which is at a lower frequency than the frame rate. In between replication events, our client is attempting to fill in what it think the CFrame is supposed to be. Since the part is traveling along the ground, our client is likely going to miss collisions (again, we’re not simulating, we’re just interpolating), so our cylinder part might begin to “drift” into the base plate. Then, when the next replication event happens, we get a correct CFrame that doesn’t produce any penetrating collisions, and we immediately correct with that CFrame, which causes a jitter.
At least in my own testing, if you set the ownership of the cylinder part to your player you will hopefully see far less jittering. I don’t think it goes away completely, and this can probably be explained by our current collision detection system. If you turn on “Show Contact Points,” you’ll likely see that the contact points of the cylinder against the base plate shift around, jitter, etc, which can cause some unstable behavior, like jittering.
One way to completely get around this issue is to slap an Orientation Constraint onto the cylinder as well which prevents the jittering by constraining the orientation of the part. However, I’m not sure how you’re ultimately using this part - perhaps you don’t want to be constraining the orientation for some other in-game behavior…
No its not because of that, i’ve confirmed it through my testing. And jittering is even worse on the block part when its owned and simulated by client.
The jittering is actually “reduced” by replication between client and server because the server doesn’t sent every update asap but in fixed intervals which only sends some of the jitter to the client (oscillation on cylinder and vertical jittering on block).
Still applies when the part is created by client.
Here’s the updated place file with client creating the part: Jittering.rbxlx (98.7 KB)
Ah, I realize now that I’ve been testing under the assumption of setting Workspace.PhysicsSteppingMethod to Fixed, what @DrCherenkov suggested, as a way to mitigate most of the issue. I was trying to tie up the loose ends with that initial setup.
I agree that the jittering is still there, no matter the setup, with Workspace.PhysicsSteppingMethod set to Default.
In the 240Hz case, when server owns the part and it’s being replicated back to the client, I’m actually seeing very little jitter (or at least the amplitude of jitter is small) from the server, but a lot of jitter on the client. The same is true if the responsibilities are swapped - at 240Hz, if the client owns the part, then I’m seeing very little jitter from the client, but a lot of jitter on the server.
A few questions for you:
Does setting Workspace.PhysicsSteppingMethod to Fixed work for you? While keeping the part on the client?
What are your thoughts on adding an Orientation Constraint onto the part to prevent jittering as another way to mitigate for now?
Yes, it eliminates most of the jitter, but some still remains and atp that is just due to some rounding errors because its only of ~1 pixel.
I use OrientationConstraint because I am using this for a custom character movement system and the cylinder being the character root, I dont want it to tilt. tldr; it prevents it, and it works.
Also, I think there is a bit of confusion here, In the setup, there are two types of parts and they both jitter slightly different.
The block/cuboid shaped part vibrates up and down on 60hz, and the cylinder along with vibrating up and down, it oscillates too.
The simple fix to this problem is the engine assigning the part a higher simulation frequency (120/240hz) at the velocity it starts to vibrate.
I m seeing that the engine only assigns the part higher simulation frequencies until the moving part attains even higher velocities and only then it stops jittering.
Setting the Workspace.PhysicsSteppingMethod to Fixed works.
You’re definitely correct in that the jittering is different depending on if it’s a block or cylinder. The two different part types go through different collision-checking algorithms, and if you enable “Contact Points” in Studio, you might notice that the contact points of the cylinder drift around the perimeter of the base, which can cause the part to exhibit different jittery behavior. The block, on the other hand, has stable collision points.
Finding good heuristics for when a part should be assigned a higher simulation frequency is a difficult problem: what’s an “allowable” amount of jittering? Ideally, the amount of jitter that a part exhibits should be less than what we can observe, but that’s hard to quantify. Completely removing jitter at large is also not feasible as that would require much more computational effort that we may not be able to afford in a single time step due to frame rate considerations. The current heuristic that is used for when to promote a part to a higher simulation frequency is if it travels more than half its length in a single time step.