x


What's the difference between Update and FixedUpdate? When are they called?

I'm making my own simple physics as I need more control and knowledge over what's going on in my very physic-driven game, and I just figured out that I can't update my velocity (final translation value) in Update(), because when the frame rate isn't fixed, I won't get the same final position after 5 seconds of game each time. I'd like to understand how precisely FixedUpdate() works, because the following explanation, taken from the Event Execution Order article on Unifycommunity, doesn't explain much to me:

Physics is run in a loop, iterating over the following until physics has caught up to the current frame:

 FixedUpdate
 Physics simulation

(...)

Say we have two timelines, and on the first one, we have fixed updates as blue rectangles, and on the second one we have normal updates (always as short as possible depending on processor and rendering) as red rectangles. How are they laid out? Are the normal updates delayed if fixed updates are still being processed? Or do the normal updates always just consider the last fixed update even if it was long time ago? I made a raycasted collision system and things never fly through anything, no matter what the speed is, and I'd like to keep it that way now.

more ▼

asked Feb 02, 2010 at 05:50 PM

Micha Lewtak 2 gravatar image

Micha Lewtak 2
268 18 14 18

(comments are locked)
10|3000 characters needed characters left

5 answers: sort voted first

As far as I understand it, the two different update functions work something like this. I'm writing it in the form of pseudocode first, and adding diagrams below, which may or may not make it clearer to understand!

In the (completely fictitious) code below, first the appropriate number of physics steps are executed in order to "catch up" with the current time (and each step, FixedUpdate() is called on each object which implements it). Next, the graphics for the frame are rendered, followed by Update() on each object which implements it.

var physicsTimeSimulated = 0; var lastUpdateTime = 0;

while (Unity is Running) { while (physicsTimeSimulated < Time.time) { Engine.ExecutePhysicsStep(); Engine.FixedUpdate(); // <-- sent to all objects physicsTimeSimulated += physicsTimeStep; }

 deltaTime = Time.time - lastUpdateTime;
 Engine.RenderFrame();
 Engine.Update(); // &lt;-- sent to all objects
 lastUpdateTime = CurrentTime;

 // and repeat...

}

It's worth noting that if the game is running at a slow frame rate, there will be numerous physics updates between each visible frame render. Conversely, if the game is running at a very high frame rate, there may be no physics steps at all between some of the frame renders, because the time elapsed since the last rendered frame has not yet exceeded the time period of a single physics step.

If the physics timescale is left at its default value (0.02) this gives us 50 physics updates per second - each physics step simulates the motion that occurs over the period of two-hundredths of a second.

The diagram below shows a period of one-tenth of a second. The dots which break up the line indicate 100th's of a second.

(I'm using an "F" to show where the FixedUpdate calls go)

0                                                0.1 seconds
|                                                 |
._._._._._._._._._._.___ 
F         F         F         F         F         F

Now, if our game were running nice and fast at 100fps, we'd have two frame renders for every physics step - and therefore two calls to our Update() functions, for every call to our FixedUpdate() functions. (Key: "F" for FixedUpdate and "U" for Update)

0                                                0.1
|                                                 |
._._._._._._._._._._.___ 
F         F         F         F         F         F
 U    U    U    U    U    U    U    U    U    U    U

If our game is running slower, say - at 30 frames per second (and therefore 30 calls to all Update() functions per second), it would mean that we actually sometimes have more than one physics step between each frame render. In the case of 30 fps, the result would be that sometimes two physics steps are executed between frames, and sometimes one, which would look something like this, for the first 10th of a second:

0                                                0.1
|                                                 |
._._._._._._._._._._.___ 
F         F         F         F         F         F
 U                U               U                U

So, in most normal circumstances, you'll always get the desired number of physics steps per frame, and interleaved with these will be the visual frame updates, at as fast a rate as possible.

It's for this reason that FixedUpdate should be used when applying forces, torques, or other physics-related functions - because you know it will be executed exactly in sync with the physics engine itself.

Whereas Update() can vary out of step with the physics engine, either faster or slower, depending on how much of a load the graphics are putting on the rendering engine at any given time, which - if used for physics - would give correspondingly variant physical effects!

The exception to this would be that if your scene was putting such a load on the physics engine that it approaches the point where it becomes impossible to execute the required number of physics time steps to keep up to speed with 'real time'. This means that your game has become impossible to simulate in real time - and in this case you need to seriously think about redesigning your game! This can happen if you have large numbers of complex objects (eg, rigidbody mesh colliders) all clumped together so you have lots of many-to-many collisions occuring each step.

Hope this sheds some light on the comings and goings of FixedUpdate and Update!

more ▼

answered Feb 02, 2010 at 09:38 PM

duck gravatar image

duck ♦♦
47.7k 131 230 471

Thanks, that really helped me out. Now I have another question - if we set fixed step time to some high value like 0.05, we'll have our physics running at 20 fps. So in the game, movements will seem to lag. Because assuming the game's running at 60 fps, only once per 3 frames will bodies' positions update. Kinda like in Bioshock for some people. Am I right here? Because if so, I don't wanna use Unity's physics for my game, which is All about physical movement...

Feb 03, 2010 at 07:14 PM Micha Lewtak 2

Well, yes - if you set the physics engine to operate at a low rate of update, it will do just that. The effects can be smoothed over by turning on rigidbody.interpolation - but why would you want to set it to a value like that in the first place?

Feb 03, 2010 at 08:30 PM duck ♦♦

Usually speeds like that are only used on iPhone, to ease the load on the cpu. For desktop builds, its commonly adjusted in the other direction for greater accuracy and to avoid the 'bullet through paper' problem - particularly for high-speed games like racing games.

Feb 03, 2010 at 08:31 PM duck ♦♦
(comments are locked)
10|3000 characters needed characters left

Update runs once per frame. FixedUpdate can run once, zero, or several times per frame, depending on how many physics frames per second are set in the time settings, and how fast/slow the framerate is.

more ▼

answered Feb 02, 2010 at 08:40 PM

Eric5h5 gravatar image

Eric5h5
110k 55 184 669

I just have a small doubt.. Say, I calculate values to add force on rigidbodies...

is it advisable

a) Get the values in Update() and then apply on FixedUpdate()

or

b) Get Values in FIxedupdate and apply in FIxedUpdate()

Sep 18, 2012 at 12:12 AM Karsnen_2

Its from February haha! Thanks for that link!

Sep 18, 2012 at 01:40 AM Paulo Henrique

Yes, February 2010 ;)

Sep 18, 2012 at 01:42 AM Bunny83

Bunny83 - the above link does not seem to work for me? Does it for you?

Paulo - Thanks I make sure to get the values from FixedUpdate()

Sep 18, 2012 at 12:50 PM Karsnen_2

@Karsnen: Hmm it works fine for me. Are you sure you have the Unity webplayer installed ? ;)

Sep 18, 2012 at 08:16 PM Bunny83
(comments are locked)
10|3000 characters needed characters left

fixed Update garanteed to run and if you make them heavy then your framerate will drop. you can easily test it. reduce the fixed update in edit/project settings/time and see how much frame rate drops. change this fixed time value to a number as large as possible. i think unity first run all FixUpdates and then run an update and render a frame.

more ▼

answered Feb 02, 2010 at 07:33 PM

Ashkan_gc gravatar image

Ashkan_gc
10.1k 77 101 164

(comments are locked)
10|3000 characters needed characters left
more ▼

answered Jan 21 at 10:40 PM

jpierre88 gravatar image

jpierre88
7 6 11 13

thats the answer!

Aug 24 at 04:23 PM syamilsynz
(comments are locked)
10|3000 characters needed characters left

Basically, without going into much detail, Update is drawn every frame, While FixedUpdate is drawn before physics calculations.

more ▼

answered Aug 28 at 02:50 AM

sillyjake gravatar image

sillyjake
5 1 2

(comments are locked)
10|3000 characters needed characters left
Your answer
toggle preview:

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Topics:

x9210
x3178
x2568

asked: Feb 02, 2010 at 05:50 PM

Seen: 51977 times

Last Updated: Aug 28 at 02:50 AM