This video is a deep-dive into the lerp function, and how it is often mis-used for smoothing in games. Basically, many developers try to smooth out some movement over time by naively calling the...
This video is a deep-dive into the lerp function, and how it is often mis-used for smoothing in games.
Basically, many developers try to smooth out some movement over time by naively calling the lerp function in the form of position = Lerp(start, end, dt) where dt is some small number, or perhaps the deltaTime of the frame. However, this results in framerate-dependant behavior. The actual behavior can vary greatly depending on your user's framerate.
Freya then steps through the math of why this occurs, and demonstrates a better way to achieve the same type of smoothing using a framerate-independant method.
It's a cool talk. I've been develping games for decades and I learned something from it.
Following up on https://tildes.net/~comp/1gpy/lerp_smoothing_is_broken#comment-cw3u after watching the video. Oops!! This is not what the video is about, but it is an interesting video. I think...
Oops!! This is not what the video is about, but it is an interesting video.
I think the use of lerp at all in the video title is a bit misleading - although it is not inaccurate - since it's really about a particularly simple control system often used in graphics. You want a value to follow an arbitrary target, but you don't want to implement a full PID controller and you don't want the result to be terribly jittery. Say you're making a camera follow the player. A common pattern is, on every frame, move the value X% closer to the target. This can be expressed with lerp but I don' think it's fair to say it islerp, which is what the title in isolation seems to imply.
The issue, as discussed, is that it's framerate dependant. You do some math and find it's really equivalent to exponential decay, which is continuous, then you use that continuous formula to create a framerate independant formula. A wonderful talk on recursion, calculus, and extension! But not quite what I thought it would be from the title and your description here.
https://www.gafferongames.com/post/fix_your_timestep/ In my projects I use a variant of that "accumulator" implementation. I'm unable to watch the video yet, but I've added it to watch later - I'm...
There's an article I read a while ago about the same issue:
In my projects I use a variant of that "accumulator" implementation.
I'm unable to watch the video yet, but I've added it to watch later - I'm curious if she arrives at a similar implementation or discusses some other strategies. I still don't really know how to parallelize things so I'm eager to learn more.
Edit: I misunderstood what the topic of the video would be. See my other comment.
This video is a deep-dive into the lerp function, and how it is often mis-used for smoothing in games.
Basically, many developers try to smooth out some movement over time by naively calling the lerp function in the form of
position = Lerp(start, end, dt)wheredtis some small number, or perhaps the deltaTime of the frame. However, this results in framerate-dependant behavior. The actual behavior can vary greatly depending on your user's framerate.Freya then steps through the math of why this occurs, and demonstrates a better way to achieve the same type of smoothing using a framerate-independant method.
It's a cool talk. I've been develping games for decades and I learned something from it.
Following up on https://tildes.net/~comp/1gpy/lerp_smoothing_is_broken#comment-cw3u after watching the video.
Oops!! This is not what the video is about, but it is an interesting video.
I think the use of
lerpat all in the video title is a bit misleading - although it is not inaccurate - since it's really about a particularly simple control system often used in graphics. You want a value to follow an arbitrary target, but you don't want to implement a full PID controller and you don't want the result to be terribly jittery. Say you're making a camera follow the player. A common pattern is, on every frame, move the value X% closer to the target. This can be expressed withlerpbut I don' think it's fair to say it islerp, which is what the title in isolation seems to imply.The issue, as discussed, is that it's framerate dependant. You do some math and find it's really equivalent to exponential decay, which is continuous, then you use that continuous formula to create a framerate independant formula. A wonderful talk on recursion, calculus, and extension! But not quite what I thought it would be from the title and your description here.
There's an article I read a while ago about the same issue:https://www.gafferongames.com/post/fix_your_timestep/
In my projects I use a variant of that "accumulator" implementation.
I'm unable to watch the video yet, but I've added it to watch later - I'm curious if she arrives at a similar implementation or discusses some other strategies. I still don't really know how to parallelize things so I'm eager to learn more.
Edit: I misunderstood what the topic of the video would be. See my other comment.