I’m not sure if this is a bug, or just my lack of knowledge on physics, but hopefully someone can help me.
I have setup a very simple UnityPackage to illustrate my issue.
I have two almost identical gameobjects with rigidbodys. The only difference is Rigidbody1 (red) has a mass of 1, while Rigidbody2 (blue) has a mass of 2. The problem I’m having is they have a different terminal velocity. I was expecting Rigidbody2 to take longer to reach its terminal velocity but still reach the same terminal velocity… Unfortunately (for my use case) this is not the result I’m getting.
2616524–183588–UnityPhysics.unitypackage (48.2 KB)
Uh… of course an object with the same drag but higher mass will have a higher terminal velocity, because drag is not proportional to mass but gravitational force is.
I’m not even getting that though… the object with the higher mass actually has a lower terminal velocity.
Uh… wait what? You’re right, that shouldn’t happen.
Terminal velocity isn’t simulated at all. Rigidbody(2D) can have a max linear/angular velocity but the default for those are super high anyway.
Linear/Angular Drag are proportional to linear/angular velocity. Gravity isn’t proportional to mass.
Uh… gravitational force equals mass times gravitational factor. So yeah, gravity is indeed proportional to mass.
In the simulation, the mass of two bodies are not causing the gravity to attract them together, gravity is just some global force that doesn’t take mass into account.
Take a look at the Box2D source which calculates how gravity affects a body here (Line#206).
As you can see:
v += h * (b->m_gravityScale * gravity + b->m_invMass * b->m_force);
v = linear-velocity, h = time-step & b = body. The user applied forces (b->m_force) is the accumulated (non-impulse) forces applied since the last update and that is inverse-linearly scaled by the mass. Global gravity (scaled by the body gravity scale) isn’t.
You’d see this if you were to simply change the mass of a Ridbody/Rigidbody2D and not that it doesn’t affect gravity. You can still think it’s true if you like though. 
Also, for fun!
1 Like
Yeah, but that line does not explicitly calculate the gravitational force, only the acceleration that’s caused by it. And of course, if you set m * g to equal m * a, m gets cancelled out and your acceleration is - surprise - equal to the gravitational constant.
From how I read the source code, the same dampening value will lead to the same delta of acceleration, not to the same dampening force. Meaning that if you want two objects to have the same drag, you need to halve the dampening value when halving the mass. Is that correct?
(Also, the vacuum chamber kind of misses the point, because obviously there is no air resistance in a vacuum.)
Nobody said anything about that calculating gravity. I am talking about what the simulation does with a fixed gravity and two bodies of differing masses. They’ll have the SAME impulse force applied irrelevant of mass. They’ll accelerate the SAME over unit-time as is easily demonstrated in Unity. Also, the video doesn’t miss the point; it’s a good analogy/approximation to what I was describing as to what’s happening inside Unity.
In Unity is isn’t unless you’re calculating this yourself.
The damping in Box2D isn’t related to mass; it’s proportional to the instantaneous velocity at that iteration.
Anyway, I’m not here to argue with you; I highlighted the facts above on how it works in the simulation. If that’s irrelevant to you then I can move on.
But as soon as you apply dampening forces, Unity no longer works like a vacuum chamber, leading to results that clearly contradict how it should work based on an understanding of traditional physics. We can argue all day about semantics if you like, but I’d much rather move on from that.
You’re saying two bodies of differing masses but same drag will move the same - so why don’t they do that in the OP’s demo?
I think Melv is just making a point about gravity being an acceleration rather than a force in Unity; drag isn’t calculated as a force either, it’s just an attenuation of the current velocity that scales with a user constant.
Also, I don’t think the vacuum chamber link was meant to imply anything about the physics behavior in Unity.
Is OP using 2D physics? I haven’t looked at the project. My first instinct is to try changing the masses to very different values to see if the final velocities differ significantly. If mass is the only variable, then the final velocity being different in either direction seems like it would be a bug to me, especially knowing that damping is not intended to be proportional to mass.
argues with guy who works for unity and has access to the source code because physics
Thanks for your snark, it really adds a lot to the discussion.
All I was saying is that a) Melv’s explanation somehow does not lead to the results we can observe in the demo and b) we need to be a bit precise with our terminology if we want to analyze why Unity differs from reality.
I do not see how these two points are invalidated by Melv’s employment status.