rotation division borked?

the following code rotates an object counter-clockwise on multiple calls...
roatation bob = llEuler2Rot( <.0, .0, 90.> * DEG_TO_RAD );
llSetRot( bob * llGetLocalRot() );
yields rot.z = 0, -90, -180, 90, 0

ok all good,
the following code SHOULD rotate clockwise.... but DOESN'T on multiple calls....

roatation bob = llEuler2Rot( <.0, .0, 90.> * DEG_TO_RAD );
llSetRot( bob / llGetLocalRot() );
yields rot.z = 0, 90, 0, 90, 0

as you can see it flips back and forth as if it were being swapped with the previous call... what's going on here?

With rotations, you always try to find a way that works, you never try to understand why all the other ways don't work. At least, that's my mantra

Try:

rotation bob = llEuler2Rot( <.0, .0, -90.> * DEG_TO_RAD );

-90 = 90 degrees in the other direction, so that might work. *shrug* Who knows. It's rotations

try this:

llSetRot( llGetLocalRot() / bob);

I always believed the tooltip syntax for the rotation stuff in the LSL editor should simply say "You will not understand this."

that'd be great jesse, except one little thing... I need it to be the local x-axis which means it must be it the rev order....

//I know that

llSetRot ( bob / llGetLocalRot() );

//is the same as

bob.s *= -1;
llSetRot ( bob * llGetLocalRot() );

but I've used this before, and at one point, I KNOW that division worked properly...

this also borks some movement by rotation scripts since they expect a right hand turn (clockwise) not a huge left hand turn.... which can be seen visually

EDIT: jira issue is here
however as noted in the issue, Division for local axis does NOT work that way... but works (properly?) as I described in the OP, however Global Division does NOT follow this pattern (as jesse noted) so I've reopend the issue, to get either a clarification, or a consistency check.... it may be related to the other issue (which I can find) regarding a borked implementation of rotations in either llSetPrimitiveParams or llSetLinkPrimitiveParams

Ignore me if it's not this, but... *tacks it on*
http://jira.secondlife.com/browse/SVC-93

This got me while ago to the extent that I put out a plea for people to go make a vote on it in JIRA.

Here's my thread with some info I found useful.

/54/9b/217272/1.html

I linked it, because it may be related to the discrepency between global and local rotations.

and thanks Day Oh, that WAS the issue I was looking for

SVC-93 isn't what's biting you here unless you're doing the llSetRot() in a child prim.

Void, what's going wrong here is that you've got a mistaken understanding of what rotation division does. Rotation division "unrotates"... but what you actually want to do is rotate in the other direction. Those are two subtly different things. I just woke up, so I can't bring to mind a good way of explaining the difference.

You're right in that multiplying in the order of bob * llGetLocalRot() rotates the amount of bob with respect to the object's local axes. To rotate in the other direction around the local axes, you need to just multiply on the left with a rotation that's the negative of the original rotation, like Ziggy suggests... something like this:

rotation bob = llEuler2Rot( <.0, .0, -90> * DEG_TO_RAD );
llSetRot( bob * llGetLocalRot() );

Now, there's another problem here; you're llSetRot()ing something calculated using llGetLocalRot(). That's almost bound not to be what you want. If this is in a child prim, look at SVC-93 to see how to work around the bug. If it's in a root prim or a single prim, use llGetRot(), which, in that case, will be identical to llGetLocalRot()

Edit: Nevermind. The way Lex wrote above works the same way, and is rather simpler to understand. There shouldn't be really any trouble using it in either a root prim or a child prim; llSetLocalRot(llEuler2Rot(<whatever amount here> * llGetLocalRot()) will rotate the prim around <whatever amount here> around its local axes as needed. All you need to do is change the direction of the angles in the vector to change which direction it's rotating in. Changing the operation from * to / does not do the same thing.

The main reason this is so confusing to everyone is because * and / operations give the same *results* as when you simply rotate by a positive or negative angle, respectively - but this is only true when you're computing global rotations, since the global axis never changes. However, since the local axis can change, you have to get used to the idea that you can either rotate by a positive or negative angle, but / is 'unrotating,' which is not the same.

oh once I read SVC-033 I realized that, per your description, but because local and global division (change / global vs global / change) seem to behave differently, I thought there might be a link in how it was implemented, someone with better math skills can check the correlation..... there needs to be a "MAY relate to" option


actually I found this to be a very elegant solution...
bob.s *= -1;
llSetRot( bob * llGetLocalRot() );

paired they make a perfect reflection on each call, separate, it's an inverse rotation (which as noted also works by inverting the original vector, but that's resource heavy)



THAT was for compatibility across linked or unlinked single prims, because llGetLocal Rot does behave the same as llGetRot in a root prim, it makes for a nice clean way to keep rotations in relation to local axis w/o coding 2 different versions for linked or unlinked

In that case, tyken's right: use llSetLocalRot(), not llSetRot(). That'll work in root and child prims.