Friday, January 19, 2007

rotations are evil

LSL rotation and quaternion math hurt my brain. Or, more dramatically, directly from the LSL scripting wiki:
"Quaternions are the things that scare all manner of mice and men. They are the things that go bump in the night. They are the reason your math teacher gave you an F. They are all that you have come to fear, and more. Quaternions are your worst nightmare." -- Confuted
Incorporating a proper correction factor for selectively angling out the back panels of a skirt while keeping the waistline smooth is not going too smoothly, primarily because I'm not that good at rotations, and because rotations act from the center of a prim and mess up where the tops of the panels end up.

So much for my initial assessment that "it would be easy"...

A code snippet to stare at. I wrote it, it seems to do something that will be useful, but I'm having trouble combining it with the rest of LoopRez. Essentially, if you toss this script into a box prim, it will appear to be rotating around an EDGE, instead of around the center, without resorting to the usual door-opening script trick of "cutting" the door. You have to combine the rotation with a compensatory position change. It really hurts my brain.


float flareAngle = 30.0;
integer n;
vector rotOrigin( rotation myLocalRot ) {
vector size = llGetScale();
return (llRot2Up(myLocalRot) * size.z / 2.0);
}
default
{
touch_start(integer num) {
for ( n=0; n<12; ++n ) {
rotation desiredRot = llEuler2Rot( < 0.0, flareAngle*DEG_TO_RAD, 0.0 > );
vector rotOriginBefore = rotOrigin( llGetLocalRot() );
rotation newLocalRot = desiredRot * llGetLocalRot();
vector rotOriginAfter = rotOrigin( newLocalRot );
llSetPrimitiveParams([PRIM_POSITION, llGetLocalPos() + rotOriginBefore - rotOriginAfter, PRIM_ROTATION, newLocalRot]);
}
}
}


Oh I've got the lonely skybox, rotational, brain-exploding scripting blues...