Should I use deltaTime in FixedUpdate when setting velocity to a rigidbody?

Questions & Answers
1

I know there have been a lot of variations on this exact topic but I’m a bit confused from all the answers I’ve seen. So I’m moving a rigidbody by setting it’s velocity in FixedUpdate by getting input (smoothed horizontal/vertical input, not raw) and multiplying it by the target speed. Relevant piece of code here

Vector3 movementVector = Vector3.zero;
Vector2 input = GetInput();                
if (Mathf.Abs(input.x) > float.Epsilon || Mathf.Abs(input.y) > float.Epsilon)
{
    // add speed to input vector
    movementVector = new Vector3(input.x * targetSpeed, 0f, input.y * targetSpeed); 
    // rotate the vector to where the character is facing
    movementVector = transform.localRotation * movementVector;
    // clamp magnitude to avoid faster speed on diagonals
    movementVector = Vector3.ClampMagnitude(movementVector, targetSpeed);

    body.velocity = new Vector3(movementVector.x, body.velocity.y, movementVector.z);
}

So I am not changing the transform, I am setting the velocity and by all logic (in my mind) this should not be affected by framerate so in that regard I don’t think I need to multiply by Time.deltaTime. However, I am fetching the smoothed input which does change between 0 and 1 in some amount of time so since that is a changing variable I feel like I might have to use dt here.

As you can see I’m quite confused with something that should be quite simple. What’s the general consensus here? Do I have to multiply by dt when setting/changing velocity?

3

I would say for 99% of projects you don’t need to use a dt here. First let me explain why you might see a very small difference if you were using Update(), then I’ll explain why you shouldn’t see a difference in your project since you are using FixedUpdate()
**
To see what exactly the difference is take an extreme example. You have 2 versions of your game and you move your input from 0 to 1 over the course of 1 second. Your first version is running at 100fps and your second version is running at 1fps. In the first version, as you slowly move your input up your are constantly updating your velocity to match, resulting in a smooth transition. In the second version your velocity only updates once during that time, going from 0% to 100% in one frame. In both versions you will hit the same velocity in the same amount of time, but in the second version you are losing all the distance that your object would travel during that acceleration phase between your inputs of 0 and 1. While this would be a lot at drastically different framerates or for drastically high velocity changes, I doubt it would be noticeable in most games.
**
Now consider that you are using fixed update. Fixed update loop doesn’t change based on computation load like normal update does. Because fixed update has a constant update period, multiplying by FixedDeltaTime is the same thing as simply multiplying by a constant. The ONLY case where you could experience any kind of problems is if you are changing your fixed update loop dynamically (which I definitely don’t recommend).
**
Hope this answer helped

2

For me, only FixedUpdate runs smoothly and lag doesn’t make problems.

4

use Time.fixedDeltaTime for FixedUpdate, and Time.deltaTime for Update.

I would say it’s much easier for long term development if your script multiply delta time. 1, the speed value will make more sense. it’s per second instead of per frame. Every unity API value is per second so it’s better to stick with it so you won’t confuse yourself in the future. 2, you are assuming the frame rate is always the same, but there may be lag, or your game need to support weak device that run it in lower frame rate.