Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

fixedDeltaTime changes how physics work

Discussion in 'Physics' started by DeadlyArtist, Jan 15, 2021.

  1. DeadlyArtist

    DeadlyArtist

    Joined:
    Oct 19, 2018
    Posts:
    9
    I have two scripts. One for gravity, and one for a tornado that works like negative gravity while the player is inside it. The player thus bounces on top of it. However, the bounce becomes smaller if I decrease Time.fixedDeltaTime, and bigger if I increase it. Here's the code:

    Gravity
    Code (CSharp):
    1. _entityRigidbody.velocity += direction.normalized * velocity * Time.fixedDeltaTime * 10;
    Tornado
    Code (CSharp):
    1. rigidbody.velocity += Vector3.up * velocity * Time.fixedDeltaTime * 10;
    I made sure that both were called exactly once per FixedUpdate. Is there a way to eliminate this strange phenomenon?

    Visualization:

    fixedDeltaTime unmodified:
    upload_2021-1-15_2-40-58.png

    fixedDeltaTime * 0.1
    upload_2021-1-15_2-42-8.png

    fixedDeltaTime * 10
    upload_2021-1-15_2-42-53.png

    Also, the bigger fixedDeltaTime, the longer the player is inside the tornado.
     
  2. Maeslezo

    Maeslezo

    Joined:
    Jun 16, 2015
    Posts:
    325
    So, you are saying that
    Code (CSharp):
    1.     rigidbody.velocity += Vector3.up * velocity * Time.fixedDeltaTime * 10;
    2.  
    the bounce is strongest than
    Code (CSharp):
    1.     rigidbody.velocity += Vector3.up * velocity * Time.fixedDeltaTime * 0.1f;
    2.  
    Is that what you mean?

    This is completly normal. You are not changing the fixedDeltaTime, you are changing a constant, so the first one is 100x "strongest" than the second one.

    Your formula is this one rearranged
    Code (CSharp):
    1.  rigidbody.velocity = rigidbody.velocity + (K*velocity*Time.fixedDeltaTime)*Vector3.up

    In the first case, K*velocity = 10*velocity. In the second one, k*velocity = 0.1*velocity.

    Your are not affecting the time step, you are multiplying your formula by a factor
    If you want to change your fixedDeltaTime, change it here:
    https://docs.unity3d.com/Manual/class-TimeManager.html
     
    Last edited: Jan 15, 2021
  3. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497
    Just remove Time.fixedDeltaTime from the calculations.Velocity is a time-independent magnitude in this context. Simply specify the desired velocity in m/s and the physics engine will move the rigidbody at that velocity, no matter the actual fixed deltatime value.

    Additional note 1: When you need to read the delta time it is advised to use Time.deltaTime instead of Time.fixedDeltaTime, also within FixedUpdate. Time.deltaTime yields the correct value depending on where you are reading it from. See: https://docs.unity3d.com/ScriptReference/Time-fixedDeltaTime.html

    Additional note 2: Typically it's better to use AddForce with ForceMode.VelocityChange instead of modifying the velocity directly. Modifying Rigidbody.velocity overrides the calculations from the physics engine, which may cause other adverse effects. See an example here:
    https://forum.unity.com/threads/doe...top-gravity-from-working.749147/#post-6220200
     
  4. DeadlyArtist

    DeadlyArtist

    Joined:
    Oct 19, 2018
    Posts:
    9
    No I am.

    My function to update time
    Code (CSharp):
    1. public void UpdateTimeScale()
    2.     {
    3.         float tmp = currentTimeScale;
    4.         Time.timeScale = tmp;
    5.  
    6.         if (affectFixedUpdate)
    7.         {
    8.             Time.fixedDeltaTime = initialFixedDeltaTime * tmp;
    9.             Time.maximumDeltaTime = initialMaximumDeltaTime * tmp;
    10.         }
    11.     }
     
  5. DeadlyArtist

    DeadlyArtist

    Joined:
    Oct 19, 2018
    Posts:
    9
    The reason why I am also changing fixedDeltaTime is because otherwise have fun playing a game with like 20 ticks per second. If you want to slow down time for your player, you have to change this.

    I am specifically avoiding AddForce (also AddTorque btw), since they turned out to be quite buggy sometimes. I mean if you know how rotations and vectors work there's little reason to not just manage the forces on your own.
     
  6. DeadlyArtist

    DeadlyArtist

    Joined:
    Oct 19, 2018
    Posts:
    9
    After some testing my guess is that because the time steps are so little, the forces negate themselves earlier when they are more often applied at smaller magnitudes. I guess it's impossible to negate this phenomenon, but you can try and keep it reasonably low at low values for time.fixedDeltaTime. But that would probably require me to change how my game works, and is sure to bring other unwanted side effects :(
     
  7. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497
    No, and indeed slowing down the time for the player using Time.fixedDeltaTime is a bad idea.

    Just leave Time.fixedDeltaTime untouched (0.02), remove it from your calculations, set standard velocities in m/s, and use Time.timeScale to adjust the player time.
    • Time.timeScale = 1.0f is normal time
    • Time.timeScale = 0.1f is very slow time (1/10 of normal time)
    • Time.timeScale = 2.0f is twice as fast of normal time
    Physics, velocity and everything else will work correctly.

    I make extensive use of these in my realistic simulations and never found any bug. But changing Time.fixedDeltaTime dynamically surely can make them behave like they're buggy.

    Collisions and frictions. Those are really difficult to resolve by yourself realistically without almost re-writing the physics engine.

    Moreover, it turns out that setting Rigidbody.velocity directly interferes with the physics engine, as you're overwriting the results from the physics solver. This causes another set of side effects. But using AddForce with ForceMode.VelocityChange allows the engine to apply your velocity and resolve the physics correctly at the same time, including collisions, frictions, etc.
     
  8. DeadlyArtist

    DeadlyArtist

    Joined:
    Oct 19, 2018
    Posts:
    9
    Imma post a video how it looks like and then you be the judge. Maybe you can more easily understand my problem based on that.

    EDIT: Nvm, too lazy to do that now.

    Seems like I need to reconsider this one.

    Yes but no cuz I'm doing something very minimalistic and nothing realistic.
     
    Last edited: Jan 15, 2021
    Edy likes this.