Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
lunelson@gmail.com

"Meta-Ease" Lib Preview

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

This is a casting for feedback, on something I've had in my junk drawer for a long time. I keep procrastinating on actually releasing it, so I thought I'd see what the community thinks ;-).

 

What I've been calling 'meta-ease' or 'split-ease' is a set of interpolation functions that variably combine acceleration (ease-in), constant-speed and deceleration (ease-out) segments in to a single sine-based or variable-power-based curve. It aims to overcome what I've always felt were limitations of the Penner easing functions on which most animation libs' core easing functions are based, namely (a) that curves which are always either accelerating or decelerating are limiting for longer/slower movements, (b) that easing itself should be able to be as strictly timed as duration, and (c) that quad, cube, quart, quint etc. were a needlessly limited range of options that could easily be combined as one function. This demo has dummy text in it right now but I'm sure everyone here will get the point. It'll be released under an ISC license.

 

Meta-Ease Dummy Preview

  • Like 5
Link to comment
Share on other sites

Cool, reminds me a bit of what SlowMo ease did but with a bit more control over the in-and-out curves.

 

We agree, professional animators need more than the "stock" Penner Eases. With CustomEase there are virtually no limitations.

https://greensock.com/customease Any path you can draw can be an ease.

 

It looks like your tool could work in a very similar way to our CustomWiggle and CustomBounce: https://greensock.com/wiggle-bounce

They both offer an API that generates super-elaborate ease curves that can then be set as a CustomEase. 

It looks totally possible for your tool to be configured to generate an SVG path that can be used by CustomEase.

 

Thanks for sharing!

 

 

 

 

  • Like 4
Link to comment
Share on other sites

Thanks Carl,

 

you're right that it's comparable to the eases CustomWiggle and CustomBounce, in particular, in that it generates curves mathematically, that would be difficult (nearly impossible) to draw accurately by hand—

 

however it's not intended to be something other than the classic Penner equations, as much as it is an advancement of them. The quadratic (x^2) ease for example, is still the go-to equation for most movement because it simulates linear acceleration (even if simplistically);

 

but what these equations do, is to use those maths internally while generating a curve in separately-timed segments: so that rather than the classic in/out/inOut options, you can combine in and out segments in any relative proportion to the duration and to each other. Moreover, if the total time/proportion of in and out segments is less than the whole duration, they are joined by a constant-speed segment. This is really the star feature. It supports for example, the use-case of accurately simulating force-based acceleration, travel and deceleration (imagine the way a car goes from point A to point B, over a longer duration), while remaining strictly timed. 

 

You're also right that it could generate CustomEase curves; but I see it rather as like RoughEase, configured on the fly with simple arguments. In its current form the in/out arguments represent a proportion relative to the duration, but they could also be absolute timings, e.g. always ease-in for 1s and out for 1s, regardless of duration...

  • Like 3
Link to comment
Share on other sites

3 hours ago, lunelson@gmail.com said:

Moreover, if the total time/proportion of in and out segments is less than the whole duration, they are joined by a constant-speed segment. This is really the star feature. It supports for example, the use-case of accurately simulating force-based acceleration, travel and deceleration (imagine the way a car goes from point A to point B, over a longer duration), while remaining strictly timed. 

 

This is awesome! I can't tell you how many times I've wanted something like that. CustomEase is cool and all, but sometimes is too much work trying to figure out how it should look and then draw it. 

  • Like 2
Link to comment
Share on other sites

Thanks @OSUBlake,

I appreciate your interest! I certainly agree that drawing or defining a complex curve 'by hand' to accomplish this is too much work ;-).

 

One of the things I'm still thinking about is the API. Currently it's configured as a 'standard' easing function, insofar as it takes a 't' parameter in the range of 0 to 1 as its first argument; but because of the additional parameters (inTime, outTime, ?power), you have to wrap it in another function...so it might be better if it was a higher order function to begin with. Some example implementations in a few different libs, as it stands:

 

// tween.js
const myTween = new TWEEN.Tween(obj);
myTween.easing(t => metaEase.power(t, 0.7, 0.2, 2));

// anime.js
anime.easings['myMetaEase'] = t => metaEase.power(t, 0.7, 0.2, 2);

// greensock
const myMetaEase = new Ease(t => metaEase.power(t, 0.7, 0.2, 2))
TweenLite.to(obj, 5, {x:600, ease: myMetaEase});

 

In GSAP in particular though, I feel like the ideal API would be something that you could configure 'inline'—perhaps like this
 

// 2.1s ease in, and 0.6s ease-out, as proportions of a 3s duration
TweenLite.to(element, 3, {y:300, ease:MetaEase.power({in: 0.7, out: 0.2, pow: 2})});

 

...but I think the most interesting would be if the Ease also had access to the duration of the Tween it was applied to, which would offer the possibility of absolute timings of in/out segments, without needing to calculate those proportions yourself. That might look something like this:

 

// fixed 1s ease in and 1s ease out, for any duration >= 2s; otherwise downscaled proportionally
TweenLite.to(element, 3, {y:300, ease:MetaEase.power({absIn: 1, absOut: 1, pow: 2})});

 

Curious to know what you all think of that. Also, whether anyone things the name "SplitEase" is better and/or makes more sense than "MetaEase"...

Link to comment
Share on other sites

On 10/25/2017 at 3:11 PM, lunelson@gmail.com said:

...but I think the most interesting would be if the Ease also had access to the duration of the Tween it was applied to, which would offer the possibility of absolute timings of in/out segments, without needing to calculate those proportions yourself. That might look something like this:

 


// fixed 1s ease in and 1s ease out, for any duration >= 2s; otherwise downscaled proportionally
TweenLite.to(element, 3, {y:300, ease:MetaEase.power({absIn: 1, absOut: 1, pow: 2})});

 

Is that possible? I don't think ease uses the old easing function like this. The last 3 parameters are always 0,1,1.

function myEase(t, s, c, d) {
    return s+(t=t/d);
}

 

On 10/25/2017 at 3:11 PM, lunelson@gmail.com said:

Curious to know what you all think of that. Also, whether anyone things the name "SplitEase" is better and/or makes more sense than "MetaEase"...

 

Honestly, not I'm a fan of either name, but I suck at naming stuff, so I don't have any suggestions at the moment. Maybe have something to do with physics in the name?

 

Link to comment
Share on other sites

Yes, the ease function would be possible that way. I know the GSAP docs quote ease functions as having [t,s,c,d] arguments, but this is for sake of compatibility with the original Penner formulations which could interpolate an arbitrary value-change over an arbitrary time-span. So just in case the arguments [time, start, change, duration] are all used by the supplied function, GSAP provides 0,1,1 for the last three, in order to normalize the first, i.e. make time range between 0 and 1; but you can also supply a function that only requires t (time) and simply assumes it to be in the range 0-1, which is the form in which that argument will always be supplied by GSAP's Ease class and by every other JS animation library AFAIK—and the trailing arguments can be simply ignored. In the syntax I propose above, the MetaEase or SplitEase function would be a higher order function that receives an options object and returns a function that accepts that t in the range of 0-1. This is is definitely the syntax I'm leaning toward.

 

But WRT my other point, I wonder if anyone can shed light on how an Ease class might access the duration of the animation it's currently applied to...?

Link to comment
Share on other sites

34 minutes ago, lunelson@gmail.com said:

But WRT my other point, I wonder if anyone can shed light on how an Ease class might access the duration of the animation it's currently applied to...?

 

I just quickly skimmed through the source code, and it doesn't seem possible, but it would be better if @GreenSock could verify that. 

 

If it's not possible, what about using ratios instead of time values for the in/out?

Link to comment
Share on other sites

Yeah, that's how you'd do it. Ratios is what the functions currently use. If the total of easeIn and easeOut is greater than 1, they are scaled down proportionally. So, to adapt my previous example, doing absolute easeIn and easeOut times would look like this:

 

// assign a duration
const dur = 3;
// ...then use it in the duration, easeIn and easeOut arguments;
// here, easeIn and easeOut will be 1s each, even if duration is increased
TweenLite.to(element, dur, { y:300, ease:MetaEase.power({easeIn: 1/dur, easeOut: 1/dur, pow: 2})});

 

  • Like 1
Link to comment
Share on other sites

2 hours ago, OSUblake said:

I just quickly skimmed through the source code, and it doesn't seem possible, but it would be better if @GreenSock could verify that. 

 

Yeah, sorry, eases just get a ratio (not duration). Tried to keep the API super clean. 

 

You could, of course, just make MetaEase accept a "duration" config property or something. 

Link to comment
Share on other sites

  • 1 year later...

Cool. And for the record, I did post about a blendEase() helper function to blend two eases together (which I realize isn't the same thing as what SplitEase aims to do). https://greensock.com/docs/HelperFunctions

  • Like 2
Link to comment
Share on other sites

Nice! I could have really used this a year ago when I had to make easings based on velocity curves.

  • Like 1
Link to comment
Share on other sites

3 hours ago, OSUblake said:

Nice! I could have really used this a year ago when I had to make easings based on velocity curves.

 

Yeah, that's really one of its main use-cases: implementing the same kind of acceleration and deceleration as you would get with velocity simulation, but with strict duration.

Link to comment
Share on other sites

13 hours ago, OSUblake said:

I could have really used this a year ago 

 

Just ask Jack to "whip together" a time travel helper function. ?

  • Haha 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×