Add Tween.interpolate() as a low-level tweening option

[Calinou]

This can be used as an alternative to Tween.interpolate_property() when additional control is needed.

Thanks @dacrystal for providing the code for the method 🙂

This closes godotengine/godot-proposals#36.

[Calinou]

@dacrystal If you'd like, I can add you as a co-author to the commit. To do this, I need to know the name and email address you typically use with Git (the email address must also be associated with your GitHub account).

[dacrystal]

Thanks man! IIRC, I just copy/paste most of the code from different parts of engine code. So I'm not sure if that considered a contribution.

• Nasser Alansari/ alansari.n[å†]gmail[∂ø†]com

[realkotob]

Nice! This is a very appreciated addition since I often end up reimplementing this myself in gdscript for new projects.

[realkotob]

Are there any blockers for this to go through? I can help if needed.

[akien-mga]

Are there any blockers for this to go through? I can help if needed.

The main blocker is reaching a consensus on whether this is a good addition to the Tween API.

The linked enhancement seems relatively popular and speaks in favor of the change.

The implementation looks good, but I do have one concern over the semantic difference between this interpolate method and the other interpolate_* methods of Tween. The existing methods all take a duration parameter in second, and will animate the property/method from start to finish, while this new methods only gives a single weighted value.
It's definitely useful, but I'm concerned that it might be confusing that similarly named methods with a similar prototype actually do a quite different thing just due to one single argument (which is a float in both cases).

[realkotob]

@akien-mga I agree about the confusion.

It does not need a node instance and definitely doesn't need to be in the scene tree, so it can be a static class method or a global function.

All the other tween methods also require start() to be called and emit notifications when done, but this doesn't. They're quite fundamentally different.

This is basically the equivalent of lerp() but with an easing parameter, so if we want to make it a global function we can call it lerp_easing() and stay consistent and neat.

[Calinou]

@asheraryam To my knowledge, GDScript doesn't have static methods for C++-provided classes. So we'd have to do it another way (e.g. a global scope method).

[realkotob]

@Calinou Yes that's fine too, I think this method would also fit very well as an extension of the lerp() we have in the global scope, with a name like lerp_easing().

It's much closer to lerp() than to the Tween methods, since lerp and lerp_ease would both have the same return value, almost identical signatures, and both lack the side effects that Tween interpolate* has.

[Calinou]

@asheraryam Alternatively, could we add optional arguments to lerp() to specify the easing type? One issue I see is that lerp() allows weights not within the [0..1] range, which doesn't make sense when using non-linear easing.

[realkotob]

@Calinou I am ok with either option really. On one hand the current lerp is a basic one liner so it might not be a good idea to extend it, but the user experience would definitely be much smoother if we do.

Regarding the [0..1] weights (and if we decide to extend lerp), I think it's fine to internally clamp the inputs if to the range we need, so when using non-linear easing we'd cap the max_val at 1 and so on.

There is rarely any sane case where values outside the range should be passed, so this salvaging makes sense.

Edit: And we can document this clamping so advanced users can know what's wrong on the off chance they expect something different.

[akien-mga]

Alternatively, could we add optional arguments to lerp() to specify the easing type? One issue I see is that lerp() allows weights not within the [0..1] range, which doesn't make sense when using non-linear easing.

Well lerp() stands for linear_interpolate(), so it shouldn't be extend to support non linear easing.

But there could be an interpolate() method in the same scope.

[realkotob]

interpolate() honestly sounds great, I suggested lerp_ease() earlier in the thread but I think interpolate is clearer.

[Calinou]

How would I go about exposing the current Tween.interpolate() method as a global scope method? Can this be done while keeping the code in the Tween class, or will I have to move it somewhere else? This sounds quite nontrivial.

[realkotob]

I guess the _run_equation() and all linked code would have to be moved to a new separate interpolation class, which can be imported inside Tween and elsewhere.

If that sounds messy, then I'd suggest we stick with this PR and choose a clearer name than interpolate if we can. The naming isn't big enough of an issue to block this.

[Calinou]

Closing in favor of #41794, which is more likely to be merged for 4.0.