I've been discussing in the some problems I was having with the interop between assimp and cml. The code used to convert a quaternion to a rotation matrix and viceversa seems to differ even using the same colum vector conventions.
At first I think cml was somehow bugged, but after some links now I think that assimp is the one that looks not standard. I would like to know if there is something I have missed, because right now I'm going to start to export animation data, so I need to transform assimp quaternions to cml quaternions and I'm missing here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-10-30
Hi,
I'm using assimp successfully with quats/bones etc in my own project.
However, I've just checked my code and I am transposing both the node matrix (although this is overwritten when animating I think?) AND the bone offset matrix.
No idea if/what is right/wrong here - I'm generally happy to just transpose/negate as required until things work!
Bye,
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wrote the quaternion code, but I'm not sure if it's actually right - this math is beyond my knowledge. I know that converting a rotation matrix to a quaternion and back yields the same matrix again - we verified this. So the only thing I can imagine which might be wrong is the transpose case. In that case, you'd have to negate the w component (or alternatively the xyz components) of the quaternion to fit it to your quaternions.
If you actually know the math background of those, I'd highly appreciate if you can look over the code and maybe point out inconsistencies or floating point precision corner case. The quaternion code works fine for me, but I wouldn't leave a chance to learn something or maybe get a more reliable quaternion code :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is Jesse (co-author of the CML, the library godog23 referred to). I've looked at the code, and it does appear to me that the quaternion-to-matrix and matrix-to-quaternion functions are the transposes of what they should be. From the following code in your Translation() function:
out.a4 = v.x;
out.b4 = v.y;
out.c4 = v.z;
I deduce that you're using column-vector notational convention. However, both of the aforementioned quaternion conversion functions appear to be set up for row vectors, hence the inconsistency.
As you note, the fact that both of the functions use the 'opposite' convention means that conversions two and from a quaternion or matrix will appear to be correct. However, users attempting to interoperate with other APIs may have to transpose matrices, negate w terms, or apply other workarounds in order to get the desired results.
Assuming I'm right about this (and I'm 99% sure that I am), I'd definitely suggest fixing it if possible. Just my $.02 :)
Jesse
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the late response. I'm pretty sure you are right. The Assimp internal matrix <-> quaternion behavior is consistent, that's why I never bothered. But when interacting with other's math libraries the deficiencies start to show.
I'm going to change this in Assimp. But I seriously fear the consequences of this change. Users all around the world will suddenly get reverse rotations in their imported animations…. grmpf. I see no way how to handle this cleanly, we'll just have to bite that bullet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I certainly sympathize! Making changes to an existing API can be a pain.
I'm fairly certain of my correctness, but if you haven't already, I'd recommend consulting some different references, just to fully confirm for yourself that the change needs to be made. (There are links to a number of references in the CML thread mentioned earlier, and there are plenty of other references available online as well.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A warning to everyone using the Open Asset Import Library: we adapted the matrix - quaternion conversion code so that it now should be using the correct column-major matrix layout. But this means that all quaternions that Assimp outputs are INVERTED. This is correct now, but previous users of the library will most probably have adapted their code to the old, wrong quaternion orientation. If you are a previous user of Assimp and you update Assimp to a revision beyond 502, you HAVE TO adapt your animation loading code to suit the new quaternion orientation.
This simply means inverting the w component of any quaternion if you want to get back the old quaternion orientation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've been discussing in the some problems I was having with the interop between assimp and cml. The code used to convert a quaternion to a rotation matrix and viceversa seems to differ even using the same colum vector conventions.
At first I think cml was somehow bugged, but after some links now I think that assimp is the one that looks not standard. I would like to know if there is something I have missed, because right now I'm going to start to export animation data, so I need to transform assimp quaternions to cml quaternions and I'm missing here.
: http://cmldev.net/forums/viewtopic.php?t=279
Hi,
I'm using assimp successfully with quats/bones etc in my own project.
However, I've just checked my code and I am transposing both the node matrix (although this is overwritten when animating I think?) AND the bone offset matrix.
No idea if/what is right/wrong here - I'm generally happy to just transpose/negate as required until things work!
Bye,
Mark
I wrote the quaternion code, but I'm not sure if it's actually right - this math is beyond my knowledge. I know that converting a rotation matrix to a quaternion and back yields the same matrix again - we verified this. So the only thing I can imagine which might be wrong is the transpose case. In that case, you'd have to negate the w component (or alternatively the xyz components) of the quaternion to fit it to your quaternions.
If you actually know the math background of those, I'd highly appreciate if you can look over the code and maybe point out inconsistencies or floating point precision corner case. The quaternion code works fine for me, but I wouldn't leave a chance to learn something or maybe get a more reliable quaternion code :-)
Hi,
This is Jesse (co-author of the CML, the library godog23 referred to). I've looked at the code, and it does appear to me that the quaternion-to-matrix and matrix-to-quaternion functions are the transposes of what they should be. From the following code in your Translation() function:
out.a4 = v.x;
out.b4 = v.y;
out.c4 = v.z;
I deduce that you're using column-vector notational convention. However, both of the aforementioned quaternion conversion functions appear to be set up for row vectors, hence the inconsistency.
As you note, the fact that both of the functions use the 'opposite' convention means that conversions two and from a quaternion or matrix will appear to be correct. However, users attempting to interoperate with other APIs may have to transpose matrices, negate w terms, or apply other workarounds in order to get the desired results.
Assuming I'm right about this (and I'm 99% sure that I am), I'd definitely suggest fixing it if possible. Just my $.02 :)
Jesse
Sorry for the late response. I'm pretty sure you are right. The Assimp internal matrix <-> quaternion behavior is consistent, that's why I never bothered. But when interacting with other's math libraries the deficiencies start to show.
I'm going to change this in Assimp. But I seriously fear the consequences of this change. Users all around the world will suddenly get reverse rotations in their imported animations…. grmpf. I see no way how to handle this cleanly, we'll just have to bite that bullet.
I certainly sympathize! Making changes to an existing API can be a pain.
I'm fairly certain of my correctness, but if you haven't already, I'd recommend consulting some different references, just to fully confirm for yourself that the change needs to be made. (There are links to a number of references in the CML thread mentioned earlier, and there are plenty of other references available online as well.)
A warning to everyone using the Open Asset Import Library: we adapted the matrix - quaternion conversion code so that it now should be using the correct column-major matrix layout. But this means that all quaternions that Assimp outputs are INVERTED. This is correct now, but previous users of the library will most probably have adapted their code to the old, wrong quaternion orientation. If you are a previous user of Assimp and you update Assimp to a revision beyond 502, you HAVE TO adapt your animation loading code to suit the new quaternion orientation.
This simply means inverting the w component of any quaternion if you want to get back the old quaternion orientation.