Rotation conversion issue.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 27/03/2003 at 09:57, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   8.100 
Platform:   Windows  ;   
Language(s) :     C++  ;

---------
Hello again,
C4D uses a rotational system based upon HPB.  For lights pointed at the origin, the only values of real interest are Heading and Pitch, Bank just spins the light about its own Z-axis.  So, for simplicity, these rotations have become Spherical Coordinates (R, theta, phi) where R isn't of much concern or Elevation and Azimuth angles off of the XZ plane.
The incoming values are Euler angles (rotations about the fixed world axes).  Order seems to be set, which explains some of the strange results in Poser when the (Infinite) light is, for instance, rotated in the Y-axis after having been rotated in the other axes.  Since no information is given, I must assume that the order in the Poser file (XYZ) is the order in which the rotations are applied.
So, my question is this: How do I convert fixed XYZ axis rotations into HP spherical angles?  I'll keep thumbing through my books, but haven't hit upon anything yet.  One possible solution (sarcasm) is to calculate the XYZ point on a unit sphere and use that point to solve for spherical coordinates (P(x,y,z) = R*sin(theta)*cos(phi), R*sin(theta)*sin(phi), R*cos(theta)), but as is easily seen, there are two solutions for x and y.  It has been some time since this kind of problem has arisen in my programming efforts - code of mine which might have helped has long since been lost to the great bit-bucket in the sky.
Thanks for any mathematical or algorithmic links or information,
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 27/03/2003 at 11:55, xxxxxxxx wrote:

Addition information:
The rotation order is definitely: ZYX-dependent.  Z always rotates about the world z-axis so it is first.  Y is dependent upon Z rotation only; second.  X is dependent upon Z and Y rotation; third.
Therein lies the problem.  C4D's independent system of rotations is making it difficult to work with an order-dependent system of rotations.  Also, Poser uses a right-handed coordinate system, while C4D uses a left-handed system which just makes this all the more confusing.
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 27/03/2003 at 13:21, xxxxxxxx wrote:

This is outside the scope of the developer support, since it's more of a mathematical question.
My suggestion is to not bother with converting ZYX to HPB. Instead, just apply these rotations to a matrix and use SetMl() to set it on the object. Perhaps it's as simple as obj->SetMl(MatrixRotX(x) * MatrixRotY(y) * MatrixRotZ(z)).

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 27/03/2003 at 17:13, xxxxxxxx wrote:

I'll agree that it's a mathematical question, but I think that I'm more interested in how C4D handles angles than in the actual conversion.  I'm quite certain of the behavior of the angles within Poser (and the same values within the file).  I spent most of last night and some of today rigorously verifying its behavior.
I considered the matrices, but had no idea of how to use them - this is my first time needing them.  Perhaps it's not as simple as obj->SetMl(MatrixRotX(x)*MatrixRotY(y)*MatrixRotZ(z)).  Because that doesn't seem to work, even considering that the only difference incurred by coordinate system handedness is the positive X rotation direction flips (X[rh] = -X[lh]) and that the system must be rotated 180d on the world Y-axis afterwards (or the "scene" rotated 180d against the lights - it's all relative).
One thing to know is whether C4D uses pre- or post-multiplication of matrices for ordering - i.e.: does your statement create a transformation matrix that rotates in the order ZYX or XYZ (though, neither ordering worked)?  I assuredly hope that it *does* matter, or I will be forced to that point-in-space calculation.
One disadvantage of using the matrix methods is that the resulting HPB's give no clues.  I am currently left to visual inspection since what happens between the XYZ angles and the HPBs after concatenation is "blackbox".  I would've expected your statement to do the job as well.  Since the Null object containing the light is at the origin, I may try SetMg() instead, just for kicks.  Maybe that will yield the expected results.
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 27/03/2003 at 23:27, xxxxxxxx wrote:

The convention in C4D is that matrices are used from the left, i.e. Ax instead of xA. So the order in my example was ZYX. You'll find [re]learning matrix math essential for any kind of 3D programming.
And the matrix method will give the same HPB as any other method you could think of. The resulting HPB will make just as much sense, i.e. none unless for simple examples.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 28/03/2003 at 06:42, xxxxxxxx wrote:

I think you misunderstood me.  My knowledge of matrix math is well-established (how could I have written a non-Java3D 3D application in Java without them) - I meant use of the matrix methods in the SDK - my mistake. :)
What I have found is that obj->SetMg(ZY-X) [to paraphrase] seems to be working in this case.  As was stated, it is difficult to assess the correctness of the results since the numbers are in HPB which are now different (after abandoning obj->SetRot()) than the input values.  I might try HPBToMatrix() and use the rotation vectors to back-check the values (?).
Just a comment: I wish that conversions like this were more readily available.  I have at my disposal: "Computer Graphics" - Foley..., "3D Computer Graphics" - Watt, "Computer Graphics Handbook", "Computer Graphics - Schaum", Graphics Gems I-IV, "3D Game Programming", "High-Resolution Computer Graphics Using C", "Computer Graphics for Java Programmers", "Numerical Recipes in C", "Mathematical, Scientific, and Engineering Formulas, Tables, Functions, Graphs, Transforms", "Machinery's Handbook 26", and a shelf of mathematics related books and not one of them discusses converting to or from HPB, let alone converting coordinate system handedness.  That's quite a collection, huh?  Rotations are, as usual, the bane of 3D (even quaternions, for all of their hyperspherical power, have downsides). If you have a reference that covers some of these rarely discussed issues, I'd love to add it to my collection.
Thanks,
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 28/03/2003 at 10:06, xxxxxxxx wrote:

I don't have any such reference, and what's worse it's often pretty hard to find such things on the Internet as well. I think that educated trial-and-error is the best way... :-)

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 28/03/2003 at 10:35, xxxxxxxx wrote:

I noticed. :0)
Interestingly, most of the results in a Google search were related to aviation navigation, which makes sense since airplanes use HPB for navigation but XYZ rotations from a fixed reference point or with reference to the globe are sometimes required.  After that, it became too complex mathematically for me!  Had I actually  followed this interest of mine in the past, flying that is, I might have the information at hand. ;0)
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/04/2003 at 12:36, xxxxxxxx wrote:

Most of the worthwhile references I've ever found on rotations and the math behind them have been in phsics texts. Books like Arfken's "Mathmatical Methods for Physicists" or Fetter and Walecka's "Theoretical Mechanics of Particles and Continua" are the things I look to the most. Of course, they leave many things unstated and can therefore be rather frustrating but all of the information is there if you know how to get it out.

John