koobas.hobune.stream
LERP operations on Transforms
I'm wondering if there was a reason LERP functions (on transform "local" values) were not included in the Transform class? Is extending the Transform class like below a bad idea for some reason? Am I missing some built in functionality that eliminates the need for this? (I read all about Transform class in the docs, but worry I just missed it)
The goal is simply to enhance clarity/readability and to reduce redundant code.
If not a bad idea, well, feel free to use it, and any suggestions on improving it are welcome.
Edit: as suggested by Eric, I have change the parameter names from "speed" to "t" (same name as Vectopr3.Lerp parameter)
Edit: As suggest by Bonfireboy, I am renaming the functions to "LerpTowards" make it clear that they are NOT as generalized as the Vector3 LERP.
public static class TransformOperations
{
public static void LerpTowardsRotation(this Transform transform,Quaternion final_rot,float t)
{
Quaternion current_rot=transform.localRotation;
Quaternion set_rot=Quaternion.Lerp(current_rot,final_rot,t);
transform.localRotation=set_rot;
}
public static void LerpTowardsPosition(this Transform transform,Vector3 final_pos,float t)
{
Vector3 current_pos=transform.localPosition;
Vector3 set_pos=Vector3.Lerp(current_pos,final_pos,t);
transform.localPosition=set_pos;
}
public static void LerpTowardsScale(this Transform transform,Vector3 final_scale,float t)
{
Vector3 current_scale=transform.localScale;
Vector3 set_scale=Vector3.Lerp(current_scale,final_scale,t);
transform.localScale=set_scale;
}
}
usage:
instead of this:
rotationAxis.transform.localRotation= Quaternion.Lerp( rotationAxis.transform.localRotation,some_quaternion,0.5f);
we can now write this:
rotationAxis.transform.LerpTowardsRotation(some_quaternion,0.5f);
The goal is simply to enhance clarity/readability and to reduce redundant code.
If your goal was to make Lerp easier, you have achieved the opposite :)
If your goal was to make Lerp easier
Guess that depends on what you mean by easier. I only intended it be faster to type and easier to read. Ins$$anonymous$$d of a=foo(a) we now can say a.foo()
Foo() just HAPPENS to be LERP functions here. (cuz' I use them on transforms a lot)
That's not how lerp is meant to be used; lerp is short for "linear interpolation", which your code does not do. See here. The third parameter isn't "speed", it's just a percentage between 0.0 and 1.0.
good point, on speed. I'll change the parameter's name to "fraction" or "t" like in the docs for Vector3.Lerp().
But what do you mean, the code is NOT actually doing LERP? I'm directly calling built-in Vector3 and Quaternion LERP functions on the transform's local values; how can THAT not be doing LERP?
of course! but it was talking about the t parameter and how it relate to time.delta time and lerp. I understand all that and agree with that part of your answer (which is just a parameter name change). [note: the usage section is just a simple sample of how to use the code I'm asking about, which is above that]
which your code does not do
Perhaps I misunderstood: I thought you were ALSO saying that my code is not perfor$$anonymous$$g lerp operations. If that IS what you meant, please explain.
Your code isn't linearly interpolating over time. It's taking a position, perfor$$anonymous$$g a lerp operation, then plugging the new position into Lerp, repeat. This results in the "slowdown" effect as discussed in the link, so it's not linear and is only useful in limited cases. In order to lerp properly you need to keep the start and end positions the same while advancing the third parameter from 0 to 1. You'd be better off using Vector3.$$anonymous$$oveTowards.
There's nothing inherently wrong with Lerping a transform between its current position and another position. Yes, if t != 1 then it'll never reach the destination, but that could be desired behaviour and seems like a red herring to me.
@Glurth The point is that there's nothing wrong with your extension methods, but that interpolating a position between itself and a destination is a specialised use. It's the first argument to the standard Lerp that's the issue here. Generally speaking, it has to be possible for the two position arguments to both be different to the current position. I think that's the answer to your question (why your extensions aren't provided for you). If you're doing a lot of interpolating from current position then you might find the extensions useful. But personally I would find it clearer not to use them; at the very least I would call them something like "LerpTowards" to try to make it clearer that they only provide an alternative to a specific use of the more general Lerp function.
