koobas.hobune.stream
What is drag and velocity measured in?
What units of measurement does Unity use for velocity and drag? I'm guessing meters/second by I just want to be 100%.
Thank you.
Velocity , like Jessy said, is in worldunits / sec. anw 1 worldunity should be 1 meter but that's up to you. Drag is a bit different. I don't think it is based on any physical formular. It's sxplained in the Unity docs on Rigidbody. "0" means no airresistance and "infinity" means it stops immideately. http://unity3d.com/support/documentation/Components/class-Rigidbody.html
World units per second.
The units for velocity is world units per second, as Jessy said.
The unit for drag is a little weird. It is "per second" (or inverse seconds). This is from a calculation (after some experimentation) done by my friend. He found that
Drag Constant = -Drag Acceleration / Object Velocity
with the mass of the object not affecting the acceleration.
As the units for acceleration are meters/second^2 (lets just call world units meters) and velocity is meters/second, the meters and one of the seconds cancel, leaving us with 1/second or "per second".
P.S. Of course, without access to Unity's code or a confirmation from a Unity employee, the exact implementation might not be this.
P.P.S. I know that I bumped this (just) year old question; I ran into this conundrum as well and I figured that others might want to know too.
Thank You, I was looking for an equation that explained how the Drag you assign in the Inspector related to velocity.
$$anonymous$$y problem came from designing a jump action for a player and they wanted a jumpHeight of 10 and I wasn't getting 10 meters / world units. Problem was really that I couldn't jump onto the object that was 10 units tall like I wanted.
I recently had to touch on Physics, and as I stumbled upon this very same question, I decided to do a little bit of experiment.
To properly understand how drag works, I decided to recreate it with a custom component.
I've come to the conclusion that drag applies a counter force equal to the expected velocity increase over the next fixedDeltaTime. To do this, it sums the current velocity plus all forces applied within current FixedUpdate, and applies an opposite force.
It's like doing the following :
void FixedUpdate ()
{
// countering gravity if the rigidbody's using it
if (rigidBody.useGravity)
rigidBody.AddForce(-Physics.gravity * Time.fixedDeltaTime * drag, ForceMode.Acceleration);
// countering constant force if present
if (_useConstantForce)
rigidBody.AddForce(-(_constantForce.force + transform.TransformVector(_constantForce.relativeForce)) * Time.fixedDeltaTime * drag, ForceMode.Force);
// countering current velocity
rigidBody.AddForce(-rigidBody.velocity * drag, ForceMode.Acceleration);
}
public void AddForce (Vector3 force, ForceMode mode = ForceMode.Force)
{
rigidBody.AddForce (force - force * drag * Time.fixedDeltaTime, mode);
}
public void AddRelativeForce (Vector3 force, ForceMode mode = ForceMode.Force)
{
rigidBody.AddRelativeForce (force - force * drag * Time.fixedDeltaTime, mode);
}
General rules of thumb :
drag doesn't account for mass
with no added force nor gravity, a value of 1 will stop an object of any mass at any velocity over the course of 5 seconds.
a value of 5 will make it stop over 1 second.
Hope this helps.
Uhm actually drag is just applied to the velocity each frame. At least that's what my tests showed. I see you also posted on the forum thread. Have you read my post? All addforces are accumulated and directly applied to the velocity after fixedupdate was called. Drag only influences the velocity. All you do by applying drag to each force manually is to add another frame. Drag is effectively just a percentage slowdown. So your general rules don't make too much sense. When a rigidbody actually stops depends on the sleeping velocity and the actual velocity it moves at. Drag alone (if it's lower than the fixed frame rate) would never really make an object stop since it's a percentage slowdown. However due to the sleeping velocity the RB will just stop when the velocity drops low enough.
A Drag value of "1" just means a factor of "1-drag*dt" So with a fixeddeltatime of 0.02 it would be "1 - 1*0.02" == 0.98. So a 2% reduction per physics frame. Have you tried different speeds in your tests?
Actually, your assumption is right too. It may well simply apply to the velocity.
But it appears it does it after all forces have been applied within the current FixedUpdate, and velocity is modified after FixedUpdate is complete. So to achieve the same result, within current FixedUpdate, I had to calculate expected velocity at the end of FixedUpdate, and apply a counter force. As we don't have access to forces applied to a Rigidbody, I also wrapped the AddForce methods to limit their forces with drag.
This is, I guess, why the documentation says, we shouldn't change velocity directly. If you modify velocity within FixedUpdate, you are always "behind", as the velocity you change doesn't reflect the accumulated forces applied this FixedUpdate frame.
I ran tests with different velocities, different masses, different forces and different drag coefficients, always comparing my custom DragBehaviour with built-in drag value.
Now, doing the same as the built-in drag isn't much interesting. I'm now adding per-direction drag, which makes more sense to simulate aero-dynamics.
Hmm. If you just wanted to show how drag works in PhysX / Unity you could just use a reference implementation. So not using a rigidbody at all. If you want to implement your own drag you shouldn't care too much how Unity implements drag as this implementation has nothing to do with real drag. real drag depends on the velocity squared. A one frame delay doesn't really matter too much. Also you can apply your own forces directly to velocity ins$$anonymous$$d of using AddForce. Note that AddTorque and AddForceAtPosition is a bit more complicated due to the intertia tensor
