Angular Damping or Rotating Parts Slowing Down

Hey devs!

We will be reducing the damping on rotating objects. This is a property of rotating bodies that reduces their rotational velocity as if there was air resistance. Basically we want to get rid of that fake air resistance or at least dramatically reduce it (you can fake air resistance with the new body movers if you need to).

Here is our current behavior:

You can see that the object rapidly slows done and stops. This is our planned behavior:

The parts keep on rotating without slowing down.

Do you have or know of places that depend on the current behavior that might break? Do you have mechanism that you think will be affected? Any other feedback?


What about friction?

This change doesn’t affect friction between bodies


Basically what we currently have is not real air friction as round shaped bodies (like wheels) would slow down at the same rate than something that has a flat surface exposed to air (like a flat sheet). This is problematic because devs can’t create fast moving vehicles as it takes very large forces/torques to fight the damping. We want to solve this in this change.


Will we be seeing something similar for things like ropes or springs? They seem to go on for pretty much forever after being moved.

Any chance of better replication of rotating parts across multiple devices, or is that up to scripting?

We are doing work (cc: @Khanovich) to improve replication. This is unrelated.



Does this mean that current vehicles with insane velocities will turn into rocket ships and break away from earth’s gravitational force because they’ll go so fast now that they won’t have dampening but still a ton of force?

1 Like

This is a fair observation. Do you know any places with overpowered vehicles that we can test?

I also know that @paul2448 has an empty super race-track with like 5,000 MPH ‘stable’ racecars.

1 Like

I think high torque means it’s just going to flip over repeatedly instead of going forward faster.

There might be a different issue in this vehicle. Could you post the place?

This is actually a general problem with vehicles that has been around since their inception. I’m no physics expert, but I think the issue has something to do with how the vehicle’s weight counters the friction of the wheels and the brakes. If there isn’t enough weight to counter a sudden change of friction in the wheels rotation, the car’s velocity implodes on itself.

(Tbh I have no idea what I’m talking about lol.)

What I’ve noticed happens a lot with both constraints and body movers is instability from over-correction when frame rates drop. Basically, you have a system that is using a force to try to keep something in equilibrium, and the magnitude of the force is tuned for 60 FPS. Then, frame rate drops, and because of the longer time between frames, the force gets applied for much longer than intended: double, triple duration, or worse. The end result is that the force doesn’t bring the system back to equilibrium, it overshoots. Now you have an oscillator. If you overshoot by more than the correction you were trying to make, you can have an unstable system that gets worse with every frame, exponentially. This often results in things flying dramatically out of the world. But weirder things can happen, especially when you have high forces but also strong damping. You can get quasi-stable behaviors. Things flipping around seemingly randomly, or levitating are both easily reproduced. I observed this the other day in the Race template, when I added too many Jeeps. I got flipping and flying Jeeps, and Jeeps that were driving OK apart from an occasional spontaneous 360-degree roll around some strange axis.

The easiest way to get into trouble, without scripting, is to use arbitrarily large maximum forces, torques, and power on body movers and constraints. It’s pretty easy to make something that goes unstable with a slight drop in frame rate. Using scripts that set forces and don’t account for time between frames is also a bit risky. I use BodyForce objects in my character controller, and I have to carefully manage the forces, compensating for frame rate drops. I also do sanity checks using the typical Newtonian motion equations for position, velocity, acceleration, etc. that games have always done. If you know where something is supposed to end up, from a simple and cheap calculation, you can catch an overcorrection in one frame and not let it oscillate out of control.


i can sing many songs about similar topics ; i once worked several months on a pure physics based hovering vehicle system ; the entire script thing still screws up at lag spikes and any framerate lower than 30 ):

I could fix it if i knew enough about scripting tough :upside_down_face:

Yes the frame rate and stability issues are a real problem, and we are aware of it. Although this is a different subject, and we should talk about this in a different thread (for example:
PGS Solver Migration Feedback Request).

Let’s stay on topic here: Do you have places that will be affected by a reduction of angular damping?


To clarify for people posting feedback here:
We are specifically looking for places that have hit “rotational terminal velocity” where no matter how much torque you apply to a spinning object it doesn’t accelerate. Rotational motion is very difficult to solve in real-time discreet systems, and often introduces inaccuracies. These inaccuracies can lead to thin objects spinning infinitely. chefdeletat has figured out a way to resolve this problem and “loosen” this terminal rotational behavior (meaning it should be easier to keep objects you want to spin, spinning).

We are looking for users who have encountered these rotational limitations (when perhaps building high performance cars), to see how much turning down this “rotational dampening” will affect their game. So, have you ever had a game where you had to turn up rotational torque really high to keep your car or other spinning objects moving correctly? Please let us know, we want to know the effects of reducing damping.

It it update up on gametest1 now?

So, which means of rotating something would you expect this to impact? If I give a part an initial RotVelocity, I see the behavior from the first video. But I haven’t seen things stopping unexpectedly when rotating them by any of the usual methods. And it seems there are quite a number of ways to skin this particular cat. The ones I’ve found are (for constant rotation of a part):

Using physics/constraints without scripting:

  • Torque object acting on attachment
  • HingeConstraint with actuator type Motor
  • BodyAngularVelocity
  • Putting Part in contact with Motor surface of another part (Surface Input type “Constant”)
  • HingeConstraint* with no actuator (to provide axis) and VectorForce applied to an off-axis attachment
  • HingeConstraint* with no actuator (to provide axis) and BodyThrust applied off-axis
  • Rigid connection or rope constraint to another rotating or orbiting part.
  • AlignOrientation constraint connecting unanchored part (to be rotated) to an anchored part with attachments that are oriented exactly 180 degrees apart on an axis other than the rotation axis. This one is more of a reproducible quirk than a method.

Using scripts

  • Animating Part.CFrame via script
  • Animating CFrame of a part’s BodyGyro via script
  • Animating Part.Orientation through script
  • Setting Part.RotVelocity (seems only to work on stationary parts by doing anchor/set/unanchor? Because of sleeping?)
    *Motor6D angle animation? Haven’t tried this yet
1 Like