Basic nubie questions

Q1: A rotation can ( real life ) be a vector with 3 variables. SL uses 4 variables.
can someome please explain how the < a, b, c, d > format specifies a rotation.

Q2: What is the diference between llSetCameraAtOffset and llSetCamaraEyeOffset

Q3: Is there a guide to the SL syntax ( I don't use Java or C ). Please help me, I am being gored by the green horned syntax monster

Regards Jonathan

I don't fully understand how it works but I think I can explain why you need 4 variables to describe a rotation. Not only do you need x, y and z to describe where an object is pointing, but you also need another to describe how it is rotated around that axis. In other words, point at something, that can be described with x, y, z. But now twist your hand. That is the 4th variable. I don't think it works exactly like that... but it's how I reasoned there must be 4 variables.
1 describes where the camera is. The other describes where the camera is pointing.

Start with the wiki: http://secondlife.com/badgeo/wakka.php?wakka=HomePage

Do a lookup around the net for the word quaternion, that's how rotations are specified internally in many 3d applications as the math on them are much quicker, ie less graphics lag.

What you are used to is the Euler rotations, <x, y, z>. We can still work with them. "However, you can use rotations without dealing with the individual elements of quaternions. LSL offers library calls that convert between a quaternion and a vector containing the equivalent Euler representation: llEuler2Rot and llRot2Euler." from the wiki page on rotations. Lots of information there if you wish to delve a bit deeper down the rabbit hole.

http://secondlife.com/badgeo/wakka.php?wakka=Rotation

I've always found the wiki to be a great place to go. It has a great explanation of rotations, too.

I'm not convinced that you really *need* 4 numbers to represent a rotation (Euler rotations only use 3, just that you're out of luck if your rotation is gimbal locked), but quaternions are great for matrix operations -- which are great for computer graphics routines.

I'm very sure LSL's representation of rotations aren't like what you described, though. The wiki has some really good links to a few places that explain how quaternions work. (http://secondlife.com/badgeo/wakka.php?wakka=quaternions)

I could be wrong (i haven't actually used this function), but i believe what you're referring to can be done with llAxisAngle2Rot().

Oh I know I'm probably way off with what they actually represent... my little explanation is how I made sense of it.... Of course, now that I think about it more, my explanation falls apart even to me.

You're actually very close, Keiki. Conceptually, the first three numbers do specify an axis of rotation, and the last number does specify the size of the rotation. The slight error in your understanding is that the axis is not the axis in which the object eventually points, but rather the axis around which it was rotated to make it point that way.

So if an object is facing in the direction of the world's x-axis, and you want it to face along y, then the first three numbers will represent the z-axis, because we the object needs to rotate around z to end up facing y.

Here comes the maths:
In this example, that's as a quater-turn counter-clockwise on the z-azis, or in numbers PI_BY_TWO radians counter-clockwise on the <0, 0, 1> axis. In my head, I always see this as <0, 0, 1, PI_BY_TWO>, but that is not actually a true rotational quat.

To make it a rotational quat we have to do something. The reason we have to do it is complex and difficult to understand or explain - but that doesn't matter!. You don't need to understand the reason, you just have to know how to do it. (Actually, you don't even calculate it yourself, you ask LSL to do it for you)

Take half of the angle. In our example, that would be PI/4.0. Multiply each of the first three numbers by the sine of that half-angle, and replace the last number with the cosine.
So: <0, 0, 1, PI_BY_TWO> becomes <0*sin(pi/4), 0*sin(pi/4), 1*sin(pi/4), cos(pi/4)>
or, in LSL, <0.0, 0.0, llSin(PI/4.0), llCos(PI/4.0)>.

Normally you would just put that into a global variable:
rotation MyRotation = <0.0, 0.0, llSin(PI/4.0), llCos(PI/4.0)>
so that the sin and cos would only ever be calculated when the script was reset.

And remember - you don't need to know why you're doing it - you don't need to be able to calculate sin and cos yourself - just tell LSL to multiply the x, y and z of the rotation axis by sin of half of the angle, and the last number is cos of half of the angle - and you're done.

This rushed explanation doesn't cover normalising the axis, or the right-hand-rule, but that is all part of a tutorial I am busy putting together as and when I have time.

Rotation isn't really a vector quantity, as the operations don't commute.
Only infinitesimally small rotations can accuratedly be described as vectors.