Since the rotations in the client are displayed and edited as yaw, twist, and roll, it makes sense that they're sent over the network that way. It sounds to me like the system is simply storing the number as sin(angle/2).

If that's the case, we need to first convert to radians and then to degrees.
To convert it back to radians you'd get the arcsin of the value.
To convert radians to degrees, divide the radian value by (pi/360).

the C# code would look something like this (you'll have to look up the exact arcsin function and PI constant)
double RotX=Math.ASin(SlRotXValue)/(pi*360)

You'd have to do that for X, Y, and Z, of course.

Let me know if that pans out.

On 9/11/06, John Hurliman <[EMAIL PROTECTED]> wrote:
I'm adding in ObjectData support and have been stuck on the rotation
format used in the ObjectData byte field of the ObjectUpdate packet.
SLProxy testing shows that rotation information starts at ObjectData[36]
and is stored as three floats that appear to be in quaternion format,
where a 90 degree twist gives the float 0.7071067690849304, or
sqrt(0.5). A 180 degree twist gives -1, and -180 gives 1 which is
backwards from the tutorial I was reading but I'm not very familiar with
this anyways. The most confusing part though is there are fields for X,
Y, and Z but not the fourth parameter of the quaternion like in
ImprovedTerseObjectUpdate. The values suggest that it definitely is a
quaternion and not a Euler rotation, but how can it be accurately
described without the fourth parameter? This is one of the last holdups
before the object code is finished, so if anyone can shed some light on
the issue please do.

John Hurliman

_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev



--
Tom Wilson
[EMAIL PROTECTED]
KI6ABZ
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev

Reply via email to