Hmmpf rotations.... *thinks out loud to channel his thoughts*

Let _dc be Domain server Coordinates. Let _ac be Avatar coordinates.

Let 0,0,0 be ZERO_VECTOR and 0,0,0,1 be the ZERO_ROTATION quatenion.

The transformation ((rot, pos) pair) of ac relative to dc is (MyAvatar.orientation, MyAvatar.position).

Let ac_rot_dc = MyAvatar.orientation and let ac_pos_dc = MyAvatar.position.

Let 0,0,0 be ZERO_VECTOR and 0,0,0,1 be the ZERO_ROTATION quatenion.

The transformation ((rot, pos) pair) of ac relative to dc is (MyAvatar.orientation, MyAvatar.position).

Let ac_rot_dc = MyAvatar.orientation and let ac_pos_dc = MyAvatar.position.

@thoys generally - in scripts of virtual worlds :P

Let yaw_rotation be an arbitrary rotation around the avatars Y axis.

Hence there is a transformation (yaw_rot_ac, yaw_pos_ac) = (yaw_rotation, ZERO_VECTOR) that defines a delta rotation around the avatars Y axis.

Hence there is a transformation (yaw_rot_ac, yaw_pos_ac) = (yaw_rotation, ZERO_VECTOR) that defines a delta rotation around the avatars Y axis.

Applying this delta transformation to an object at (ZERO_ROTATION, ZERO_VECTOR) in _ac coordinates then gives the new desired transformation of the avatar:

`(new_rot_ac, new_pos_ac) = (ZERO_ROTATION * yaw_rot_ac, ZERO_VECTOR * yaw_rot_ac + yaw_pos_ac) = (yaw_rot_ac, ZERO_VECTOR) = (yaw_rotation, ZERO_VECTOR) relative to ac.`

The new transformation relative to dc then is:

`(new_rot_dc, new_pos_dc) = (new_rot_ac * ac_rot_dc, new_pos_ac * ac_rot_dc + ac_pos_dc)`

Since new_pos_ac is ZERO_VECTOR, new_pos_dc becomes ac_pos_dc .. and thus didn't change (obviously.. but it's easier for me to think it complete transformations then ignoring translations from the start :P)...

So, for just the rotation we get:

So, for just the rotation we get:

`new_rot_dc = new_rot_ac * ac_rot_dc = yaw_rotation * MyAvatar.orientation`

Emperically, I found that this works:

MyAvatar.orientation = Quat.multiply(MyAvatar.orientation, yaw_rotation)

Ugh - does this mean that the order of the arguments of Quat.multiply are reversed with respect to LSL's '*' operator?

@Thoys Would you happen to know if x * y (in LSL) equals Quat.multiply(y, x) in javascript? -- that is what was confusing me, if that is the case :\

@AlericInglewood not sure, its a while since i've tempered with LSL rotations, I know i got some advanced rotations working, but it wasn't really that easy

I got so tired of how hard rotations were that at some point I spent 2 weeks exclusively on understanding them. I invented a coding style, a way to write variable names, that made it "easy" and wrote a wiki page about it (here: http://wiki.secondlife.com/wiki/User:Timmy_Foxclaw/About_Coordinate_Systems_and_Rotations), after which you can call me THE LSL rotation expert ;)

Trying to convert that knowledge to javascript now - it would be annoying if the multiplication order was inversed, because the notation system is designed around that order :P

@thoys

`Namely, the fact that you can convert by writing something_*_A = something_*_B * B_rot_A ... where the '_B * B_' short circuits and drops out`

:P
`X_rot_dc = X_rot_ac * ac_rot_dc reads better than X_rot_dc = Quat.multiply(ac_rot_dc, X_rot_ac);`

:\
There seems to be bug with regard to the cam position.. it has a vertical offset in world coordinates, while that should be in avatar coordinates.

This way the avatar wobbles around the center of the screen when you change the Roll

@murillodigital killed the particle server on sandbox by throwing frisbee's

```
glm::quat Avatar::getWorldAlignedOrientation () const {
return computeRotationFromBodyToWorldUp() * getOrientation();
}
```

is not according to the coding style: getWorldAlignedOrientation should be computeWorldAlignedOrientation
Something isn't right here though... how can this ever involve a computation that using acosf()? :\ The whole reason for using quaternions is to avoid that!

What is Avatar::computeRotationFromBodyToWorldUp supposed to do? Cause documentation/comments are painfully absent again :\

anyone here running a domain with a still functional particle server?

how about your domain?

coughs coughs, well it flickers on mine, alpha and sandbox particle servers are down

noo idea how they went down though ;) http://gyazo.com/38ff987aa3942fc1a8aa552bdb37e91c

are the fisbees not being removed?

they are, but i guess they're saved in the particle assignment server

forgot about that one

see how many you can take down before the netherlands V costa rica game

haha, I need some volunteer servers then

do you have a mac?

not sure if it happend automatic or not

using particles for the frisbees, only have a little problem with their lifetime

I guess I need to replace them with a new one whenever you throw it

I wish the code said which coordinate systems the stored orientations are against :\

I guess that most are relative to the world coordinates.

Nooo... why?

```
void AvatarData::setOrientation(const glm::quat& orientation) {
glm::vec3 eulerAngles = glm::degrees(safeEulerAngles(orientation));
_bodyPitch = eulerAngles.x;
_bodyYaw = eulerAngles.y;
_bodyRoll = eulerAngles.z;
}
```

Every time an avatar changes orientation the interface calculates the Euler *angles*???

That hurts

AlericInglewood @AlericInglewood starts optimizing code...