[#VWR-4471] "Copy Selected" with "Rotate Copy" behaves incorrectly

1. Second Life Viewer - VWR

"Copy Selected" with "Rotate Copy" behaves incorrectly

Created: 01/Feb/08 09:24 PM Updated: 04/Feb/08 09:24 AM

Component/s:

Building (in-world)

Affects Version/s:

1.18.5.3

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)

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.

Description

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.

Show »

All

Comments

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Jacek Antonelli - 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. ^_^;

[ Permlink | « Hide ]

Coyote Pace - 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!

[ Permlink | « Hide ]

Lex Neva - 02/Feb/08 11:15 AM

I love your little smiley-face diagrams :D

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.

[ Permlink | « Hide ]

Jacek Antonelli - 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.

[ Permlink | « Hide ]

Coyote Pace - 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.

[ Permlink | « Hide ]

Torley Linden - 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.