• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-4471
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Jacek Antonelli
Votes: 35
Watchers: 11
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

"Copy Selected" with "Rotate Copy" behaves incorrectly

Created: 01/Feb/08 09:24 PM   Updated: 30/Jul/09 06:04 PM
Component/s: Building (in-world)
Affects Version/s: 1.18.5.3, 1.21, 1.23
Fix Version/s: None

File Attachments: None
Image Attachments:

1. repro_number_1.jpg
(21 kB)

2. repro_number_2.jpg
(21 kB)

3. repro_number_3.jpg
(21 kB)
Issue Links:
Relates
 

Linden Lab Issue ID: DEV-9951


 Description  « Hide
The "Copy Selected" tool does not behave correctly in all cases if the "Rotate Copy" option is enabled.

What it's supposed to do is create a new copy of the selected object, rotated to the same angle as the prim you click on, and positioned flush against that prim (i.e. no gap between them). In the past, this has been extremely valuable, allowing builders to quickly and accurately align prims against each other (such as the floors and walls of a house).

However, it does not work reliably when one or both of the prims involved have been rotated away from the default <0,0,0> rotations.

  • If one prim has been rotated, the copy will have the correct new rotation, but its position will be incorrect. This bug has existed for as long as I can remember, as far back as Sept 2006.
  • If both prims have been rotated to different orientations, neither the new rotation nor position of the copy are correct. This misbehavior is new, within the past several months.

(Incidently, it does work correctly if both prims have been rotated to the same orientation. This fact made the longstanding bug minor, as making a copy of the copy resulted in the correct behavior.)

REPRO #1: (To see what it's supposed to do all the time)
1. Rez two cubes, A and B. Do not rotate either cube.
2. Right click on B, and Edit it.
3. Access the Create tab of the Build floater (Ctrl-4), and enable the checkboxes "Copy Selected", "Center Copy", and "Rotate Copy"
4. Click on a face of A.
= Observed and expected: a new copy of B appears, with the same rotation as A, positioned flush against A.

[[ NOTE: I accidently switched the labels in the pictures for repros #2 and #3, so I'm also switching the A and B designations below ]]

REPRO #2: (Rotation is correct, but position is not)
1. Rez two cubes, A and B.
2. Rotate A to a rotation different from B. (The more different the angles, the more dramatic the bug.)
3. Right click on A, and Edit it.
4. Access the Create tab of the Build floater (Ctrl-4), and enable the checkboxes "Copy Selected", "Center Copy", and "Rotate Copy"
5. Click on a face of B.
= Observed: a new copy of A appears, with the same rotation as B, not positioned flush against B.
Expected: a new copy of A should appear, with the same rotation as B, positioned flush against B.

REPRO #3: (Neither rotation nor position is correct)
1. Rez two cubes, A and B.
2. Rotate both A and B, but not to the same rotation. (The more different the angles, the more dramatic the bug.)
3. Right click on A, and Edit it.
4. Access the Create tab of the Build floater (Ctrl-4), and enable the checkboxes "Copy Selected", "Center Copy", and "Rotate Copy"
5. Click on a face of B.
= Observed: a new copy of A appears, with a different rotation than B, not positioned flush against B.
Expected: a new copy of A should appear, with the same rotation as B, positioned flush against B.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Jacek Antonelli added a comment - 01/Feb/08 09:27 PM
Oops, I switched the A and B labels in images 2 and 3. The cube on the left should be labelled B in all images. _;

Coyote Pace added a comment - 02/Feb/08 08:52 AM - edited
In case #3, I notice that the copied cube not only doesn't get properly rotated so as to flush up against the reference cube, it also doesn't preserve the original cube's rotation.

In fact, with a few simple trials, I couldn't quite gather WHAT rotation was being applied. For example, create two normally-aligned cubes as per Jacek. Rotate the to-be-copied cube A to some multi-axis change of orientation. Then rotate the reference cube B very simply: merely by 45 degrees on the Z axis. Then perform the copy-align-rotate of A onto the top face of B. The resultant copy cube A' doesn't have the orientation of the original A. Nor does it seem to have the orientation of A rotated through another 45 degrees on Z. Or any other orientation obvious to my feeble mind.

Somebody's got their quaternions in a knot!


Lex Neva added a comment - 02/Feb/08 11:15 AM
I love your little smiley-face diagrams

What an odd bug. Coyote's right, someone's done something strange with quaternions. This reminds me of SVC-93 at first glance... I wonder if someone divided when they should have multiplied, or maybe did a multiply in the wrong order. That kind of thing can work fine when one or both rotations are ZERO_ROTATION, and only show up when you're dealing with two non-standard rotations.

Since you mislabelled the diagrams, and we can't seem to remove attachments, maybe you should change the description for case 2 and 3 to match the diagrams, to avoid confusion.


Jacek Antonelli added a comment - 02/Feb/08 11:38 AM
Good idea, Lex. I've changed the text for repros #2 and #3 in the description to match the A and B labels in those images.

Coyote Pace added a comment - 02/Feb/08 11:54 AM
@Lex Neva – yup, good possibility that somebody forget quaternions operations aren't commutative.

@Jacek - you might want to edit away your original clarifying comment, because it's not clarifying anymore ! (Since you modified the main report to match the diagrams.) I have modified MY comment accordingly, too.


Torley Linden added a comment - 04/Feb/08 09:24 AM
What an awesome bug repro! (And the smiley faces too.) I remember this bug from long ago... usability-wise, this part of the UI isn't intuitive to understand either. I'll import this for our Resident Experience Team to check out.

Erica Linden added a comment - 22/Sep/08 12:17 PM
This passed Rx triage - It looks like a straightforward bug, rather than an intentional design. Waiting for viewer triage and watching vote count.

Moon Cole added a comment - 18/Nov/08 11:14 AM
I have noticed this for over a week now.. just in time to rebuild my new store. sighs

Moon Cole added a comment - 16/Dec/08 03:12 PM
This says it only affects the version 1.18... This is untrue I am on the most current version and I am having issues. My last post was a month ago and nothing has changed. No info has been released NOTHING. You guys awake over there?

Coyote Pace added a comment - 16/Dec/08 03:41 PM
@Moon, if you've verified it applies to additional versions, go ahead and "Edit this issue" (in the left-hand menu) and add those version numbers. The jira is a contributory process, so feel free.

Moon Cole added a comment - 16/Dec/08 06:37 PM
It has even been copying the prims a different size then the prim you are trying to copy. TY for telling me about that edit issue .. i did that

Jacek Antonelli added a comment - 30/Jul/09 06:00 PM
This is still broken in 1.23.4.