1
\$\begingroup\$

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.

enter image description here

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?

\$\endgroup\$
  • \$\begingroup\$ Note that the orientation of the transform gizmo will vary based on your Transform Gizmo Toggles in the Editor Toolbar - in Local mode it will reflect the selected object's local transform. In Global mode it will stay aligned to the world coordinate system. Can you confirm which mode you have your editor in? Screenshots can often help in diagnosing geometric problems like this. \$\endgroup\$ – DMGregory Nov 16 '17 at 22:24
  • \$\begingroup\$ I'd rather not paste the scripts. The structure is as follows - the parent is an empty, there is a child object with a mesh that gets rotated in 90 degree steps, inside that script I have Debug.LogError(obj.transform.up); This gives a different result than expected. So I then did a track script that just copies the transform value of this object. the script is attached to an object that is child to the parent empty. In the script aside from copying transform, it also has Debug.LogError(transform.up); which does give expected results \$\endgroup\$ – confuzzled Nov 16 '17 at 22:25
  • \$\begingroup\$ It was definitely in local mode, first thing I checked. I also experimented with various things to see if I could get any clue, even things I was sure would be pointless. TransformDirection, InverseTransformDirection, vector3.up, all sorts of faffing about. \$\endgroup\$ – confuzzled Nov 16 '17 at 22:28
  • \$\begingroup\$ I'll see In a second. I tried adding a script to the empty objects I used as track points, these track points were set as children to the mesh object and its these transforms that are copied. The script I attached simply had called Debug.LogError(transform.up); in update. This output matches the output of the tracking object, but differs from the script attached to the rotating mesh object. I find it peculiar, shouldn't they be referencing the same block of heap allocated memory? Why is transform.up different from referenceobj.transform.up \$\endgroup\$ – confuzzled Nov 16 '17 at 22:35
1
\$\begingroup\$

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.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Commenting to help you remember :) \$\endgroup\$ – Stephan Nov 17 '17 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.