I'm Unsatisfied with Easing Functions

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.sin( scale*t)/scale , math.cos( scale*t)
      elseif resid>0 then
         T1,T0 = math.sinh(scale*t)/scale , math.cosh(scale*t)
      end
      local dissipation = math.exp(-decay*t)
      local evolved_pos = dissipation*( pos*(T0+T1*decay) + vel*(   T1      ) )
      local evolved_vel = dissipation*( pos*(-T1*omega^2) + vel*(T0-T1*decay) )
     return evolved_pos , evolved_vel
   end

The section on feedback control reminded me of procedural animation where you don't calculate the velocities and positions directly; instead the animation is a consequence of constraints and a target.

I took your PD controller concept and added anticipation using two targets: the original mouse target, and an "anticipation" target set proportionally based on the distance from the point to the main target[1].

This also made me think of Jelly Car and the amazing simulations they did using rigid frames for soft bodies, called Shape Matching[2]. Instead of simulating the soft body physics directly, they used a frame, springs, and "gas" to constrain points, which moved towards targets fixed to the frame.

[1]: https://editor.p5js.org/Thomascountz/sketches/YXWm_VV6s

[2]: https://www.gamedeveloper.com/programming/deep-dive-the-soft...

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 continuity and it's even harder to control?

Personally I've had far better results using the repeated-lerping-towards-a-target trick, aka a true exponential ease. When stacked, you get a classic LTI (linear time invariant) system, and the math around how those behave is well established.

Classic hand-drawn animation does often use stretching and squeezing to emphasize and to create a sense of anticipation, but that's very different and always dependent on the specific motion. You can't automate that by making everything act like jello.

Why does literally every single article on easing functions mention Penner? First off he didn’t invent them. Games had been using those functions since at least the 80s.

Second, why only him and these functions? I don’t write: In JavaScript by Brendan Eich using Node.js by Ryan Dahl I installed a package using npm by Isaac Z. Schlueter called React by Jordan Walke and for the backend I used TJ Holowaychuk’s express.js. Instead just write: In JavaScript using node.js I installed react and express.js

But literally, I’ve never read an article about easing functions that just says “easing functions”. they all feel obligated to mention Penner” Why? and no, it’s not because open source or multiple contributors. I used those examples because I can’t name the 1000s of people for functions which is precisely my point

I wrote about analytic easing functions a number of years ago and show how to precisely design a spring function:

https://medium.com/hackernoon/the-spring-factory-4c3d988e712...

And a bounce function:

https://medium.com/hackernoon/the-bounce-factory-3498de1e526...

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.

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

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...

I have the feeling that B-splines would be a good solution for this problem. Given that they have a continuous zeroth (i.e., the function is continuous), first, and second derivative, the motion will always be smooth and there will be no kinks. However, maybe it's moving the problem because now you must tune the coefficients of the B-spline instead of damping parameters (even though a direct mapping between these must exist but this mapping may not be trivial).

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).

Apple's easing function (like others) is parameterized by physical characteristics (e.g. spring force, damping) that are easier to model from first principles, but there are other parameters (overshoot distance, anticipation size, animation time) that are more useful for animation. A closed-form parametrization with the latter might be tricky to derive, but some kind of iterative solver (plug in desired animation parameters, get values for the physical parameters) shouldn't be too difficult?

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.