ebassi / graphene

A thin layer of graphic data types

Home Page:http://ebassi.github.io/graphene

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Issue with euler conversions

alexlarsson opened this issue · comments

I'm having some issues with euler conversion in gthree.
I'm not sure exactly what is going wrong, but at least I found a testcase that fails, but should not.

First we use graphene_matrix_init_look_at() to create a rotation matrix, then we first directly convert it to a quaterion, secondly we convert it to a quaternion via an euler, like so:

  graphene_quaternion_init_from_matrix (&q1, &m);
  graphene_euler_init_from_matrix (&e, &m, GRAPHENE_EULER_ORDER_DEFAULT);
  graphene_euler_to_quaternion (&e, &q2);

These should produce equal q1 and q2, but for some orientations it does not:

Looking at origin from 0.000000 0.000000 f
With q_from_m: +0.000 +0.707 +0.000 +0.707, inverted: +0.000 +0.707 +0.000 +0.707
With e_from_m: +0.000 -0.000 -0.707 +0.707, inverted: +0.000 -0.000 -0.707 +0.707

Looking at origin from 0.000000 -0.707107 f
With q_from_m: +0.000 +0.000 +0.000 +1.000, inverted: +0.000 +0.000 +0.000 +1.000
With e_from_m: -0.000 -0.000 +0.000 +1.000, inverted: -0.000 -0.000 +0.000 +1.000

Looking at origin from 0.000000 0.000000 f
With q_from_m: +0.000 +0.383 +0.000 +0.924, inverted: +0.000 +0.383 +0.000 +0.924
With e_from_m: +0.000 -0.000 -0.383 +0.924, inverted: +0.000 -0.000 -0.383 +0.924

They are not vastly different, it seems like just y and z are mixed up in the quarternions. I don't know which one is right though...

Sample code here:
test-euler.c

y and z are mixed up and sign-flipped.

Eh, ignore the "looking at from headers", the testcase is buggy, it should be:

Looking at origin from 1.000000 0.000000 0.000000
With q_from_m: +0.000 +0.707 +0.000 +0.707, inverted: +0.000 +0.707 +0.000 +0.707
With e_from_m: +0.000 -0.000 -0.707 +0.707, inverted: +0.000 -0.000 -0.707 +0.707

Looking at origin from 0.000000 0.000000 1.000000
With q_from_m: +0.000 +0.000 +0.000 +1.000, inverted: +0.000 +0.000 +0.000 +1.000
With e_from_m: -0.000 -0.000 +0.000 +1.000, inverted: -0.000 -0.000 +0.000 +1.000

Looking at origin from 0.500000 0.000000 0.500000
With q_from_m: +0.000 +0.383 +0.000 +0.924, inverted: +0.000 +0.383 +0.000 +0.924
With e_from_m: +0.000 -0.000 -0.383 +0.924, inverted: +0.000 -0.000 -0.383 +0.924

I assume this has now been fixed by #193.