Live data from Hacker News

I'm Unsatisfied with Easing Functions

davepagurek.com

51–60 of 88 posts

Re: I'm Unsatisfied with Easing Functions

#51
post #49

Earlier quoted context omitted.

You wouldn't really need an incremental force: a step-function force (first backward for some time steps, then instantly forward) will still produce a continuous velocity curve.

true! I suppose you'd risk getting some oscillations in the anticipation depending on the scale of the force, but that could be desirable, or might not happen if the scale is small enough, and certainly makes the math a little easier

You can trivially calculate the time-to-peak overshoot using the closed form equation. It’s the first (0-indexed) zero of the velocity response, i.e. happens at t = (pi / scale)

And obviously it would only apply for the underdamped case.

Re: I'm Unsatisfied with Easing Functions

#52
post #27

I also didn't like when a new easing happened _while_ another easing was happening, which often felt very jerky. Had to do a bunch of calculus (derivatives) by hand and wrote a small library for it in JS: https://github.com/franciscop/ola Note: ola means (sea) wave in Spanish

Thanks for sharing this library! Author of the post here, I'll definitely check out your implementation.

Thanks! From your article, you might not want/like my library since it's based on a single easing function. I used a cubic function to find out the interpolation values, and the derivative to make sure it's always smooth. The equation looks like this, it's on the source code:

https://www.wolframalpha.com/input/?i=x+%3D+2+*+t+%5E+3+-+3+...

If you wanted some more details please feel free to ping me (email through my website's resume, or Twitter) and I'll dig the handwritten equations.

Re: I'm Unsatisfied with Easing Functions

#53
post #28
post #7

To me this article is ridiculous bcause the first thing I think of when I hear "easing function" is the css version of that concept, which seems to solve all the authors problems? The css easing functions are weirdly limited, because they consist of a single function that takes 4 parameters, then a bunch of specializations of that function. There are great websites on the internet for configuring those parametere tho…

how would any of that make the article ridiculous?

It circles around the point without ever reaching it. Each section seemed like it was missing the obvious. "To me" meaning that was my personal impression.

Re: I'm Unsatisfied with Easing Functions

#54
post #7

To me this article is ridiculous bcause the first thing I think of when I hear "easing function" is the css version of that concept, which seems to solve all the authors problems? The css easing functions are weirdly limited, because they consist of a single function that takes 4 parameters, then a bunch of specializations of that function. There are great websites on the internet for configuring those parametere tho…

I read the article as an unreasonably deep dive into something that few people care about as much as the author. I certainly don’t, but that’s what makes it good. That’s perfect for HN.

It didn't seem unreasonably deep at all. It was long, sure, but it seemed to only scratch the surface of the topics it was discussing. That was sort of my point in bringing up the css function - it is itself incredibly bare-bones, but just describing it's usage would have covered more ground imo.

Re: I'm Unsatisfied with Easing Functions

#55
post #7

To me this article is ridiculous bcause the first thing I think of when I hear "easing function" is the css version of that concept, which seems to solve all the authors problems? The css easing functions are weirdly limited, because they consist of a single function that takes 4 parameters, then a bunch of specializations of that function. There are great websites on the internet for configuring those parametere tho…

By "CSS version" I'm assuming you mean cubic-bezier [1], which definitely does not solve all the author's problems. For example, you cannot use it to create their third example (easeOutElastic), nor many of Apple's kinematic easing functions or the feedback control. [1] https://developer.mozilla.org/en-US/docs/Web/CSS/easing-func...

Yes, you can't use it to create those other functions, but you can use it to fulfill the authors purported goal in using those other functions. It also solves the deficiencies the author highlights in those other approaches. You could of course point to deficiencies in it and seek to resolve those deficiencies, but that wasn't how the article was structured.

Re: I'm Unsatisfied with Easing Functions

#56
post #48

Earlier quoted context omitted.

My only real beef with the article is that "Uneasy about easing functions" would have been a much better title.

Author here -- kicking myself because this is way better lmao

You should edit the title. I'm sure there's plenty of people who will find this post later on and be tickled by that :)

Re: I'm Unsatisfied with Easing Functions

#57
There are a lot of post and talks out there about why spring is easier to use and gives nicer results than most easing functions.

In CSS, there's a long standing feature request to add a spring() timing function: https://github.com/w3c/csswg-drafts/issues/280

This would not only be great for developer ergonomics, but would remove JS from the animation path for these cases.

Re: I'm Unsatisfied with Easing Functions

#58

Earlier quoted context omitted.

I read the article as an unreasonably deep dive into something that few people care about as much as the author. I certainly don’t, but that’s what makes it good. That’s perfect for HN.

It didn't seem unreasonably deep at all. It was long, sure, but it seemed to only scratch the surface of the topics it was discussing. That was sort of my point in bringing up the css function - it is itself incredibly bare-bones, but just describing it's usage would have covered more ground imo.

"Unreasonably deep" is a relative term. Certainly deeper than I care to go. But sure, it could be unreasonably deeper.

Every time I have used animation my approach has been to treat it as frosting to be used sparingly. As such I would be much more attracted to simple/supported modes (that someone else will be interested in keeping functional) than I would be to obsessing over physics realism. But I am also a UI caveman with no taste, so there's that.

Re: I'm Unsatisfied with Easing Functions

#59
post #13

As an engineer I'm attracted towards the PID based one, but also wary of the amount of CPU cycles used just for a little animation. It seems like overkill, for some reason.

I don't imagine stepping through the ODE with finite differences at the same time step as drawing should be very expensive, essentially it's a handful of sums and products. In fact, using a closed form solution with an exponential is probably more expensive.

You're right, it's not that expensive! The main limiting factor for me is that not all animations play monotonically forward in time. I'm also interested in using these in animation software where you have a timeline and can seek anywhere. So a closed form is helpful in handling that case too.

Re: I'm Unsatisfied with Easing Functions

#60
post #48

Earlier quoted context omitted.

My only real beef with the article is that "Uneasy about easing functions" would have been a much better title.

Author here -- kicking myself because this is way better lmao

Take it--it's all yours :-)
Post reply on HN