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

@AlericInglewood rotations where?

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?

@thoys did you knock sandbox offline?

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

lol. that looks fun.

are the fisbees not being removed?

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

I just pinged leo. did you try root?

ah will try root thanks

forgot about that one

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

yeh, i pinged leo 3 hours ago in this channel

haha, I need some volunteer servers then

also kevin?

do you have a mac?

ah its back up now

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

yeah

else you cant eternally throw them

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...