1

I have a question about Lerp. So I know that lerp helps you to move your object like:

void update(){
transform.position = vector3.lerp(start.position,end.position, (Time.time / 1000));
}

this will get your object to your endposition. But if you have this code:

void Update(){

    transform.position = Vector3.Lerp(transform.position,
                                      destination.position,
                                      speed * 3.0f * Time.deltaTime);
}

How is it possible that your object arrives at your destination, the 3th parameter of lerp has to reaches slowly 1 so your objects arrives at your destination. But "speed" , "3.0" , "Time.deltaTime" will always be the same, so how is it possible that your object arrives at your destination?

So the big question: Is it possible to do the lerp with some variables, which have always the same value and with Time.deltaTime?

Now, because of the different comments etc. I don't know exactly how lerp works, i have to possibilities:

1.) First i thought it works like this:

Vector3.lerp(a,b,c) The c value has to change every frame to move the object. If the c value is 0.2 your object will moved 20% of the way and if the c value doesn't change the object will always be on 20% of the way. So the get the object moved fluently your c value have to change every frame a little so you c value will go from 0 to 1 and so is your object going from start to destination.

Or is it like this

2.) Because of several comments i thought lerp works like this

Like the comments say, the c value doesn't have to change the value, becaue if you have c = 0.2 you will pass 20% of the way and the next frame, if c is still 0.2 you will pass 20% of the remaining way and so on.

So is it lerp working like 1(you have to change c) or is it working like 2(you don't have to change c)

Gmunderos7
  • 11
  • 1
  • 1
  • 6
  • please make sure you properly format your code by highlighting it and pressing the `{ }` button, I have fixed it for you. – Scott Chamberlain May 01 '17 at 14:37
  • Also, you might be interested in [Zeno's dichotomy paradox](https://en.wikipedia.org/wiki/Zeno%27s_paradoxes#Dichotomy_paradox) – Scott Chamberlain May 01 '17 at 14:39
  • Possible duplicate of [Vector3.Lerp is not working](http://stackoverflow.com/questions/42611960/vector3-lerp-is-not-working) – Galandil May 01 '17 at 15:02
  • Sorry for the codeproblems. I know how i can use lerp, but i want to know if i can use variables, which have always the same value and with Time.deltaTime and if yes how? – Gmunderos7 May 01 '17 at 17:28
  • Zeno's dichotomy paradox is very interessting, but I don't know if it helps in this case. – Gmunderos7 May 01 '17 at 17:39
  • 1
    It's not that it helps, it is the situation you are in. Lets say `speed * 3.0f * Time.deltaTime` evaluates to `0.75` that means you will go 75% of the way each frame. The first frame you go 75%, the next frame you go 75% of the remainder of that, the next frame you go 75% of the remainder of that (that is Zeno's paradox, you never get there, you only go 75% of the way), this keeps repeating till the 75% increase is smaller than the smallest change a `float` can change by. – Scott Chamberlain May 01 '17 at 18:17
  • Ah okey I understand and i can arrive at the target because in this case a infinitely amount of additions returns a finally value? And this is also the reason why the object will get slower and slower if is use the 3th parameter like this okey :) – Gmunderos7 May 01 '17 at 20:22

5 Answers5

7

The distance between your transform position and the destination is an exponential decay. The distance shrinks by (1 - speed) every frame (given that speed is less than 1). Say your game is supposed to run at 60FPS. If for whatever reason the frame rate drops to 30FPS, the deltaTime is gonna be twice as big and you’re supposed to execute the Lerp 2 times. In such case, the distance will shrink by (1 - speed) then (1 - speed) again yielding a result of (1 - speed)^2 shrinkage. From this, you can generalize that the shrink amount of the distance is (1 - speed) ^ (deltaTime / baseDeltaTime) with baseDeltaTime being the deltaTime the game is supposed to run at i.e. 1/60 (for 60FPS). To put in code:

transform.position = Vector3.Lerp(transform.position, destination.position, 1 - Mathf.Pow(1 - speed * 3.0f, Time.deltaTime * 60));
Jack Le
  • 311
  • 4
  • 8
1

The object reaches the goal because your start position is the current position, and after lerping, you set the position of the object to the resulting position of Lerp. If you change your starting position to a normal Vector3 it would Lerp to "speed * Time.deltaTime * 3f"

1

I guess you didn't understand that how lerp works in unity. I will recommend you this Article of Robbert How to Lerp like a pro.

I see this sort of thing far too often:

transform.position = Vector3.Lerp(startPos, endPos, Time.deltaTime);

The person posting it is usually convinced that Vector3.Lerp is “broken”, but the real problem is that they’re not using it correctly.

Lerp, short for “linear interpolation” does one very simple thing: given two values, x and y, it returns a value that is t percent between them. If you expect the output to change, the arguments you pass in need to reflect that!

In the example above, it doesn’t make sense to just pass in Time.deltaTime, because that’s only the time that passed during the most recent frame. If your game is running at a constant 50fps, that’s always going to be 0.02.

Community
  • 1
  • 1
Muhammad Faizan Khan
  • 10,013
  • 18
  • 97
  • 186
  • Yes, i thought it works a little bit different, but if the 3th value is 0.02, than i will pass 2% of the way and the next frame 2% of the remaining way an so on, so the target will be reached slowly is this correct? – Gmunderos7 May 02 '17 at 12:40
  • yes, it should be work like that. The least amount you will provide, the slower it will work – Muhammad Faizan Khan May 03 '17 at 04:36
  • Okei, so the 3th value doesn't have to change, it can always be the same value and lerp will work? – Gmunderos7 May 03 '17 at 12:08
  • no 3 value can be change and it will work also. no matter it remain same or frequently change, it will work. but if you will change the 3 value frequently then it should not be smooth – Muhammad Faizan Khan May 03 '17 at 12:29
  • you can test it your self, take to cubes and apply this with public variable – Muhammad Faizan Khan May 03 '17 at 12:29
  • Yes, that was what i mean, i can change the 3th value(if i do it right thats how the object wob't slows down) but i don't have to(so the object will slow down) thank you:) – Gmunderos7 May 03 '17 at 14:10
0
myLocation = Mathf.Lerp(myLocation, myDestination, 0.02)

If you are storing the return of the Lerp function into a variable and then also using that same variable as the minimum value in that same Lerp function, then the min value is getting bigger and bigger everytime the function is called.

So, even though you're not changing T, you're changing the starting value and thus, the stored value gets closer and closer to the max value.

It will accelerate very quickly initially and then slow down the closer it gets to the max value. Also, the max value will either never be reached or take an extremely long time.

ItsPete
  • 2,363
  • 3
  • 27
  • 35
Simon Borg
  • 31
  • 4
0

(See https://gamedev.stackexchange.com/questions/149103/why-use-time-deltatime-in-lerping-functions)

There are two common ways to use Lerp:

1. Linear blending between a start and an end

progress = Mathf.Clamp01(progress + speedPerTick);
current = Mathf.Lerp(start, end, progress);

2. Exponential ease toward a target

current = Mathf.Lerp(current, target, sharpnessPerTick);

Note that in this version the current value appears as both the output and an input. It displaces the start variable, so we're always starting from wherever we moved to on the last update. This is what gives this version of Lerp a memory from one frame to the next. From this moving starting point, we then then move a fraction of the distance toward the target dictated by a sharpness parameter.

This parameter isn't quite a "speed" anymore, because we approach the target in a Zeno-like fashion. If sharpnessPerTick were 0.5, then on the first update we'd move halfway to our goal. Then on the next update we'd move half the remaining distance (so a quarter of our initial distance). Then on the next we'd move half again...

This gives an "exponential ease-out" where the movement is fast when far from the target and gradually slows down as it approaches asymptotically (though with infinite-precision numbers it will never reach it in any finite number of updates - for our purposes it gets close enough). It's great for chasing a moving target value, or smoothing a noisy input using an "exponential moving average," usually using a very small sharpnessPerTick parameter like 0.1 or smaller.

Petr Varyagin
  • 287
  • 3
  • 6