How Links Rotate (aka "Center Screwiness")

I was doing some tests last night, and found some scary facts with regard to linked prims...

1) There are at least four (4!) different "centers" to linked prims that the system uses.

2) Control-Drag rotations and Numerical rotations are not interchangeable.

Now the main reason for number two is number one. Let me try and explain...

My test link was three default cube prims arranged like this on the ground (looking down), each cube a half-meter in size, with the bottom left cube the head of the link, and the other two cubes a half meter away from it.

[]

[]  []

I aligned it over a checkerboard floor with half-meter squares so I can monitor the motions. When the trio is selected, the arrow cluster sits at the average of the three cubes' positions, marked here with a period.

[]
  .
[]  []

If you wanted to calculate the position of this center, you would need to add the positions of each prim together, and divide by the number of prims. This gives you the "average center" for the link. There is no easy way to calculate this via a script in-game.

When you control-drag to rotate the link, it is that center (the period) that the group rotates around. So if you rotate it 90 degrees, it will go out of alignment with the checkerboard floor since that center point is not on the half-meter grid.

Now if you look at the numerical data for the link, you'll see the Z rotation field says 90 degrees. But this is deceiving! This number is NOT the rotation of the link (as much as we would like it to be) but is JUST the rotation of the head prim. Changing this number back to zero WILL rotate the link back to it's starting rotation, but it does this around the center of the head prim, and NOT the link's center (the period). The end result is that the trio has moved from it's starting location, even though all we did is rotate it.

It was this that caused me to notice the flaw in the system. I had rotated something with control-drag, but needed to fine-tune the rotation (since control-drag rotations using the red, green, and blue rings are limited to 5 degree increments) so I edited the number in the object window. But after that, the position was different!

I've mentioned two of the centers, "head center" and "average center", but there are two more. One is only used for physics, "center of mass", and there is a function to get it. It does not match the "average center" because it weights the positions by the mass of the prims.

The fourth center is the one used by llRezObject. I call this one the "f-ed-up center" (read that as you will...) because it does not match ANY of the others. I'm not even sure how to calculate it. At first, based on my tests, I though it was another average of the prims' locations, but not including the head prim. But one of the tests doesn't match that, so I really have NO idea what the f it's using.

Oh, and the "f-ed-up center" is only used by llRezObject to POSITION the link. It uses the "head center" to ROTATE it. Total screwage.

Now, I reported all this as a series of bugs, but... FIXING any of it is going to either change the way we are used to building (in regard to the control-drag rotations) or break existing scripts (if the llRezObject is changed to use a calculable center, like the head's position).

I'm curious what everyone here feels would be best. I know that if they "fix" llRezObject, a bunch of my builds will break... But it will be a HELL of a lot easier to fix them than it was to make them in the first place!

I'm for it.

Oh..... f'en A..

Maybe that's what made me think that there was a bug with rotations causing a change in position... in fact that has to be why.

SO I WASN'T DELUSIONAL AFTERALL! YAY!

Oh...and yeah fix it I'd say..

For the rotation strangeness:


The llRezObject mysteries have been "forwarded it to the developers".

Though I'm sure that they'd be at least somewhat interested in what we feel on the mater, in regards to changing how llRezObject works.

It will break many of the things people have used llRezObject in (as long as the object rezed is more than a single prim... most guns should work just fine) so it will cause some chaos if they change it.

I also suggested perhaps making a new llRezObject command so the old one is still there for old scripts.

Fix it, fix it, fix it!
Screw the previously existing projects that relied on buggy functions. Give us a logical and understandable system.
Hey why not start showing the center of linked objects as a little virtual sphere, like they do in P2P joints.

Well A center is already marked with the arrow cluster when you select the link. If we can ever nail down what a center actually IS, then that will do just fine.

Personally, I'd like the center to be definable, but that may be too difficult to do. Perhaps with a script command called llSetCenter( vector center ) or something like that. It would be better if you didn't need to add a script to the object to set it, but then that's true for so many things, like phantom and permissions.

(Here's hoping that the UI revisions reported to be coming in 1.2 will have more controls over such things from the edit interface.)


Oh, and I STILL can't figure out how to pre-determine the "center" of script-rezed objects. Though I HAVE been able to determine that it has no relation to which prim in the link is the head. My test group of three prims in a right triangle formation (as drawn in the first post of this thread) always rezed in the same location regardless of which prim I set as the head.

They need to give us the option to have rotations happen around the averaged pivot point of the linkage, or to use the pivot point of the parent prim like the checkbox in edit, but for all operations (scripted or otherwise) that use the pivot location.

For times when the averaged pivot is not where you want it, you can always add transarent phantomed objects to the linkage to change the averaged pivot location. It's a clumbsy workaround but it can be useful.

Yes, quite useful, though not suited for general use.

That trick is also good when fighting with llRezObject to store the rotation of an object. Rotate it to the angle you want it to rez at, then attach an alpha-ed prim with a zero rotation to it as the head. Then when llRezObject forces a rotation upon it, you can set it to <0,0,0,1> and not screw it up.

This won't be as necessary if llRO used the same center for positioning and rotations (which it doesn't right now), since then we can predict the behavior.