FixedUpdate()

Unity Engine
1

Why do you have to use FixedUpdate for physics. What is wrong with using Time.deltaTime in update() i mean what is wrong with compensating the force upon an object using addForce() with Time.deltaTime? sure the frames in update() take different amounts of time to complete but when you are using Time.deltaTime is it possible to compensate the amount of force on a object from one frame to another?

2

I found the answer here to be pretty good : What's the difference between Update and FixedUpdate? When are they called? - Questions & Answers - Unity Discussions

Also, think this: You have physics running in update, game runs at 60fps, then hangs for 2 seconds (for some reason), then resumes to 60fps. What happens to the physics?

3

Well just a guess since you are utlizing Time.deltaTime and i am assuming one frame took long. It compensates that frame
so that even though it took 2 secs it adds force equals to multiple frames it might have completed in that time period.

4

Assume you are adding forces when, say, keypresses happen. And you tap “A” and add force Vector3.LeftTime.deltaTime. Then you tap “D” and Vector3.RightTime.deltaTime just as the game hangs for a couple of seconds.

5

I believe doing it in Update would make the physics less predictable, and therefore less reliable when it comes to collisions.

6

You say that but what if the game hangs for 2 secs in FixedUpdate() during the 0.02 time interval each frame takes to complete?

7

A frame doesn’t take 0.02secs, it can take whatever. Also not sure what you mean by “hangs on fixed update”. Fixed update can be ran multiple times per frame if needed (or just once, or none, depending on fixed update rate and actual framerate).

Did you read the link I posted? It explains it quite nicely.

8

Yes i did read it but i am a noob i do not understand anything that is going unless it applies to me. I cannot relate give me a simple scenario and i will understand.

9

Building a simulation for physics with a variable time step is a night mare. Believe me, I’ve done it. Getting consistent results is pretty difficult. Things like collision checking, applying forces, drag and friction all have much simpler calculations if they are done with a discrete time step. The simulation happens for 0.02 seconds, then all of the various forces are calculated, then simulation, then calculations. Rinse and repeat forever.

The folks at NVIDIA came to the same conclusion when they built their PhysX. Simulated physics is just far, far simpler with a discrete simulation.

So Unity comes along and says “What is the best physics engine for games on the market”. The answer is PhysX. Since PhysX is built around a fixed time step, it makes sense to interact with PhysX using a fixed time step. Thus FixedUpdate is born and created.

You don’t have to use FixedUpdate for physics, but expect to see some inconsistent results if you don’t. Occasionally jumping twice as high as normal is a common one.

  • Player holds down jump key
  • Update runs, player is grounded. Force up is added
  • Update runs, player is grounded. Force up is added
  • FixedUpdate runs. Force is added twice. Player moves, and is no longer grounded
  • …
  • Players final jump height is twice the expected height, because of the double force added.
1 Like
10

Imagine a car, with the engine as your AddForce().

Now imagine driving your car down a freeway with your foot held on the throttle at a certain postition, your ride will be smooth and you will always know how fast and how far you are traveling at any given moment. This is FixedUpdate…

Now imagine traveling down the highway and slamming your foot on and off the throttle, sure you can time it to reach your destination in the same amount of time but you’re going to be jerked back and forth and in for a bumpy, uneven, ride and never quite sure how fast you may go at any second of your ride. This is Update().