|
|
|
Are you sure that's the way it chooses which axes to align with, Jacek? I was under the impression that the axes didn't actually match any of my prims... perhaps I wasn't paying close enough attention. Either way, I'm not sure I agree with warkirby. The current local axes are essentially useless for linked sets (or unlinked selections), and this is NOT the way it used to work. It used to align the local axes with the root prim, I believe.
Warkirby, can you give an example of a building sequence that makes use of the local axes as they are now, that would break if this is changed to meet Jacek's expectations? @Lex: It definitely matches the rotation (but not position) of one of the prims, but I was not quite correct in how it chooses which prim to match. I went back to confirm that it always worked the way I described, but found that sometimes it acted differently. After doing some tests with several prims (5), I've figured out a description which always applies:
The axes align themselves to the OLDEST NON-ROOT PRIM in the linkset. ("Oldest" is measured by creation date of the prim, which you can check with the Inspect floater.) I can produce screenshots documenting this, if needed. This is a very strange way for it to choose which prim to use. I doubt anyone could argue that this behavior is either "expected" or "useful". Any "valuable build tool" which takes advantage of this quirk in the Local ruler mode UI would be more robust using the Reference ruler mode, anyway. (Setting aside the slight inconvenience that "Use selection for grid" is broken when selecting a linked part – but that's a different bug entirely.) Importing from our UI triage for further investigation... thanks for all the details, Jacek...
Attached a patch to fix this issue. The problem turned out to be that the rotation of the manipulators was being taken from the rotation of the selection bounding box for the object, which was in turn being taken from the rotation of the first object that it looked at when creating that bounding box (which, it seems, is the oldest prim in the link set). Phew, that's a mouthful.
Anyway, I fixed it by initializing the bounding box from the root prim first. Now the move, rotate, and scale manipulators are oriented with the root prim, as they ought to be. Note that the bounding box I'm talking about is not related to the physics simulation; it's part of the selection manager, and as far as I can tell without seeing the server source, is client-side only. Okay, I've discovered that the patch has a unwanted side effects when editing linked parts, and so is not ready to be applied. I'm working on an alternative patch to correct the side effects.
Attached a new patch, which should be applied instead of the other one.
I'm mostly satisfied now. The only annoyance I have is that the order the prims in a linkset are selected when Edit Linked Parts is turned on, means that the axes change. But, it's a minor annoyance, and can be worked-around by un-selecting and then re-selecting the root prim, if desired. D'oh. I totally forgot to mark "Patch attached". My bad.
Confirmed fixed in 1.19.1 (2) RC. Yay!
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Normal
Edit Manipulators have Wrong Orientation with Local Ruler Mode on Linked Objects
Not only that, it is useful, this way. Your proposed solution would break a valuable build tool for the sake of correctness in naming terms. That is unacceptable.
A better idea, would be to have a NEW ruler mode, aligned to the root.