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.
9 Likes
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).
Let’s stay on topic here: Do you have places that will be affected by a reduction of angular damping?
2 Likes
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
Essentially if you apply a torque to wheels of a car, once they get to a high enough RPM, the angular damping will essentially behave like a “friction” force, lowering the amount of RPM increase each unit of torque you add applies. It can potentially hit a terminal velocity (asymptotically I think).
So it won’t affect much stuff that you’re applying a force to, unless it is very high RPM. This change will cause Torque driven systems with high RPMs to experience even higher RPMs.
Fidget spinners in Roblox will spin forever? Call the press!
2 Likes
I have encountered this issue multiple times while trying to create vehicles, as documented on a thread from last year when we were first made aware of it. However I am no longer using anything that would be affected by this.
Edit, here’s some discussion on the issue for anyone who hasn’t come across it.
http://devforum.roblox.com/t/new-wip-car-chassis-feedback-wanted/26691/24
Hey guys, we’ve opened up GT3 for testing if any of you are interested:
https://www.gametest3.robloxlabs.com/
It has the angular damping reduction enabled.
3 Likes
Any feedback on this? We will be closing public access to GT3 and soon enabling this change, I’d like as much feedback as possible,
Just tested my game’s cars there and everything appeared to be working as intended. (They’re pretty modest cars, nothing with super high torque)
2 Likes
Thank you for doing so!
Angular damping has been reduced today. Please report any issues.
3 Likes
How do I control the rolling friction of a ball/sphere? After this update when I move a small ball in motion, nothing can stop it from rolling.
This is the properties on the ball:
This is where the ball ended up after recording the gif and typing this post up:
The ball is first moved via CFraming, and when close to the ground the ball’s velocity is set and becomes unanchored, no other forces are on the ball.
Here is the link to the place, however on current version of the game, the ball’s friction is at 1 instead of 0, but there is still no noticeable difference: https://www.roblox.com/games/598947721/HCBB-9v9-Alpha
1 Like
Try adding some friction to the ball, it’s currently at 0. Let me know if this helps. Changing frictionWeight doesn’t change friction, but only how the friction is averaged between the two parts. Review the docs:
http://wiki.roblox.com/index.php?title=API:PhysicalProperties#Friction_and_FrictionWeight
If you still get too much rolling, you might need to add a script that will apply a torque opposite to the angular velocity of your object