My head hurts (or 'I Hate Rotations')

As I mentioned in a recent thread about poseballs (found here) I had decided to dust off my partially-completed poseball positioning helper scripts and finally complete them. I've gotten an initial version that works accurately - as long as I never ever ever rotate the prim (or the target) around any axis other than vertical (z?). If I try to rotate either case, the sit position starts to drift - not a whole lot, but definitely enough to be noticable and to screw up the positioning.

Let me repeat - this only happens whenever the rotation is not <0, 0, 0, s>, where s can be any value. If the x, y or z is changed, the position starts drifting ever so slightly, even if I try to mathematically remove the prim's rotation from the positioning. The avatar will always sit correctly, as long as the rotation includes sitting vertically.

As much as it equates to a short putter around the parking lot, this is driving me nuts! Any tips/ideas/suggestions?


- Newfie Pendragon

In a quaternion of form <0, 0, 0, s>, s MUST equal 1 for it to be a valid rotation. If you are specifying other values for s, LSL is probably clamping the value to 1.

It may be that once you start changing the x, y, or z values, LSL no longer knows which value it should fix in order to make it a valid rotation. (After all, how could it know your intentions?)

My apologies, the <0, 0, 0, s> may have been a red herring - I included it to try to explain a little what was happening (in other words, it's possible I goofed with the value). What I meant to underscore was that the drift did not happen whenever the rotation was occurring around the vertical - only when the rotation was away from the vertical.


- Newfie Pendragon

Hi, I'm new to scripting, and didn't expect to be posting just yet, but I had exactly the same problem, but I solved it as follows:

Firstly, to get a rotation value that actually works, I used the llEuler2Rot method: i.e

rotation rot = llEuler2Rot(<0,PI_BY_TWO,0>;

It took me a while to work out that I needed to use degrees instead of radians - as soon as I started to used PI_BY_TWO instead of 90, I started getting somewhere!

I hope this helps!

- SM

This is NOT true!

The "s" component is not restricted to the value 1.0. If this were the case, LSL would simply use 3-component vectors to represent rotations.

- Ace

Please see my responses in this thread. I don't feel I need repeat them.

Oh, and concerning this... the resulting rotation must be normalized (that is, "equal to 1" in a subset of quaternions known as ternions. That has little to do with what the S component equals, as you've noticed - it's a matter of what the whole kit and kaboodle is.

Second Life commonly uses normalized quaternions, AKA ternions, for efficiency. Quaternions that aren't normalized will work fine, though.

llRot2Euler gives you the radians not degrees.

you can make them degrees by multiplying by RAD_TO_DEG

float degrees = radian * RAD_TO_DEG.

you can convert a vector that uses degrees into radians to make a rotation by using DEG_TO_RAD.

rotation rot = llEuler2Rot(<360,360,360> * DEG_TO_RAD);