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:
* 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.
Answer by duck
Feb 02, 2010 at 09:38 PM
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.FixedUpdate(); // <-- sent to all objects
physicsTimeSimulated += physicsTimeStep;
deltaTime = Time.time - lastUpdateTime;
Engine.Update(); // <-- 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)
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:
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!
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...
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?
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.
Nice explanation :), Please rewrite the entire Unity Documentation Please
@duck Is there any proper way to get knowledged like you? :) _/_
Answer by Eric5h5
Feb 02, 2010 at 08:40 PM
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.
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()
b) Get Values in FIxedupdate and apply in FIxedUpdate()
If you get the data from Update it maybe inaccurate.
Ohh, another thread about FixedUpdate, so i link my FixedUpdate simulator just as reference ;)
Its from February haha! Thanks for that link!
Yes, February 2010 ;)
Answer by jpierre88
Jan 21, 2014 at 10:40 PM
This short video clarified it for me: http://unity3d.com/learn/tutorials/modules/beginner/scripting/update-and-fixedupdate
thats the answer!
Answer by Ashkan_gc
Feb 02, 2010 at 07:33 PM
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.
Answer by sillyjake
Aug 28, 2014 at 02:50 AM
Basically, without going into much detail, Update is drawn every frame, While FixedUpdate is drawn before physics calculations.
Do you mean 'called'?
In FixedUpdate we deal with anything related to physics. And tied in with each FixedUpdate call (presumably right after exiting FixedUpdate for all objects), Unity's own physics-machine run one tick, lock-stepped.
Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.
The best place to ask and answer questions about development with Unity.
To help users post good questions and use the site effectively we have posted a user guide.
If you are a new user, check out our FAQ for more information.
If you are a moderator, see our Moderator Guidelines page.
We are making improvements to UA, see the list of changes.
For troubleshooting common problems with Unity 5.x Editor (including Win 10).
Answers and Comments
8 People are following this question.
The name 'Joystick' does not denote a valid type ('not found')
Quake like movement
Strange Rigidbody Behavior
Force to Velocity scaling?
Hit problem unity