I'm Unsatisfied with Easing Functions • Hacker News Board

Re: I'm Unsatisfied with Easing Functions

#71

Post by creata » Thu, Jul 24, 2025, 12:00 AM UTC

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…

Material Design 3's "motion physics system" uses damped harmonic oscillators, too. The parameters (undamped angular frequency omega0 and damping ratio zeta) they use are on this page:

https://m3.material.io/styles/motion/overview/how-it-works

Re: I'm Unsatisfied with Easing Functions

#72

Post by ww520 » Thu, Jul 24, 2025, 1:16 AM UTC

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…

Wow. This is so good. I would never imagine using PID control for animation motion. Saving this.

Re: I'm Unsatisfied with Easing Functions

#73

Post by Obscurity4340 » Thu, Jul 24, 2025, 2:41 AM UTC

Can anyone comment on easing functions vs constant on a longer period of time, would they be distinictive or seem the same on a long and smooth enough slope

Re: I'm Unsatisfied with Easing Functions

#74

Post by esafak » Thu, Jul 24, 2025, 3:07 AM UTC

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…

How did you even find this site; did you make it?

Re: I'm Unsatisfied with Easing Functions

#75

Post by [deleted] » Thu, Jul 24, 2025, 4:57 AM UTC

ww520 wrote: post #72

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…

Wow. This is so good. I would never imagine using PID control for animation motion. Saving this.

[deleted]

Re: I'm Unsatisfied with Easing Functions

#76

Post by aappleby » Thu, Jul 24, 2025, 5:13 AM UTC

I've used the same easing function in my personal projects for decades now - move the variable 90% of the way to the goal every 80 milliseconds.

Re: I'm Unsatisfied with Easing Functions

#77

Post by [deleted] » Thu, Jul 24, 2025, 5:44 AM UTC

Jyaif wrote: post #68

ipv6ipv4 wrote: post #66

Earlier quoted context omitted.

Overshoot is important for scroll views. Without the bounce, there is no feedback if you have scrolled to the edge or not. Early Android lacked the bounce, and it would invariably lead to users scrolling again to be sure they had indeed scrolled to the edge of the view.

> Early Android lacked the bounce Early android had some visual feedback (a gradient that faded out) instead of the bounce, possibly because Apple owns a patent ( https://patents.google.com/patent/US7469381B2/en ). Current Android still does not use the bounce, and instead stretches the content, which works well enough on the high resolution screens that we have now.

[deleted]

Re: I'm Unsatisfied with Easing Functions

#78

Post by panic » Thu, Jul 24, 2025, 5:52 AM UTC

ipv6ipv4 wrote: post #66

unconed wrote: post #3

Bouncy animations that overshoot just seem like a bad idea in general. The purpose of a UI animation is to guide the eye, but the bounce explicitly introduces a reversal of motion at the end before stopping. Easing functions are just very cargo culty. We've had the same basic set that dates from the Flash era. Now there's an Apple variant that's just a parametric version of the same idea, but it lacks guaranteed cont…

Overshoot is important for scroll views. Without the bounce, there is no feedback if you have scrolled to the edge or not. Early Android lacked the bounce, and it would invariably lead to users scrolling again to be sure they had indeed scrolled to the edge of the view.

You can add the bounce as a second layer of dynamics on top of the exponential deceleration (this is how iOS scroll views do it).

Re: I'm Unsatisfied with Easing Functions

#79

Post by panic » Thu, Jul 24, 2025, 5:55 AM UTC

bhk wrote: post #8

Oscullation/"anticipation" in transitions is so gimmicky and cartoonish. Living things don't move like that, and mechanical things don't unless they are broken, chintzy, or poorly designed (underdamped).

The correct way to do "anticipation" is to apply it as something is being pressed, then finish the animation on release. Putting both together in a single easing function is missing the point, IMO.

Re: I'm Unsatisfied with Easing Functions

#80

Post by Koffiepoeder » Thu, Jul 24, 2025, 5:58 AM UTC

aappleby wrote: post #76

I've used the same easing function in my personal projects for decades now - move the variable 90% of the way to the goal every 80 milliseconds.

Reminds me of Zeno's paradox. Do you have a terminating condition? Or just a fixed number of iterations?