Could anyone explain this behaviour between FixedUpdate and Update?

Hi!,

I have passed all day trying to make things smooth in my game, and there is something I don’t really understand.

I have done some test with built-in character controller that really makes me crazy.

I have 7 character controllers on screen all allways visible. If I move them (Move()) in FixedUpdate then device lags a lot, but If I move then in Update() everything is much more smooth. Which’s the reason of this behaviour?

I have been checking the wiki here unifycommunity.com and it seems that FixedUpdate runs 1 per several Updates?
Then, how is it possible it works better in Update than FixedUpdate :S. I have profiled the game, and yes, sometimes FixedUpdate gets around 214ms, but shouldn’t update() have same issue?

Thanks in advance,
HexDump.

update is called each frame
fixed update at the fixed rate you set (its the physics update rate). if its called more often than update for you then either you run at 10fps or you did by error raise the physics rate to 60 which won’t work out normally unless you target 4th gen / ipad only

FixedUpdate does its repetition in fixed timesteps, and is for physics stuff. If you go to Edit Projectsetings Time, you see a variable for Fixed Timestep.
Update does its repetition when the previous is done, faster framerate of the game means update goes faster, or Time.deltaTime is shorter :wink:


dreamora guckt au nur dä ganz tag is forum, da chunt ja keinä hinterhär!

Hi!,

Thanks for the answers.

Ok, what you explained is what I read in the docs and what I knew, but the behaviour I explained is what is making me crazy.

Again (Surely I’m missing something), If Update is called at a higher rate than FixedUpdate, how is it possible that moving the Character controllel in Update gives better frame rate than moving it in FixedUpdate? :S, it is pretty odd to me.

To give a bit more information the only thing I do in FixedUpdate and Update is this:

void Update / FixedUpdate()
{
	CharacterController cc=GetComponent<CharacterController>();
	cc.Move(new Vector3(200*Time.fixedDeltaTime,-250*Time.fixedDeltaTime,0));
	Vector3 pos=cc.transform.position;
	pos.z=0;
	Camera.mainCamera.transform.position=pos;
}

Well, this simple code produces what I explained in the first post. If in FIxedUpdate() this is slowwwwww, but in update it is almost good for 7 character controllers.

Edit: I have added some profiler output to check results:

With Update: iPhone Unity internal profiler stats:cpu-player> min: -4.7 max: 560.9 a - Pastebin.com
With FixedUpdate: http://pastebin.com/3hQEXYsu

I would really apreciate if anyone could bring some light about this, because I’m really lost right now. One of my assumptios is that moving character controller in fixedUpdate is invalidating all the collision tree or something like this, but not sure. Would be pretty nice if one of the devers could confirm.

Thanks in advance,
HexDump.

I’ve also been doing research into this whole FixedUpdate/Update thing, and I think I may have some useful answers for you.

First, if you check out the Update Order page, you’ll notice the line stating that “FixedUpdate() is often called more frequently than Update().” Good to hear, since that might explain your FixedUpdate performance being worse, but WHY is it called more frequently? I’ll try to explain below.

You can calculate the amount of time spent per frame very easily by dividing 1 by the frame rate. For example, if your game is running at 30fps, then:

1/30fps = 0.033s, or 33ms

So, let’s say that you’ve gone into Project Settings > Time and set your fixed timestep to 0.02s, or 20ms. Your FixedUpdate functions will be called every 20ms, while your game is actually updating and processing a frame approximately every 33ms. This means:

(1 update) / (0.033s) = 30 updates per second
(1 update) / (0.02s)  = 50 fixed updates per second

When your game is running at 30fps and doing fixed timesteps every 20ms, you can see that you are calling FixedUpdate nearly twice as often (50 times) as you are calling Update (30 times) per second of gameplay. In this case, FixedUpdate is being called more often, which means that your code in FixedUpdate could be called too often.

Now, let’s say you set your fixed timestep to now be 0.04s, or 40ms, which means you’ll be calling FixedUpdate approximately 25 times per second. Assuming your frame rate stays the same, you will now be calling FixedUpdate and Update roughly the same number of times.

You could abstract this and say that FixedUpdate is called more often than Update when (1/fixedTimestep) is greater than your framerate. And it is called less often than Update when the opposite is true. Whether FixedUpdate is called more often than Update is not a “set in stone” thing.

I’ve found that this answer page has a really good explanation of this, along with some graphics and an idea of what may be going on under the hood in Unity that causes this behavior. I’ll also note, based on what I’ve been reading, that you should pretty much only do physics stuff in FixedUpdate. I believe that CharacterControllers are not really physics objects, so it might not be great to update them in FixedUpdate.

I’m not an expert on this stuff by any means, so I may have gotten some of this explanation incorrect, but this is my understanding at the moment.