Frame-rate independency is non-existent. Send help.

Development Programming & Scripting Blueprint
1

I have been having real problems troubleshooting my physics-based project, where everything seems to work differently based on your frame-rate. I should mention I’m quite new to game development (2-3 months), so any knowledge you can give me is well appreciated.
UE4 Version is 4.24.2. the game itself is single-player based.

The problem is basically this: 120 fps and everything works like it should -> the lower the fps goes, more faster everything physics-based seems to be. I have scoured forums reading about Delta-time and how you should use it to stabilize your physic-calculations, but that doesn’t seem to work (so I’m doing something really wrong - I know).

Link to movement blueprint

[Album] imgur.com

This is the basic gist of my current movement. As you can see I’ve tried multiplying it with delta seconds, but to no avail. Though I quite haven’t grasped the idea of delta-time.

My Pawn consist of Capsule collision (Simulates physics), and camera with spring arm component. I’m applying all the forces to that capsule.
So it’s meant to be First-person pawn with no visible mesh.

https://forums.unrealengine.com/core/image/gif;base64
​
I have 2 pawns which I can control (“astronaut-pawn” and “spaceship-pawn”), and both have identical physic-movement setup (force-based). Both pawns obviously have the same problem.

Video of the inconsistent turning speed. For clarification, I’m turning with constant speed, but toggling framerate from 60 to 25. the latter version has probably twice the turning speed. (I’m seeing a pattern here eh…)

https://youtu.be/f6NmCYUAxSs

Even my Particle-Effect is irregular size(???), depending on the fps which I can’t understand (It does have a Point Gravity parameter so maybe that’s the problem?).

Video About the particle Inconsistency. Again For clarification. First I’m throwing the projectile at 60fps, then at 25fps. The latter particle radius is almost twice the size of the 60 fps particle.

That isn’t even that bad, I gave a copy of this package to my friend (who has a bit slower computer), and the particle effect was absolutely broken (like all over the world broken.) How am I even supposed to handle that?

Also about the inconsistencies with Editor and packaged build. I have 120 fps in the editor while playing, and 120 fps in the packaged build, but still everything seems to be atleast 10x(ish) slower in the packaged build (it feels like sensitivity is all around slower, event with same consistent fps), is this the same problem? And what’s the fix for that?

Bonus problem: (not sure if related)

Every mesh I attach to my pawn starts to Jitter / Stutter when moving.

Video of the stuttering:

Things i have tried:
-Different ways of multiplying with delta-time.
-Sub-stepping in project settings, and fiddling with those settings.
-lowering net-update frequency, with lower t.maxfps (someone mentioned it on other thread)

If you have any other questions let me know.
Help is much appreciated.

UPDATE

By removing the delta-time node from the input calculations i have managed to get close enough results between 120 fps and 30 fps physics-movement. I have no idea why, but it seems to work, but since I don’t have a second computer it’s hard to know if it breaks as soon as someone else tries it… for some reason adding the delta-time only makes things more inaccurate, at least when using Addforce function through input axis event.

2

All of your image links are broken. Do you understand how * by delta time helps?

3

Thanks for letting me know. added a Imgur link to my basic movement setup.

As for delta time, not really. I just slam the deltatime there and hope for the best D:

4

It works line this:

Say ( just for example ), you’re running at 100fps, and you have an object moving on tick across the screen. If you move that object 1 unit per tick ( per frame ), it will take 100 frames to move 100 units. This is 1 second.

But the same sequence, for someone running at 50fps, will take twice as long. Because the object still has to move 100 units, but now it will take 2 seconds.

Delta time, is how long the last frame took to render, in seconds.

For you, delta time is 100th second. For the slow machine, delta time is 50th second. It’s twice as big.

For the person on the slow machine, the frames are taking twice as long to draw, their delta time is twice as big as yours. So if you multiple ( in some way ) by delta time, the object will move twice as quick. That’s what you want…

Multplying by delta time is only relevant for things which are moving a fixed amount of units on tick. The good thing about timelines is they always take the same amount of time to execute, no matter what the hardware.

5

Thanks for the analogy, I think i now understand how it should work…

The thing is, even though I multiply my movement with delta-time, (since Input works on tick()) the results are the opposite how it should work. So I’m getting quite confused when I’m actually supposed to do the multiplication. I removed my delta-time from the calculations and my movement is 90% more accurate now between 120 fps and 30 fps and that only adds to my confusion… oof

6

You don’t just * by delta.

To see the problem is action, take out delta. Then put your fps down to about 20. Then you’ll see it.

To fix the problem, you have to * delta * x

X:= something you work out for each different blueprint

In this case X is your torque, but if you’re seeing weird results, it means you have that value wrong, for this bit of code.

To find out what X is in this case, run it normally with a range of torque values. Then run it at 20fps for the same values. What is happening, how far off is it? Guess X and try again…

7

In order to do proper physics between different machines, you have to use a fixed tick rate. Unreal uses variable time tick rate, aka your fps determines your simulation ticks. This causes huge problems in physics. Here are 2 articles to explain the proper way to do game loops and where physics is involved.

In multiplayer games you usually dont see the issue because unreal multiplayer is server-client method and the server runs on a fixed tick rate (40 iirc), so the physics are fixed delta stepped, all clients get their physics simulation from the server as the governing source.

In summary, rounding errors… is what happens when you use frame delta time to update physics. a ball moving 20 meters a second divided 200 times then added back together vs divided 30 times a second will produce a different final number because of floating point rounding errors inherent to floats. The more your fps fluctuates the increase in rounding errors. Depending on the situation, you can “see” or “feel” this difference.

8

thanks for the links, fascinating stuff. Especially the rounding errors and how computers handle floats. Now I finally start to understand about the inconsistent results I’ve been getting…

Most of the time I only got the same answer, to multiply stuff with delta-time, which clearly isn’t that simple.

9

0.0166667 / (Current FPS * 0.0166667) = Frame independency & second accuracy