koobas.hobune.stream
No Movement when Attempting to Lerp through an array
Hello Again, Thought I could work through this one on my own but I guess not.
I have a collection of game objects that when triggered should lerp to a new position. Each target position is an empty game object stored as a child of the object that will be moving for easy access.
void Update(){
// global event is triggered
if (explode)
{
// get the blocks that should move
GameObject[] blocks = GameObject.FindGameObjectsWithTag("b1");
// get the starting position of each block
foreach (GameObject block in blocks)
{
Transform t = block.transform;
// add starting transform to List<Transform> origins
origins.Add(t);
//get ending position if any from gameobject nested under this
if (block.GetComponentInChildren<Transform>() != null)
{
Transform t2 = block.GetComponentInChildren<Transform>();
//add ending transform to List<Transform> targets
targets.Add(t2);
}
}
//loop through blocks[] and move each from its origin location to its target location
for (int i = 0; i < blocks.Length; i++)
{
blocks[i].transform.position = Vector3.Lerp(origins[i].position, targets[i].position, Time.deltaTime);
}
//Prevent from future loops
explode = false;
}
}
Whats happening is that it loops through the discovery phase each frame finding blocks, origins, and targets, but doesnt move anything and doesnt stop looping.
been at the for hours and don't know where i'm stuck :(
My opening observation is not directly about your question, but I assume you know that both arrays "origins" and "targets" could end up out of alignment if the return from getting the transform from a child returns null. If you have a guarantee, you'd not actually need to test for null (and I'm not saying you shouldn't test for null, you should). Maybe you should 'sense' if this alignment is invalid and abandon the operation and log an error.
That said, after you get through debugging and this works, you may do well to consider retaining origins and targets, because forming them anew every time is probably not necessary (though I don't know your construction, maybe that does change during runtime).
That's not the problem. Your puzzle is solved simply, but first I must assume the two arrays are in alignment, and that for any 'i', targets and origins are not the same vector3 values.
The problem is the use of Time.deltaTime. If Update fires at the refresh rate of the device, and assuming that's 60 fps and is fairly steady, then Time.deltaTime will always be .0166667 seconds, at every update. Time.deltaTime would differ only if the frame rate isn't steady, but even in that case it shouldn't vary by much (unless something is wrong or you're debugging). If, say, the rate slowed to 30 fps occasionally, Time.deltaTime might reach 0.3333, but then if the next frame returns to the rate of 60 fps, Time.deltaTime will return to .0166667.
For a slerp or lerp (and several similar functions), the third parameter is expected to transit between 0 and 1.0. When 0 is provided, the result will be the first vector provided, when 1.0 the result will be the second vector provided, and all values between are interpolations of a vector (point) between the first and second, as a ratio expressed in the third parameter. Since that value in your code, as posted, is probably never changing, nothing will ever change the result (except for what might look like some small jitter if the frame rate isn't constant).
The solution is simple. Establish a float that counts elapsed time. Start it at zero. Increment this float by Time.deltaTime just before using that float as the third parameter to a lerp or slerp, so it can accumulate over time, and move from 0 to 1.0.
You should clamp the value to 1.0 for the parameter to lerp (there isn't much of a meaning to a lerp where this parameter exceeds 1.0). When it reaches 1.0, all of the transitions from 'origins' to 'targets' is completed, and this should stop the motion (or reset it to proceed to some next step).
Hello JVene, Thank you for such a detailed response.
yes, there is the possibility of misalignment in this script but i've mitigated that in the scene so no issues there.
while I appreciate your detailed explanation of the Time.deltaTime function I don't think thats the issue. I just created a version of this function using the exact same language but ins$$anonymous$$d of getting the target position from a transform that is a child of the moving object i manually entered in the location and it works perfectly.
That leads me to believe there is a logic loop within the parent child relationship of the scene structure. it seems like it should work since the values of origin and target are defined and stored in a List prior to any movement but that's what i'm able to figure out.
going to begin exploring other ways of storing and accessing target vectors rather than nesting it as a child of the moving object unless anyone has any other ideas.
thanks!
Your point doesn't quite explain the reason for a lerp in the first place. I submit there is no reason for a lerp, since the value given to lerp is always the same (under stable frame rate conditions), and is so low a value as to be nearly always the origins[i].position. targets[i].position has almost no influence in that code. This means there must be something happening to origins[i].position in order for anything to move, and that's the motion you're getting from the lerp (almost without regard to targets[i].position). Put another way, you should hardly see a difference in results if you replaced the lerp with something like:
blocks[i].transform.position = origins[i].position;
Or something effectively similar.
OK solved it. IT's what I though. By getting the target location from a child it was creating a logic loop where nothing was happening.
Moved all the target transforms to another GO parent and it worked.
That was something only you could see, nothing about that structure issue was visible out here. Glad it worked out.
