Re: [ggt-devel] Question about EulerAngleZXY, XYZ, ZYX

[Allen B. <al...@vr...>]

Doug McCorkle wrote:

> Allen Bierbaum wrote:
>
>> Doug McCorkle wrote:
>>
>>> Allen Bierbaum wrote:
>>>
>>>> Doug McCorkle wrote:
>>>>
>>>>> Allen Bierbaum wrote:
>>>>>
>>>>>> Allen Bierbaum wrote:
>>>>>>
>>>>>>> Unfortunately, it looks like there are some bugs in the 
>>>>>>> conversion somewhere.  My guess is that there are some border 
>>>>>>> cases in the extraction of the euler angles from the Matrix.
>>>>>>>
>>>>>>> I have added a new test case that exhaustively tests all Euler 
>>>>>>> getting and setting to find these issues. The test can be found 
>>>>>>> in the MatrixGenTest test case.  If anyone has some time to look 
>>>>>>> into this, you can use this test case to reproduce the problem.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I just commited some changes that should fix the errors. (at 
>>>>>> least it fixes the ones the test case found :)
>>>>>>
>>>>>> Give it a spin and let me know.
>>>>>>
>>>>> Just do a cvs checkout I assume?
>>>>>
>>>> Yep.
>>>>
>>>>> Thanks for the prompt response. This was going to be my evening 
>>>>> project but I guess I can do some testing instead. I appreciate 
>>>>> the help.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I wasn't planning on working on it, but I had some down time 
>>>> waiting for some builds and I found a good solid algorithm in a 
>>>> reference so I just gave it a try.
>>>>
>>> Ok. It appears that things are better but not quite right. If 
>>> rotations are purely about an individual axis X,Y,Z everything works 
>>> fine. If rotations become compounded things begin to act odd. This 
>>> affect may be due to us not understanding how rotations are applied 
>>> in OSG though so I would like to do more testing. Some things do 
>>> appear to working better but one odd thing did occur. With EulerXYZ 
>>> under the old version of gmtl  the compound rotations appeared to 
>>> work correctly no mater what had been done. This does not appear to 
>>> be working now. I will continue to test and try to provide better 
>>> feedback.
>>
>>
>>
>> One point of feedback.  Because Euler angles are non-unique, 
>> sometimes the angles returned do not appear to be continuous.  There 
>> is really no way around this.  The test code I wrote sets a matrix 
>> using a set of euler angles and then extracts the euler angles and 
>> uses the extracted eulers to make a new matrix.  Then it tests if the 
>> two matrices are equal.  Note, that this does not require that the 
>> original euler values and the extracted euler values must match.  It 
>> only requires that the values are functionally equivalent.  The test 
>> shows that this works for all angles in the range of -190 degrees to 
>> +190 degrees for x,y, and z in all 3 euler types.
>>
> That is what I am seeing. The angles are not continuous. Is there a 
> better way to handle this? I need to extract rotations for XYZ out of 
> a matrix. I thought that EulerAngle would be the best way. Is there a 
> better way?

Depends upon why you need them to be continuous.  You could always use 
Quaternions if you needs something that has numbers that look more 
continuous.

-Allen

>
>> -Allen
>>
>>>
>>>> -A
>>>>
>>>>>
>>>>>> -A
>>>>>>
>>>>>>>
>>>>>>> -Allen
>>>>>>>
>>>>>>> Doug McCorkle wrote:
>>>>>>>
>>>>>>>>  Hello,
>>>>>>>>      When using gtml I noticed that when I pass an identity 
>>>>>>>> Matrix44f into
>>>>>>>>  make< gmtl::EulerAngleZXY >( identity ) that I get back 
>>>>>>>> 90,0,90. If I
>>>>>>>>  ask for an EulerAngleXYZ I get back 0,0,0 and ZYX return 0, 
>>>>>>>> nan, 0. Is
>>>>>>>>  this the correct behavior of EulerAngle? I thought that no 
>>>>>>>> matter what
>>>>>>>>  Euler combination that I ask for should return 0,0,0 for an 
>>>>>>>> identity
>>>>>>>>  matrix. Thanks for the help in understanding this better. I am 
>>>>>>>> using
>>>>>>>>  gmtl 0.4.5.
>>>>>>>>
>>>>>>>>
>