Good solution? Problems with VInterp and Frame Rate

Development Programming & Scripting Blueprint
, , , , ,
1

In my game the player moves objects and the player camera movements are determined largely by VInterps that were being controlled like this, what most tutorials show. However this causes the speed of the object’s movement to vary wildly if frame rate changes.

203003-1.png
203003-1.png1263×326 113 KB

I tried to solve this problem like this, and it seems to be more consistent across different frame rates, but I’m unsure of this solution because I don’t know if this is an efficient solution or how to adjust the update speed of the timelines that I have to place in every blueprint that uses the Event Tick.

203004-2.png
203004-2.png1273×436 134 KB

Does anyone have any advice on how to keep movements looking consistent across frame rates?

2

Using the timeline with a track that goes from 0 - 1 would be a good delta for a lerp. And a better solution.

Also, you don’t have to store Delta Seconds, you should instead use Get World Delta Seconds for gameplay mechanics. This will scale based on world time scale.

What is Get World Delta Seconds

Explanation of tick delta time.

Delta time is the fraction of sections that have passed by since the last tick.

When you multiply distance by delta time on tick, you’re making that calculation independent of frame rate.

For instance:

  • 1 frame per second: delta time will be the float value of 1
  • 60 frames per second: delta time will be 0.0166666
  • 128 frames per second: delta time will be 0.0078125

Over the course of 2 seconds move an object 5 meters. so you want it to move 5 / 2 meters per second = 2.5 meters per second.

So multiply delta by your speed Delta Time ( DT )

The following is the distance the object will travel in the first second:

distance traveled will be = frames called * DT * Speed

  • 1 frame per second, the tick will be called once.

    final distance = 1 * 1 * 2.5 => 2.5 meters

  • 60 Frames per second, the tick will be called 60 times.

    final distance = 60 * 0.0166666 * 2.5 => 2.5 meters

  • 128 frames per second, the tick will be called 128 times.

    final distance = 128 * 0.0078125 * 2.5 => 2.5 meters

The Delta Time changes every tick to account for how long it has been since the last tick, so you don’t have to rely on a steady framerate.

1 Like
3

Thanks, I didn’t know about the Get World Delta Seconds node.

4

Do you know if I could get a similar problem with Update on the timeline though caused by changes in speed of different speed CPUs instead of frame rates? I wasn’t able to find this in the documentation. I wish there was a way to time things directly using miliseconds independent of frame rate.

5

I’ve updated my answer to include this information.

6

Also looks like interp methods yeld different results on client and server. I think this should be added to their description so we don’t have to learn the hard way.