deltaTime

[dull radish]

making a thread here

Suppose I just add my velocity to my position every frame like this:

transform.position += velocity;

Also suppose that the framerate is 100 frames per second, and that my velocity is [10, 0, 0].

The end result is that I move by this much per second:

10 meters   100 frames    1000 meters
--------- * ---------- = ------------
 frame        second        second

So we're moving at 1,000 meters per second. That's probably not what you wanted to do.

Since we just directly added our velocity to our position each frame, our velocity was 10 meters per frame.

You basically never want to be measuring things per-frame, because your framerate is constantly varying. You need to calculate how much to do per-frame right when you use it.

So let's fix that.

If I want velocity to be meters per second, then I need to do something to turn it into meters per frame.

10 meters   0.01 seconds   0.1 meters
--------- * ------------ = ----------
 1 second     1 frame        1 frame

0.01 seconds / 1 frame is what Time.deltaTime represesnts

It's how long one frame takes.

transform.position += velocity * Time.deltaTime;

Since we're running at 100 frames per second, we run this code 100 times per second.

0.1 meters   100 frames   10 meters
---------- * ---------- = ---------
 1 frame      1 second     1 second

and boom -- 10 meters / 1 second falls back out

exactly what we wanted

[merry ice]

Hm I see, so we could say that deltaTime calculates how much it should do per frame when we update it?

[dull radish]

It tells you how long a single frame is.

This does, indeed, tell you how "much" you should be doing per frame

If the frames are long, you need to do more.

[merry ice]

So in the example I gave, we shoot a projectile from a pistol. Why exactly wouldn't we use deltaTime in there

[dull radish]

Well, if you're accurately simulating how the bullet accelerates down the barrel, you would start caring about deltaTime

because you'd need to correctly change its velocity each frame

But you probably aren't doing that. I'm guessing you're just setting the velocity of the bullet

[merry ice]

I was thinking of adding a force on the rigidbody and times it with deltaTime

[frigid mural]

rigidbodies has their own methods of movements

[dull radish]

Do not think of just "using deltaTime" to make things work right

this will result in bogus code

Consider carefully what you are doing here.

For example, if you're using Rigidbody.AddForce to apply force to an object, the outcome depends on the ForceMode you use

[frigid mural]

the reason why I was saying to split physics with visuals is how unity does their physics operations and that moving a transform using position and deltatime can overshoot collider events

[dull radish]

The default, ForceMode.Force, models applying a steady force to the rigidbody

If you use deltaTime here, you get bogus results

[merry ice]

I used .Impulse

[dull radish]

It doesn't matter how long my timestep is. I'm pushing with the same amount of force.

If you use Impulse, that means you're applying an instantaneous force to the object

deltaTime makes no sense here. It doesn't matter how long each frame is.

You're instantly changing the rigidbody's momentum

You wouldn't do this to teleport the player, would you?

transform.position = destination * Time.deltaTime;

[frigid mural]

also going back on the stamina thing, comparing real-time should be similar in that regard, right? Resources and stuff like that is not something I consider using frame time for

[merry ice]

Ah i see

[merry ice]

Yeah that's true

[dull radish]

I don't follow.

If you're steadily draining a resource, you need to use deltaTime, because you need to drain the appropriate amount each frame.

If you're just paying an instant one-time cost, you don't use deltaTime, because this process isn't time-dependent at all

That's the big rule of thumb

Continuous things use deltaTime to calculate the amount you do per frame.

AddForce is a notable exception, because its various force modes already account for the length of each frame (well, ideally, the length of each physics timestep)

I forget if that misbehaves when used in Update. I checked that once but I dont' remember what happened.

[merry ice]

So to come back on my piece of code, specifically playerStamina -= staminaDrain * Time.deltaTime;

We * it with Time.deltaTime so it correctly calculates how much to drain each frame. Rather than using only staminaDrain which would just take that amount off playerStamina each frame

[merry ice]

That sounds reasonable, and somewhat easier to understand for a beginner

[frigid mural]

An example would be something like an ability cooldown. Instead of using deltaTime we'd compare cooldown operations by Time.time.

[dull radish]

Right.

[dull radish]

oh, yeah, you can just declare when something will be done, rather than counting down to 0 every frame

[frigid mural]

right, but if you want to visually see it updating then you probably do want to count down with delta time

[merry ice]

So to summarize it a bit. Time.deltaTime calculates the amount of action it should be doing per frame on continuous things rather than doing it without deltaTime which would mean in the stamina case it just drains that amount per frame the user has. However, this doesn't mean we apply it to everything we see lol

Did I say that correct?

[frigid mural]

Seems about right, but now you have to question when to use fixedUpdate ;)

and fixed time in that regard

and the secret is if it comes from Physics lib, then you probably do

[merry ice]

Yeah I also read up on that a bit, from what I understood so far is that fixed update is called independently of framerate

[dull radish]

FixedUpdate runs immediately before the physics update

which runs at 50 hertz, by default

[frigid mural]

if you stick with rigidbodies, you probably don't need to use fixedtime much

[dull radish]

well, to the contrary

you should be interacting with the rigidbodies inside of FixedUpdate

[frigid mural]

right right

[merry ice]

So just curious, don't want to get all off course, but how do we know if something comes from the Physics lib?

If i think about it, I would say something like Physics.Raycast f.e.

[frigid mural]

https://docs.unity3d.com/ScriptReference/Physics.OverlapSphere.html

[dull radish]

I'm specifically talking about things that modify the physics world

You can do physics queries whenever you want, like raycasts and overlaps and checks

Modification would be stuff like applying forces

[merry ice]

So therefore player movement would go in fixedupdate as we apply forces on the rigidbody?

[frigid mural]

hmm, actually the only time I really used fixedtime is moving gameobjects with colliders

but you wouldnt do with with rigidbodies as it has it's own methods of movement

[merry ice]

Hm i see, are there any resources of reading up on rigidbodies their own method of movement and the physics lib?

[dull radish]

if you're using a rigidbody, then yes

[frigid mural]

mostly cause I'm doing a lot of my own physics operations and trying to prevent my stuff from clipping through walls

[dull radish]

You would still read input in Update. You'd just apply it in FixedUpdate.

[merry ice]

I see yeah, and now I might start talking crap, but when you add the force on the rigidbody using Forcemode.Force you would * it with deltaFixedTime as its continuous and it needs to calculate what to do per frame

[dull radish]

No. You would not, because how hard you're pushing does not depend on the timestep

Internally, AddForce is going to change the velocity by force / mass * fixedTimestep

[merry ice]

Hm I see I need more experience with it, I was more thinking so that someone with a higher frame-rate could walk faster, but I guess if the speed is the same it wouldn't matter

[dull radish]

You won't, since all you're doing here is telling the physics system how hard you're pushing

you wouldn't set gravity = 9.81f * Time.deltaTime, after all

it's just 9.81f

now, when you use gravity to change your velocity, you would factor in deltaTime

velocity += gravity * Time.deltaTime;
position += velocity * Time.deltaTime;

[merry ice]

Alright yeah

Practice makes perfect I guess..

But anyways, thanks for the explanation and I think this thread will be helpful at times when I need it 🙂

[frigid mural]

So, previously I was doing a lot of this stuff in update because I thought querying this stuff would be more accurate even if it were less performant than just doing it in fixedupdate. However, I was having problems with fluctuating frames, where it did feel like I was losing out on that precision. One of the big factors is how fixed update will slow down will update more to compensate for this lose in framerate but not update, but I'm not entirely sure if that's the overall problem.

It's something I'll have to test more, but really I've moved a lot of transformational logic into fixedupdate for now

[merry ice]

So i did some more research on deltaTime and FixedUpdate, I was just wondering if what I'm about to say now sounds correct. If I would have a gun shooting a bullet I wouldn't use deltaTime as it has a rigidbody and the forcemode would be Impulse. Now what I'm wondering is would the shoot method be in fixedupdate as the bullet hitting someone should be independent of how many frames a person has?

[frigid mural]

Shoot method which intakes from input would be in Update, but the movement and behavior would be in fixed

[merry ice]

I see yeah, and since it's in fixed we also wouldn't use deltatime

[merry ice]

But in that same case you would have the input of a jump function in update and the forces you apply in the fixed update?

[frigid mural]

FixedUpdate can miss inputs, specifically really frame dependent like mouse/analog, but I've read that OnPointerDown stuff can be missed too. I don't really use rigidbodies, but I'd assume you want to just queue up everything in update and check for flags that input was set in fixed