The while loop is not the problem. If it was the problem then I wouldn’t be making this post as I don’t use while loops.
The documentation says it is equivalent to PreRender, and I also have tried to use a BindToRenderStep as that is what I use in my game and the same problem still occurs.
I always do this:
math.min(1, dt * 24)
This ensures there won’t be an overshoot.
1 Like
This is still kind of a clamp but it is a faster way to clamp the number to 1, if I can’t find a solution I will just stick to using this.
Clamping the alpha between 0-1 is part of the fix, but you’re missing the other part. The issue is that your start value is continuously changing as you progress through the lerp because you’re using the previous lerp product which is now the part’s size. Instead the start and goal should remain constant and all you need to do is cache the start and goal values when you want to begin the animation like so:
local RunService = game:GetService("RunService")
local Example1 = workspace:WaitForChild("Part")
local Start, Goal = Example1.Size, Vector3.one
RunService.RenderStepped:Connect(function(delta)
Example1.Size = Start:Lerp(Goal, math.clamp((0.25 * delta * 60), 0, 1))
end)
while true do
Goal = (Vector3.one * 0.5)
task.wait(2)
Goal = (Vector3.one * 2)
task.wait(2)
end
1 Like
Not sure if this would work, as it would keep trying to lerp from the cached size instead of the current size causing stutters and other problems.
The problem here is that you’re binding interpolation alpha variable to the delta time which will inherently cause to produce large numbers when the time between frames is bigger (1/10 seconds), while is smaller on (1/60) seconds.
1 Like
How could I solve this then so it doesn’t overshoot and cause problems? I have had an endless supply of issues with lerping and I have no idea where to start.
Here you don’t need delta time since there’s no moving variable over time (like a camera sway that uses sine with time and with higher framerates moves faster) .
The thing is this is the entire point of the post is to solve issues relating to high and low framerates, as the video shows the framerate going below 20 and the cube warping out of space and time due to the overshoot. I want to apply this knowledge to fix the other lerps in my game and to keep this knowledge for the future.
Do you need it to work dynamically so the start changes when the scale of the part does? What other code is trying to, or being planned to change the part’s size while this code does as well?
Also the jitter probably coming from changes in the framerate affecting the delta, this isn’t a problem if the framerate is consistent despite being 240fps or 30fps. What’s causing the framerate to fluctuate so much?
Well, my point is that you don’t need to use delta time as a multiplier in the alpha from the lerp since that would make it dependent to the framerate spikes.
I am setting the framerate to a low value to showcase how it overshoots when the framerate is low enough.
This could cause problems as say a Player has a big stutter, the lerp then overshoots and causes visual problems with say a viewmodel sway.
I want to make sure that no matter the framerate everything happens correctly and is all working visually.
This would likely work in this example, however in most instances clamping the deltaTime would cause issues.
If I don’t use delta then the cube would change size either way too fast, or way too slow as you can see in the examples below. And I do not want to use Tween as the scale would be changing constantly.
240 FPS
10 FPS
you don’t clamp delta time but lerp value
You can use the following formula to exponentially decrease as the delta time grows
(1 - f^delta)
where f is the constant speed you want. If the delta increases as 2, it would multiply f by f, if it’s a decimal it would mean you’re decreasing it. If the delta is also a decimal, it would produce the root of the number and produce a bigger number. (Like 0.5 ^ 0.5 which equals ~0.707)
I saw this solution on another post, but the explanation there looks overcomplicated. Can’t link it since I’m on mobile and I don’t know how to.
1 Like
Expanding upon this is a video that shows pretty much what you want @PainfulZachZero (I think it’s linked to what you are saying @gato_todomenso): https://youtu.be/LSNQuFEDOyQ?si=sDmBnn0XBuVDkp6z
Check out timestamps 38:32 and 49:38 for the highlights, but also skim through the rest of the video (or watch the whole thing, up to you).
2 Likes
Not sure if you got the solution from here but this does kind of work but I have to divide the constant by a really high number for it to have the same result as the original post. If you know a way to keep the same result that would be nice.
This works beautifully, amazing video and I will be watching the whole thing to understand this better.
Thank you for your help everyone!
The answers and questions in the pinned comment lists my exact issue of the post too which is nice, pretty much exactly what I was talking about the overshooting.
1 Like