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

Physics velocity doesn't actually make objects move at the correct speed?

Discussion in 'Physics for ECS' started by PhilSA, Apr 27, 2020.

  1. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    Here's the situation: I have two cubes (A and B) in my scene
    • CubeA moves its translation every frame like this:
      Code (CSharp):
      1. translation.Value += World.Time.DeltaTime * new float3(0f, 0f, 10f);
    • CubeB is a kinematic PhysicsBody that has a constant linear velocity of (0f, 0f, 10f)
    When I press Play, CubeA moves about 30% faster than CubeB

    Any ideas why this happens? Using Unity 2020.1b6 and Unity Physics 0.3.2
     
    Last edited: Apr 27, 2020
  2. petarmHavok

    petarmHavok

    Joined:
    Nov 20, 2018
    Posts:
    461
    This might be silly, but are you sure physics and this custom translation code are both using exactly the same delta time?
     
  3. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    As far as I can tell, my cubeA uses the variable update deltaTime (same as UnityEngine.Time.deltaTime), and I didn't change anything about the way physics are updated. I'm assuming it also uses an equivalent of UnityEngine.Time.deltaTime?

    What I find weird is that even if physics was running on fixed update, a velocity of 10 should still be a velocity of 10

    I'm still not discarding the possibility that I made a dumb mistake somewhere, but I was just wondering if this was a known issue. Kinda like in earlier Physics releases where the demos would play super fast because they were using fixed dt but updating on regular update as a temporary measure before simulation/presentation world was properly implemented
     
  4. petarmHavok

    petarmHavok

    Joined:
    Nov 20, 2018
    Posts:
    461
    I don't think we have anything know here, it seems like a strange issue. Is there a chance you could provide us with a simple repro project to look into? Or edit any of our sample demos to showcase the same artifact?
     
  5. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    I played with it some more, and found out that if I move a cube like this:
    Code (CSharp):
    1. public class MonobehaviourMover : MonoBehaviour
    2. {
    3.     public Vector3 Velocity;
    4.  
    5.     void Update()
    6.     {
    7.         transform.position += Velocity * Time.fixedDeltaTime;
    8.     }
    9. }
    the cube moves at the same speed as the physics cube. So I guess this answers my question. It seems that the default Physics systems update every regular update, but are still using the fixedDeltaTime nonetheless, so they move faster/slower than they should depending on framerate

    Seems like it should be either VariableUpdate + variableDeltaTime, or FixedUpdate + fixedDeltaTime, but not any other combination of those. I'm aware of the FixedTimestepWorkaround in the samples, but I thought the physics was just running with variable deltaTime until the real fixedUpdate solution was added to DOTS
     
    Last edited: Apr 27, 2020
    petarmHavok likes this.
  6. steveeHavok

    steveeHavok

    Joined:
    Mar 19, 2019
    Posts:
    481
    Yeah, currently the StepPhysicsWorld uses the following:

    Code (CSharp):
    1. #if !UNITY_DOTSPLAYER
    2.             float timeStep = UnityEngine.Time.fixedDeltaTime;
    3. #else
    4.             float timeStep = Time.DeltaTime;
    5. #endif
     
    Thygrrr and petarmHavok like this.
  7. PerfidiousLeaf

    PerfidiousLeaf

    Joined:
    Aug 30, 2019
    Posts:
    20
    Unity Physics systems have always used fixed time since movement, forces and collisions are very sensistive to lag and need to ensure synchronization across clients.

    Repeat the above test using a MonoBehavior with all movement code stored in FixedUpdate().
     
  8. ComputerKim

    ComputerKim

    Joined:
    Jan 6, 2019
    Posts:
    15
    This gave me a headache recently. Movement is not consistent when the timeStep changes like this, so I have been using the following code to make the simulation group / physics run at a fixed interval. (Systems are in the Simulation group by default)
    Code (CSharp):
    1. using Unity.Entities;
    2.  
    3. public class StartSystem : ComponentSystem {
    4.     protected override void OnUpdate() {
    5.         // Make simulations run on fixed time
    6.         FixedRateUtils.EnableFixedRateWithCatchUp(World.GetOrCreateSystem<SimulationSystemGroup>(), UnityEngine.Time.fixedDeltaTime);
    7.  
    8.         // Disable system, it is only meant to run once.
    9.         Enabled = false;
    10.     }
    11. }
    Is there a reason why this is not the default?
     
  9. VildNinja

    VildNinja

    Joined:
    Jan 17, 2013
    Posts:
    8
    The error is that new physics uses fixed time, but ECS simulates it in update.

    I think that is the plan (in the future), but doing this now would make other (non-ECS) systems such as input break/be more cumbersome to interface with. Plus the added complexity of a job dependency chain, where some systems might be skipped some frames.
     
    Last edited: May 4, 2020
  10. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    Once the fixed update API design is figured out in DOTS, can we expect physics systems to use variable dt if they're not setup to use fixedUpdate, and fixed dt if they are?

    There are some situations where one could possibly want physics to run on variable update. For example, some people want to run character controllers on update for maximum responsiveness. In that case, for proper interaction with kinematic bodies that move with PhysicsVelocities (imagine moving platforms), these bodies would need to move with variable dt as well. (if someone chooses a variable physics dt, they will usually be in a situation where they don't need any rigidbody physics, so the variable dt won't have a super negative effect)

    It's kind of a rare use case but it would just be cool if the physics dt is not hard-coded
     
    Last edited: May 4, 2020
    Zeffi and florianhanke like this.
  11. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    699
    I, too, would like to be fully able to decide what time step simulates each of my physics worlds.

    I'd be happy with CONSISTENT updating at the moment, the fixedDeltaTime in a dynamic update is totally bonkers and causes juddery movement. :(+
     
    Zeffi likes this.
  12. KwahuNashoba

    KwahuNashoba

    Joined:
    Mar 30, 2015
    Posts:
    110
    Why would you necessarily need fixed timeStep if you have fixedUpdate? Delta time is delta time, it's just the matter of when you call the update method. But yes, that can be usable in case you would like to speed up or slow down physics simulation for special effects.