I'm Unsatisfied with Easing Functions • Hacker News Board

Re: I'm Unsatisfied with Easing Functions

#31

Post by LegionMammal978 » Wed, Jul 23, 2025, 3:26 PM UTC

pahgawk wrote: post #22

EsportToys wrote: post #6

Closed-form (non-iterative) PID solution: https://www.desmos.com/calculator/mu80ttc9aa function sprung_response(t,pos,vel,k,c,m) local decay = c/2/m local omega = math.sqrt(k/m) local resid = decay*decay-omega*omega local scale = math.sqrt(math.abs(resid)) local T1,T0 = t , 1 if resid 0 then T1,T0 = math.sinh(scale*t)/scale , math.cosh(scale*t) end local dissipation = math.exp(-decay*t) local evolved_pos = dissipatio…

This is good! Although I'd also say that initial velocity doesn't quite cover what I was talking about in the post -- even anticipation arguably can start from 0 velocity, accelerate backwards, decelerate, then accelerate in the opposite direction. Imo, any sudden change in velocity should by default be avoided (there are always valid uses where breaking that expectation is good, but I'd want it smooth by default.) T…

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.

Re: I'm Unsatisfied with Easing Functions

#32

Post by x187463 » Wed, Jul 23, 2025, 3:27 PM UTC

I have found myself leaning heavily on easing functions to smooth motion within my terminal visual effects engine. I do not have a very strong math background so I am limited in how much I can modify the commonly available functions. I have found it useful to create custom easing functions by mapping the easing function progress across a bezier curve. There's an example in the changeblog write-up from the last release:

https://chrisbuilds.github.io/terminaltexteffects/changeblog...

Re: I'm Unsatisfied with Easing Functions

#33

Post by MITSardine » Wed, Jul 23, 2025, 3:28 PM UTC

Interesting article. But why is it an issue for it to be iterative?

I would imagine you're going to step through time anyways, to draw frame after frame. Wouldn't it in fact be cheaper to step through using some finite differences scheme, with one FD step for one draw step? It could be as cheap as a handful of additions per time step. Unless I'm overlooking something?

If needed for stability or accuracy, you can also step through several FD steps in one frame, but I'd imagine at a rate of 20fps, this should not be necessary for the types of equations considered.

Re: I'm Unsatisfied with Easing Functions

#34

Post by MITSardine » Wed, Jul 23, 2025, 3:30 PM UTC

Liftyee wrote: 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.

Re: I'm Unsatisfied with Easing Functions

#35

Post by mattkrause » Wed, Jul 23, 2025, 3:36 PM UTC

shermantanktop wrote: post #25

f33d5173 wrote: 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.

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

Re: I'm Unsatisfied with Easing Functions

#36

Post by eviks » Wed, Jul 23, 2025, 3:41 PM UTC

ajkjk wrote: post #29

imo there just need to be a few more default easing functions, the standard ones aren't quite natural enough. There must be a standard curve equivalent to the "human pushing/pulling an object from A->B" function that would actually look natural. EaseIn/EaseOut/etc is never quite it; human motion has a bit of higher-order feedback used to regulate it. Maybe to do with the combination of: all the motion happens via mus…

And the parameters should be tied to reality as well like object weight, surface tension, hand strength, ...?

Re: I'm Unsatisfied with Easing Functions

#37

Post by pahgawk » Wed, Jul 23, 2025, 3:42 PM UTC

MITSardine wrote: post #33

Interesting article. But why is it an issue for it to be iterative? I would imagine you're going to step through time anyways, to draw frame after frame. Wouldn't it in fact be cheaper to step through using some finite differences scheme, with one FD step for one draw step? It could be as cheap as a handful of additions per time step. Unless I'm overlooking something? If needed for stability or accuracy, you can also…

Hi, author here! Two things come to mind:

- Part of my use case is that I build animation software. In there, you've got a timeline, and you can seek anywhere on the timeline. So in that scenario, you're not always moving consistently forward in time.

- In real-time contexts, sometimes you drop frames, even for simple motion, just due to the hardware it's being run on and what else the computer is doing. Simulations can be sensitive to time steps and produce slightly different results depending on them. The size of the issue depends on a lot of factors, but you don't have that issue at all with a closed form solution.

Re: I'm Unsatisfied with Easing Functions

#38

Post by jakelazaroff » Wed, Jul 23, 2025, 3:42 PM UTC

f33d5173 wrote: 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...

Re: I'm Unsatisfied with Easing Functions

#39

Post by ajkjk » Wed, Jul 23, 2025, 3:44 PM UTC

eviks wrote: post #36

ajkjk wrote: post #29

imo there just need to be a few more default easing functions, the standard ones aren't quite natural enough. There must be a standard curve equivalent to the "human pushing/pulling an object from A->B" function that would actually look natural. EaseIn/EaseOut/etc is never quite it; human motion has a bit of higher-order feedback used to regulate it. Maybe to do with the combination of: all the motion happens via mus…

And the parameters should be tied to reality as well like object weight, surface tension, hand strength, ...?

If you want? I don't care about the parameters, I just think the default functions should include some more sensible options that look less mechanical.

Re: I'm Unsatisfied with Easing Functions

#40

Post by sixthDot » Wed, Jul 23, 2025, 3:45 PM UTC

Basically any transfert function that is used as interpolator can also be used as "easing". E.g a quadratic Bézier (let's say with empirically determined coeffs). One lesser known I used to like much is the super ellipse, although very costly.