Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-213] Rotation -X and Rotation -Z are changed from 0 to 180 degree while changing value of Rotation -Y property #3276

Closed
2 tasks
sl-service-account opened this issue Sep 26, 2012 · 4 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Sep 26, 2012

Steps to Reproduce

  1. Login to Viewer and create new object.
  2. Switch to 'Object' tab and specify Rotation -Y as 180 degree.
  3. Observe other properties in Rotation section

Actual Behavior

Rotation -X and Rotation -Z are changed from 0 to 180 degree

Expected Behavior

Rotation -X and Rotation -Z are not changed

Other information

Links

Duplicates

Original Jira Fields
Field Value
Issue BUG-213
Summary Rotation -X and Rotation -Z are changed from 0 to 180 degree while changing value of Rotation -Y property
Type Bug
Priority Unset
Status Closed
Resolution Expected Behavior
Reporter Agolovan ProductEngine (agolovan.productengine)
Created at 2012-09-26T19:59:27Z
Updated at 2019-02-11T17:23:03Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2012-09-27T06:01:47.976-0500',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'Rotation -X and Rotation -Z are changed from 0 to 180 degree',
  'What were you doing when it happened?': "1. Login to Viewer and create new object.\r\n2. Switch to 'Object' tab and specify Rotation -Y as 180 degree.\r\n3. Observe other properties in Rotation section",
  'What were you expecting to happen instead?': 'Rotation -X and Rotation -Z are not changed',
}
@sl-service-account
Copy link
Author

Moon Metty commented at 2012-09-27T11:01:48Z

Hi Agolovan,

Of all things broken with the numeric rotation fields, the <180, 0, 180> angle is actually the correct behaviour.
The Y-axis is subject to gimbal lock, and should only accept values in the range [-90, 90].
Ok, the viewer stubbornly wants to use values in the range [0, 360], so the range for Y-rotation works out as [270, 360] & [0, 90].
To illustrate, add this script to a box:

default
{
    state_entry()
    {
        llSetColor(<0, 0, 1>, 0);
        llSetColor(<0, 1, 0>, 1);
        llSetColor(<1, 0, 0>, 2);
        llSetColor(<1, 0, 1>, 3);
        llSetColor(<0, 1, 1>, 4);
        llSetColor(<1, 1, 0>, 5);
        llSetTexture("5748decc-f629-461c-9a36-a35a221fe21f", ALL_SIDES);
    }

    touch_start(integer total_number)
    {
        llSetRot(ZERO_ROTATION);
    }
}

Before each test, touch the box to reset the rotation, and check if the viewer has actually set all rotation fields to zero.

=======

  1. Type 135 in the Y-rotation field, commit by clicking one of the size-fields.
    Observe: Rotation is <180, 45, 180>, this is correct.

  2. Type -135 in the Y-rotation field, commit by clicking one of the size-fields.
    Observe: Rotation is <180, 315, 180>, this is not pretty, but correct.

  3. Type 135 in the Y-rotation field, commit by pressing ENTER.
    Observe: Rotation is <180, 135, 180>, incorrect. The Y-field wasn't updated to 45.

  4. Type 135 in the Y-rotation field, commit by clicking the X-rotation field.
    Observe: Rotation is <0, 45, 180>, incorrect. The X-field wasn't updated to 180.

  5. Type 135 in the Y-rotation field, commit by clicking the Z-rotation field.
    Observe: Rotation is <180, 45, 0>, incorrect. The Z-field wasn't updated to 180.

  6. Type 135 in the Y-rotation field, commit by pressing ENTER.

  • Try to adjust the Y-rotation by scrolling the mousewheel on the Y-field.
    Observe: The object's rotation goes crazy, like in VWR-28914.
  1. Type 45 in the X-rotation field, commit by pressing enter.
  • Right-click touch the object, to reset the rotation by script.
    Observe: The X-field still says 45.
  • Type 45 in the Z-rotation field, commit by clicking the X-rotation field.
    Observe: The X-field still says 45.
  • Try to adjust the X-rotation by scrolling the mousewheel on the X-field.
    Observe: The box' orientation suddenly snaps to the rotation as seen in the viewer's edit tools.
  1. ...

=======

There's an attempt to figure things out over here: http://wiki.secondlife.com/wiki/Talk:Rotation
But few people ever reach that page. And now this jira is also hidden from public view.
Personally, I think the code has to be rewritten, after establishing the desired behaviour.
Another complication is the accuracy of the viewer's rotation math, see VWR-2567 and possibly other issues.

@sl-service-account
Copy link
Author

Grumpity ProductEngine commented at 2012-10-03T18:42:42Z

Stinson says:
the server only stores the rotation as a quaternion whereas the edit panel shows the euler rotations. Even in a 3.3.4 incrementing the Y-axis past 90 causes strange behavior.
The actual conversion between quaternion and euler has not changed in the 3.4.0 viewer. But some stuff around object updates did.

will dig in.

@sl-service-account
Copy link
Author

Moon Metty commented at 2012-10-03T19:10:25Z

Thanks for the update Grumpity,

Note that most of these problems already existed in 1.23.5

@sl-service-account
Copy link
Author

Kyle Linden commented at 2019-02-11T17:19:25Z

Updating to expected behavior for posterity. These observations in the object edit menu are due to gimbal lock.

https://en.wikipedia.org/wiki/Gimbal_lock

For help with scripting under these conditions please check out our forums for further assistance.
Here are some pointers:
https://community.secondlife.com/forums/topic/409181-help-with-two-axis-rotation-problem-before-i-go-insane/
https://community.secondlife.com/forums/topic/358093-understanding-rotations-any-info-for-non-physicists/
https://community.secondlife.com/forums/topic/64551-rotations-huh/

Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant