koobas.hobune.stream
Physics behaviour changing with framerate - Is FixedUpdate() actually working properly?
I've asked elsewhere about small objects falling through a mesh collider. I think scale is playing a role but i got to thinking that the results i'm seeing don't really line up with the concept of Fixed Update working properly.
Namely if at 90hz a small sphere can settle on a plane, then at 1hz (an extreme unplayable example) that same small sphere should still stay settled on the plane, as its fixed updates will all be constant time up to the maxFixedUpdateTime where by i'm assuming it just does no more updates that frame, causing it to slow down as the documentation describes.
This doesn't seem to happen. I'm seeing occasional falling out of the world in my actual game but in testing it in the editor i've noticed that if i have a mostly settled object and then i just move my mouse cursor quickly across the mac dock icons so they animate and enlarge, the framerate in unity drops down to around 20hz and the settled objects just fall through the surface they were previously mostly settled on.
Now as i said i think scale must be playing a role as a tiny sphere will pass through a super thin polygon due to gravity much quicker than a larger sphere.
But still given
- gravity set to around 2.8m/s2 (just for the aesthetic of the simulation)
- fixed update of 0.01s
- rough increase in velocity from acceleration is 0.028m/s during a fixed update
- rough distance moved due to velocity is 0.00028m during a fixed update
- -
- (i hope those calculations are about right?)
now I'm not sure exactly what happens as the sphere settles on a surface but i guess its fair to assume that a lot of micro bounces are occurring and so the velocity may get a few fixed update frames to be accelerating down before it collides with the plane again (leading to a larger distance moved) but still these are the kind of orders of magnitude we're talking about, and the sphere radius shouldn't be much smaller than say 0.01m.
Yet the object, seemingly when small enough DOES pass through the plane.
Hence my question, surely something is happening that is breaking the time passed during fixed physics Updates for an object to pass through its radius in a fixed update step, even when its radius is nearly 100x greater than the distance it should be moving in the specified fixed step. Either that or some serious scale related rounding errors are creeping in.
I'll try this test out in a simple scene in Unity iPhone that i'm using, as well as in latest Unity to see if its the same in both. But I just can't understand what it's doing, even though i'm hopeful i can work around it.
Cheers
The FixedUpdate loop is normally called at fixed frequency, but when things get rough it can drop. I believe in Unity iPhone you can actually control this behavior a bit, in Edit -> Project Settings -> Time, you can here define a maximum allowed TimeStep, if Unity doesn't manage to make this deadline, time is slowed down (TimeScale).
Edit:
Okay, I'm not sure if the TimeScale is changed (don't think it is, but having fixed update called less often does about the same thing), but the max. allowed TimeStep limits the number of FixedUpdates in a frame. The value is in seconds. Generally several fixed updates are done in one frame, when your framerate drops, more fixed updates are run per frame. The Max. Allowed Timestep is the number of seconds the sum of the fixed updates in a frame may spend, if this budget is exceeded, no more FixedUpdate calls are made during this frame.
Example: Let's say you've got Fixed Timestep on 0.016666 (60Hz), the time to handle the physics/fixed update is generally 10ms, your max allowed timestep = 0.040 (40ms), if your game runs at 30fps, it means 2 fixed updates = 20ms time, if your fps drops to 20, it means 3 fixed updates = 30ms. if your fps drops to 10, without the limit you would get 6 fixed updates = 60ms processing time, but with the limit of 40ms, the fixed update isn't called for this frame anymore after the fourth time.
i thought the maximum time step was only something used to restrict the number of fixed updates that could occur, not the time that the fixed update time actually is allowed to go up to in a single jump.
Something is definitely going on though.
I'll take a look at the docs a bit more closely to check on the meaning of the max allowed time step.
Cheers
sorry to elaborate. fixed update of 0.5, max fixed update of 2. Would mean that a maximum of 4 fixed updates (of 0.5s) would be allowed, to reach the 2 second maximum. If this still wasn't enough to pass as much time as had occurred that frame then its just left till the next tick. At runtime the physics would seem to run slower as they'd not managed to update the same amount of time as had occurred.
Yes, indeed, you're right, just added it to my text, but now I see you're saying the same thing, only using less words :-)
thanks, but my original question still stands then. With fixed updates the physics should be completely framerate independent aside from when it drops so low that max fixed update comes into play. But even then it should just cause the physics to slow down, NOT change their update frequency so much that settled objects fall through planes!
I'll try more test scenes tonight, to see if physx behaviour is different in unity to unity iphone.
Tonight I actually tried to reproduce this in a more simple case..
I placed a 0.01m scale sphere on a plane and tried to get it to drop through.
It wouldn't!!!
So the short answer seems to be YES, fixed update is doing its job.
The original mesh i was describing had some transformations being applied to it via rotate and move. These transformations were being made within Update() not FixedUpdate() which i guess is just a terrible idea. Their movement stays constant and i presume the tiny fixed updates have to suffer the entire frames movement.
I confirmed this by initially stopping all transformations and the physics behaved themselves.
I then slowly increased the magnitude of these transformations and was able to see that it was these transformations themselves that were actually causing the dynamic objects to pass through the mesh.
Moving the transformations into FixedUpdate() and all seems well so far with a quick test!!
So. Yes there are gotchas, but all is sane in the world... fixed update, DOES do its job by providing framerate independence!!!! Phew! :)
If Unity wants to be a great Engine for Mobile platform, which its heading towards. I believe Unity should work on Fixing the issue of Physics not syncing with frame rate. I also faced the same issue. Did a jump animation using physics and in low end device it lagged and physics reacted badly. No doubt it worked good on high end device but for devices which suddenly dropped fps it was bad.
