koobas.hobune.stream
Should I use deltaTime in FixedUpdate when setting velocity to a rigidbody?
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?
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
Wow this is really informative. Thank you for taking the time to explain all this. I hope you don't $$anonymous$$d but I got a few more questions.
... 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.
So if I want to make absolutely sure that this discrepancy is not noticable no matter the framerate or magnitude of change in velocity i should multiply by dt?
Also one thing I'm a bit confused by is: Let's say that the target speed is 16. If I multiply that by dt then that means that the entity will move 16 pixels per second while otherwise it will move 16 pixels per frame? Am I right in that assumption?
Since you are using fixed update there will be no discrepancies due to variable frame rate because the fixed update frame does not ever change unless you change it manually. So no, do not multiply by dt. If you were using Update instead of fixed Update you could multiply by dt, but not directly because just multiplying your velocity by dt will make you move slower. You would have to change the way you were applying velocity, and it wouldn't work perfectly either way. TLDR: don't worry about it in this case.
Because you are setting velocity you should not multiply by dt directly ever. If, however, you were moving an object by incrementing its position every frame, then you should use dt.
public float speed = 10f;
void Update(){
//Approach #1
rigidbody.velocity = speed; //Do not multiply by dt here. You are setting the velocity which is a constant value
//In other words the velocity at any moment in time does not depend on the time since the last frame.
//Approach #2
transform.position += speed * transform.forward * Time.deltaTime;
//Here you do multiply by dt because the amount you should move every frame depends on how long it has been since the last frame
}
Here a speed of 10 means that you want the object to move 10 units every frame (not pixels, which depend on the location and size of the camera). If you are setting velocity then that's that, but if you are moving the object's position directly then remember Velocity = Distance over Time, or in other words Distance equals Velocity times Time, therefore if you want to move an object at a certain velocity by changing its position, you need to move it by Vecocity x Time every frame, so in this case speed * Time.deltaTime
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.
The speed was 16 before. To get that same movement speed after multiplying with dt I had to set it to 800. What is 800 in this case? (Units?)Pixels per second? Also Unity docs say that usingthe speed value will make more sense. it's per second instead of per frame.
Time.deltaTimein
FixedUpdate is the same as using
Time.fixedDeltaTime
This is wrong on multiple levels. First of all Time.deltaTime will return the value of Time.fixedDeltaTime when used from inside FixedUpdate. You never need or should really read fixedDeltaTime. This makes code much more flexible in case it gets moved from FixedUpdate to Update. Time.fixedDeltaTime is mainly used for setting the fixed update rate.
Though the biggest issue with this answer is to suggest to multiply be deltaTime in this case. He is setting the velocity to a certain value. This is not a process that happens over time. The velocity of an object is already given in units per second. The physics system uses it to move the object every physics step where it does apply delta time automatically.
Lastly FixedUpdate runs at a "fixed" call count per second. This call count is ensured. Even when your framerate is just 10 fps, FixedUpdate will still be called 50 times per second. In this case it will be called about 5 times per frame. If the frame rate is 100 fps it will only be called every second frame. That's how fixed update works. I once made this little helper which allows you to implement your own / seperate fixed update callbacks that run at whatever framerate you want. That's essentially how Unity's fixed update works internally. Even longer ago I made this visualization to give a better understanding what FixedUpdate actually does.
Thanks for the explanation. Just a quick question. Is the fact, that I'm using non-raw input and multiplying that input value by speed, messing anything up? Will the rigidbody accelerate differently on different FPS's and if yes what should I do to fix that?
For me, only FixedUpdate runs smoothly and lag doesn't make problems.
