Difference between ForceMode.Force/Acceleration/Impulse/VelocityChange?

Question

What is the difference between the four modes of ForceMode? I don't understand how you can apply a force in multiple ways. For example, if I put my hand on a car and push with a specific amount of force for 5 frames, what's the difference to hitting it with the same amount of force once each frame for 5 frames?

Answer 1

Best Answer

Answer by Clonkex · Nov 14, 2015 at 12:37 PM

History Lesson ^{_{_{(not really)}}}

Ok, so more than a year later I've had the need to come back and attempt to fully understand this problem (as I never really understood what the differences were). After staring at the formulae for a long time and not really getting anywhere, I decided to stare at the page linked by @jchangxu (thanks btw!). After a short while, one phrase jumped out at me: Think of it as 'Force exerted per second'

Instantly I realised I understood the differences. It's actually really simple, but everyone makes it sound so complicated that you assume it's more complicated than it really is. Since no one has yet managed to explain it clearly, here's my attempt from the viewpoint of someone who's only just figured it out.

_{Incidentally: The official documentation could do with a better explanation since the current explanation in the docs is crappy and doesn't actually tell you anything unless you do the maths yourself, and even then the maths alone doesn't tell you everything about the function.}

tl;dr ^{_{_{(...or "The Boy That Couldn't Be Bothered")}}}

 ForceMode.Force == Force per second
 ForceMode.Impulse == Force per frame

There's no actual difference in the way Force and Impulse apply the forces, only in how they calculate the amount of force to apply. If you do Force once every FixedUpdate for exactly one second, you will have applied the same amount of total force as doing Impulse on just one frame.

Longer Explanation ^{_{_{(for maximum understandings)}}}

The real difference is that Force treats the force parameter as Newtons and Impulse treats the force parameter as Newton-seconds, but we don't need to understand that to have a good understanding of how to use the function.

Force is calculated as:

 Acceleration = Force * Time ^ 2 / Mass

Thus if the object has a mass of 2, you apply a force of 40 and the fixed timestep is left at the default of 0.02, it will look like this:

 Acceleration = 40 * (0.02 * 0.02) / 2
 Acceleration = 40 * 0.0004 / 2
 Acceleration = 0.016 / 2
 Acceleration = 0.008

So the object will gain 0.008 metres per second of velocity. In other words, it will accelerate by 0.008m/s.

Impulse is calculated as:

 Acceleration = Force * Time / Mass

Thus if the object has a mass of 2, you apply a force of 40 and the fixed timestep is left at the default of 0.02, it will look like this:

 Acceleration = 40 * 0.02 / 2
 Acceleration = 0.8 / 2
 Acceleration = 0.4

So the object will accelerate by 0.4m/s.

Notice that 0.4 is exactly 50 * 0.008 (50 being the default number of timesteps in a second). That's because Force treats your force input as force per second, whereas Impulse treats your force input as force per timestep.

The other two ForceModes, Acceleration and VelocityChange, are even simpler because they leave mass out of the equation.

Acceleration is calculated as:

 Acceleration = Force * Time ^ 2

Thus, regardless of the object's mass, if you apply a force of 40 and the fixed timestep is left at the default of 0.02, it will look like this:

 Acceleration = 40 * (0.02 * 0.02)
 Acceleration = 40 * 0.0004 
 Acceleration = 0.016

So the object will accelerate by 0.16m/s.

VelocityChange is calculated as:

 Acceleration = Force * Time

Thus, regardless of the object's mass, if you apply a force of 40 and the fixed timestep is left at the default of 0.02, it will look like this:

 Acceleration = 40 * 0.02
 Acceleration = 0.8

So the object will accelerate by 0.8m/s.

And finally, it's worth saying it again, just to be clear: no matter which ForceMode you choose, the force will not be applied on subsequent frames automatically. It will only be applied at the instant you call the function. The difference is simply in how it calculates how much force to apply, not in how it applies the force.

Add comment · Show 28 · Share

Clonkex · Nov 14, 2015 at 01:00 PM 0

Share

If someone reckons this answer isn't correct in any way, please say so and explain why you say that. Thanks!

jimmy12day Clonkex · Apr 07, 2021 at 06:58 PM 0

Share

Saying “ForceMode.Impulse == Force per frame” is totally wrong. The author even realized it by himself by saying "It will only be applied at the instant you call the function".

I am tired to explain this again, Unity physics is bad physics because those Forcemodes were not correctly implemented as it sounds.

Basically, they are all the same method, two of them have 50x speed(50 physics frame in a second) multiplier, two of them include Mass.

Clonkex jimmy12day · 3 hours ago 1

Share

It's not totally wrong. It's "force per frame" but only if you keep applying it every frame. It's talking about the units in use, not the behaviour of the function.

When you say "Unity physics" do you mean the new DOTS physics engine? Because the regular physics engine that's existed for years is Nvidia PhysX.

Your last sentence is exactly right. They all do the same thing, and we could easily achieve the same result with only one function and some maths on our end.

Show more comments

mgto · Jan 12, 2016 at 07:26 AM 0

Share

Your answer is good but there is one problem in the way you describe the effect.

So Force$$anonymous$$ode.Impulse is applying 50 per frame

50 what?

What you are currently doing when using AddForce() is not applying a 'distance' but:

Force$$anonymous$$ode.Impulse: you're applying an Impulse in Newton Seconds (Ns)
Force$$anonymous$$ode.Force: you're applying a Force in Newton (N)

If you're applying a Force of 5 (or an Impulse of 5) that's it. You don't have to calculate the actual force.

BUT if you want to know how big delta_s or delta_v are (the relative change in distance / velocity) you can use (for example) the formulas you've posted to calculate the values.

So if you have an Impulse of 5 Ns your object will travel 5 * 0.1 / 1 = 0.5 (relative) units after applying the impulse.

If you have a Force of 5 N your object will travel 5 * 0.1^2 / 1 = 0.05 (relative) units after applying the force for one frame and 0.5 (relative) units after applying it for 10 frames and 5 (relative) units after applying it for 100 frames etc.

I always write 'relative' because it always depends on the start conditions how the objects absolute movement will look like

HeavyStorm · Mar 09, 2016 at 07:29 PM 0

Share

I'm pretty sure where you typed 1 x 5 / 0.1 x 0.1 you meant 1 x 5 / (0.1 x 0.1), after all the math is based on the square of delta time, which would be 1 x 5 / 0.1^2. So the total force applied would be 500, not 5.

Clonkex HeavyStorm · Sep 28, 2020 at 01:05 AM 0

Share

500 force would be incorrect, and I didn't mean 1 x 5 / (0.1 x 0.1). At the time I assumed that internally it was treating time^2 as time * time, even though that would mean the manual's mass*distance/time^2 was incorrect to how it actually worked. In reality I was using mass*distance/time^2 incorrectly and it was just coincidence that it worked out if I did 1 * 5 / 0.1 * 0.1. I'll update my answer with the correct maths if I can find the time this weekend (the difficulty being that the correct maths is more complicated and I want the answer to remain easy to understand).

jimmy12day Clonkex · Apr 07, 2021 at 07:02 PM 0

Share

Dear Clonkex, your solutions are voted most, can you rewrite it in a simpler paragram please? Please take a chance to look at my explanations also.

Show more comments

oscarAbraham · Jun 07, 2019 at 07:26 PM 3

Share

This gets on top results on google, so I thought I'd clarify something. In spirit, this is right, but not in maths:

So the formula for force is force = mass * acceleration, that can be understood also as force = mass * (distance / time^2) When we input a force to the function, we are not using the formula like that, though. We already know the value for force, what we need is the value for acceleration. So the formula we are using is acceleration=force/mass.

For example, if our force is 5 and our mass is 1, then we get that acceleration = 5 / 1. So, Acceleration would be 5. That means our object's velocity would be augmented by 5. The problem is that we don't know over how much time our velocity would be augmented that much. Unity uses seconds as a time unit, should the velocity change be applied over a whole second? On the other hand, we are calling the function right now, to simulate what happens over a specific timeStep, should the velocity change be applied over this timeStep?

In Force mode, the value that we pass is in newtons. A newton is equal to 1kg * 1m/s^2. That means that if this force is applied to an object with a mass of one kilogram over one second, its velocity will been have augmented by one meter per second. Since our function is calculated on the fixed time step, the object's velocity will only be augmented as if the force was applied over that amount of time. In our previous example, if the fixed time step is .1 seconds, the velocity would be augmented by 5*.1, that means .5.

In Impulse mode, we say to the function: "Whatever the time step, I wan't the velocity change that would be applied in a second to be applied NOW". So our value is passed in units of 1kg * 1m/(s*timeStep). That means that if this force is applied to an object with a mass of one kilogram over one timeStep, its velocity will been have augmented by one meter per second. In our example, the velocity would be augmented by 5 each time the function is called.

Another way of thinking about it is that acceleration = velocityChange/time, that's why time is squared in the answer's formula, because distance/time/time = distance/time^2. Anyway, that means that velocityChange = acceleration*time. So in our example, if we are using Force mode, our time is .1 seconds (so it's 5*.1); but, if we are using Impulse mode, our time is 1 timeStep (so it's 5*1).

Clonkex oscarAbraham · Sep 28, 2020 at 12:59 AM 0

Share

It seems like you're co$$anonymous$$g at this from a physicist's perspective, but the problem is that as game programmers the majority of us don't see it that way. For instance:

The problem is that we don't know over how much time our velocity would be augmented that much. Unity uses seconds as a time unit, should the velocity change be applied over a whole second? On the other hand, we are calling the function right now, to simulate what happens over a specific timeStep, should the velocity change be applied over this timeStep?

That's essentially meaningless to me. Game physics simulations are processed in discrete steps, and they don't apply forces continuously over a period of time, so changes don't happen "over a whole second" or "over a specific timestep". They happen instantaneously, over no time at all. Boiled down, the only thing I care about is how much the object's velocity will change in this timestep, and whether the function will continue to have any effect on subsequent frames even if I don't call it again.

I'm also a little confused about your maths, because distance / time / time != distance / time ^ 2, unless you have a very different definition of exponents than I do.

Otherwise I do see that my maths is technically incorrect, and the only reason it works out is coincidence. I'll try to find the time to update this answer, but of course I'll need to figure out how to explain it well enough that it doesn't make it more confusing.

DeadlyArtist Clonkex · Oct 15, 2020 at 02:35 AM 1

Share

distance / time / time == distance / time ^ 2

because distance / time / time == distance / (time * time) == distance / time^2

because of how math works you do from left to right and ^ before * before + pls update i instantly noticed the error and others do as well and then they are confused

Show more comments

gillemp · Jun 09, 2020 at 03:58 PM 5

Share

I created this table from your answer so it is even simpler and quick to read: alt text

Clonkex gillemp · Sep 28, 2020 at 01:01 AM 0

Share

Personally I find this just as confusing as the manual's original explanation. The key problem here is that it makes it sound like .Force and .Acceleration will continue to apply the force over 1 second's worth of frames, when in reality they don't do anything past the single frame where you call them.

DeadlyArtist gillemp · Oct 15, 2020 at 02:12 AM 1

Share

Honestly by far best explanation. Literally says everything there is to it in an intuitive format. Best UX.

Seeing this pretty much confirmed my suspicions though: Force and Acceleration are utterly useless and it's better to just make a script that manages your object's velocity. I don't see a single reason for Force and Acceleration to even exist.

Tortuap DeadlyArtist · Oct 15, 2020 at 08:17 AM 2

Share

They are all useful, it's a matter of how you express and manipulate your values. If you manipulate values over seconds (speed) then you wan't to use Force or Acceleration. If you express values over a frame then you'll use Velocity or Impulse.

Show more comments

Answer 2

Answer by Jeff-Kesselman · Apr 27, 2014 at 11:47 PM

Okay, basic physics, Force = Mass * Acceleration

This means if you apply the same force to something with twice as much mass, the resulting change in acceleration is half as much.

Force Add a continuous force to the rigidbody, using its mass. Does what the formula says. The force is applied evenly across the period of the frame which is how you normally push on something.

Acceleration Add a continuous acceleration to the rigidbody, ignoring its mass. Just adds the force vector to the current object acceleration without dividing it by the mass

Impulse Add an instant force impulse to the rigidbody, using its mass. As the description says, this is the entire force, divided by mass, added all at once. Its for simulating things that accelerate very suddenly like explosions

VelocityChange Add an instant velocity change to the rigidbody, ignoring its mass. This is like Impulse but does not divide the force nby the object's mass.

This is all explained on the web pages https://docs.unity3d.com/Documentation/ScriptReference/ForceMode.html

Add comment · Show 8 · Share

Clonkex · Apr 27, 2014 at 11:51 PM 1

Share

But...what I don't understand is how a force can be applied continuously when the physics is only calculated in set steps. Surely it has to be applied all at once in the step that the function is called from?

Jeff-Kesselman · Apr 28, 2014 at 12:26 AM 0

Share

Again, the answer si in the docs:

" In this mode, the unit of the force parameter is applied to the rigidbody as mass*distance/time^2."

The force is calculated as being applied over the distance traveled so that in the intervening time, it accelerates to the final speed. This means it will not move as far as if the force changed the velocity at the start of the duration and the object moved at that final speed over the entire duration, which is what an impulse would do.

Clonkex · Apr 28, 2014 at 12:41 AM 0

Share

Ok...still not sure I totally understand how this works, but it doesn't really matter since I now understand what happens as a result of each method. Thanks! :)

Clonkex · Nov 14, 2015 at 12:39 PM 0

Share

I unaccepted your answer because I wrote my own after I figured it out for myself. You clearly misunderstood why I was confused before since your answer didn't really answer my question, but it's all good now since I've worked it out :P

Clonkex · Nov 14, 2015 at 12:45 PM 0

Share

To be clear, my confusion revolved around the fact that you didn't explain what "continuous" meant. I sounded like you meant the force continued to be applied for a certain number of frames after you called the command, or that it applied a decaying amount of force over a number of frames. That kind of thing. Not explained anywhere and super confusing if you don't know any better. In the end I decided you must mean the physics engine treated the force differently, so a .Force would be calculated as though it were a constant force between one timestep and the next, and .Impulse would be calculated as though it were an instantaneous force at the start of the the timestep... or something. I still didn't understand how that could work, though, so I gave up on trying to figure it out.

Show more comments

Answer 3

Answer by jchangxu · Oct 11, 2014 at 07:13 PM

I had difficulty understanding the 4 modes as well, especially what is the period of frames it applies to. This helped me.

http://www.redshiftmedia.com/gamasutra/Tomasz%20Kaye.%20Understanding%20ForceMode%20in%20Unity3D%20(salvaged%20from%20Gamasutra).html

Add comment · Show 2 · Share

Clonkex · Nov 14, 2015 at 12:40 PM 0

Share

You answer helped me finally solve the mystery. I've posted my own answer in the hopes that it may help other people confused by the lacking documentation of this feature :)

metroidsnes · Sep 14, 2018 at 06:08 AM 0

Share

The link is broken.

Answer 4

The trick with ForceModes and all the physics talk is it wasn’t written for us. It’s from general physic simulators, where you don’t talk about framerates and don’t script, but you know Newtonian physics really well. When Unity borrowed the Physics Engine, those terms just came with it.

So the confusing part is two things. One, it seems like they’re using that strange Physics language because there’s no easier way to explain it (not true.) The other is how using it is pointlessly awkward. AddForce really is written in a bad way for regular game designers.

All AddForce ever does is change your speed, as a 1-time thing. Some of the options say stuff about “force over time” — we can ignore that. One ForceMode option divides by the framerate, another divides by how much you weigh. The other two divide by both, or neither.

That seems insane, to have options for math we can easily do ourselves. We all know if you want to add 10 per second, you add 10*Time.fixedDeltaTime every frame in FixedUpdate(). If you want to divide by the weight, you put 10/rb.mass. If you want to use both — it’s math, you just type it all out.

It happens that ForceMode.VelocityChange is the “just add it” option. To speed up by 10/second we could put either of these in FixedUpdate:

 rb.AddForce(10*Time.fixedDeltaTime, 0, 0, ForceMode.VelocityChange);
   or
 rb.AddForce(10, 0, 0, ForceMode.Acceleration);
 // ForceMode.Acceleration multiplies by fixedDeltaTime

To a Physics guy, that star symbol and the Time-dot part is super-confusing. But they understand Acceleration means you’re only giving it a little fraction of 10 right now.

Or suppose this was in a non-Unity system with a drop-down number picker — you couldn’t even put an equation after the 10, and would have to use the right ForceMode.

The last mystery is why the default is the most complicated option. If you just use rb.AddForce(10,0,0) it uses ForceMode.Force, which divides by the frameRate and your weight. It’s that way because it was designed by physicists —- that’s the real way pushes work.

They don’t understand that we don’t care about the real way.

Even the command-name is needlessly Physics-based. AddFORCE? Why not just AddVelocity, which is what it really does? Again, to a Physicist, using a Force is more natural. To us, giving just a speed is normal (like giving a boulder a speed of 10, no matter what it weighs.)

Answer 5

Answer by LouisHong · May 22, 2018 at 01:52 PM

ForceMode.Acceleration is ForceMode.VelocityChange but mutiplied by Time.fixedDeltaTime

ForceMode.VelocityChange just changes velocity by force parameter

ForceMode.Impulse changes velocity by force / mass

ForceMode.Force changes velocity by force / mass * Time.fixedDeltaTime

They should just write this as the unity documentation for ForceMode, hope you found it useful

Add comment · Show 4 · Share

MrLeaky · Feb 06, 2019 at 09:05 AM 1

Share

Exactly; this is a great way to summarize it. The documentation is totally confusing, and their bloated, unreadably formatted (i.e. no proper syntax highlight) example code is not helpful at all.

Tortuap · Sep 27, 2020 at 09:03 PM 0

Share

Force$$anonymous$$ode.Force changes velocity by force / mass * Time.fixedDeltaTime, no ?

Owen-Reynolds Tortuap · Sep 27, 2020 at 09:13 PM 0

Share

Yes. Every mode is the same: a 1-time change to velocity. The only difference is the amount they change it by.

Bunny83 Tortuap · Sep 28, 2020 at 12:20 AM 0

Share

There was a similar question like this from the same year and I gave a pretty clear explanation I_m sure Louis wanted to say "velocity" and not "acceleration". I'll edit this answer to fix it.

Difference between ForceMode.Force/Acceleration/Impulse/VelocityChange?

8 Replies

History Lesson ^{_{_{(not really)}}}

tl;dr ^{_{_{(...or "The Boy That Couldn't Be Bothered")}}}

Longer Explanation ^{_{_{(for maximum understandings)}}}

Your answer

Follow this Question

Related Questions

Difference between ForceMode.Force/Acceleration/Impulse/VelocityChange?

8 Replies

History Lesson (not really)

tl;dr (...or "The Boy That Couldn't Be Bothered")

Longer Explanation (for maximum understandings)

Your answer

Follow this Question

Related Questions

History Lesson ^{_{_{(not really)}}}

tl;dr ^{_{_{(...or "The Boy That Couldn't Be Bothered")}}}

Longer Explanation ^{_{_{(for maximum understandings)}}}