High-degree easing functions shouldn't be jerky

[scottmcm]

Bevy version

bevy/crates/bevy_math/src/curve/easing.rs

Lines 283 to 295 in 72f096c

	#[inline]
	pub(crate) fn quintic_in_out(t: f32) -> f32 {
	if t < 0.5 {
	16.0 * t * t * t * t * t
	} else {
	1.0 - (-2.0 * t + 2.0)
	* (-2.0 * t + 2.0)
	* (-2.0 * t + 2.0)
	* (-2.0 * t + 2.0)
	* (-2.0 * t + 2.0)
	/ 2.0
	}
	}

What you did

Low-degree easing functions have no choice to be jerky -- a quadratic one is forced to be jerky because it doesn't have enough degrees of freedom not to be.

If I'm using QuinticInOut, though, I'd expect it to be using those extra degrees to give continuous acceleration.

The current definition is still jerky, though: it jumps from +40 acceleration to -40 acceleration instantly: https://www.desmos.com/calculator/vrnk8cfacz

Or if the existing ones shouldn't be edited, for some reason, should maybe some Hermite in-out easing functions be added with 0 nth derivates at the endpoints?

[scottmcm]

Looking deeper, Cubic{In,Out} are the hermite cubics I'd expect (In for f(0)=0, f(1)=1,f'(0)=0, f''(0)=0, Out for f(0)=0, f(1)=1, f'(1)=0, f''(1)=1).

So it's just the way that the halves are merged that is odd.

Maybe CubicInOut should be -2t³+3t², the cubic for f(0)=0, f(1)=1,f'(0)=0, f'(1)=0?

And then QuinticInOut could be t³-3t³(t-1)+6t³(t-1)², which adds the f''(0)=0 and f''(1)=0 constraints.

Higher than that looks like it might be better to just go to C^∞ instead, though https://www.desmos.com/calculator/30decjugf0

[mockersf]

many easing functions are standardised, we're using the formula defined in https://easings.net

[scottmcm]

Where's the spec? Is it in GL somewhere?

And if upstream won't change, would it be ok to add more? The enum isn't extensible right now :/