Typo at the end! Should be b^(n+m) = b^n * b^m Btw, support me for more videos: GLSL Course: simondev.teachable.com/p/glsl-shaders-from-scratch Patreon: www.patreon.com/simondevyt
Holy crap! A long time ago, I was writing a multiplayer top-down shooter and I ran into a weird issue where the camera would start jittering like crazy, some kind of de-sync between the client and server. I never figured it out and just lost hope in the project, abandoning it. Fast forward *15 years* and at the end of a video about interpolation, there's a quick side-note about a common mistake when interpolating positions. And, if memory serves, that is *exactly* what I did with the camera. ...Holy crap..!
You're saying it jittered, so it's probably not the mistake mentioned here. (If you even consider it a mistake - it's so close to being perfect that you might as well use that solution). But if I were to guess, it's possible that you accidentally let t be larger than 1 - making the camera overshoot its target. If frame rates were low enough, you'd get jitters as the camera moves back and forth.
Hey man, if your game is fun, I think you should just resume working on it. Don't bother with visual updates. The market needs more passion projects and fun games.
@@commenturthegreat2915 They said the stutter is caused by a desync between server and client. If the server is running interpolation at a fixed timestep and the client is doing it based on framerate, then yes actually this would be precisely the type of thing that would cause desyncs in position.
I didn't check the math exactly but the last example when you are following the target, you are effectively solving a differential equation. The initial fix by multiplying by timestep should be forward Euler method. Using the exponential is an exact solution to the differential equation, hence the frame rate independence. However, it is exact solution only if the target is stationary(maybe also in the case of linear movement). Therefore it is still not frame rate independent but the error is much much lower.
I'd say the length is very good. I feel like I now know what to google when I need to implement it and know the most common pitfalls. I'd just forget most of it if more info were crammed in the video. I'm sure there are more in depth videos on interpolation functions tho.
I was lerping to change model heading, and the speed of the rotation was behaving differently in Unity editor and in build, and what you are talking about in the end was the exact problem I found.. and yes, I fed the delta time into the lerp to "solve" it. Thank you so much for the proper solution!
I've experienced 2 of the issues mentioned with deltaTime lerping and the camera zoom lerping problem. I found ways around both at the time but this video was very insightful and i've made some notes for these in the future as i'm sure i'll run into them again. I knew how lerp worked but i was always curious about smoothstep, it was funny cuz i've experimented with lerping between lerps so was a suprise that i was on the right track just didn't think of the sqrt. Great video Thanks!
Hey, so some people (like me) might be calculating their lerp rate as t = K * (targetFrameRate / frameRate) instead of t = muchLargerConstant * frameTime {i.e. t = .35 * (60 / 240) instead of t = 21 * (1 / 240); this is if the result is supposed to be equally large, t = .0875 in both cases} bc they wanted to be able to write constants (K values) that were equal to the actual used lerp rate at a target frame rate, meaning a lerp rate between 0 and 1. If you use a K value from 0-1 in the second equation, your t value will be very low and cause slow lerping, thus you have to use a K value that is (targetFrameRate) times as large as the first equation (21 = .35 * 60) to get the same result. Basically, if you are ok with small lerp rates, then the second equation works fine with K being a 0-1 value, and the use of the equation presented in the video gives similar results. Using my method, however, means that your constants will not work the same way in the new frame rate independent lerp function. And if you, like me, instead of refiguring many different lerp constants, want to use the same constants to get the same result except truly frame independent, then you can use this method. After some fiddling with math, I found that you can add an extra constant out front of the (new) equation so that it becomes: t = A(1.0 - pow(K, frameTime)), where: A = K / (1.0 - pow(K, (1 / targetFrameRate))) It probably goes without saying, but this has the same effect if you were previously using something like: t = targetFrameRate * K * frameTime, as that is the same as my original equation. There is probably a shorter version of calculating A, but I didn't bother trying to condense it. A stands for Adjust, as it adjusts the result of the new function to be identical to the result of K * (targetFrameRate / frameRate) at a given targetFrameRate and all subsequent rates for different real frame rates to be much closer to the original function as well, allowing you to use the same K value used while utilizing t = K * (targetFrameRate / frameRate) (Note: There is nothing wrong with the equations in the video, they just give small lerp values that you might be required to adjust later since you can't use a K value greater than 1 in the new equation). The constant A only needs to be calculated once upon creation of the object that uses A (assuming K is indeed a constant). In summary, this provides a way for t values from the new equation to be close to the old equation using the same k values. I hope this helps anyone looking to implement this function in an already largely completed version of their project! And here is a Desmos graph I set up to help understand why this might be useful: www.desmos.com/calculator/sylkom3bze Try getting rid of A on the purple line and f on the blue line. That illustrates the exact way the original equations were portrayed in the video.
Awesome, yeah that was one problem with the new equation, is that it doesn't map easily to the old values without some work. And I didn't do the work heh
Interesting stuff. My favorite functions in Unity game development always has been lerp and slerp because they are easy to use and extremely useful in many situations. Also I love their names
Every time I go to write I a comment you're ahead of me explaining what I know from intuition, but way better than I could. Then adding to that something I don't know. brb gonna bing your videos.
1:13 Using this in conjunction with ‘B*t + A*(1-t)’ was an idea I never heard before and will be SO MUCH more useful than having to go into desmos to hand craft functions whenever I need interpolation, so thank you for all this! I know this was probably the simplest concept for others, but I work in a sim tool that doesn’t offer interpolation functions and I only really need them when making nice animations. But this is so much cleaner than reimplementing complex functions...
2:18 From what I understand this can be achieved using integer math as well. I've heard you can do something similar on 8 bit platforms using the following: char speed = 0; unsigned char accel = 0; void gametick(){ accel++; if (accel) { if (speed > 0 && speed < 0x7f) { speed++; } } Essentially accel acts as a timer that increments speed whenever accel overflows. If you wanted to achieve an effect like x^3 or sqrt(x) you could AND accel with a bitmask that grows or shrinks based on the value of speed.
I love these videos, covering basic concepts and tool sided in game development. I always learn new things and get a deeper understand of what I'm doing, and what I could do better. Thank you so much!
Absolutely astonishing video! I was aware of the lerp itself, but these tiny things, like the interpolation of colors to get nice gradients, which are very quickly overlooked while programming. I'm amazed by the solutions. Thank you very much!
Absolutely blown away by the insights offered by these videos. There is a lot of how to do XYZ game dev videos on RUclips. But the depth and breadth covered on this channel🤌 You are a rare and beautiful beast. Thank you.
Amazing stuff. I've done all these kinds of things without LERP (e.g., moving objects, color transitions, camera tracking). So it will be interesting to see how I use these commands to improve my programs.
Oh my god, learning the right way to lerp positions independently of framerate IS a must and I never thought of it... Totally required for online games where position matters.
I've been doing smooth lerping as shown at the end wrong all this time! I did the exact same as the same as the second example, slapping on delta time. I was never satisfied with how it looked with low framerates as it gets jittery, so I tended to add some additional checks to make it not freak out.
I didn't know about the slerp function until now, and it is SUPER helpful! I'm a 3d artist, and I often face the problem of having to interpolate between two normal maps. When searching how to do this, there are tones of unhelpful answers. some say to just interpolate between the raw pixel values (which never looks right). Others say to use an overlay blend operation, which does an ok approximation. I have never once heard someone mention slerp! One great property is that you can rotate one normal map by the other by using t=2, or t=-1 to rotate it in the opposite direction.
@@simondev758 I've actually read that blog before. It was very useful, but the slerp function adds some more flexibility. For example, I often need to mix 3 normal maps when working with clothes (seams/pockets, fabric wrinkles, and procedural noise). I can divide their angles by 3 using slerp(normal_map, surface_normal, 1/3), and then add them together with two instances of slerp t=2.
What I like about lerp is how it can be cheated to be smooth, like you showed. But also in shaders how it can be used for shapes and patterns. Where T is a value of 0 to 1, meaning black to white with grey in between. So by feeding it a black and white pattern "aka any colored image but only one of the 3 colors" then you can use lerp to paint effects onto a surface. Say you have a texture with spots you want lit up. You just use the non lit part into the A, the lit part into the B. And the black and white part into T. So now it lights up the white parts of the texture while smoothing out in the greys.
I could see how I could have a whole library of different variations to lerp with some better names for what you want to do. Like the smoothstep. Thank you for this, it sounds awesome.
I'm currently working on a game that has some events that sometimes causes a spike in the frame time, if I happened to be moving the camera in a specific way during those events the camera starts to freak out shaking all over the place. I ironed out some time consuming events to minimize the problemas but never understood why the camera of all things was suffering from the fps drops... until now
@@simondev758 it's the consequence of doing too much math haha I just made a matrix multiplication function in JS last week where I added instead of multiplied the elements, so it'll be the first thing I look for a while 😂
For a way more detailed explanation about the framerate-independence concept mentioned at the end, look up Freya Holmér's very insightful video titled "Lerp smoothing is broken".
on the 3rd method, frame independent lerp thing, its ilke K = 1 - pow ( K , frameTime) we're using the variable K when declaring it is odd. shouldn't it be pow(constant , frameTime) ?
I wonder if the log function for zoom in zoom out should not be a sqrt function for natural view, because then your velocity with which you distance in or out is constant, as the area you cover increases with the sqr of the distance.
amazing video, you should leave a little more time at the end of the video, so the recommended videos appear there. Currently the explanation of method #3 get interrupted for being at the end of the video
@@clif2craf273 I know. Here's my way to get it: f(t)=lerp(1-(1-t²), (1-(1-t)², t)= =1-lerp((1-t)(1+t), (1-t)(1-t), t)= =1-(1-t)lerp(1+t, 1-t, t)= =1-(1-t)((1+t)(1-t)+(1-t)t)= =1-(1-t)²(1+2t)= =1-(1-t)²(1+2t+t²)-(1-t)²t²= =1-(1-t)²(1+t)²-(1-t)²t²= =1-(1-t²-t+t²)(1-t²+t-t²)= =1-(1-t)(1+t-2t²)= =1-(1-3t²+2t³)= =3t²-2t³ I just decided to see how fast someone replies with that
As a web frontend programmer for an online store, I rarely get to very fancy animations... I rarely end up using anything except a linear interpolation and very rarely ease in out. But if I did use anything more fancy it would be annoying as heck to use. Because in a tool such as a webshop any animation must finish in under a second, usually between 200 ms and 400 ms not to feel frustratingly sluggish. Only when doing large distance animations such as dialogs animating onto or off the screen I get to use up to 1.2 seconds long animations; but usually half of it is basically transparent anyway.
I have a bit of a problem: what function f is required for C=slerp(A,B, f(t)), such that the dot product of C,B increases linearly for t in [0,1]? The angle between A,B is always less than 90 degrees if that makes a difference.
After plotting a few of the smoothstep family of functions, it seems like it gets steeper and steeper in the middle. Does it converge towards the discontinuous step function, or towards a "smoothest" step function ? My intuition would be the former, since the nth derivative of S_n is made to be zero at x=0 and x=1 on purpose, the taylor series should be 0 + O(x^n) and 1 + O(x^n) respectively, and thus should converge to 0 and 1, with a discontinuity in the middle. Maybe the function isn't analytical, but all smoothstep functions are polynomials and therefore analytical, so I don't think that's possible...
Wait why is Delta t not enough for syncing position and lerping? P1 += v*dt P2 += v*dt P1 and p2 are time-synced, just ad the lerped values are. What am I missing??
The two scenes shown in the video are running at different frame-rates. Also, it is not simply using a velocity to calculate a new position, but rather lerping towards a target to create a "follower" behavior. That means the actual speed of the object being simulated depends on the distance between the object and the target on any given frame. Since the bottom scene runs twice as fast as the top scene, while the top scene is still calculating the new position, the bottom scene has already moved the object closer to the target meaning the speed will actually be slower on the next frame. So if we call the distance covered in one frame by the object on the top "d", then the object on the bottom covers a distance 0.5 * d on the first frame, and then a distance _smaller_ than 0.5 * d on the second frame, meaning the overall distance covered by the object on the bottom is not d.
@UCSEjq8o06sqfuJ10jK26jYw "The video is effectively saying that higher frame rates are more accurate" When we aim to achieve _frame-rate independence_ in our games, no frame rate should be any more accurate than any other. The output of the system should only depend on the time, not on how many frames it takes to get there. "Won't the delta t's just cancel out the difference?" Maybe my previous comment wasn't very clear. If we have two games running, one with a frame time dt and another with frame time 0.5 * dt, then the second can calculate two frames in the time it takes the first to calculate one. Since the speed of the follower depends on the distance to its target, on the second frame it is closer, and therefore _slower._ The result is that it actually covers less distance than the game running with a lower frame rate in the same amount of time.
@@APaleDot Hm... Still can't catch it right If the first instance is running with a dt1 = 10ms (100fps) and the other one runs dt2 = 20ms (50fps) After same amount of time both will be in same position as dt1*fps1 == dt2*fps2 So both positions should be the same, just like the speed if acceleration also considers dt
@@MrJloa They won't be in the same position because we're lerping, we're not moving with a constant speed. As shown in the video, lerping towards a target can be achieved by doing x' = x * (1 - dt) + y * dt, where x is the position of the follower and y is the position of the target. Then in the 20ms case, the final position after 20ms is x' = x * 0.98 + y * 0.02. Basically, 2% of the way towards y. In the 10ms case, we have to run the calculation twice. On the first frame we get x' = x * 0.99 + y * 0.01, and then the final position after 20ms is x'' = x' * 0.99 + y * 0.01. Substituting x' into that equation gives us x" = (x * 0.99 + y * 0.01) * 0.99 + y * 0.01, which is not 2% of the way towards y. If you do the math it's actually 1.99% towards y. It may seem like a small error, but with faster speeds and larger differences in frame time, it can make a difference.
I like your examples of UI animation. This animation you've done are not simulative, right? The animations you've shown doesn't take velocity or other physical properties in consideration, right? Is it possible for you to do a video on spring-based system and normal curves? Great video!
Is there a course that teaches you the various ways to apply this? I’ve been having very limited success in experimenting by myself and I think I need, like, a legit teacher to help me step by step
0:28 the t shall be [0..1] and A and B shall be constant but in 7:15 it is a wrong usage of lerp because of two things 1/ using delta time x movement time (instead of t = [0..1]) can be > 1, and 2/ because the new value of A is used back in the next iteration, so this will never converge i.e. for camera transform.position = lerp(transform.position, traget_position, dt * K) your camera never halt moving since, let suppose dt * K is constant 0.5, and initial distance is 1 unit, you'll move of 0.5 at initial step then moving of 0.5 of the 0.5 for the second iteration, then 0.5 of 0.5*0.5 for the third etc ...
Typo at the end! Should be b^(n+m) = b^n * b^m
Btw, support me for more videos:
GLSL Course: simondev.teachable.com/p/glsl-shaders-from-scratch
Patreon: www.patreon.com/simondevyt
Holy crap!
A long time ago, I was writing a multiplayer top-down shooter and I ran into a weird issue where the camera would start jittering like crazy, some kind of de-sync between the client and server. I never figured it out and just lost hope in the project, abandoning it.
Fast forward *15 years* and at the end of a video about interpolation, there's a quick side-note about a common mistake when interpolating positions. And, if memory serves, that is *exactly* what I did with the camera.
...Holy crap..!
Time to pay a visit to your closet/storage unit and dust off the old hard drives....
What is the mistake?
You're saying it jittered, so it's probably not the mistake mentioned here. (If you even consider it a mistake - it's so close to being perfect that you might as well use that solution).
But if I were to guess, it's possible that you accidentally let t be larger than 1 - making the camera overshoot its target. If frame rates were low enough, you'd get jitters as the camera moves back and forth.
Hey man, if your game is fun, I think you should just resume working on it. Don't bother with visual updates. The market needs more passion projects and fun games.
@@commenturthegreat2915 They said the stutter is caused by a desync between server and client. If the server is running interpolation at a fixed timestep and the client is doing it based on framerate, then yes actually this would be precisely the type of thing that would cause desyncs in position.
Thanks, Simon. I'm lerping as a programmer but smoothing and shaping my path.
i like the part where he said "It's lerping time!" and lerped all over the place
Man, I really lost an opportunity to actually do that
@@simondev758 The fact that you didn't do it makes the joke funnier.
@@simondev75842thliker
Go Go Lerping Rangers!!
I didn't check the math exactly but the last example when you are following the target, you are effectively solving a differential equation. The initial fix by multiplying by timestep should be forward Euler method. Using the exponential is an exact solution to the differential equation, hence the frame rate independence. However, it is exact solution only if the target is stationary(maybe also in the case of linear movement). Therefore it is still not frame rate independent but the error is much much lower.
This is exactly what I needed for my game. Camera Log Zoom and Frame Rate independent tracking for aiming. Thank you so much, Simon! Subscribed.
Your smooth voice and professional animation and videos design gives your videos such nice aesthetics! Also love the knowledge you share with us
There is a mistake at 8:07 IG b^(m+n ) = b^m * b^n not b^(m+n) = b^m + b^n.
This video needs to be waaayyy longer. I want more!
I'd say the length is very good. I feel like I now know what to google when I need to implement it and know the most common pitfalls. I'd just forget most of it if more info were crammed in the video.
I'm sure there are more in depth videos on interpolation functions tho.
That's an effective lesson, explaining all these concepts, functions, and implementations in such short time.
0:50 to 2:30
2:20 smoothstep
3:07
formula for smoothStep
4:02 diff between simple linear interpolation and smoothstep
5:42 zoom
till 6:15
6:18 to 7:00
Nice linear/log zoom example! I was just staring at a linear fade in and thinking it didn't look good. I'll have to give log a try
I was lerping to change model heading, and the speed of the rotation was behaving differently in Unity editor and in build, and what you are talking about in the end was the exact problem I found.. and yes, I fed the delta time into the lerp to "solve" it. Thank you so much for the proper solution!
I've experienced 2 of the issues mentioned with deltaTime lerping and the camera zoom lerping problem. I found ways around both at the time but this video was very insightful and i've made some notes for these in the future as i'm sure i'll run into them again. I knew how lerp worked but i was always curious about smoothstep, it was funny cuz i've experimented with lerping between lerps so was a suprise that i was on the right track just didn't think of the sqrt. Great video Thanks!
Hey, so some people (like me) might be calculating their lerp rate as t = K * (targetFrameRate / frameRate) instead of t = muchLargerConstant * frameTime {i.e. t = .35 * (60 / 240) instead of t = 21 * (1 / 240); this is if the result is supposed to be equally large, t = .0875 in both cases} bc they wanted to be able to write constants (K values) that were equal to the actual used lerp rate at a target frame rate, meaning a lerp rate between 0 and 1. If you use a K value from 0-1 in the second equation, your t value will be very low and cause slow lerping, thus you have to use a K value that is (targetFrameRate) times as large as the first equation (21 = .35 * 60) to get the same result. Basically, if you are ok with small lerp rates, then the second equation works fine with K being a 0-1 value, and the use of the equation presented in the video gives similar results. Using my method, however, means that your constants will not work the same way in the new frame rate independent lerp function. And if you, like me, instead of refiguring many different lerp constants, want to use the same constants to get the same result except truly frame independent, then you can use this method. After some fiddling with math, I found that you can add an extra constant out front of the (new) equation so that it becomes:
t = A(1.0 - pow(K, frameTime)),
where: A = K / (1.0 - pow(K, (1 / targetFrameRate)))
It probably goes without saying, but this has the same effect if you were previously using something like: t = targetFrameRate * K * frameTime, as that is the same as my original equation.
There is probably a shorter version of calculating A, but I didn't bother trying to condense it.
A stands for Adjust, as it adjusts the result of the new function to be identical to the result of K * (targetFrameRate / frameRate) at a given targetFrameRate and all subsequent rates for different real frame rates to be much closer to the original function as well, allowing you to use the same K value used while utilizing t = K * (targetFrameRate / frameRate) (Note: There is nothing wrong with the equations in the video, they just give small lerp values that you might be required to adjust later since you can't use a K value greater than 1 in the new equation). The constant A only needs to be calculated once upon creation of the object that uses A (assuming K is indeed a constant). In summary, this provides a way for t values from the new equation to be close to the old equation using the same k values. I hope this helps anyone looking to implement this function in an already largely completed version of their project! And here is a Desmos graph I set up to help understand why this might be useful:
www.desmos.com/calculator/sylkom3bze
Try getting rid of A on the purple line and f on the blue line. That illustrates the exact way the original equations were portrayed in the video.
Awesome, yeah that was one problem with the new equation, is that it doesn't map easily to the old values without some work. And I didn't do the work heh
Interesting stuff. My favorite functions in Unity game development always has been lerp and slerp because they are easy to use and extremely useful in many situations. Also I love their names
I didn't know I needed this video until now, thanks!
Every time I go to write I a comment you're ahead of me explaining what I know from intuition, but way better than I could. Then adding to that something I don't know.
brb gonna bing your videos.
Hah, happy you're getting value from them!
That bit at the end is especially brilliant! Thanks for the video!
Hey Simon, I finally got around to implementing Lerps and I am very happy I kept your vid around. Helped a ton!
1:13 Using this in conjunction with ‘B*t + A*(1-t)’ was an idea I never heard before and will be SO MUCH more useful than having to go into desmos to hand craft functions whenever I need interpolation, so thank you for all this!
I know this was probably the simplest concept for others, but I work in a sim tool that doesn’t offer interpolation functions and I only really need them when making nice animations. But this is so much cleaner than reimplementing complex functions...
2:18 From what I understand this can be achieved using integer math as well. I've heard you can do something similar on 8 bit platforms using the following:
char speed = 0;
unsigned char accel = 0;
void gametick(){
accel++;
if (accel)
{
if (speed > 0 && speed < 0x7f)
{
speed++;
}
}
Essentially accel acts as a timer that increments speed whenever accel overflows. If you wanted to achieve an effect like x^3 or sqrt(x) you could AND accel with a bitmask that grows or shrinks based on the value of speed.
I love these videos, covering basic concepts and tool sided in game development. I always learn new things and get a deeper understand of what I'm doing, and what I could do better. Thank you so much!
Absolutely astonishing video! I was aware of the lerp itself, but these tiny things, like the interpolation of colors to get nice gradients, which are very quickly overlooked while programming. I'm amazed by the solutions. Thank you very much!
Thank you Simon! I'm studying CS and this is amazingly useful.
A bunch of awesome concepts in just enough detail, great video!
Wow, I don't think I've seen such a useful video before, and it only was released a week or two ago. Major props, thanks for sharing
This is so well done! Thank for making this content. I'll check out more of your videos now that I've stumbled across your channel 👍
I gotta thank you a lot especially for that last one. My camera was lerping weirdly on different frame rates and that solved my problem!
Good to see you making videos again! I always learn something.
Love how you always seem to be able to simplify things to make it easy to understand
I will appreciate more math videos like this. thanks
This is gold. Thank you for all the effort you put into this beautiful video
Yes! I've been looking for something like this! Thanks so much for making this video, now I know how to derive lerp functions
Absolutely blown away by the insights offered by these videos.
There is a lot of how to do XYZ game dev videos on RUclips. But the depth and breadth covered on this channel🤌
You are a rare and beautiful beast. Thank you.
Amazing stuff. I've done all these kinds of things without LERP (e.g., moving objects, color transitions, camera tracking). So it will be interesting to see how I use these commands to improve my programs.
2:43 "A parabola..."
*shows a bell curve*
it's like all the fun parts of cs course without the boring parts
I wish this video existed when I was getting to know all about these functions myself! Great video!
Thank you! This helps me _understand_ the functions. Cheers!
Oh my god, learning the right way to lerp positions independently of framerate IS a must and I never thought of it... Totally required for online games where position matters.
I've been doing smooth lerping as shown at the end wrong all this time! I did the exact same as the same as the second example, slapping on delta time. I was never satisfied with how it looked with low framerates as it gets jittery, so I tended to add some additional checks to make it not freak out.
I didn't know about the slerp function until now, and it is SUPER helpful!
I'm a 3d artist, and I often face the problem of having to interpolate between two normal maps. When searching how to do this, there are tones of unhelpful answers. some say to just interpolate between the raw pixel values (which never looks right). Others say to use an overlay blend operation, which does an ok approximation. I have never once heard someone mention slerp! One great property is that you can rotate one normal map by the other by using t=2, or t=-1 to rotate it in the opposite direction.
If you're trying to blend normal map, check this site out: blog.selfshadow.com/publications/blending-in-detail/
@@simondev758 I've actually read that blog before. It was very useful, but the slerp function adds some more flexibility. For example, I often need to mix 3 normal maps when working with clothes (seams/pockets, fabric wrinkles, and procedural noise). I can divide their angles by 3 using slerp(normal_map, surface_normal, 1/3), and then add them together with two instances of slerp t=2.
Loved this so much Simon! Thanks for the video 🙆🏻♂️
This video earned you a subscription. Very nice work.
Happy to have you around!
What I like about lerp is how it can be cheated to be smooth, like you showed. But also in shaders how it can be used for shapes and patterns.
Where T is a value of 0 to 1, meaning black to white with grey in between.
So by feeding it a black and white pattern "aka any colored image but only one of the 3 colors" then you can use lerp to paint effects onto a surface.
Say you have a texture with spots you want lit up.
You just use the non lit part into the A, the lit part into the B. And the black and white part into T.
So now it lights up the white parts of the texture while smoothing out in the greys.
that frame-time independent lerp will be useful, thanks!
I could see how I could have a whole library of different variations to lerp with some better names for what you want to do. Like the smoothstep. Thank you for this, it sounds awesome.
very nice, i like it a lot. short and on topic.
Great video. Really interesting to see how functions can combine to make smooth step.
Great timing, just implemented this in my little engine!
I'm currently working on a game that has some events that sometimes causes a spike in the frame time, if I happened to be moving the camera in a specific way during those events the camera starts to freak out shaking all over the place. I ironed out some time consuming events to minimize the problemas but never understood why the camera of all things was suffering from the fps drops... until now
Sorry... shouldn't it be b^m * b^n = b^(m+n). Is it different if the numbers are strictly between 1 and 0?
I wanted to write the same thing. I think this is a typo
Dammit
Even worse, this was correct in my draft, haha
@@simondev758 it's the consequence of doing too much math haha
I just made a matrix multiplication function in JS last week where I added instead of multiplied the elements, so it'll be the first thing I look for a while 😂
One content, two languages. What I have now written may have a perfect mirror in another language.!!!!!!!!!!! Hack in the brainlll
For a way more detailed explanation about the framerate-independence concept mentioned at the end, look up Freya Holmér's very insightful video titled "Lerp smoothing is broken".
Thanks. That was really interesting and inspiring!
Super cool video. Love to see more of those math videos :)
I wish I had this channel when I was younger.
Watched this a second time, realized already had given a thumbs up.
One of the best explanations
ty!
Is that a typo in the triangle function at 2:48 ? Should there be abs( t - 0.5 ) instead of abs( x - 0.5 )? I got confused when I saw the x there.
Thanks especially for the last part. I am the person who always used deltaT. I will do better now. ;)
I had no idea about the naive position lerp being framerate-dependent. The more you know!
lost me at the end lol but very good video on some game maths fundementals. Nice refresher after not having dabbled in stuff like shaders in a while
Crazy good videos thank you!
I'm not sure if what happened at 7:47 was a genuine audio screwup or you faked out censoring the word "infuriating" but I love it
Oh weird, yeah that's totally something going wacky with the audio heh
Thanks Bob from the hit show Bob's Burgers
That last pitfall has filled me with terror.
on the 3rd method, frame independent lerp thing,
its ilke K = 1 - pow ( K , frameTime)
we're using the variable K when declaring it is odd.
shouldn't it be pow(constant , frameTime) ?
Oops, yeah, it's more like
K = some_constant
K = 1 - pow(K, frametime)
etc..
Wow! That was beautiful 🤩
I need to learn math today
Teacher Simon. Thank you for the great tutorial. God bless you. Can I request a video on "How will I learn to code if I could start over"
I wonder if the log function for zoom in zoom out should not be a sqrt function for natural view, because then your velocity with which you distance in or out is constant, as the area you cover increases with the sqr of the distance.
Might be interesting to try
amazing video,
you should leave a little more time at the end of the video, so the recommended videos appear there. Currently the explanation of method #3 get interrupted for being at the end of the video
Ooh good point
Here's a simpler smooth step function: f(t) = 3t²-2t³ = t²(3-2t). I'm not sure if it gives better or worse results
It's actually the same. If you plug the equations A = t² and B = 1 - (1 - t)² into the lerp equation B*t + A*(1 - t) and simplify you get 3t² - 2t³
(1 - (1 - t)²)*t + t²*(1 - t)
(1 - (1 - 2t + t²))*t + t²*(1 - t)
(1 - 1 + 2t - t²)*t + t²*(1 - t)
(2t - t²)*t + t²*(1 - t)
2t² - t³ + t² - t³
3t² - 2t³
@@clif2craf273 I know. Here's my way to get it:
f(t)=lerp(1-(1-t²), (1-(1-t)², t)=
=1-lerp((1-t)(1+t), (1-t)(1-t), t)=
=1-(1-t)lerp(1+t, 1-t, t)=
=1-(1-t)((1+t)(1-t)+(1-t)t)=
=1-(1-t)²(1+2t)=
=1-(1-t)²(1+2t+t²)-(1-t)²t²=
=1-(1-t)²(1+t)²-(1-t)²t²=
=1-(1-t²-t+t²)(1-t²+t-t²)=
=1-(1-t)(1+t-2t²)=
=1-(1-3t²+2t³)=
=3t²-2t³
I just decided to see how fast someone replies with that
@@clif2craf273 It may give different results due to precision errors
lerping is the most underrated field in math
As a web frontend programmer for an online store, I rarely get to very fancy animations... I rarely end up using anything except a linear interpolation and very rarely ease in out.
But if I did use anything more fancy it would be annoying as heck to use. Because in a tool such as a webshop any animation must finish in under a second, usually between 200 ms and 400 ms not to feel frustratingly sluggish. Only when doing large distance animations such as dialogs animating onto or off the screen I get to use up to 1.2 seconds long animations; but usually half of it is basically transparent anyway.
i never specify the ease function to use CSS's built-in ease -
transition: 0.2s;
animation: animation-name 0.2s;
Post this on your twitter!
RUclips’s algo highly values the first few hours!
Huh, algo seems fine for me.
I have a bit of a problem: what function f is required for C=slerp(A,B, f(t)), such that the dot product of C,B increases linearly for t in [0,1]? The angle between A,B is always less than 90 degrees if that makes a difference.
After plotting a few of the smoothstep family of functions, it seems like it gets steeper and steeper in the middle. Does it converge towards the discontinuous step function, or towards a "smoothest" step function ?
My intuition would be the former, since the nth derivative of S_n is made to be zero at x=0 and x=1 on purpose, the taylor series should be 0 + O(x^n) and 1 + O(x^n) respectively, and thus should converge to 0 and 1, with a discontinuity in the middle. Maybe the function isn't analytical, but all smoothstep functions are polynomials and therefore analytical, so I don't think that's possible...
thanks for these videos.. these are pretty dope :D
I always wondered how texture filtering worked, yet never considered lerp.
can someone tell me where did the -13 come from at 2:51
Wait why is Delta t not enough for syncing position and lerping?
P1 += v*dt
P2 += v*dt
P1 and p2 are time-synced, just ad the lerped values are. What am I missing??
The two scenes shown in the video are running at different frame-rates. Also, it is not simply using a velocity to calculate a new position, but rather lerping towards a target to create a "follower" behavior. That means the actual speed of the object being simulated depends on the distance between the object and the target on any given frame.
Since the bottom scene runs twice as fast as the top scene, while the top scene is still calculating the new position, the bottom scene has already moved the object closer to the target meaning the speed will actually be slower on the next frame. So if we call the distance covered in one frame by the object on the top "d", then the object on the bottom covers a distance 0.5 * d on the first frame, and then a distance _smaller_ than 0.5 * d on the second frame, meaning the overall distance covered by the object on the bottom is not d.
@UCSEjq8o06sqfuJ10jK26jYw
"The video is effectively saying that higher frame rates are more accurate"
When we aim to achieve _frame-rate independence_ in our games, no frame rate should be any more accurate than any other. The output of the system should only depend on the time, not on how many frames it takes to get there.
"Won't the delta t's just cancel out the difference?"
Maybe my previous comment wasn't very clear. If we have two games running, one with a frame time dt and another with frame time 0.5 * dt, then the second can calculate two frames in the time it takes the first to calculate one. Since the speed of the follower depends on the distance to its target, on the second frame it is closer, and therefore _slower._ The result is that it actually covers less distance than the game running with a lower frame rate in the same amount of time.
@@APaleDot Hm... Still can't catch it right
If the first instance is running with a dt1 = 10ms (100fps) and the other one runs dt2 = 20ms (50fps)
After same amount of time both will be in same position as
dt1*fps1 == dt2*fps2
So both positions should be the same, just like the speed if acceleration also considers dt
@@MrJloa
They won't be in the same position because we're lerping, we're not moving with a constant speed.
As shown in the video, lerping towards a target can be achieved by doing x' = x * (1 - dt) + y * dt, where x is the position of the follower and y is the position of the target.
Then in the 20ms case, the final position after 20ms is x' = x * 0.98 + y * 0.02. Basically, 2% of the way towards y.
In the 10ms case, we have to run the calculation twice. On the first frame we get x' = x * 0.99 + y * 0.01, and then the final position after 20ms is x'' = x' * 0.99 + y * 0.01.
Substituting x' into that equation gives us x" = (x * 0.99 + y * 0.01) * 0.99 + y * 0.01, which is not 2% of the way towards y. If you do the math it's actually 1.99% towards y. It may seem like a small error, but with faster speeds and larger differences in frame time, it can make a difference.
You da best, Simon!
tbh the top interpolation of the colors at 6:52 is wayyyyy nicer
Great video, thank you!
How can shaping functions be used with the frame rate independent “method 3” shown at the end of the video?
super helpful! thank you so much.
I like your examples of UI animation. This animation you've done are not simulative, right?
The animations you've shown doesn't take velocity or other physical properties in consideration, right? Is it possible for you to do a video on spring-based system and normal curves?
Great video!
Damn Bob Belcher is also a math nerd???? Such a good video
Is there a course that teaches you the various ways to apply this? I’ve been having very limited success in experimenting by myself and I think I need, like, a legit teacher to help me step by step
Yeah, I have a shader course that uses lerp (mix in glsl) extensively.
How do you generate the voice on these videos? It sound super real 👍
I only subbed bc of that cheeky little gag you did.
but forreal, this is very useful if I eventually finish my ideas for music production plugins.
😀
omg definitely use quaternions to interpolate between two random rotations ;D
useful stuff i found here
Very good video, keep it up
note to self: slerp = spherical linear interpolation
Look at this remind me abt bezier curves is just lines lerping together
Bob Belcher's computer genius brother's name is Simon.
0:28 the t shall be [0..1] and A and B shall be constant but in 7:15 it is a wrong usage of lerp because of two things 1/ using delta time x movement time (instead of t = [0..1]) can be > 1, and 2/ because the new value of A is used back in the next iteration, so this will never converge i.e. for camera transform.position = lerp(transform.position, traget_position, dt * K) your camera never halt moving since, let suppose dt * K is constant 0.5, and initial distance is 1 unit, you'll move of 0.5 at initial step then moving of 0.5 of the 0.5 for the second iteration, then 0.5 of 0.5*0.5 for the third etc ...
We'll get down to Planck length eventually, it's anyone's guess at that point :)
@@apasserby9183 yep definitely not the good algorithm for modeling the Universe lol