"Kenneth" <kdw### [at] gmailcom> wrote:

>
> You might notice that the code produces rotations for only TWO axes, around x
> and y; but that's enough for determining the proper orientation of an object.
> The third rotation axis is 'synthesized' by the other two, in a manner of
> speaking...

Now that I've had a chance to stand back and look at the results, I see that the
'3rd-axis' of rotation isn't really there. It would be the additional 'spin' or
facing-direction of the POV-Ray logo. Currently, the logo direction is just a
natural and automatic consequence of the code rotations in x and y.

I've already worked out one conceptual way of adding that spin-- to keep the
logo always facing -z, for example:

rotate (1 - (VECTOR.z))*90*y
THEN, the main rotations...
rotate <X_Y_PLANE_ANGLE,X_Z_PLANE_ANGLE,0>

The ordering of these is important. Note that there's a rotation in y first,
then a rotation in x, then *another* rotation in y. Simply adding the first
y-rotation within the 2nd rotate command does not produce the same results.

But I want the final rotation vector to be a *single* entity-- all the rotations
being combined-- in order to GET the final rotation angles themselves. The only
way to do that is to combine these two rotation statements into a transform, for
use. But I want to avoid using a transform-- because it becomes a pure matrix
behind-the-scenes, with no (easy!)way to then reconstruct the individual
rotations.

Although-- I'm still studying some matrix-to-angle code suggestions made by
others here  ;-)

While it's true that this 3rd-axis 'spin' can EASILY be added *manually* to an
object-- see the end of my scene file-- it would be far more elegant to do so
within the code (especially for animation purposes, where the 'spin' rotation
might need to constantly change.)

The code as-is is perfectly usable, though; it's just not as elegant or
self-contained as I'd like.

Post a reply to this message