Bug In Code Lecture 28_FB_UY3

I had to take a moment to test and double check but I did find a weird problem with the lecturers code.

If the starting Z-position of the oscillating object is 0 the function works fine.

However if the starting Z is NOT zero then the target position goes off.

Starting Z value at Zero line drawn from Start to “movementVector”

Starting Z value et -10 and line drawn from Start to “movementVector”

Here the code used in these examples

public class Oscillator : MonoBehaviour
{
    Vector3 startingPosition;
    [SerializeField] Vector3 movementVector;
    float movementFactor;
    [SerializeField] float period = 2f;
    
    private void Start() {
        startingPosition = transform.position;
    }
    void Update()
    {
        float cycles = Time.time / period;  // continually growing over time
        
        const float tau = Mathf.PI * 2;  // constant value of 6.283
        float rawSinWave = Mathf.Sin(cycles * tau);  // going from -1 to 1

        movementFactor = (rawSinWave + 1f) / 2f;   // recalculated to go from 0 to 1 so its cleaner
        
        Vector3 offset = movementVector * movementFactor;
        transform.position = startingPosition + offset;
    }
        private void OnDrawGizmos()
        {
        Gizmos.DrawLine(startingPosition, movementVector);
        }
}

Does anyone know what could be causing this? For some reason X and Y values don’t effect the behavior. This Sphere I used for testing is not parented to anything it’s an empty primitive for testing.

For some reason this only happens with the startingPosition Z value and nothing else (so far)

I’ve done some further testing and It would seem that the Z position is added to the movementVector position for some reason.

If startingPosition Z = 10
and movementVector Z = 0

So if Start is 0,0,10
and target is 10,0,0

Then the object will oscillate to 10,0,10 instead of 10,0,0 which it should. I’ll continue testing this for a while if I can figure out a fix… :smiley:

image
Atleast my diagnosis was true

I logged the offset as well and it has a Z of Zero so it can’t be the offset value which gives Z it’s start value.

image

I have no idea what is causing this. :smiley:

Hi,

Good job on analysing the problem. :slight_smile:

I’m not sure what bug you identified because what you describe sounds like the correct behaviour. We make a game object oscillate between two points/coordinates. A point consists of three floats, which means that our x-values “oscillate” between the two predefined x-values, our y-values “oscillate” between the two predefined y-values, and our z-values “oscillate” between the two predefined z-values.

In your screenshot, the y-axis is the axis which points into the screen.

The behavior is most certanly not correct. Atleast this code is not usable outside of Z=0 as the behavior in unpreditacle.

What should happen or what should be the case is that the object move

between PosA and PosB

Not between

PosA and PosB + PosA.Z

This Gif for example the start pos is at Y = -7 and target position is Y = 7 and the oscillation starts at the starting position but the target posititions Z = TargetZ + startZ when is should just be TargetZ. The Sphere should go directly up and back down, not toward the camera.

Z_problem

This doesn’t happen if you start all oscillating objects at Z = 0 but this code can’t be reused this way in any game or level that doesnt’ happen on the Z axis.

And I can’t figure out what causes this. Reminder, this behavior is in the lecturers code.

This could be fixed by lerping the positions instead of adding positions.

AAAAAND I finally figured out the “problem”.

The movement vector can’t be used with an absolute position in the world as the target point it can only be used as a local offset to the object that you are attempting to oscillate.

If you input a “target” position then the code doesn’t work.

So I guess technically this perhaps isn’t a bug after it’s just a limitation of the implementation that you have to calculate the difference between to positions and not set a position.

I was perhaps confused since I’ve done similar things like this with Vector3.Lerp which takes in a position in the world so I was attempting to use this in a similar way.

I’m glad you figured the problem out yourself. :slight_smile:

We do use the lerp function in this code but it is a bit difficult to see because of the names and because movementVector is the distance between the startingPosition and the “targetPosition”. (startingPosition + 1 * movementVector) is the “targetPosition”.

Rick’s code is not the only way to implement this concept. Feel free to rewrite your code.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms