standard lerp is frame rate dependent - is ours?

[BaddRadish]

so i found this article that points out the fact that standard lerp is frame rate dependent.
https://www.gamedeveloper.com/programming/improved-lerp-smoothing-

a significant portion of lerp use cases is for changes over time. maybe even the majority.
higher frame rates means more calls to lerp.
yes its called with less delta, but that only fixes move_toward, not lerp.

does our lerp have this issue?
if so, the problem might also be present in slerp as well.

the article offers a solution: exponential lerp.
it might be seriously worth considering fixing this or at least adding this as an alternative!
we should potentially keep the original lerp around for one time lerping.

it would probably be trivial to scale the new lerp to the default frame rate.
this way, most users can just swap it out without requiring additional changes.

or is this solution already implemented in godot?
thanks!

[filantus]

standard lerp is frame rate dependent - is ours?

@BaddRadish I guess yes, it's rate dependent. If i got a point of question right.
At least in example from documentation the delta argument is passed to lerp function (for solving that dependency).

$Sprite2D.position = $Sprite2D.position.lerp(mouse_pos, delta * FOLLOW_SPEED)

https://docs.godotengine.org/en/latest/tutorials/math/interpolation.html?highlight=lerp#smoothing-motion

[Calinou]

does our lerp have this issue?

Not if you use delta properly in your calculations.

[aXu-AP]

It might hold some value to provide alternative version which can be used frame-independent way. It's not about 'fixing' something that's broken, since linear interpolation is, by definition what it is.
I have figured out the math in some of my projects but it's not so intuitive that I could write one straight away when prompted.

[aXu-AP]

Yes, it works under assumption that delta never changes. But if you decide to change physics fps or if physics processing doesn't hit target framerate, this assumpion breaks. So there delta isn't much more than a magic number (albeit somewhat compensates in these situations). Under normal circumstances this code works well enough, possibly that's why the error has gone under radar.

[meheleventyone]

If the physics processing doesn't hit target framerate you'll have bigger issues than things not damped lerping properly because you'll be pathologically running behind. But yes behavior will change if you alter the desired physics update rate, which is going to be a rare event, it's not so much an error as not being explained fully why you can expect it to work properly under normal conditions. The example would be stronger in _process because variability of delta is expected.

[aXu-AP]

That's true 👍

[wyvernbw]

I don't really get the example in the documentation. If t is the value between 0 and 1 and it "represents the states in-between" why is it using FOLLOW_SPEED (which is equal to 4.0)? t is not a speed, and in the example it's between 0 and 1 by coincidence because we multiply by delta. The way I see lerp is like the mix function in a shader. I just don't get how we go from the point between two states to a speed

[tetrapod00]

Two years later, and the doc example for "lerp smoothing" has been updated to also include an example that is fully framerate independent: godotengine/godot-docs#10197. It's based on @aXu-AP's work.

[BaddRadish]

ah yes i see now, good point - it should be safe AND effective to use the lerp we have now as long as you use the same starting position each time, instead of updating per frame.

still, there /might/ be situations where thats not desired? maybe? like if the target keeps moving every frame. this is still doable probably, since the process rate would likely stay the same. you would lerp correctly in physics process, then use the end position as the new start in process. something like that. so this might still make a decent additional feature.

side benefit: having the extra function around would remind people to not abuse the lerp we have now lol.

but honestly who wants the bloat.

[theraot]

Being picky here: lerp means linear interpolation. And it has nothing to do with frames.

Now, you might want to lerp over time. If you have a fixed target and you compute the time correctly there is no problem. As alternative you can use tweens, and I would encourage you to.

But people use lerp a different way: they use it to approach a moving target. That is a cheap way to implement a different behavior: damping. But damping implemented with lerp the naive way is frame rate dependent. You can solve this by using exponential, which the linked article mentions. Sadly the linked article does not mention the word "damping".

If you think of it in terms of damping, you will get a different idea: the velocity of a spring depends on the distance, not the time. Ok, you can think of it as "rubber banding" and get to the same idea. Thus, you can define a maximum speed, a distance at which it should reach that speed, and an easing function from zero to there. And this way you keep control over the behavior (by changing the easing function. Yes, you can still use a lerp).

[timothyqiu]

lerp() has nothing to do with frame rate. It's how the user uses lerp() that's frame rate dependent or not.

# this is frame rate dependent
position = lerp(position, target_position, weight * delta)

# this is not frame rate dependent, but more or less the same as `move_toward()`
current_weight += delta * speed
position = lerp(start_position, target_position, current_weight)

I think the overall intension of the "frame rate dependent" version is not to do linear interpolation, calling lerp() here is an poor-man's way to ease out the movement.

So it's not lerp() that's frame rate dependent, but the trick to ease out movement is frame rate dependent. Instead of "fixing" lerp(), it'll be more useful to provide a easy way of achieving frame rate independent easing.

Edit: ah, just saw @theraot 's comment after posting this one 😂 we're saying basically the same thing.

[seocwen]

You wouldn't lerp by a constant if you wanted frame rate independence. Here's what I always do:

var progress = 0
var duration = 2
const start = 50
const end = 200
var value = start

func _process(delta):
if progress < duration:
progress += delta
value = lerp(start, end, progress/duration)
else:
value = start

You won't need a different function to lerp consistently over time if you do it this way. This also makes it easier to "tune" your values because you set an exact duration.

[tetrapod00]

As mentioned already, the lerp() function itself doesn't have anything to do with framerate; it's just a mathematical function. Our docs example of "lerp smoothing", has been updated in godotengine/godot-docs#10197 to also suggest a truly framerate independent version. The example actually links to the article in the OP.

I'm going to close this discussion, as the discussion seems to have run its course, and the tangible docs improvement suggested here has been made.