How do you know which things need delta time?

[Perfect_Human_Interface]

Hello, I’m new to UE, and using BP graphs. I started making my game without accounting for delta time. Since I became aware of the issue now I have to go back and fix things.

I know the basic premise of delta time and how to implement it, using multiplication to make value changes “over time” instead of “per tick.” But I’m not sure if I know everywhere I need to use this. It’s critical to get this right.

How can you know what things need delta time? I can understand gradual changes over time should use it. I also have read that Add Force accounts for delta time automagically, whereas calling Add Impulse every tick apparently does not. But what about Add Torque? Or how about timelines, do they account for delta time? What about, well, who knows what else? I’m still learning so I’m not aware of all the things.

Also, I’m trying to internalize the thought process necessary for this. I think it’s correct to say that every exec node being continuously ticked on that isn’t meant to be an instantaneous effect would need delta time. Then I just need to look backwards at all the data nodes connected to it and determine which values there need to be multiplied. However, let me share with you an example:

Say I wanted to use Set Physics Linear Velocity (ignoring for now that I could use Add Force etc. instead). here this code takes a fractional amount of the actor forward vector and a fractional amount of the current velocity vector and mixes them together to create a new velocity vector. The value connected to the lerp alpha is a constant. I believe the correct way to implement delta time into this would be to multiply in by that value connected to the lerp alpha. However, it wasn’t easy for me to figure this out. What kind of thought process should I use to make sense of these things?

I would appreciate any advice to be more confident in this!

[JPritchard1010]

DeltaTime, TickTime, FrameTime, etc. is used when numerical operations are performed as a factor of and over time.

Take, for example, a very simple implementation of velocity.

Velocity is measured in distance over time, commonly m/s.

Let’s assume we’d like to implement a constant velocity of 10 meters per second on a cube.

Computers process over time in terms of discrete ticks, whereas real-time works in terms of continuous time.

Our only way of doing something over time on a computer is to do it every tick/frame.

So we could implement our 10 meters per second by simply moving our cube forwards by 10 meters every tick.

This is a problem, however, as not every tick takes the same amount of real world time. You’ll have seen this when your framerate fluctuates in a game.

At particularly high framerates, say 240 fps, there are 240 ticks happening every real time second. Therefore our simple implementation of velocity is actually moving the cube at 240 meters per second, not the 10 we originally planned.

DeltaTime tells us how long the last frame took in real time.

This is essential because now we can scale our velocity value (measured in m/s) by an actual time interval.

If you’ve ever done physics, you’ll know that units can often tell you what is being calculated.

Velocity * Time = Distance

m/s * s = m

m/s * s/1 = ms/s = m

In summary: DeltaTime is our discrete-value computer’s link to the real-time world that we as users perceive.

[Everynone]

@Perfect_Human_Interface

Or how about timelines

Depends on how you use them:

• the Update pin fires every frame; more frames = more updates → we push further with higher framerates:

• and now it does not matter; same distance moved in the same time regardless of frame time / fps:

Less frequent updates translate into fewer chances to sample values.

Add Impulse, Add Force, Add Torque

You must account for delta time. But! There is this bad boy in the engine right now:

Runs at a fixed interval on a separate thread. You could (and probably should!) do physics here.

who knows what else

Enhanced Input with its perplexing notes :

No need to adjust for delta.

[Shmoopy1701]

Anything that moves, changes, or animates in any way should incorporate DeltaTime or it will animate differently at different FPS.

[jwatte]

@Perfect_Human_Interface

How can you know what things need delta time?

@Shmoopy1701

Anything that moves, changes, or animates in any way should incorporate DeltaTime or it will animate differently at different FPS.

Except when you use some quantity that does not in itself incorporate time, you should NOT. For example, AddForce, and AddTorque.
Also, anything that runs a timeline that already has “time” as input, and outputs “position,” it will already account for time.

The real answer is that you have to understand the math of the physics simulation. Write out time, position, force, mass, acceleration, velocity, and their relationship. In cases where time is involved, use delta time.

As illustration:

acceleration = force * deltatime / mass
velocity = velocity + acceleration * deltatime
position = position + velocity * deltatime

(this is not the exact equations, because of numerical integration, but it’s good enough for illustration)

Very similar equations apply for orientation/spin/torque.

Based on this simulation, you can work out whether you need deltatime.
Also, sometimes it’s totally OK to change position to an exact value – if the player gets run over by a bus, you’ll probably want to immediately update the position, rather than using delta-time.

[Perfect_Human_Interface]

Thank you all for the answers, these are all very helpful.

@JPritchard1010

At particularly high framerates, say 240 fps, there are 240 ticks happening every real time second.

So UE’s game logic is fully synced with the rendering? I was thinking the game logic capped out at 60 fps or something.

[Everynone]

@Perfect_Human_Interface

I was thinking the game logic capped out at 60 fps or something.

It’s up to you. Every actor can tick at different interval.

[Perfect_Human_Interface]

Wow, all very interesting points! Thank you!

So let me get it straight; anything connected to Async Physics Tick will tick according to delta time? And it’s the same thing for Enhanced Input ticks?? This is really important to know!

You mention though to account for delta time with Add Force, which I’ve read already accounts for it internally. That’s what got me wondering about Add Torque for instance, like is that more like Add Impulse or is it more like Add Force in how it handles or doesn’t handle time? I suspect it’s the former.

But, it seems like I can just connect all of these physics nodes to Async Physics and no longer have to worry about it?

[Everynone]

@Perfect_Human_Interface

But, it seems like I can just connect all of these physics nodes to Async Physics and no longer have to worry about it?

Yup. Technically you can use regular Tick and set the interval:

It only ticks as fast as framerate by default.

---

ASync runs in another thread (apparently) - note it’s still experimental at this point. Tread with caution - I’ve been using it for a couple of months, so far, so good.

---

You mention though to account for delta time with Add Force, which I’ve read already accounts for it` internally.

Never trust internet people. Add Force on Tick → observe results.

t.MaxFPS 10 vs t.MaxFPS 100

What do you get?

[Perfect_Human_Interface]

Ok, after several edits, I’ve tested some things and here is what I’ve found.

Enhanced Input with its perplexing notes :

No need to adjust for delta.

From my testing ticks on Enhanced Input events and the Async Physics Tick both seem to be limited by framerate, exactly like the normal Event Tick, and so would need to be scaled by delta time. They are, however, independent of the Event Tick and the Tick Interval parameter (which specifically affects the Event Tick). Async physics has its own timestep set in project settings where you enable it, but it’s still limited by framerate if it drops below that.

If I’m understanding the ticks themselves correctly, as in the things that go across the white exec wires, the only way ticks could possibly account for frame time is if they were at a fixed timestep independent of frame time and which never changed, including when FPS is low. Otherwise it’s the data being fed to the nodes which needs to be scaled to time, hence the whole delta time thing.

So if I have all this correct, I’m back to being a bit confused about which things need delta time. Some say this or that has it built-in and you don’t have to worry about it, other say different, testing seems to say another thing.

@Everynone

Never trust internet people. Add Force on Tick → observe results.

t.MaxFPS 10 vs t.MaxFPS 100

What do you get?

When I do it on tick, I do indeed get inconsistent results depending on the framerate. But not as much as expected. Measurably and noticeably different, but not very different. This suggests it is accounting for frame time, or at least trying to, but not entirely successfully. But if that’s the case, wouldn’t adding in delta time only cause problems?

Indeed, when I multiply the force by delta time as shown here it creates wildly different results depending on the FPS!

Does this mean that Add Force was never consistent to begin with?

By the way, I tried also this Add Force test with async physics tick and could not get it to move, with any amount of force. I have async physics enabled in the project settings and in the actor. In general the rest of my game’s physics seem wonky and broken (jittery motion, clipping through collisions) once I enable async physics. Maybe I’m doing something wrong?

[BIGTIMEMASTER (Aljav)]

just want to mention that scale by delta time is one of the modifiers you can add to an enhanced input action.

to test to confirm if you really need it or not, you can set the max framerate and then enter PIE and see that input is slowed down.

then enable the delta time modifier and now input remains consistent regardless of the FPS.

don’t ask me any follow up questions on subject, that’s all I know. just wanted to put this FYI in there cause it’s easy to miss

[jwatte]

@Perfect_Human_Interface

When I do it on tick, I do indeed get inconsistent results depending on the framerate. But not as much as expected. Measurably and noticeably different, but not very different. This suggests it is accounting for frame time, or at least trying to

If you add the same force every tick, then you will indeed get similar results with different tick sizes.
The acceleration is proportional to “time force is applied” times “force magnitude.”

If you add a force for only one tick, the duration of the tick will impact how big an impulse gets impacted on the object.

[Perfect_Human_Interface]

Thank you for the input. I actually spent a while doing random google searches and testing things. Unless I made some grave error, there are measurable differences from using Add Force, applied continuously per-frame, at different frame rates. I invite you to do your own testing.

It seems what we’re getting in Add Force is more of an approximation of framerate independence. However, I found enabling substepping improved things significantly, and using the async physics with its substepping enabled seemed to do even better. Achieving a fixed timestep seems to be a necessity for consistent physics.

[jwatte]

@Perfect_Human_Interface

there are measurable differences from using Add Force, applied continuously per-frame, at different frame rates

Yes, absolutely! This is why I made sure to say “similar results” not “the same results!”
The classic case of this is Quake gameplay, where higher framerates meant you could jump to reach some ledges, that weren’t reachable at lower frame rates, because of the way that integrator worked.

A classic first-order forward integrator like I sketched out above, will behave like that, because the second order effects of adjusting acceleration and velocity more frequently will make the integral more closely approximate the “perfect” result the higher the frame rate.

One solution to this challenge is to fix the time step, perhaps at some pretty high rate (like 240, or even 1000,) and if the frame rate is lower, step many physics steps for a single render frame. Unreal has a little bit of support for this, by being able to configure a maximum time step size, using the substep size (as you discovered) but it will still also do fractional steps to make the time “perfect” with the tick, so it still won’t give you fully consistent results (much less deterministic, which is another kettle of wax …)

This is a choice Epic made for the engine, and, in my experience, one that you have to accept, and if you can’t accept it, use another engine.