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
For anticipation, just add an extra initial velocity in the opposite direction and let the closed-form solution handle the time evolution. The main trick here is to keep both position and velocity as state. There is no need to “step through the simulation”.
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:
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.)
That could possibly be done by incrementally changing force to move it back first, then forward, or to model this as a PD controller following an input with some baked in reversal before moving forward. That can still be closed-form (state response to a known input will be; Laplace transforms can help there), but still would need a bit of effort to model and tune to look right.
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.
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.
Author here! Nice, thanks for taking the time to create that demo! I also like the look of commenting out `vel.set(0, 0)` when the anticipation target is reached, as it has less "snap" between velocities. Although if you keep velocity the same, now it'll go a little farther than the anticipation target. So maybe if you wanted to have a specific distance of anticipation (I think something an animator would reasonably want to do), one could do some math to figure out where to place the target position so that by the time it decelerates to 0, the distance is the real anticipation distance.
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
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.
Hi, author here! When writing this, I was thinking more in the space of procedural character animation and motion graphics than UI animations. That's part of why I want a system with nice parameters, so that I do have the ability to fine tune and tweak the motion to fit the context. My background is in classical animation so it's something I might just keyframe by hand in a non-code context, or in Flash when it's easier to jump back and forth between code and non code. Although I think having it parameterized still can lead to interesting opportunities for variation in procedural animation!
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.
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.
Desktop doesn't have bounce and I prefer it that way. For mobile maybe bounce is more important since its less precise than a mouse, but point is that bounce is not obviously superior since on desktop the bounce just feels buggy rather than what you want.
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:
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:
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:
Readit News
https://www.desmos.com/calculator/mu80ttc9aa
For anticipation, just add an extra initial velocity in the opposite direction and let the closed-form solution handle the time evolution. The main trick here is to keep both position and velocity as state. There is no need to “step through the simulation”.https://m3.material.io/styles/motion/overview/how-it-works
That could possibly be done by incrementally changing force to move it back first, then forward, or to model this as a PD controller following an input with some baked in reversal before moving forward. That can still be closed-form (state response to a known input will be; Laplace transforms can help there), but still would need a bit of effort to model and tune to look right.
Is there a name for this kind of motion? I'd love to use it sometime.
Deleted Comment
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...
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
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.
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.
https://github.com/franciscop/ola
Note: ola means (sea) wave in Spanish
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.
https://medium.com/hackernoon/the-spring-factory-4c3d988e712...
And a bounce function:
https://medium.com/hackernoon/the-bounce-factory-3498de1e526...
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.
https://chrisbuilds.github.io/terminaltexteffects/changeblog...