Second Life Forums Archive

Fremont Cunningham

Senior Wizard

Join date: 15 May 2004

Posts: 48

10-02-2005 11:43

llGetRot and the Prim Editor Object Rotation field appear to have a chronic bug. If one increments or decrements the X or Z rotations using the editor or llSetRot, then the editor and llGetRot report the X and Z rotations correctly.
This is not true for Y rotations between 90 and 270.
What happens is that as Y rotation is incremented past 90 then suddenly X and Z rotations change to numbers close to 90, 180 etc, and Y goes to a strange number.
I talked to somelinden about this long ago, and was told it was likely the result of euler>quat>euler conversion. At the time I did not care too much, one could use the graphical editor to get the desired rotation. However, I am now trying to use rotations returned by llGetRot to calculate face angles, and this Y-rotation bug appears to be screwing things up. And yes, the same bug is there in 1.7.0(3

.
It seems to me that if one can get X- and Z-rotation to transform correctly through euler>quat>euler conversion, then it sould be possible to handle Y- correctly as well, since the whole system is symmetrical.
1) Has this been reporoted as a bug? (is there yet an accesible bug list?)
2) Is there a respose buried elswhere in the ForumSpam?
3) Does anyone have a work-around for a script to obtain sane results from llGetRot?

Seifert Surface

Mathematician

Join date: 14 Jun 2005

Posts: 912

10-02-2005 13:07

From: Fremont Cunningham

It seems to me that if one can get X- and Z-rotation to transform correctly through euler>quat>euler conversion, then it sould be possible to handle Y- correctly as well, since the whole system is symmetrical.

I'm not convinced that it is symmetrical. It seems to me that incrementing the x rotation always rotates around the global x axis, incrementing the y rotation mostly rotates around the global y axis (but sometimes not...?), and incrementing the z rotation always seems to result in a rotation around an axis depending on what the x and y rotations are.

I haven't yet needed to do much dealing with angles <-> rotations that hasn't worked by itself. One thing you might look at: if myrot is a rotation, then -myrot encodes the same geometrical rotation, but may interact with the conversion to angles differently. Also look out for angles near but below 360 that you really want to think of as near 0 but negative.

I certainly don't have a full understanding of what's going on here, but I know enough to know that it's pretty nasty.

Good luck...

_____________________

-Seifert Surface
2G!tGLf 2nLt9cG

Nathan Stewart

Registered User

Join date: 2 Feb 2005

Posts: 1,039

10-02-2005 13:49

Might be good to post this in the 1.7 forum, and if you think its a bug report it in 1.7, as that is getting priority at the moment.

There is updates on versions and knowsn issues but the known issues is a bit out of date www.secondlife.com/preview

_____________________

Ben Bacon

Registered User

Join date: 14 Jul 2005

Posts: 809

10-03-2005 07:06

From: Fremont Cunningham

llGetRot and the Prim Editor Object Rotation field appear to have a chronic bug.

I don't know how relevant this is to your problem - but Euler rotations have a chronic bug - and not just in SL!
There are three main reasons many 3d apps use quaternions instead of Eulers - and Gimbal lock is one of them. (Efficiency and smooth interpolation are the others)
What, specifically, do you need to do with the face angles? You may find that you can use the quats directly, rather than converting to Euler first.

Y-rotation bug
Fremont Cunningham Senior Wizard Join date: 15 May 2004 Posts: 48	10-02-2005 11:43 llGetRot and the Prim Editor Object Rotation field appear to have a chronic bug. If one increments or decrements the X or Z rotations using the editor or llSetRot, then the editor and llGetRot report the X and Z rotations correctly. This is not true for Y rotations between 90 and 270. What happens is that as Y rotation is incremented past 90 then suddenly X and Z rotations change to numbers close to 90, 180 etc, and Y goes to a strange number. I talked to somelinden about this long ago, and was told it was likely the result of euler>quat>euler conversion. At the time I did not care too much, one could use the graphical editor to get the desired rotation. However, I am now trying to use rotations returned by llGetRot to calculate face angles, and this Y-rotation bug appears to be screwing things up. And yes, the same bug is there in 1.7.0(3. It seems to me that if one can get X- and Z-rotation to transform correctly through euler>quat>euler conversion, then it sould be possible to handle Y- correctly as well, since the whole system is symmetrical. 1) Has this been reporoted as a bug? (is there yet an accesible bug list?) 2) Is there a respose buried elswhere in the ForumSpam? 3) Does anyone have a work-around for a script to obtain sane results from llGetRot?
Seifert Surface Mathematician Join date: 14 Jun 2005 Posts: 912	10-02-2005 13:07 From: Fremont Cunningham It seems to me that if one can get X- and Z-rotation to transform correctly through euler>quat>euler conversion, then it sould be possible to handle Y- correctly as well, since the whole system is symmetrical. I'm not convinced that it is symmetrical. It seems to me that incrementing the x rotation always rotates around the global x axis, incrementing the y rotation mostly rotates around the global y axis (but sometimes not...?), and incrementing the z rotation always seems to result in a rotation around an axis depending on what the x and y rotations are. I haven't yet needed to do much dealing with angles <-> rotations that hasn't worked by itself. One thing you might look at: if myrot is a rotation, then -myrot encodes the same geometrical rotation, but may interact with the conversion to angles differently. Also look out for angles near but below 360 that you really want to think of as near 0 but negative. I certainly don't have a full understanding of what's going on here, but I know enough to know that it's pretty nasty. Good luck... _____________________ -Seifert Surface 2G!tGLf 2nLt9cG
Nathan Stewart Registered User Join date: 2 Feb 2005 Posts: 1,039	10-02-2005 13:49 Might be good to post this in the 1.7 forum, and if you think its a bug report it in 1.7, as that is getting priority at the moment. There is updates on versions and knowsn issues but the known issues is a bit out of date www.secondlife.com/preview _____________________
Ben Bacon Registered User Join date: 14 Jul 2005 Posts: 809	10-03-2005 07:06 From: Fremont Cunningham llGetRot and the Prim Editor Object Rotation field appear to have a chronic bug. I don't know how relevant this is to your problem - but Euler rotations have a chronic bug - and not just in SL! There are three main reasons many 3d apps use quaternions instead of Eulers - and Gimbal lock is one of them. (Efficiency and smooth interpolation are the others) What, specifically, do you need to do with the face angles? You may find that you can use the quats directly, rather than converting to Euler first.

Welcome to the Second Life Forums Archive

Y-rotation bug