Prim Rotations Don't Make Sense

I'm trying to build what I thought was a simple object that has two parts that switch back and forth between two positions by rotating. The rotating parts are cut boxes so that their centers are the axis of rotation. I have the script in another linked prim that tells them when to rotate, no problem. In each object I have used llSetPrimitiveParams to set the rotation, llSleep to wait a bit and then llSetPrimitiveParams to rotate them back. The thing is, they are rotating to different angles than I think they should. To get the x, y and z angles for each position I put them where I wanted them, wrote down the x,y,z values that were in the editing window and then put those in like --> [PRIM_ROTATION, <90.0, 18.0, 0.0, 1.0> ] but when the script runs they flop around to different, weird angles. The root prim with the controller script is set at 0,0,0 for its rotations. Full disclosure: I don't do this a lot so I may be missing something obvious. What am I missing?

Rotations expressed as 3 numbers are called eulars. This is what you see in the edit window (x, y and z) and are the ones that make sense. Each goes 0-360.

Rotations expressed as 4 numbers are called quaternions and, for most people, don't make a lot of sense. Any time you want to give LSL a rotation, it needs to be one of these things.

If you set variables x, y and z from what you see in the editor, you can convert them to the right format by doing this incantation:

rotation rot = llEuler2Rot (<x, y, z> * DEG_TO_RAD);

Then feed [PRIM_ROTATION, rot] to llSetPrimParams..

edit: see also http://wiki.secondlife.com/wiki/Rotation

If one or more of your rotations is on an axis you might be running into gimbal lock. Try this...

Rotate the object slightly using the rotation rings. You might find that the numbers in the rotation boxes change a lot, to what seems like another axis. You've found a different set of numbers for the same rotation. Use those instead of the numbers you were using.

Here's an example...

Rez a cube and rotate it to 0,90,0. Now rotate it very slightly about the world Z-axis. Its rotation should now read something like 270,88,90. So, 270,90,90 is the rotation you're looking for.

And if it is a child prim that you are rotating then you must take into account the llSetRot/PRIM_ROTATION bug that has been unfixed for years. Read the caveats section of LSL Portal page.

Quaternions are a 4 dimensional representation of a 3d angle. It's a point on a 4d sphere. Don't try and imagine it. To complicate things, they only use half the sphere, if a point falls in the other half it is treated as if it's direction were reversed. Now your asking why this strange representation? Quaternions are easy to combine and they don't suffer from gimbal lock.

IMO Euler angles are next to useless. Maybe WORSE than useless because the representation they give is both inviting and misleading, which tends to give people a false sense of confidence at first and horrible headaches later.

Quaternions are more useful in that they provide a convenient one-to-one (unambiguous) notation for storing rotations. Behind the scenes and in non-LSL applications they can also have other benefits, but to the LSL scripter who hasn't looked into their structure and behavior a bit, they can unfortunately be a bit daunting. If that is you, my advice is to not trouble yourself too much about what the components of the quaternion mean, and simply use the four component ("<a, b, c, d>" representation where you need to store a rotation as a whole entity (in other words, just treat it as "binary data".

There are two ways to think of and picture rotations that I find much more intuitive and immediately useful for LSL scripting:

1.) As a general transformation between rotated coordinate systems. An object A's rotation (llGetRot()) gives a transformation that can be applied to a vector expressed in its local coordinates (imagine yourself sitting at the prim's center, facing in the direction of its x/fwd axis, with its y/left axis to your left and its z/up axis going up through your head) to get that vector's representation in global coordinates. For example, let's say a box's scale is set to 6.0 in x, 3.0 in y, and 1.0 in z. One of its corners would be at '<3.0, 1.5, 0.5>' in the prim's local coordinates, which means in global coordinates that corner would be offset from the box's center by '<3.0, 1.5, 0.5>*llGetRot()'. Conversely, if there is a doorknob offset from the prim's center by '<5.0, 0.0, 0.5>' in global coordinates, that doorknob will be at '<5.0, 0.0, 0.5>/llGetRot()' in the prim's local coordinate system.

Another application is coming up with an orientation for the prim or object. If you imagine the direction the local x, y, and z axes should point, you can come up with a rotation that orients the prim/object in that way using llAxes2Rot().

Here are some functions that come in useful when thinking about rotations in these terms:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=llAxes2Rot
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llRot2Fwd
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llRot2Left
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llRot2Up

2.) As a single rotation about a known axis by a specified angle. DON'T try to complicate things by putting together multiple of these operations and trying to figure out what the resulting rotation will be. Instead simply concede that it can't be expressed as simple rotations about multiple axes. There's really no such thing as "this rotaiton about the x axis and that rotation about the y axis and some other rotation about the z axis" because order is important, rotation about two axes does create a component of rotation about the third axis, etc. So if you really mean, "first rotate this amount about x, THEN rotate that amount about y", then realize you are talking about TWO concatenated rotations: rot1*rot2, and become comfortable with expressing it that way and keeping it like that.

Here are some functions that come in useful when thinking about rotations in these terms:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=llAxisAngle2Rot
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llRot2Axis
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llRot2Angle

You might consider to make two sets of objects and make them transparent / phantom in turn. That way you can easily switch between to rotations without having to think in terms of rotations at all

Wow! Who knew just getting a couple of wings to flap up and down could be so involved! Thanks for all your replies. I hope to get some time this weekend to look into this further.

Dora, I like your idea and could do it a lot easier but I'm already at the limit of the number of prims I can have in this vehicle and don't think I can cut any more

Aha! If what you want are flapping wings, and you want them to flap at the same time, and you are running out of prims: then you can do both wings in a single prim and dispense with rotation.

Take a hollow box and give it a beginning and end twist of 45 degrees, so that it is diamond shaped. Trust me, play with the dimensions and you will see that it is diamond shaped, not box shaped. Cut away half of it so that the remaining half-diamond looks like two wings. To flap the wings you change the X and Y dimensions from tall and skinny to wide and flat. You need to shift the center of the prim at the same time so that the wing joint remain in the same place.

Hmmm.... well you could save yourself an error-prone move by using two half-cut "doors" then the rotations are easy and they don't mess up when the reposition fails (you don't need to move the two wing-prims).

/esc