Suggestion: the ease function should be split / reworked

[Zylann]

There is an ease function in GDScript, but when I read its documentation I was a bit confused:

    float ease ( float s, float curve )

Easing function, based on exponent. 0 is constant, 1 is linear, 0 to 1 is ease-in, 1+ is ease out. Negative values are in-out/out in.

On first read, it's not easy to get what the function will actually return. So I made a project to visually see the curves:

So it looks like the function is handling 2, or maybe 4 different curves at once, using some magic offset.
I would suggest to change this API to something more understandable, like:

ease(x, EASE_IN, bend), ease(x, EASE_IN_OUT, bend) or something like ease_quad(x, bend) or ease_sine(x, bend) ?

[Causeless]

I completely agree. A multi-purpose ease like this is just... weird.

[ghost]

Or maybe have 3 different ease functions like ease_in, ease_out, ease_inout.

[simonpuchert]

I looked into the problem and came up with a couple of thoughts on the matter:
The functions should satisfy the following conditions:

• The values at 0 and 1 are 0 and 1, respectively.
• The derivative(s) at 0 (ease_out), 1 (ease_in), or both points (ease) are zero.

The polynomial solutions of lowest degree would be f(x) = x², 1-(1-x)² (standard parabola) or 2x³-3x² (bezier curve).
However, these don't allow adjusting the behaviour, which the current function does.
That, of course, is easily solved by increasing the degree by 1.

The parameter p_c allows adjusting the accelerations against each other (if you want more/less acceleration on both ends you have to shrink/stretch the time interval anyway).

// Overshoots for |p_c| > 3
double Math::ease(double p_x, double p_c) {
	if (p_x < 0)
		return 0;
	else if (p_x > 1.0)
		return 1.0;

	return ((p_c * (1.0 - p_x) + 2.0) * (1.0 - p_x) + 1.0)*p_x*p_x;
}

// Overshoots for p_c < -1 or p_c > 2
double Math::ease_out(double p_x, double p_c) {
	if (p_x < 0)
		return 0;
	else if (p_x > 1.0)
		return 1.0;

	return (p_c * (1.0 - p_x) + 1.0)*p_x*p_x;
}

double Math::ease_in(double p_x, double p_c) {
	return 1.0 - Math::ease_out(1.0 - p_x, p_c);
}

[reduz]

The function is OK as is, it's used in animation to store different types of curves with low overhead. If you export the property by specifying that it's an easing curve, you will get an editor that can change the values from the GUI. It's not really meant to be used from code so much.

…

On Tue, Sep 12, 2017 at 5:47 PM, Simon Puchert ***@***.***> wrote: I looked into the problem and came up with a couple of thoughts on the matter: The functions should satisfy the following conditions: - The values at 0 and 1 are 0 and 1, respectively. - The derivative(s) at 0 (ease_out), 1 (ease_in), or both points (ease) are zero. The polynomial solutions of lowest degree would be f(x) = x², 1-(1-x)² (standard parabola) or 2x³-3x² (bezier curve). However, these don't allow adjusting the behaviour, which the current function does. That, of course, is easily solved by increasing the degree by 1. The parameter p_c allows adjusting the accelerations against each other (if you want more/less acceleration on both ends you have to shrink/stretch the time interval anyway). // Overshoots for |p_c| > 3double Math::ease(double p_x, double p_c) { if (p_x < 0) return 0; else if (p_x > 1.0) return 1.0; return ((p_c * (1.0 - p_x) + 2.0) * (1.0 - p_x) + 1.0)*p_x*p_x; } // Overshoots for p_c < -1 or p_c > 2double Math::ease_out(double p_x, double p_c) { if (p_x < 0) return 0; else if (p_x > 1.0) return 1.0; return (p_c * (1.0 - p_x) + 1.0)*p_x*p_x; } double Math::ease_in(double p_x, double p_c) { return 1.0 - Math::ease_out(1.0 - p_x, p_c); } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10572 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z2_AkvisA-ZjToG6q4bqVynStDuBYks5shu35gaJpZM4O_RLd> .

[jahd2602]

Would it be a lot of work to make a code-friendly easing function? Like the suggestions made by @Zylann :

ease(x, EASE_IN, bend), ease(x, EASE_IN_OUT, bend) or something like ease_quad(x, bend) or ease_sine(x, bend)

[Calinou]

We could have a few constants in GlobalScope that could be used to specify "standard" easing curves. This way, various easing curves would be easier to discover, but we could still rely on a single function for all our easing needs.

We could also link to @Zylann's visualization in the ease() function's documentation.

PS: Could you share the project files if you still have them? Thanks in advance 🙂

[Seel]

@Zylann Thank you so much for the visual representation, I'm a relative newbie and I was struggling to understand how ease worked so spent some time googling it and found this thread.
If the docs showed something like this that would've been enough for me to go on I think.

[Didifred]

Others suggestions of API for easing from QT (bezierCurve type not needed since available in Curve) :
easing.amplitude : real
easing.overshoot : real
easing.period : real
easing.type : enumeration

See https://doc.qt.io/qt-5/qml-qtquick-animator.html

[Gaffen]

I've just stubled on this issue and wanted to give a +1 to having a more programatically accessible ease function - it'd be nice to throw a named constant into it to get the ease you want. For context, in this case I'm not using it for anything to do with animation.

Even just adding the visualisation to the docs would be really useful - I understand this may not be a priority, but the reference here is really useful.

[Calinou]

@Gaffen You may be interested by this pull request: #36997

It still requires creating a Tween node (which can be done via code), but it gives you more control.

This PR probably addresses the need to rework ease(), since it's a relatively specialized function as reduz said.

Edit: Tween was rewritten in 4.0 by #41794.