0
\$\begingroup\$

I need help on something I'm struggling with very much.

I am working on a TouchDesigner patch where I have a Camera COMP with rotation on x, y and z axes. I need the formulas to convert such rotations in a direction vector, that I am going to use in other programs to define the direction I am looking at. The point is having camera and for instance a microphone pointing in the same direction.

I have implemented the rotation matrix as explained in the "General 3D rotation" section of this Wikipedia article.

With this equations implemented I get the direction vector correctly but only when rotating on a single axe. But when I rotate on multiple axes it gets weird.

Example: the initial camera vector is {0,0,-1} with no rotation. So basically the camera is pointing in the negative-Z axes. With Y-rotate 45° the equation gives me {-0.707, 0, -0.707}, and it looks like the camera is actually pointing in that direction.

Now, if I add an X-rotate 90° the equation gives me {-0.707, -0.707, 0}, which is weird because the camera is now pointing in the negative Y, as if the vector was {0, -1, 0}.

I am missing something huge in this transformation. Can anybody please help me out? Thanks

\$\endgroup\$
2
  • \$\begingroup\$ What did you expect instead? Because there's no one universal convention for coordinate system and rotation sequence, this could just be a case where your desired convention differs from the one the formula was written for. We can't guess at the right correction from the math alone though. So, tell us, in your app, which way do the x+, y+, and z+ axes point? Which rotation do you want to always apply around the camera's local axis, and which one do you want to always apply around the global axis? Note that if you're trying to compose rotations over time, Tait-Bryan angles are not the way to go \$\endgroup\$
    – DMGregory
    Commented Apr 5 at 14:36
  • \$\begingroup\$ When the camera is 90^ rY I want the direction vector to be {-1,0,0} and from here, with a -90^ rX I want it to be {0,-1,0}. In this case, the camera is actually pointing at {-1,-1,0} due to the camera orientation. As answered here, do I need to implement quaternions instead of rotation matrices? \$\endgroup\$ Commented Apr 6 at 15:31

1 Answer 1

0
\$\begingroup\$

I recommend using quaternions because Euler angles have the natural flaw of "Gimbal lock" and the interpolation of quaternions is easier and more convenient.

\$\endgroup\$
2
  • \$\begingroup\$ -1; the asker is using Rotation Matrices, which are not Euler Angles and don't have the same problems. \$\endgroup\$
    – Tim C
    Commented Apr 5 at 17:01
  • 1
    \$\begingroup\$ noodle_run has a point. Although OP is converting their angles to a rotation matrix, they're still using Tait-Bryan angles (commonly called Euler angles, though they're a slightly different representation with the same core issues) as the source of truth. That means changes in those angular inputs can lead to gimbal lock problems and other common angular math issues in the rotation matrices they produce. \$\endgroup\$
    – DMGregory
    Commented Apr 5 at 17:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .