Rotations and Vectors... BRAINCRAMP!

OKies

I want to make a script that will put a sit target one meter above a prim, no matter how the prim is rotated.

Now, killing the rotation is easy, I use ZERO_ROTATION / llGetRot() to get the av always facing "east" and upright.

But I am having the damndest time understanding how to rotate the offset vector so that I'm always one meter "up" globally. Can one of you geniuses help?

One step ahead of you. Copy and paste!

// Use this to base the target on world units
vector sit = <0,0,5>; // Relative Position vs. object in World Units
rotation rot = <0,0,0,1>; // Rotation of Object in World Units

default
{
    state_entry()
    {
        rotation reverseSit = llGetRot();
        reverseSit.s *= -1;
        llSitTarget(sit * reverseSit,rot * reverseSit);
    }
}

See my post on this thread for more goodies.

I... I ... still don't understand.

Why do you have to invert the rotation first?

And why is the link you posted to a thread in the archives entitled "A question/plea for the women of SL..."?

Ahahah... that's what I get for "memorizing" the post number and attempting to link it. This is the correct thread. I'm going to leave the erroneous one up simply because that's a perfect example of what not to do.

Note the subtle problem with the links. One is a post number, the other is a thread number. Guess I won't be making that mistake again.

Anyway, "inverting" the rotation first is simply telling it to rotate in the opposite direction. This, in effect, "cancels out" the original rotation.

What you want to do, then, is multiply the vector times this inversion. The result? World units.

Multiplying a vector times a rotation sets the vector in that rotation's "local frame." To get the reverse, multiplying the vector by the inverse of the local frame gives you global.

Clear as mud, yes?

ROTATIONS! Bwah-ha-ha-ha!

This is the part where you run away.


AAAAARRRRGGGHHH!

- C

I'm not 100% there yet, but you've helped TONS. Thanks

Actually incredibly clear Jeff!

Multiplying the vectors is a 'peculiarity' of quaternions I think.

A normal rotation around X, Y, Z you could subtract (or add to 360 degrees if you prefer to think of it that way) as you suggested to Cocoanut. The equivalent for quaternions is the multiplying by the one with the negative sign in the fourth location.

You could do rot_to_euler, then negate, add and euler_to_rot - it gives you the same answer as Jeff's much shorter function.

It could actually be shorter; I just prefer the *.s *= -1; notation.

rotation rot = llGetRot();
rot.s *= -1;

Is essentially identical to doing this.

rotation rot = ZERO_ROTATION / llGetRot();

Where ZERO_ROTATION = <0,0,0,1>; Note these are different rotations that do the same thing.

Note that the first one flips the S value, whereas the second one flips X/Y/Z. These two rotations do not evaluate as equal to one another in LSL. However, they do the exact same thing in practice.

but what if your rotation is <1,0,0,0>? no s

// Use this to base the target on world units 
vector sit = <0,0,5>; // Relative Position vs. object in World Units 
rotation rot = <0,0,0,1>; // Rotation of Object in World Units 

default 
{ 
    state_entry() 
    { 
        rotation reverseSit = llGetRot(); 
        llSitTarget(sit / reverseSit, rot / reverseSit); 
    } 
}  

you can use "/" on vectors as well

llGetRot will never evaluate as <1,0,0,0> - at least, I've yet to see it do so. Not having an "s" is an error in notation that LSL corrects for, I think.

After all, you'd be telling it to rotate 0 units on axis <1,0,0>... which should evaluate <0,0,0> in Eulers. In LSL, it comes out to <PI,0,0> in Eulers, which is rather strange. Works the same way for Y and Z.

I've had mixed results with using division with vectors - probably due to my order of operations being wrong. It's all saying the same thing, anyway.

pfft

// Use this to base the target on world units 
vector sit = <0,0,5>; // Relative Position vs. object in World Units 
rotation rot = <0,0,0,1>; // Rotation of Object in World Units 

default 
{ 
    state_entry() 
    { 
        rotation reverseSit = ZERO_ROTATION / llGetRot(); 
        llSitTarget(sit * reverseSit, rot * reverseSit); 
    } 
}  

OK, I'm confuzzled again.

Al these varuous techniques work just fin keeping the av facing the rotation I specify. However...

The sit target still scoots around a little with the rotation, using any of the techniques exampled here. Rather a bit like it's rooted a little off-center to the prim. So, with the prim at 0,0,0, I sit 5 meters up. With the prim at 180,0,0 (degrees) I sit 4.6 (or so) meters up.

IDGI! Hep!

And thanks again to you both for this - it's enlightening!

sounds like a bug. i'll take a look into it later.

Thanks Strife!

I noticed this too. Not sure what's causing it either... might be roundoff, but it seems too much to be so with just a cube prim.

Seems to me that the default sit target is a little off-kilter.

This is sounding very familiar. I think I remember in a time before time there was a linden post asking us if we wanted this fixed...