Why Doesn’t Everyone Use This Animation??? 

webdevs really do be making a whole blog about animating a button

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"

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

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

Even a junior game dev will have encountered the classic "My animations shouldn't be locked to framerate, but the amount of time passed since the last frame render" Lerp with deltaTime is such a fantastic function because it doesn't require knowning the endState, just your currentDesiredTarget and it will always smoothly animate towards it.

High school math jump scare

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)

The next step is making it all CSS

Web devs discover fundamental principles of animation: part 1

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

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

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.

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

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

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.

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!

"delta over delta time" 🤣🤣

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?!

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.

This was a really cool video. Thanks! =]

amazing format! i like it.

I love the attention to details.

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.

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.

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.

On my own website I try to avoid animating manually using JS, I try to do it as either a single JS Element.animate() call or even as a CSS animation directly if I can predefine it, as for example on the toggle switches in the settings menu. There I use a simple cubic bezier animation that's defined in CSS to run whenever the state changes.

The sqrt-interpolation can be made stateless too, in a similar manner to the exponential function. The update should look like: function sqrtEaseIn(dt, currentX, targetX, sqrtAccel) { const deltaX = currentX - targetX; const q = Math.sqrt(Math.abs(deltaX)) - sqrtAccel * dt; if (q

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

This is cool. I've used the "simple" version when programming games, because it's an easy way to get smoothing. But I didn't realize it could easily be made to work correctly when dt is varying.

I tried them all in the source article, and honestly I liked the cubic easing the most.

i have recently been using hyprland WM for my laptop. and man those bezier curve animation for window's are sooo smooth man. every time i go back to windows i realized how jank windows is especially in terms of looking and feeling good

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

Deltatime is not the amount of time you want the animation to take. It is the time pffset between frames. It makes it so your animation is unaffected by the amount of frames your computer can pump out

I have used this (although the naive, only-valid-for-small-dt version) plenty of times. I don't quite like how slow it is at the end, though. Some times that's fine, but some times it's not, and you can really notice that extra fraction of a second things take to align. The immediate solution would be to increase speed, but then it goes too fast when things are far away. I dunno. Right tool for the right job, I suppose.

I love lerp, when I first learned about it, it helped me so much :)

Can't tell you enough, how often and how powerful your channel has been in exposing me to new and exciting techs! (at least to me) I don't know how you find all this stuff, but I want access to your sources! Are you pulling mostly from some techy website, or are people just posting interesting things in the discord? My brain yearns for a 24/7 feed of this sort of thing. Google (and other search engines) have been unfortunately letting me down, more and more.

Well you could also use sine or cosine or tangent. (You got to cut theinterval that you want for example pi *0.5 to pi *1.5, I mean the part between the top and the bottom part of the function. Also adding exponents can make the animation more „springy“

Why does the blogpost look so much better in this video? Arc Boost?

I love how TLDR is added in about two-thirds of the way through.

Oh yeah, the good old virtual RC-lowpass. Pretty neat at times (as it closely mimics lights, pseudo-analog meters etc), pretty boring for motion, as the speed is changed immediately on condition change. When I wanted auto-aim in my game, I wanted not just the stuff to fly where a target is, but also your actual guns to follow the new aim, and that change of speed looked unnatural for something massive. Morale: the actual physical simulation (just constant acceleration, e.g. +a, -a or 0) with a per-frame condition resolution (e.g. are we still picking up the speed, or it is time to brake in order to stop at the desired point) is the key! It is not that complex to implement (although is not trivial either TBH), yet has a defined end condition, has a smooth square ramp-up and ramp-down, has a PERFECT reverse response (in your case the slider would move slightly past the point where you've tried to reverse it, smoothly stop and accelerate back to the initial edge) - and actually gives your animated object the feel of mass.

15:00 YOU ARE A PROGRAMMER, MAKE A SMALL SCRIPT TO TRANSLATE YOUR VARIABLES BACK FROM THEIR SHORTHAND WHEN YOU'RE DONE! something like this maybe #!python #took me 3 minutes. could probably optimize better, but the point is to save time above all else def expand(in_str): return in_str.replace('x','position').replace('a','target').replace('c','speed') print(expand("d/dt x = (a-x) c")) # d/dt position = (target-position) speed I don't know what sort of math markup is being used, but surely there's some way to define shorthand, or regex replace or something like that and then run your mathml through it. And if there isn't there should be

“1−e^(−ct)”, the value of the lerp parameter u = 0..1, describes the charging or discharging of a capacitor (through a resistor) to some new voltage where 1/c is the “time constant”, the number of time units that will pass before about 63% of the ever-slowing progress is made towards a new state. You sometimes see a time constant being the thing to set for smoothing function of a variable speed drive for controlling an electric motor.

I know it's the simplest courtesy, but I appreciate that you bother always putting the links. It feels more and more common that people won't bother, even if they mention it in the video 😿

The blogpost hangs tab when navigating to a certain section on Firefox, is it only me?

The toggle buttons are very short so it doesn't show the subtle differences very well. Try moving something a longer distance or along curved paths to show the difference. How does exponential smoothing compare to Bezier spline curves?

I have an unfinished game where I find it hard to make the player movement smooth. Should I make the scrolling when the player reaches the edge smooth?

Until now I didn't understand why floating point errors happen

I've been using it ever since I started game dev many years ago since it seemed like a no-brainer solution

This is like a simple smooth gliding code in Scratch😂

I used to code with this technique a lot, but then I questioned why I was avoiding storing that little bit of state value, it wasn’t because I didn’t have the memory, or the cpu cycles to spare, I was being kind of lazy really. My preferred way to animate was to conserve momentum, just like objects do in reality. You can use a Tweening library, or put something together yourself After that, I found it was actually even less code and hassle to write than these stateless Lerp techniques, plus I could use meaningful quantities like duration ( measured in seconds) or maximum velocity ( m /s), and not arbitrary scaling values like ‘speed’ ( without any tangible unit)

Thank you for reminding me why I still use gsap

Outer Wilds mentioned 🎉 It's progression is you gaining information so you should play it as blind as possible.

This was so sick. The final boss is writing this in Tailwind lol

You should read up on Robert Penner's easing functions

The function guy uses for interpolating called linear interpolation or just lerp It interpolates between start and end by value t When t is 0, then it returns start When t is 1, then it returns end Anything else is inbetween So, to smoothly move camera or stuff, you just put something like x = lerp(x, target, 0.2) 0.2 here is interpolation between x and target Each time we run it x is getting close to target And heres the function of lerp return start * (1 - t) + end * t;

I have been an early adopter of the iPhone (got it as soon as it was possible) and have lived with smartphone interfaces for at least 15 years and yet I still find these toggles harder to understand than good old checkboxes. Unless there is also some color these toggles to me feel confusing. Maybe it is also because I grew up in a country where light switches are not consistently mounted the same way (even if the electric code always said they should) so there is no consistent association for me between left-right, up-down and on-off. Is it just a me problem?

im partial to the sigmoid (σ = 1 / (1 + e ^ (-αx)) function to get that 3b1b manim look. I set alpha to 8 or 10 usually, and it looks pretty good!

While the content of the article might be "naïve", it actually contains good amount of math and comparison behind the little smooth animation thing we used in a lot of places. Very well explanation for many. You will be surprised tons of devs (includes game devs) who used it daily but never try to know the logics behind. They used it because it feels smoother comparing to other linear/cubic approaches. Even a lot of good animations later are fairly based on this type of thing and keep iterating upon it. I was kinda upset as a "semi-senior" dev (ppl called me senior but I don't feel like it), instead of trying to understand/appreciate the math/concept behind, and take the switch as the simple example how a math function can effectively affect our perception, the comment section has fair amount of "we don't need animation" "who cares" "a whole blog about animating a button". I mean even we know that it doesn't mean we need to use it, but know some math isn't a bad thing right? The web community has a lot of geniuses, they made the entry bar so low that everyone can quickly pick it up and build something, but also now we have huge amount of "pragmatic" coders that don't appreciate simple thing and don't realize we stand on the shoulder of giant.

13:01 Another typo: "out" instead of "our"

hey theo! how come you record your videos at 30fps? is it a mac limitation?

the bots are early

Is there any reason why people have decided that radial switches should go fast first and ease out, and that it's the best looking solution? Most real life switches I've used have bi-stable mechanisms, where they are slow first (due to resistance) and then snap to the other stable point. Does that not look good in UI? Does it somehow feel bad to use from a UX standpoint, since a user gets slightly delayed visual feedback after clicking the button? It just seems like it genuinely would look much cooler if the radial switches behaved like real switches. They could even overshoot a little and snap back to the position to give it a little extra oomph.

Now make a video about using this exponential animation with Tamagui..!

I thought you can just do allat with css transitions

I audibly gasped when I saw the title "differential equations (oh no)

Film in 60fps then already. 😁

pov: over engineering a button slider

18:40 ah this is why this video was in my recommended lol any mention of outer wilds and RU-vid decides to show it to me.

@1:00 In which way does an animated button, which can only be in one of two states, improve the understanding of the user? If it would have an effect at all, it would be a confusing or misleading one, since the state seems to be in an intermediate state meanwhile. The truth is, that the designer likes to implement some gimmick, and takes the first and simplest justification, which comes to his mind.

lerp is its own word

I’m just casually watching this in cs class, we where just learning about this and I just get a little cheatsheet from Theo just on time 😭

I wonder if the 2X speed issue is related to this: en.wikipedia.org/wiki/Nyquist_frequency

Outerwilds mentioned 🗣️🔥🔥

UI/UX is going to be reintroduced in 2025; thanks for sharing this video Theo. The example explaining (Unity's transform) floating points was very valuable.

Quadratic formula. "Jesus Christ this math is insane" 🤣🤣

as a gamedev this is so f-ing funny

You really need calculate all this floating point stuff for simple animation? I wonder why websites are so slow...

Is this a reupload, because I swear I already saw the video

This is cool

So Outer Wilds runs on Futurama warp drive... How am I not surprised?

imaging not using that bezier

The minecraft farlands also exhibit the behavior described in 20:00

Its cool beans.

He talks about the simpler code, but I wonder how expensive LERP and EXP are in compute time? Should we write our own version of these complex functions that do less granularity while being perceptually identical? #FeedTheAlgorithm

16:08 got me haha

It’s a rite of passage for all compsci students to think they invented a PID

I don't know what you dev's are taught but delta T(not "dt", it's something else but similiar) is basically the difference between two times of significance. Can be the difference between the desired finish time and beginning time, the time has passed since beginning, can be the time difference between two events, whatever. So you all are right.

that website doesn't work in firefox?

Uhm, are there really people who think that 1-exp(-x*dt) looks weird? That's like most common thing in science when it comes to describing processes...

Are web devs just now discovering interpolation methods?

damn, dude just discovered lerps. I think that's how every dev reacts when they discover lerps. lerps are cool

because i animate with frame to frame

3 t squared minus 2 t cubed ... "this math is insane!" Yeah, ok ;) Thanks for pointing this out, though: I now know what to do next time I need to animate anything. I've always noticed things moving nicely in certain UIs and games, this must be how they do it. Please continue to do more like this in the future. It has applications everywhere. Diversions like 22:05 are also educational. 20:44 This must be normal for any open world game. Elite Dangerous has to model entire real life scale solar systems down to pebbles on the planet's surface.

My $0.02 hot take: If you're doing any kind of skeuomorphism based UI, you probably should make that switch/toggle (near) instantaneous - that's how switches work in the real word. It also saves you from edge cases where the user click again while the animation is running.

Take a few seconds: thing that works. Take a few minutes: thing that works and animates. Take a few weeks, study some math, take a few more weeks and write animation interpolation framework, take a few more weeks debug edge cases, and you have a thing that works and animates and "feels nice". I know which of these I pick, and I know the world calls me lazy, and I call the world crazy.

Great video, I prefer differential equations over React any day

So is pi/2

I actually don't like the human hand stuff. As i get older it starts to give me a head ache.

Já descobri onde é que o canas foi buscar as notas de AC

Saw this in Jonas Tyroller's video: Dear Game Developers, Stop Messing This Up! Where he wrote it as this: float blend = 1 - Mathf.Pow(0.5f, deltaTime*lerpSpeed); position = Vector3.Lerp( position , target, blend ); or float blend = Mathf.Pow( 0.5f , deltaTime * lerpSpeed ); position = Vector3.Lerp( target, position, blend );