Why Doesn’t Everyone Use This Animation???

Animation is hard. Getting "smooth" animations is even harder. Getting them to work in all scenarios? Forget it.

That said...this "exponential smoothing" thing seems like a genius hack. I'm excited to play with it more!

SOURCES
@lisyarus

S/O Ph4se0n3 for the awesome edit 🙏

[NyanCoder]

1:41 deltaTime is not the "amount of time that we want it to take", it's more like the "amount of time that elapsed since last frame"

[theDanielJLewis]

And here I thought the conclusion of this whole thing would be like, "And you can get this perfect animation with this one line of CSS."

[vectorlua]

"Oh no Math! My worst fear as a JavaScript Dev!" rofl.

[monad_tcp]

4:54 "The missile knows where it is at all times. It knows this because it knows where it isn't. By subtracting where it is from where it isn't, or where it isn't from where it is (whichever is greater), it obtains a difference, or deviation. The guidance subsystem uses deviations to generate corrective commands to drive the missile from a position where it is to a position where it isn't, and arriving at a position where it wasn't, it now is. "
(the rest isn't required for this case)

[givrally]

This sort of "exponential smoothing" is, in essence, an animated and slightly modified solution of an ODE that's found all throughout nature, called exponential decay : dx/dt = k(T-x), with k being a "speed" factor and T being the target.

It shows up every time that 1. some quantity is approaching a target, 2. the further away it is, the faster it goes (proportionally to that distance), and 3. the quantity has no "memory", meaning that at some value it will go the same rate, doesn't matter whether it just started, or started at twice that value and reached it going down.

For example, heat dissipation : A kettle filled with boiling water will lose ten degrees much quicker than that same kettle filled with barely warm water, and once the former reaches the temperature that the latter was at, it will cool in exactly the same way. Thus, Newton's law of cooling states that the temperature T of a cooling body follows dT/dt = k(T_ambient - T).

Another example is radiation : If you have twice the amount of uranium atoms, you'll expect about twice of them to decay each minute. And, if you discard the decayed material, there's no difference between 1kg of fresh uranium and 2 initial kgs of uranium at its half-life : The former has 1kg of uranium, and the latter has lost about half of its original amount, and is now 1kg of uranium too. They'll both decay at about the same rate. Because decay is actually probabilistic, I'm simplifying a bit using the law of large numbers, so it won't work if you have only ten atoms of uranium, but radioactivity does indeed follow the ODE of exponential decay, with a target at 0. dM/dt = -kM

One last example for the Data Scientists : A nice and simple gradient descent on the L2 norm actually obeys the law of exponential decay too ! The derivative is proportional to the distance, and k is your learning rate.

Of course, in this case it's slightly modified, because we're solving it numerically : The initial solution near 11:00 corresponds perfectly, the new position being the old position plus the derivative (= (target - position) \* speed) times dt, but if the speed is too large compared to dt, it becomes jittery, as the approximation "overshoots" the true value. But if you look at the (1-e^(-speed \* dt)) term, if speed times dt is small enough, then we can use the e^x = 1+x Taylor approximation to find that, 1-e^(-speed \* dt) = 1-(1-speed \* dt) = speed \* dt ! The difference is that, once it reaches 1, instead of overshooting, it's brought down to almost exactly the target.
We could probably rewrite the equation as a well defined differential equation, but because of the exponential it would likely involve nonstandard functions and stuff, so I'd rather not.

EDIT : Well, crap, that's exactly what the blog post talks about only a minute after I've unpaused the video.

[scrimb]

Web devs discover fundamental principles of animation: part 1

[plusonerabbit]

the construct game engine's blog has an article on basically the exact same concept titled "using lerp with delta-time", but it ends up with a different formula that i find much more intuitive :) lerping by 1 - (1 - f) ^ dt, where f is the amount of progress you want to have made over the course of 1 second

can also multiply dt to change the scale of things, e.g. dt * 60 would make it so f would be how much progress is made every 1 frame at 60 FPS, except it's framerate-independent

[TVDaJa]

I could enjoy these videos more if you would not pretend to not have pre-read the articles

[aaskrad]

I was expecting some new css easing function, but ended up getting memories of war from uni.

[winniedobrokot]

This math becomes much easier if you focus your thoughts not on the absolute position, but on the distance to the target. It become something like “shrink twice distance to target each second”, split to multiplicative steps by multiplication e^(-s*delta_time). When the exponents are multiplied, their powers add up, making the animation frame rate independent.

[Spongman]

for your audio engineer take: this is simply a low-pass filter on the step function (implemented in this case as a first-order "infinite impulse response" filter).

[TheFerdi]

There is another game that solved the float precision thing in an interesting way: StarMade (back when it was first released at least) divides the world into chunks that each have their own origin, and along the borders the game does a smooth transition between the two coordinate systems.

That is of course much less elegant than the outer wilds solution, but is also a neat trick :)

[jst]

Btw it is exponential moving average again (same thing as in the load balancer video). In the lerp(position, target, min(1, speed * dt)) position is the smoothed value, target is the noisy value and the last part is the factor.

[RiversJ]

Everything contained is essentially required fundamentals for any game devs and then some, most have entire collections of hyper optimized easing / zoom / jump / delay / mass and meet type animations and an entire vocabulary exists to describe them and mixing them together is an art form of it's own.
One of the things i do miss from when i was a tech art!

[SteinGauslaaStrindhaug]

8:30 Yet, Apple think it's perfectly acceptable to not move the input focus to the obviously next active window when changing spaces until the animation (or the fade if you disable seasick-mode) is completed! I'm so sick of typing half a shell command in the editor on the previous space when changing to the space with my terminal. Who has the patience to sit and wait a whole second for the input focus to move to the terminal before start typing!?

Ironically, ignoring input while animating; rather than letting me type half a git command in an editor and then have copilot hallucinate some insanity based on my misplaced shell commands; would be somewhat better than the current behaviour. But of course the real and simple solution would simply be to move the ducking input focus _before_ starting the animation! It would not affect patient users who patiently sit and admire the ridiculously slow and motion sickness inducing full screen slide animation, at all but it would make my life much better. I cannot think of any reason that the input focus should remain for about a second (maybe it's less, but it feels like ages to my ADHD) on the previous screen. Are there really anyone who regularly decides to change to a different screen with the intention of finish writing a couple of words in the previously active window while the animation finishes?!

[Lampe]

20:02 Well, that's exactly why the camera movement in Minecraft gets jittery after a while and why the stripe lands appear. It's just the numbers getting so unprecise that the imprecision gets noticeable.

[seanthesheep]

Exponential motion is used pretty much everywhere on Scratch, since it's pretty easy to do

change x by (((dest) - (x position)) / (10))

in a loop to get any variable to smoothly glide. It's nice because it continues to be smooth even when the animation is interrupted, like if the user moves their mouse around or spam clicks a button

[DKSubconscious]

Everybody was using that in the flash days, in fact I was doing it just today while prototyping a Hero transition animation using Adobe Animate, first time I've been near that program in about 12 years but the shortcuts came back pretty quickly.

[mrt_]

1:40 dt or Δt, also known as delta time, is the time between two timestamps. (delta is a greek letter, and it's usually used in math to mean a difference/distance between two things)
Usually this is done in game development, and it's the time between two frames. So you can move more or less depending on how long the last frame took to render, etc.

[ThymeCypher]

My entire issue with the whole article is the adding to position. Switches are fixed width, fixed state. You can set position to an interpolator function based on position. The approach given is using position as a state which is excessive.