File implements some generalized quaternion to/fro Euler angle routines. These are reversible and with +1,1,2,3 (right handed XYZ) template arguments are consistent with the matrix classes. What Euler angle routines are currently defined are not consistent with aiMatrixNxN and may not be accurate.
These routines are not perfect as is. The first ignores the handedness argument (wasn't confident what to do) and the second has some commented out code in the singularity branches which seemed out of place to me. I've adapted the code from different sources online more or less.
At any rate it's a start. Along side the shortcomings mentioned some matrix routines would also be a welcomed addition.
Feel free to change anything you like.as long as the basic functionality is preserved.
In my project space, I've put this file in the include/Cpp folder.
Mick P.
2010-08-25
Kim Kulling
2010-08-25
Hi,
thanks for your patch. Is it possible to get a small unittest for it? It will be much easier to verify that your code works right with a small cppunitclass as a unitets for it.
Kimmi
Mick P.
2010-08-25
Hi kimmi,
I have to apologize. I'm not sure exactly what you mean by a cppunitclass etc. I'm fairly confident it's good except for maybe at the singularities in the the to Euler routine.
I've tested it back and forth with a number of previously problematic files through the importer interface so at the least I think it's a step up from the present Euler code.
I can see the benefit of absolute validation, but am not really qualified for the task I think.
Alexander Gessler
2010-08-25
Hey!
I'm very positive to adding this to Assimp quickly, but I too believe that a unit test is needed.
If you provided a set of assertion-like snippets to verify the functionality .. i.e. a few conversions back and forth and tests for the proper outcome and detection of singularities - I would put them in the right unit-test format and integrate them with the existing tests so you can quickly proceed.
Bye, Alex
PS: input parameters and the expected outcome would do. But please don't take them from your implementation but rather from the math behind :-)
Mick P.
2010-08-25
I understand, but personally I've think I've contributed a bit already, and maybe this could be left to someone else.
The to quaternion code is extremely straight forward and I don't think it requires any validation to see what is going on.
I took the from quaternion code from here (http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToEuler/Quaternions.pdf) found on this (http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToEuler/index.htm) page.
The *2/*-2 also comes from that page, but is not present in the pdf. There is a kind of proof of why the *2 is desirable but it doesn't add up to me, and the pdf seems more authoritative. The final section of the pdf demonstrates a rigorous proof without any numbers. If you can make sense of it, it might help setup a test. This kind of stuff seems pretty obscure online. Finding the numbers laid out might be possible but I'm not committed enough to seek them out, much less work them out.
That said, this code is not in a position to effect anything in the library. It's a courtesy more or less. If someone uses it in their client app or importer, the responsibility should lie on them. Admittedly a "use at your own risk" comment might not hurt in the meantime. But I recommend fast tracking it.
If a visual test would satisfy, pick any importer, and slip the two routines in anywhere where a quaternion is computed and see if that bungles the output or not. Try the template in different orders if necessary.
Kim Kulling
2010-08-26
Hi mick-p
I have to apoligize. Currently the assimp-team is really rare on time. We have to verify, that your patch works. So a small testcase will be enough I think. This will accelerate the import of youur patch.
The other possible way is: we have to write it on our own and that needs time we do not have at this moment.
And thank you for your work!
Kimmi
Mick P.
2010-08-28
I see the UnitTest project space (just by chance today) but am not exactly clear what to add to it.
My personal feelings are if the project leaders want more stringent code it's their job to facilitate that, and if they can't find time to do so it's inappropriate to sit on code like this as an excuse.
That said I'm not sure where you'll find the numbers for your test, because the existing Euler routines appear way less reliable and are presumably themselves untested. And like I said before this code if/when introduced will not effect anything in the library in any way. So it seems like you're just being unnecessarily bureaucratic.
At any rate, if you have numbers for any particular Euler to quaternion implementation or a table found in some mathematics textbook. I'm confident if one checks out all other permutations must also hold. Just make sure the correct template arguments are provided so to match whatever numbers you decide are authoritative.
I agree proving the singularities would be worth while, but I'm afraid I'm not qualified to do that, and I'm not sure if I did my methods would be up to your standards. My time is at a premium also.
Mick P.
2011-05-30
Mick P.
2011-05-30
I happened to run into a model that crosses into the singularity...
qIn = {w=-0.70688528 x=-0.011297977 y=-0.70719147 z = 0.0080745481}
I had to correct the singularity code, by uncommenting the *2 (and *-2) bit.
So anyway, I'm sure now even in the singularity branches WYSIWYG.
It's not a full "unit test" proof, and I'm not sure how you'd arrange that. But it's 100% solid. You can use the values above to force a singularity. Dunno if that would be helpful in a unit test. Might be for an environment test.
I'm not sure what it means for a quaternion to be in a singularity Euler angles wise myself.
So right. I highly recommend incorporating the code somehow now. Be sure to uncomment the *2 and *-2 in the singularity branches and it's good.
Only the angles->quaternion handedness parameter is missing. I'm not sure if the current implementation is +1 for H. I don't know if that's right or left handed :D
I'm sure if someone needed the other hand, they could intuitively slip in the necessary *H operations.
Mick P.
2011-05-30
Nvm, my comments say, "// H: handedness. possible values, +1 for right handed, -1 for left handed."