- Home /

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

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** 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.

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

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.

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

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.

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).

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.

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`

).

It seems like you're coming 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.

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

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

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.

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.

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.

**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

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?

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.

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! :)

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

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.

**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.

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 :)

**Answer** by Owen-Reynolds
·
Mar 11, 2016 at 11:36 PM

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.)

Best explanation! I'll just add to illustration:

```
//all these functions produce the same effect
//number will be just added,
// so we usually want to multiply by dt by ourselves
rb.AddForce(10*dt, 0, 0, Force$$anonymous$$ode.VelocityChange);
//number will be multiplied by dt inside
rb.AddForce(10, 0, 0, Force$$anonymous$$ode.Acceleration);
//number will be <divided by mass AND multiplied by dt> inside
rb.AddForce(10*mass, 0, 0);
rb.AddForce(10*mass, 0, 0, Force$$anonymous$$ode.Force);
//number will be <divided by mass> inside
rb.AddForce(10*mass*dt, 0, 0, Force$$anonymous$$ode.Impulse);
```

**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

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.

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

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

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.

### Your answer

### Welcome to Unity Answers

The best place to ask and answer questions about development with Unity.

To help users navigate the site we have posted a site navigation guide.

If you are a new user to Unity Answers, check out our FAQ for more information.

Make sure to check out our Knowledge Base for commonly asked Unity questions.

If you are a moderator, see our Moderator Guidelines page.

We are making improvements to UA, see the list of changes.

### Follow this Question

### Related Questions

ForceMode.VelocityChange vs. simply adding to .velocity 0 Answers

Predicting trajectory using Equations of Motion considering drag & Magnus effect 0 Answers

Trouble with spring platform 0 Answers

Foces only change during collision 1 Answer

Trying to Understand Rigidbody ForceMode Derivation 3 Answers