Maxon Developers Maxon Developers
    • Documentation
      • Cinema 4D Python API
      • Cinema 4D C++ API
      • Cineware API
      • ZBrush Python API
      • ZBrush GoZ API
      • Code Examples on Github
    • Forum
    • Downloads
    • Support
      • Support Procedures
      • Registered Developer Program
      • Plugin IDs
      • Contact Us
    • Categories
      • Overview
      • News & Information
      • Cinema 4D SDK Support
      • Cineware SDK Support
      • ZBrush 4D SDK Support
      • Bugs
      • General Talk
    • Unread
    • Recent
    • Tags
    • Users
    • Login

    Matrices from Right-Handed to Left-Handed

    Scheduled Pinned Locked Moved SDK Help
    3 Posts 0 Posters 423 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H Offline
      Helper
      last edited by

      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:   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?

      1 Reply Last reply Reply Quote 0
      • H Offline
        Helper
        last edited by

        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, 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,

        1 Reply Last reply Reply Quote 0
        • H Offline
          Helper
          last edited by

          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 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! 😄

          1 Reply Last reply Reply Quote 0
          • First post
            Last post