Additional easing functions

[MSGhero]

Linear, smoothstep, and smootherstep eases.

[Gama11]

Currently, all other ease functions have three versions: in, out and in-out. Is there a reason smoothStep and smootherStep don't? Seems like a strange asymmetry.

[MSGhero]

Short answer: both of those are easeInOut functions by design without needing the t<=.5 conditional. easeIn and easeOut don't really apply.

Longer answer: It's based on how those two functions are defined. Not sure how familiar with calculus you are, but smoothStep is the simplest polynomial with 0 derivative on both ends (t=0 and t=1), and smootherStep with 0 derivative and double derivative on both ends. In general, easeIn has 0 derivative at t=0, easeOut at t=1, and easeInOut on both ends.

smoothStepIn/Out, if they had to exist, would just be cubicIn/Out, I guess. And smootherStepIn/Out would just be quinticIn/Out.

[Gama11]

Right... This kind of messes with how the UI is set up in the FlxTween demo. :P

[Gama11]

We should probably use a flat list of ease modes and get rid of that second dropdown for in / out / in-out. Can you make a PR for that (unless you can think of a better solution)?

[MSGhero]

Maybe disabling/ignoring that dropdown and setting currentEaseDirection = "" or something along those lines? I'd have to understand the demo a little better first, but yeah I can.

linear is the same as none, so linear can be skipped or none can be renamed.

Edit: Unless linear should be renamed to none within FlxEase.

[Gama11]

I thought about that solution too, but it doesn't seem very elegant / seems quite messy. No need for special cases like that if you have a flat list.

[JoeCreates]

Surely in and out versions are still possible... The in version would effectly be 2f(t/2) and out would be 2f(t/2+0.5)-1?

…

On 18 Jun 2017 09:33, "Jens Fischer" ***@***.***> wrote: I thought about that solution too, but it doesn't seem very elegant / seems quite messy. No need for special cases like that if you have a flat list. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2080 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACbEvEd5XZa3r9NU9sl-c6y1cNP7InJ2ks5sFODSgaJpZM4N5FmN> .

[MSGhero]

I mean at that point, you're manufacturing functions that don't already exist in the field of computer science, as far as I'm aware.

Plus, if doing that math causes the derivative stuff to change at all, then they're not smoothStep functions anymore. Similar to if you tried to make linearIn, which would no longer be linear.

[JoeCreates]

This math wouldn't change the derivatives on the relevant sides. I.e at 0 the ease in functions would maintain the same derivatives and at 1 the rase out would. All the math does is chop was is the easeInOut function in half so that it's possible to only use the curve in or curve out.

SmoothStep probably wouldn't be the correct name anymore due to the lack of the step in all cases, but you could call them SmoothIn, SmoothOut and SmoothInOut.

It seems to me in any case SmoothStep might be useful one of the in/out variants could also be useful. It doesn't seem to me relevant whether or not the in/out variants "exist in computer science", but I'm pretty sure I've come across them before in other tweening libs.

[JoeCreates]

Just did a quick search. Evidently I'm not the first to have had the idea of chopping it in half. https://rexrainbow.github.io/C2RexDoc/c2rexpluginsACE/behavior_rex_lunarray.tween_mod.html

A second point, what is a use case for the linear function? Why include it when it is identical to simply not specifying and easing function?

[MSGhero]

What does the code for those look like? Chopping a smooth function in half doesn't necessarily keep it smooth.

If you need to specify an easing function, like if it's mandatory, it's easier to use FlxEase.linear than function(t) {return t}. Maybe that's not the case within flixel itself, but it only helps to add it.

[MSGhero]

In the equation you posted before, both the in and the out reduce to multiplying smoothStep by t, since the 2f*t/2 just reduces to f*t. That function does not have 0 derivative at the end, so it doesn't satisfy being an easeOut. At that point, you've just found a polynomial that is 0 at one end and 1 at the other, of which there are an infinite number.

[JoeCreates]

You seem to have misread my equations. The stuff in the brackets are the arguments of f.

[MSGhero]

Last point still remains, and I feel like this is going out of scope of the PR.

[JoeCreates]

Your last point does not stand as it isn't true. I have not given arbitrary polynomials. They are the front and end of the smoothStep and smootherStep functions. Im on my phone right now so it's not convenient for me to link you to a graphing tool to illustrate what these do, but I encourage you to do so.

My suggestion maintains the symmetry in flixel, is easily useful if ever the full inout version would be useful, and contrary to what you say, the relevant derivative propeties are maintained.

[MSGhero]

I know what polynomials look like, thanks. If the only reason to invent and include these functions is for parity with the others in flixel, then go for it. Although to me it's confusing as smoothStep has a definition, and adding In to the end doesn't correspond to anything that typically exists (i.e. why would you use a smoothStep-based function if you don't want the definition of smoothStep?).

[JoeCreates]

I know what polynomials look like, thanks.

I only suggested the graph seeing as the equation alone evidently wasn't clear, given that you read it as something totally different. Considering I've already graphed them now, here are SmoothInOut (SmoothStep), SmoothIn and SmoothOut: https://www.desmos.com/calculator/vpyfohq3fo

Symmetry is one of the two reasons I gave, the other is the fact that if the in/out version is useful, then so will the in and out variants be. If you, for example, use the functions for tweening UI, for some elements it may be sensible for them to ease in and out, whereas for others the timing/positioning etc may better warrant only the start and end of that function, and consistency between the functions may be necessary to keep elements positioned correctly with respect to other elements.

Sigmoid inout functions (e.g. quadInOut) can be defined with respect to the separate in/out functions, or the separate in/out functions can be defined with respect to a sigmoid function such as smoothstep. The direction of this relationship has no bearing on the utility of the combined or separated versions. This is my main point. The presence of t<.5 conditions in the former cases isn't relevant.

[MSGhero]

That's all fine, and you can PR mine to add them, but you could just use any other easeIn function to get the zero derivative at 0 property if you don't want to actually use smoothStep. If a user knows they need the exact function f=3t^5/8-15t^4/8+5t^3/2, it's not like they can't just write it out themselves.

But like I said, you can just PR my branch. Makes the demo easier to change. smoothInOut doesn't mean much compared to smoothStep, though, and would be intentionally confusing since every easing function besides the InOuts and bounce are smoothly defined.

[JoeCreates]

PRed. I'm open minded about what to call them. smoothIn/smoothstepIn/hermiteCubeIn?

[MSGhero]

smoothStepIn, smoothStepOut, smoothStep I think is best.

[JoeCreates]

Regardless of the prefix, I'd prefer to maintain the In/Out/InOut pattern. @Gama11?

[Gama11]

@JoeCreates agreed.

[MSGhero]

If I were looking for smoothStep, I wouldn't know which of those three to pick without looking at the implementation. OpenGL and MSDN both call it by its actual name. But I'll just merge it to end this...

[Gama11]

Maybe add a doc comment?

[MSGhero]

Yeah that's what I was thinking.

[MSGhero]

I think I'll comment all of the easing functions in a separate PR