Search Unity

Disadvantages with fixed timestep = 0.01 on android and iOS?

Discussion in 'Scripting' started by Bongmo, May 20, 2017.

  1. Bongmo

    Bongmo

    Joined:
    Jan 18, 2014
    Posts:
    155
    I set in the my code the fixed timestep to 0.01 (Default: 0.02), because it looks better on android.

    Code (CSharp):
    1. void Start() {
    2.  
    3.     Time.fixedDeltaTime = 0.01f;
    4.  
    5. }
    What for disadvantages would I get now? Has somebody experience with that?
     
    Last edited: May 20, 2017
  2. WheresMommy

    WheresMommy

    Joined:
    Oct 4, 2012
    Posts:
    890
    What is looking better?
     
  3. Bongmo

    Bongmo

    Joined:
    Jan 18, 2014
    Posts:
    155
    The movement of the objects. No jitter.
     
  4. JoshuaMcKenzie

    JoshuaMcKenzie

    Joined:
    Jun 20, 2015
    Posts:
    916
    fixedUpdate plays "catchup" based on the fixedDeltaTime and the amount of time that has passed since the previous frame.

    the danger with setting fixedDeltaTime too low is that you can have a runaway loop and performance will just crash.

    imagine this:
    fixedDeltaTime is set to 0.01. The previous frame happened 0.16 seconds ago. fixedUpdate needs to catch upto this frame so it loops until its caught up. so it loops 16 times. and it now caught up. and everything looks smooth. later you make even more complex FixedUpdate functions and one particular FixedUpdate takes 0.06s to run. then if previous frame was .1 seconds ago FixedUpdate must run 10 times to catchup to this frame. but it took 0.6s to run that loop. Thus on next frame it'll see that the previous frame happened 0.6 seconds ago and thus FixedUpdate must loop 60 times.

    suddenly that single fixedUpdate is now taking 3.6 seconds to run. and it only gets worse from there.

    Reducing FixedUpdate is fine it'll work and make things look smooth. but you must keep it on a short leash.

    give your FixedUpdates a time budget, a duration that they should always remain under, and then set your fixedDeltaTime to above that budget. in the previous example that means either cleaning up that FixedUpdate so it always runs under 0.01 seconds or increase the fixedDeltaTime to above 0.06, or a compromise between the two. its a good idea that the difference is an entire magnitude (as in FixedUpdate must run in under 0.001 - 0.005 seconds if fixedDeltaTime is 0.01) so that sudden fps drops doesn't suddenly tank the game and it can recover.
     
    thefirstplaybae and WheresMommy like this.
  5. DroidifyDevs

    DroidifyDevs

    Joined:
    Jun 24, 2015
    Posts:
    1,724
    Well you're going to get worse performance with that, as it's now calculating many more times per second. One of the first things I do to optimize is actually slow down the fixed timestep. If something is jittering, perhaps you should find out why it's doing that?
     
  6. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    You've got maximum allowed time step which prevents this exact scenario. So it's not really a problem.

    This. Reducing the time step increases the number of times physics is caculated. So you have less time for other calculations.
     
  7. UziMonkey

    UziMonkey

    Joined:
    Nov 7, 2012
    Posts:
    206
    This will cause the physics engine to do a lot more work. Generally this is not required, if you want objects to move smoothly you should be setting either the Interpolate or Extrapolate modes and they'll generate "fake" physics frames and move the objects between physics updates. This generates very minor glitches (fast-moving objects may appear to go through walls for a single frame if using extrapolate, for example) or some very minor lag (interpolate generally keeps the objects a single frame behind where they "actually" are) but in general works really well and everything looks perfectly smooth.

    So no, I don't recommend setting the fixed timestep to 0.01.