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?
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.
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?
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
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 - #10 by chefdeletat).
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.
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
