*On 19/01/2008 at 23:08, xxxxxxxx wrote:*

User Information:

Cinema 4D Version: R9-R10

Platform: Windows ; Mac ; Mac OSX ;

Language(s) : C++ ;

---------

Unfortunately, Poser isn't the problem in this situation. Instead it is Cinema 4D that is the problem.

Basics: Poser uses a right-handed coordinate system. The Spherical Falloff Zone (SFZ) matrices are the same (but seem to be in a non-standard row-major format). So, here's an example right-handed matrix (NudeBody:lCollar:jointY:innerMatSphere) :

-0.0312836 -0.00783613 -0.013012 0 (X-Axis Basis)

-0.012188 0.0731294 -0.0147378 0 (Y-Axis Basis)

-0.0297495 0.00843272 0.0664458 0 (Z-Axis Basis)

0.104637 0.507761 -0.0222363 1 (translation: x,y,z)

Translation, simple: invert the z value. Scale, simple: extract the components using basis vector lengths. Rotations are never simple (read on).

In a right-handed coordinate system the positive rotations are all counter-clockwise when viewed down their respective axes. Poser, again, is spot on here. What I find is that Cinema 4D, with a left-handed coordinate system, doesn't stick to 'usual'. Usually, in a left-handed coordinate system, the positive rotations are all clockwise. Not so for Cinema 4D! They are all counter-clockwise. So, every RH->LH conversion method that I've employed to convert these SFZ matrices has failed to be consistent because they assume these conventions which don't apply to Cinema 4D!

Problem: How to convert a standard right-handed coordinate system matrix to a non-standard left-handed coordinate system matrix (and not go insane in the process)?

When you look at the two systems' rotations graphically, the only difference is that the z rotations are the opposite direction (since counter-clockwise for z into the screen is clockwise for z out of the screen). In other words, only the z-rotation needs negation and the x and y rotations need to be preserved. Unfortunately, similarity matrices completely flip the rotational system (because standard left-handed systems rotate in the opposite direction in every axis). Looking at the concatenation details of matrices, it is evident that one cannot simply negate particular matrix elements. Concatenation involves both multiplication and addition of terms. That addition of terms will confound *any* attempt to simply alternate systems via element negation.

I had considered applying a negative z-scale to the matrix but this may either A) not change the direction of rotations or B) change the direction of all rotations. As noted, neither of these is satisfactory. Also considered was extraction of the rotations as Euler angles but most of these end up zeroing the z-rotation (+0 = -0). That doesn't accomplish anything, does it?

This is quite a situation, huh? I can't simply negate elements of the matrix and I can't simply extract the z-rotation and rebuild the matrix afterwards.

ETA: For the sake of argument, the joint orientation matrix is applied to the spheres as well. I was just thinking that the z-rotation of the sphere could be negated and maybe resolve the problem. But this wouldn't work in any situation where the joint orientation is non-zero (as all of the rotations are combined)! It also wouldn't work as the Cinema 4D HPB rotations are not directly relatable to the Euler rotations from the matrix.

Any ideas on how to handle this?

]]>*On 19/01/2008 at 23:08, xxxxxxxx wrote:*

User Information:

Cinema 4D Version: R9-R10

Platform: Windows ; Mac ; Mac OSX ;

Language(s) : C++ ;

---------

Unfortunately, Poser isn't the problem in this situation. Instead it is Cinema 4D that is the problem.

Basics: Poser uses a right-handed coordinate system. The Spherical Falloff Zone (SFZ) matrices are the same (but seem to be in a non-standard row-major format). So, here's an example right-handed matrix (NudeBody:lCollar:jointY:innerMatSphere) :

-0.0312836 -0.00783613 -0.013012 0 (X-Axis Basis)

-0.012188 0.0731294 -0.0147378 0 (Y-Axis Basis)

-0.0297495 0.00843272 0.0664458 0 (Z-Axis Basis)

0.104637 0.507761 -0.0222363 1 (translation: x,y,z)

Translation, simple: invert the z value. Scale, simple: extract the components using basis vector lengths. Rotations are never simple (read on).

In a right-handed coordinate system the positive rotations are all counter-clockwise when viewed down their respective axes. Poser, again, is spot on here. What I find is that Cinema 4D, with a left-handed coordinate system, doesn't stick to 'usual'. Usually, in a left-handed coordinate system, the positive rotations are all clockwise. Not so for Cinema 4D! They are all counter-clockwise. So, every RH->LH conversion method that I've employed to convert these SFZ matrices has failed to be consistent because they assume these conventions which don't apply to Cinema 4D!

Problem: How to convert a standard right-handed coordinate system matrix to a non-standard left-handed coordinate system matrix (and not go insane in the process)?

When you look at the two systems' rotations graphically, the only difference is that the z rotations are the opposite direction (since counter-clockwise for z into the screen is clockwise for z out of the screen). In other words, only the z-rotation needs negation and the x and y rotations need to be preserved. Unfortunately, similarity matrices completely flip the rotational system (because standard left-handed systems rotate in the opposite direction in every axis). Looking at the concatenation details of matrices, it is evident that one cannot simply negate particular matrix elements. Concatenation involves both multiplication and addition of terms. That addition of terms will confound *any* attempt to simply alternate systems via element negation.

I had considered applying a negative z-scale to the matrix but this may either A) not change the direction of rotations or B) change the direction of all rotations. As noted, neither of these is satisfactory. Also considered was extraction of the rotations as Euler angles but most of these end up zeroing the z-rotation (+0 = -0). That doesn't accomplish anything, does it?

This is quite a situation, huh? I can't simply negate elements of the matrix and I can't simply extract the z-rotation and rebuild the matrix afterwards.

ETA: For the sake of argument, the joint orientation matrix is applied to the spheres as well. I was just thinking that the z-rotation of the sphere could be negated and maybe resolve the problem. But this wouldn't work in any situation where the joint orientation is non-zero (as all of the rotations are combined)! It also wouldn't work as the Cinema 4D HPB rotations are not directly relatable to the Euler rotations from the matrix.

Any ideas on how to handle this?

]]>*On 21/01/2008 at 00:19, xxxxxxxx wrote:*

More research, more information.

Okay, it appears that the Poser spherical falloff zone matrices are in the same format employed by Alan Watt in "3D Computer Graphics". That is, right-handed row-major:

sx 0 0 0

0 sy 0 0

0 0 sz 0

tx ty tz 1

Pages 4 and 5 of the Second Edition match exactly, including the individual rotation cosines and sines (even in sign). So, now I know what is being given.

The first question then is: How do I convert (shoe-horn) that into a Cinema 4D Matrix (since that is where it will be stored and 'manipulated')? One thing that is not known is whether the rows or columns of the input matrix are considered the basis vectors for the axes. That would go a long way to establishing, say, what to use to extract scales (as they are the lengths of the orthonormal vectors). Since Cinema 4D Matrices are structured on this premise - three vectors representing the axial bases - that information is tantamount.

Thanks,

]]>*On 21/01/2008 at 16:19, xxxxxxxx wrote:*

Solved! :)

The rotation extraction required some rearranging of terms from the C4D matrix since the input matrix is in row-major format. Instead of negating the z rotation, obviously :sarcasm: you have to negate the x and y rotations. But then the matrix determinant is needed to negate these in the opposite direction (a positive determinant, multiply by -1, a negative determinant, multiply by 1).

Sheesh. I ~~loathe~~ matrices. ;) This entire excursion into insanity could have been avoided had the Poser developers just stored the translation, scale, and rotation vectors (9 real values) instead of wasting time AND space with a full-on matrix (16 values). Matrix decomposition is a pita. I put a hex on them! :D