Matrices from RightHanded to LeftHanded

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/01/2008 at 23:08, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R9R10
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 righthanded coordinate system. The Spherical Falloff Zone (SFZ) matrices are the same (but seem to be in a nonstandard rowmajor format). So, here's an example righthanded matrix (NudeBody:lCollar:jointY:innerMatSphere) :
0.0312836 0.00783613 0.013012 0 (XAxis Basis)
0.012188 0.0731294 0.0147378 0 (YAxis Basis)
0.0297495 0.00843272 0.0664458 0 (ZAxis 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 righthanded coordinate system the positive rotations are all counterclockwise when viewed down their respective axes. Poser, again, is spot on here. What I find is that Cinema 4D, with a lefthanded coordinate system, doesn't stick to 'usual'. Usually, in a lefthanded coordinate system, the positive rotations are all clockwise. Not so for Cinema 4D! They are all counterclockwise. 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 righthanded coordinate system matrix to a nonstandard lefthanded 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 counterclockwise for z into the screen is clockwise for z out of the screen). In other words, only the zrotation needs negation and the x and y rotations need to be preserved. Unfortunately, similarity matrices completely flip the rotational system (because standard lefthanded 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 zscale 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 zrotation (+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 zrotation 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 zrotation of the sphere could be negated and maybe resolve the problem. But this wouldn't work in any situation where the joint orientation is nonzero (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?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
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, righthanded rowmajor:
sx 0 0 0
0 sy 0 0
0 0 sz 0
tx ty tz 1Pages 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 (shoehorn) 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,

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
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 rowmajor 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
loathematrices. ;) 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 fullon matrix (16 values). Matrix decomposition is a pita. I put a hex on them! :D