What runs more often? Update, FixedUpdate or OnGUI? Documentation mistake?

Hi all!

Can someone give me an idea of how often these run? I'm not looking for numbers, but just relative frequency.

My understanding, according to what I read in the documentation, is as follows:

Update, the reference says "called every frame" -- So, I believe ONCE per frame
FixedUpdate, the reference says "called every fixed framerate frame" -- So, I believe less frequently than Update
OnGUI, the reference says "might be called several times per frame" -- So, I believe more frequently than Update

While attempting to debug a script today I was using the following code:

Code (csharp):

1.     // Declared outside of the methods
2.     private string DebugId {
3.         get { return Time.frameCount + ":" + this.ToString() + ":" + _playerName + ": "; }
4.     }
5.  
6.     // this is the first line in each of the methods: Update, FixedUpdate and OnGUI
7.     // In each method, I replaced the string "Awake!" with the respective method name, e.g., "Update"
8.     if (debugMsgEvent)  Debug.Log (DebugId + "Awake!");
9.  

I got the following results:

Code (csharp):

1.  
2. 248:GameAdminObject (NetworkController):happy1511: FixedUpdate()
3. 248:GameAdminObject (NetworkController):happy1511: FixedUpdate()
4. 248:GameAdminObject (NetworkController):happy1511: FixedUpdate()
5. 248:GameAdminObject (NetworkController):happy1511: FixedUpdate()
6. 248:GameAdminObject (NetworkController):happy1511: FixedUpdate()
7. 248:GameAdminObject (NetworkController):happy1511: FixedUpdate()
8. 248:GameAdminObject (NetworkController):happy1511: FixedUpdate()
9. 248:GameAdminObject (NetworkController):happy1511: FixedUpdate()
10. 248:GameAdminObject (NetworkController):happy1511: Update()
11. 248:GameAdminObject (NetworkController):happy1511: Update()
12. 248:GameAdminObject (NetworkController):happy1511: OnGUI()
13. 248:GameAdminObject (NetworkController):happy1511: OnGUI()
14. 248:GameAdminObject (NetworkController):happy1511: OnGUI()
15. 248:GameAdminObject (NetworkController):happy1511: OnGUI()
16.  

The pattern repeats consistently.

Notice that in a single frame,
FixedUpdate ran 8 times
Update ran 2 times
OnGUI ran 4 times

Is this a typical result? Basically, if I decide something needs to run less often, then I should put it in Update and keep FixedUpdate for stuff that needs to run more often? I thought it was the other way around. I also thought Update only ran once per frame.

Can someone clarify for me? Have I just misunderstood all along?

Thanks

Patrick

 

FixedUpdate should run the most as it is tied to the physics clock ticks, which are finer grained than the frame rate clock ticks which Update and OnGUI should run in.

 

FixedUpdate is fixed. By default, it runs every 0.02 seconds, meaning that if your framerate is slower than 50 FPS, then FixedUpdate will run more frequently than Update.

That's how I've understood it, anyway.

 

Also with OnGUI, it's just as the documentation says. It might get called more than once per frame, it might not. It seems to be affected by how often there are events for any GUIs present to act on. So something like dragging a slider control around should cause more frequent OnGUIs to happen as opposed to not touching any controls at all.

 

I would use FixedUpdate when you need something updated on a set scale, Update when it doesn't matter on rate, and OnGUI when it's GUI relevant. They each will effect your scripts differently, so know what you want while designing the solution.

 

Really, FixedUpdate is that frequent? I thought it was closer to every .1 seconds. Can you point me to a source please? I'd like to read more, but I haven't been able find anything definite.

 

I understand what you are saying. I'm asking which one runs at the slower rate. I know OnGUI can vary wildly, depending on what you are doing, so that's out. But between Update and FixedUpdate, what are the update rates? I thought Update varies, but basically it is "as fast as possible" whereas FixedUpdate is fixed. But fixed at what rate?

I guess I figured FixedUpdate ran slower because I dont understand what would be the point of running a physics update more than once per frame. Yet it seems to be running 8 times per frame. I'm also getting a result (see above) of Update running twice a frame. If a 'frame' is a render to the screen of the state of the game, what's the point of computing Update or FixedUpdate more than once per frame?

 

FixedUpdate is for physics, it wouldn't work if it was just updated 10 times per second. It's whatever you have the fixed timestep set to (.02 by default). Therefore, the answer to "Does FixedUpdate run more or less often than Update" is "Yes".

You're doing something wrong (like attaching the script twice). Update runs once per frame, that's the definition of Update.

--Eric

 

I thought it only ran once per frame. Ok, I added a gameObject.getInstanceID() to my output and you are correct! Somehow there are two copies of the object existing. Thank you very much for your help! Everything makes a lot more sense now.

Patrick

 

FixedUpdate's rate is controlled by your project's time settings - see Edit/Project Settings/Time for where to adjust the rate. The default is 50Hz (a period of 0.02s), as already stated.

Update, LateUpdate, and the various rendering functions are called once per rendered frame, after the FixedUpdates. How frequently they run depends on the frame rate. They don't run as fast as possible - many platforms lock the maximum frame rate, e.g. at 60Hz. It depends on the platform though.

So FixedUpdate may be called zero, one, or very many times per rendered frame.

If you want something to happen infrequently and don't care too much about the exact timing, start a coroutine containing an infinite loop, and inside the loop, do your work and yield a wait instruction for however long you want to wait.

 

InvokeRepeating is somewhat better for that sort of thing.

--Eric

 

I thought coroutines were made for the purpose of fixed time instructions, so not depending on the framerate but only on the yield instruction you feed it. So what you're saying sounds contrary to what I thought I knew about coroutines. So what's up with that.

 

Thanks Eric, I didn't know about that method.

Random, I don't know what you mean about fixed time instructions... but coroutines are a tool that's useful for all sorts of things.

 

I mean functions that are executed in pre-determined time intervals.

 

That depends on your system. If you have an ultra computer, FixedUpdate would run the slowest because Update and OnGUI is typically dependent on your frames per second. However, if you have a computer that can barely run your game, Update could run the slowest. If you are only getting half a frame per second, well... you get the point.

 

Not necessarily:

Code (csharp):

1. function CoUpdate () {
2.     while (true) {
3.         // do something
4.         yield;
5.     }
6. }

That works essentially the same as Update, for example.

Again, not necessarily; you could set FixedUpdate to something like 200fps if you want. Also if you have vsync on, then Update won't go faster than the refresh rate of the monitor (often 60Hz), no matter how fast the CPU is.

--Eric

 

So let's say in my case, I'm making a simple audio sequencer. It's better to use InvokeRepeat than to make a function with a coroutine? Now I use a function with a coroutine, timing seems not to be a problem yet. The importance is, when I make a sequence (or a loop) of a sound (a kick for example), the intervals between kicks should be at a steady rate. I'm curious to what's best to do in this situation. Perhaps Unity isn't made for this purpose, but I'm doing it anyway just because

 

I was going off of default values, which FixedUpdate is executed every 0.2 seconds. Obviously she/he didn't change the settings, if they didn't know about them. That's a lot faster than a single update per frame, at one frame per second.

My sole point was that the code should be known of it's usage prior to creating it. Each method is used for a specific purpose. (in most cases)

 

I haven't tested it, but this came up on UnityAnswers and someone said that InvokeRepeating was the most accurate.

--Eric

 

Perfect! Exactly what I wanted to know. Thanks!

Patrick

 

So what happens if the code inside FixedUpdate takes more than 0.02 seconds to execute? How can you guarantee that is runs at a fixed frame rate in this case?

 

You can't; the maximum allowed timestep setting will kick in if necessary, slowing physics down.

--Eric

 

Here is a test with 1024 frames at the default fixed timestep with no scene objects.
Times + frames passed are listed, and total calls are listed at the bottom.
http://pastebin.com/UnHyQzLw

 

Some thoughts on the conversation

Physics (Fixed Update)
Unity's physics system works on a discrete model. That means that every physics frame is determined by applying the calculations to the information from the previous frame. Discrete simulations require a set frame rate to maintain stability. The default tick timing of 0.02 (50 Hz) has several things going for it.

• Its faster then humans perceive
• Its reasonably close to the screen refresh rate
• Its fast enough to provide accurate physics
• Its slow enough that modern computers have no trouble calculating it

The physics time step should typically be left alone unless you have a good reason to change it.

Legacy GUI (OnGUI)
The legacy GUI uses an intermediate mode GUI system. OnGUI runs twice per GUI event. The first call is done using a Layout event. The second call is done with the GUI event. Every rendering frame there is a repaint event. This means at a minimum OnGUI runs twice per frame. Each input event comes with two calls, so if the user clicks there will be two calls for mouse down and two calls for mouse up. You can quickly see how these calls add up, which is why OnGUI was so unpopular for published games.

 

No, that's only 50fps, and humans perceive much, much faster than that. There's no particular limit.

Depends on which screen...120Hz is becoming more common.

Well...for some things. I wouldn't attempt, say, a pinball game with those settings, where you'd need at least .01 or better.

--Eric