Why is there a discrepancy between these two transform.up vectors?

Question

I was trying to implement a feature which required transform.up, the result didn't match the green axis gizmo displayed in the editor so I assumed it was being put off by the rotation of the object despite expecting the gizmo to adapt to that. I then modified the prefab such that everything was now child to an empty object and the secondary objects were child to that instead of the rotating model, and wrote a script that simply copies the transform so that it tracks. This still didn't show the values expected from what the gizmo in the editor showed. I then did a Debug.LogError in the track script and this time the result was as expected.

Why is transform.up showing the value expected from the local y-axis gizmo but when passing a reference to the original script and checking tracked.transform.up gives off results?

---

To reproduce in a simpler environment I set up a simple test scene.

Simple default cube with the hierarchy structure shown in the screenshot. The transform values are as follows:

parent zeroed
x:0, y:-90, z:0 for cube
x:0, y:-90, z:90 for TrackPoint

Scripts are as follows:

test.cs - attached to trackpoint

private void Update()
{
    Debug.LogError(transform.up);
}

Track.cs - attached to tracker

public Transform transformToTrack;

private void Update()
{
    transform.position = transformToTrack.position;
    transform.rotation = transformToTrack.rotation;
    Debug.LogError(transform.up);
}

byref.cs - attached to cube

public GameObject refObj;

private void Update()
{
    Debug.LogError(refObj.transform.up);
}

When run, if you clear the console then click pause you'll see that one of them differs from the others. I don't understand why. My project and this sample scene differ in which it is that is giving unexpected results but the results are inconsistent with what I would expect.

But wouldn't they all give the same result?

Answer 1

I called the method that ran the Debug.LogError(obj.transform.up); inside a coroutine, the coroutine essentially had an off by one error and given that the object was moving in 90 degree steps and I didn't see the data transforming I didn't realize my mistake.

My effort to reproduce accidentally had the test script attached to the wrong object giving its actual transform, which is why I mistakenly thought the resulting data backed my error up. I shouldn't work when tired.

In the end I realized my error when I discovered my reproduction was misguided and I changed the Debug.LogError into the Update callback, allowing me to see the data transform, recognise that it was essentially an off by 1 error and fix the call so that it was no longer off by 1 move. This gave the expected results.

Perhaps if you experience a similar problem you should check for race conditions and/or off by one errors.

You should try to see your data as it transforms, could give valuable insight into the problem.