Spring Easings

[joegaudet]

Hey guys,

Love the work, seems like a very useful library, wondering if there are any plans to incorporate spring-type animations? They have a much nicer feel than linear, or even cubic-bezier easings.

.joe

[samselikoff]

I agree this is important, I think it's just a matter of showing some examples and documentation for custom easing functions

[joegaudet]

@samselikoff any examples of using something like a spring to change the position of a component on a mouse event? Or perhaps some other transform?

[samselikoff]

I haven't done this yet. I'm not exactly sure what it would look like because ember-animated motions have a notion of a fixed duration, and I think springs have a derived duration based on the distance and other factors.

If I had to do this I'd start by googling around to see if anyone has done a sort of spring-to-bezier conversion.

[ef4]

This is one of those scenarios where it sounds nice to have a true physics-based simulation, but the reality of UI design means you really don't want things to be able to vibrate all over the place for unbounded time. Thankfully harmonic oscillators have closed-form solutions, so we can work from "both ends" of the transition and tune the parameters to match so that it gets to where you want in the time you want.

The more architectural question here is whether we want to adjust the boundary between what motions do and what easings do. Right now easings are too simple to do proper interruptions with spring physics, because they can't see the initial velocity. Motions can, which is why motions are where we handle momentum & interruption now.

Given the current architecture, there are two paths here, and we could choose to do both or either.

1. We can make a spring easing and it would be equivalent to what people are used to in other animation systems, but its momentum will still be governed by whatever motion you use it with (usually move), which won't always look exactly right for the spring case.

2. And/Or we can make a spring-move motion. This could have proper interruption, but it's not an easing, you don't get to use it as the easing function inside other motions like scale.

Alternatively, we could change the architecture so that easings govern momentum. I think that would be possible and might be very cool. But it's a much more powerful kind of easing than people are used to, so you're teaching against what the word "easing" already means to people.

[joegaudet]

Spring scale makes for some pretty cool rollover effects.

I think if we (ember folks writ large) want to build experiences that are comparable to those being provided by our friends in the react community the third option of changing the architecture so that we can accomplish effects similar to what you see in framer-motion ( https://www.framer.com/motion/) makes the most sense. (Of course, acknowledging that I'm not a current contributor to this library).

How much work would this ultimately be, and are there ways I, or someone from my team might be able to help?

.joe

On Tue, Nov 5, 2019 at 9:07 AM Edward Faulkner notifications@github.com wrote:

This is one of those scenarios where it sounds nice to have a true physics-based simulation, but the reality of UI design means you really don't want things to be able to vibrate all over the place for unbounded time. Thankfully harmonic oscillators have closed-form solutions, so we can work from "both ends" of the transition and tune the parameters to match so that it gets to where you want in the time you want.

The more architectural question here is whether we want to adjust the boundary between what motions do and what easings do. Right now easings are too simple to do proper interruptions with spring physics, because they can't see the initial velocity. Motions can, which is why motions are where we handle momentum & interruption now.

Given the current architecture, there are two paths here, and we could choose to do both or either.

1.

We can make a spring easing and it would be equivalent to what people are used to in other animation systems, but its momentum will still be governed by whatever motion you use it with (usually move), which won't always look exactly right for the spring case. 2.

And/Or we can make a spring-move motion. This could have proper interruption, but it's not an easing, you don't get to use it as the easing function inside other motions like scale.

Alternatively, we could change the architecture so that easings govern momentum. I think that would be possible and might be very cool. But it's a much more powerful kind of easing than people are used to, so you're teaching against what the word "easing" already means to people.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ember-animation/ember-animated/issues/140?email_source=notifications&email_token=AAA6IBZ3RDTDU6XO7WHFZ6TQSGR4XA5CNFSM4IBJFH72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDDPNZY#issuecomment-549910247, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA6IBYKTXC63QLX34YWP73QSGR4XANCNFSM4IBJFH7Q .

[ef4]

Framer's spring support is equivalent to if we just make a spring easing. It doesn't handle second-derivatives during interruption either. So we don't need any architectural changes to have the same behaviors.

[joegaudet]

How complex would adding one be do you think?

[joegaudet]

Any further thought on this, spring easings would really make the animations feel a lot more lively.

[ef4]

Yes, I know how I would like to implement this. And it goes nicely with some other things that octane unlocked for us (like using modifiers to control exactly which dom elements are animatable). It's just a question of finding time to work on it. If other people are able to commit time, I can spend some mentoring.