llRezObject rotation help

Hello, I am using the "llRezObject" function to rez an object relative to the prim it was in, but the rotation relative to the original prim is causing me a heachache.

This is the line of script I am using, taken from the LSL wiki(http://wiki.secondlife.com/wiki/LlRezObject)

llRezObject("Object", llGetPos() + <0.0,0.0,1.0>, <0.0,0.0,0.0>, <0.0,0.0,0.0,1.0>, 0);


Now, I understand the first series of 0s relates to the position the prim is rezzed in relation to where it came from, no problem there.
The second series relates to velocity, I dont think I need to use that at all.
The third series relates to rotation, and is what is causing me the heachaches, I cant seem to work out what I need to put in there to make the prim rotate how I would like in relation to the original prim.

From looking around (for example here http://wiki.secondlife.com/wiki/Rotation) , I have managed to find out that the numbers in the third series should be in radians, not degrees, and after looking into the maths of radians, I still cant get a satisfactory combination of numbers for the rotation.

Is there any more information I could read somewhere that would give me example of the kinds of numbers I could use and the effects on the prim?

Or perhaps I made a mistake somewhere and the numbers I need to use are not radians after all?

Or parhaps there is someone willing to help me modify my line of script so the numbers come out right... If the first prim is at this rotation <0.0,0.0,0.0,1.0>, then what would the line look like if I wanted the second prim (no matter where it is) to be rotated (according to the numbers in its "Edit" - "Object" window at X:90 Y:0 Z:90 dgreees?

Any help would be very welcome!

llRezObject("Object", llGetPos() + (<0.0,0.0,1.0 > * llGetRot()), ZERO_VECTOR, ZERO_ROTATION, 0);

The amount of rotation isn't actually directly present in the value. It is a quaternion. See http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#Summary

But rather than starting up with the trig, you can actually use the functions in the tables shown on the http://www.lslwiki.net/lslwiki/wakka.php?wakka=rotation page to make it a lot easier. For example, if you know the direction you want the root prim's axes to point, llAxes2Rot() should be helpful. If you want it rotated a certain angle about an arbitrary axis, llAxisAngle2Rot() should work.

And in either case, if you want the rotation to be relative (e.g. start the rezzed object out aligned with the rezzing object, THEN apply your rotation), use: 'llGetRot()*relativeRotation', where 'relativeRotation' is calculated using the functions mentioned above.

If you always want the object rezzed in a fixed orientation relative to the rezzing object, here's a nifty trick. Put both objects in-world, set the rezzing object's rotation to zero (all zeros in the edit window's rotation fields), and then position the object to be rezzed where you would like it. Then put the following script in and touch the object that is going to be rezzed.

default
{
    touch_start(integer nDetected)
    {
        integer i;
        for (i = 0; i < nDetected; ++i)
        {
            if (llDetectedKey(i) == llGetOwner())
            {
                llOwnerSay("vector RELATIVE_ROT = "+(string)llGetRot()+";");
                return;
            }
        }
    }
}

The script will spit out a line for you to put a the top of the script that does the rezzing. The rotation you should use to rez will then be: 'llGetRot()*RELATIVE_ROT'. When you are done, you can delete the above script from the object to be rezzed.

As Jesse showed above, you may also want to transform the relative POSITION where you rez the object according to the rotation of the rezzing object. That way essentially the coordinates you give are along the axes of the rezzing object, not along the region's fixed axes.

I'm surprised I haven't seen anyone pipe up with this yet:

llEuler2Rot(<90,0,90>*DEG_TO_RAD);

That x/y/z rotation trio is an "Euler" rotation, and llEuler2Rot() will convert it into the internal (quaternion) format used by LSL. Multiplying by DEG_TO_RAD converts those degrees into radians.

llRezObject() rezzes at a world-relative rotation and position that you specify. To make the rotation relative to the rezzing object:

llRezObject("Object", llGetPos() + <0.0,0.0,1.0>*llGetRot(), ZERO_VECTOR, llEuler2Rot(<90,0,90>*DEG_TO_RAD)*llGetRot(), 0);

This will rez the object one meter away along the rezzing object's local Z axis, and rotated <90,0,90> relative to the rezzing object's local axes.

Thank you for your replies

While I dont want someone else to do the work for me, I perhaps do need to be led by the hand a little because it's only my first week or two of scripting, and as far as I am concerned, I Lack examples of the kind of numbers that can be put into these lines.

Jesse, thank you, but your line of script didnt seem to change the rotation at all. I dont know if I put it in the right place, but it didnt work for me.

Hewee, thank you very much too, you showed me even more information about these variables that might help me in the future, but when I read the pages I actually wondered if you worked for NASA or something, because there was no way I could understand that stuff! Also, the additional functions might be helpful, but at this stage I have very little idea about how to put these things together ina line or sequence to make them work

Lex, your suggestion worked for me, thinking in degrees is right now the easiest thing for me, while I work out the other aspects of scripting, and it actually worked It will help me next time too, I am pretty sure about that, until I get my head around quaterions. Thank you!

Thanks for all your replies.

most of the time you shouldn't have to deal with placing values directly into a quaternion, if that's any consolation.

for ease of modifying you can place the Euler rotation (vector in degrees) in a global variable, and then convert it later in the script. this leaves you the option of tweaking it in the easiest form, but still applying it within the script as a rotation.

as an example

vector gVecEuler = <90.0, 0.0, 90.0>;
rotation gRotQuaternion;

vector gPosOffset = <0.0, 0.0, 1.0>; //-- rez offset 1m local 'up' from rezzor

default{
  state_entry(){
    gRotQuaternion = llEuler2Rot( gVecEuler * DEG_TO_RAD );
  }

  touch_start( integer vIntTouched){
    llRezObject( "Object Name",
                 llGetPos() + gPosOffset * llGetRot(),
                 ZERO_VECTOR,
                 gRotQuaternion * llGetRot(),
                 42 );
  }
}

the multiplication by llGetRot cases the object to be rezzed in relation to the rezzor, regardless of the rezzors placement. without them the object will rez based on global sim orientation, regardless of the placement of the rezzor.

the first call w/ get rot breaks down like this
llGetPos() + gPosOffset * llGetRot()
rezzor_position + (offset_position, rotated to match the rezzor)

multiplying a position vector by a rotation effectively swings that position arround it's point of origin (0,0,0), by the amount of the rotation

the second call breaks down to
gRotQuaternion * llGetRot()
local_orientation, applied to rezzors_orientation

in the second call, it's important that the local orientaton comes first, order matters when mulitpling quaternions together. the last one acts as a starting point, and the first one is appllied as a change to that.

to illustrate why order matters, place a book flat on a table
rotate the top of the book to where the spine was (90deg ccw around the z )
then rotate spine to the position of the front cover (90deg cw around the y )
the back of the book should be facing you
place the book as before, but reverse the order of the instructions
now the spine should be facing you.
same instructions, different order, different results.

hope some of that helps.