Uploaded image for project: 'Snowstorm'
  1. Snowstorm
  2. STORM-2078

Editing an objects rotation with the rotation rings often causes the object to jump to position <0,0,0> on the region and rotation changes to <0,0,0>

    Details

    • Type: Defect
    • Status: Closed
    • Priority: Major
    • Resolution: Released
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Description

      Steps To Reproduce

      REPRO 1

      • Rez a prim (default cube or sphere will do - video shows sphere but cube reproduces just as easily)
      • Sit on the prim
      • Right click -> Edit the prim
      • Under object tab set Z rotation to 270 by typing 270 into the text box and hitting Enter key.
      • Change edit mode to rotation so you see the rotation rings
      • Make small rotation edits using the rotation rings but keep the Z rotation fairly close to 270, for example 268-270.
      • If the bug does not reproduce, close the edit floater and edit on the prim again, change to rotation mode and repeat.

      NOTE: Bug also reproduces when the X or Y rotation is close to 270

      REPRO 2

      This is the same repro as above but without sitting on the prim.
      The bug is much easier to reproduce when sitting on the prim, but sitting on the prim is not necessary to reproduce.

      • Rez a default cube.
      • Edit cube.
      • Under object tab set Z rotation to 270 by typing 270 into the text box and hitting Enter key.
      • Change edit mode to rotation so you see the rotation rings
      • Make small rotation edits using the rotation rings but keep the Z rotation fairly close to 270, for example 268-270.
      • If the bug does not reproduce, close the edit floater and edit on the prim again, change to rotation mode and repeat.

      NOTE: Bug also reproduces when the X or Y rotation is close to 270

      Observed Behaviour

      REPRO 1

      • Please see attached demo video.
      • When the X, Y or Z rotation values are at or close to 270, attempting to rotate the prim with the edit rings will easily cause the prim to shoot off to position <0,0,0> on the region and the prims rotation also changes to <0,0,0>
      • Your avatar will remain seated on the prim and will also be at position <0,0,0>
      • Often, just touching (left clicking) one of the rotation rings without actually moving it will cause this to happen.
      • When this bug reproduces, you will have the prim still held in edit - observe the prims position in edit is <0,0,0> and it's rotation has also changed to <0,0,0>.
        See Fig 1 attached.
      • This is not a client side glitch - observers will also see you seated on the prim at <0,0,0>
      • If your camera does not follow the prim when it moves to <0,0,0>, hit ESC a couple of times to reset your camera view onto your avatar.
      • Observe that your avatar is sitting on the prim at position <0,0,0>
        See Fig 2 attached.
      • Hitting ESC may have exited edit mode.
      • If so, edit on the prim again and use CTRL+Z to undo the position and rotation change to take the prim back to its previous (correct) position and rotation.
      • Observe the prim and your avatar move back to the correct position on the region and the correct values display in the edit floater for position and rotation.
        See Fig 3 attached.
      • When this bug reproduces, I always get the following lines immediately in my log as soon as the object position changes to <0,0,0>:

        WARNING: LLXform::warn: Non Finite in LLXform::setRotation
        WARNING: LLXform::warn: Non Finite in LLXform::setPosition(LLVector3)
        

      • Log file attached from the session I made the demo video.
        You can see the above log warnings at:
        Line 949 - 2014-08-20T01:47:01Z
        Line 1535 - 2014-08-20T02:00:06Z
        Line 1680 - 2014-08-20T02:01:05Z

      REPRO 2

      • When the X, Y or Z rotation values are at or close to 270, attempting to rotate the prim with the edit rings will easily cause the prim to shoot off to position <0,0,0> on the region.
      • There are 2 different behaviours seen when this happens

      1. The prim will very briefly disappear from your view and then reappear back in its original position.
      When this happens, observe that you have lost edit focus on the prim so the edit fields will be greyed out.
      See Fig 4 attached.

      Again, observe in logs that you see the following lines:

      WARNING: LLXform::warn: Non Finite in LLXform::setRotation
      WARNING: LLXform::warn: Non Finite in LLXform::setPosition(LLVector3)
      WARNING: LLFloaterTools::refresh: Failed to get selected object
      

      2. The prim will disappear from your view, you lose edit focus on the prim and the edit floater fields are greyed out.
      The prim will not return to its correct position and it is apparantly "lost"
      Go to location <0,0,0> and you will find your prim here.

      Expected Behaviour

      To be able to build and edit on the official viewer without my objects suddenly ending up at <0,0,0> on the region.
      To be able to sit on pose balls and edit them into position without suddenly ending up sitting at location <0,0,0> on the region.

      Other Information

      I am fairly sure that this bug was introduced with the STORM-1915 fixes (DRTVWR-351)

      I really want to mark this Severe because it has been driving me crazy until I realised what was happening.
      Over the last week or so I have been losing random objects when editing them with the official viewer and today I discovered them all in a pile at <0,0,0> on the region. Mystery solved

      To Do: Test a pre DRTVWR-351 build and make sure this does not reproduce.


        Attachments

        1. blue edge on.jpg
          blue edge on.jpg
          31 kB
        2. Fig 1.png
          Fig 1.png
          36 kB
        3. Fig 2.png
          Fig 2.png
          506 kB
        4. Fig 3.png
          Fig 3.png
          1.38 MB
        5. Fig 4.png
          Fig 4.png
          244 kB
        6. SecondLife.log
          317 kB

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                whirly.fizzle Whirly Fizzle
                Contributor:
                Moon Metty
              • Watchers:
                4 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved: