0
\$\begingroup\$

My code for rotating my 3D fps camera isn't working as expected.
I expect that the X-axis does rotate with the Y-axis, but it ain't so.

I made some pictures to explain it better, I think its doing global rotation instead of local rotation.
But I searched in the internet and used code for local rotation and it was still the same result.

Image

  1. Normal Position
  2. Rotated on Y-Axis
  3. Rotated on X-Axis (how it is)
  4. Rotated on X-Axis (how it should be)

And this is my rotating code: X-Axis

float sx = sinf(x);
float cx = cosf(x);

up.y = up.y*cx - up.z*sx;
up.z = up.y*sx + up.z*cx;

center.y = center.y*cx - center.z*sx;
center.z = center.y*sx + center.z*cx;

Y-Axis

Math::Vector3f f = Normalise(center - eye);

float sy = sinf(y);
float cy = cosf(y);

center.z = eye.z + f.z*cy - f.x*sy;
center.x = eye.x + f.z*sy + f.x*cy;

It doesn't matter with which order I rotate, still the same.

\$\endgroup\$
2
  • \$\begingroup\$ Gimbal lock hits every beginner so hard \$\endgroup\$ Commented Apr 22, 2012 at 9:08
  • \$\begingroup\$ Are you sure it's Gimbal Lock? Seems more like global/local rotation issue to me \$\endgroup\$
    – Pillum
    Commented Apr 22, 2012 at 16:24

1 Answer 1

0
\$\begingroup\$

Hmm, when you update a point, e.g. your center, you destroy the information! Here's a snippet to illustrate my point:

 NewCenter.y = center.y * cx - center.z * sx;
 NewCenter.z = center.y * sx + center.z * cx;
 center = NewCenter;

The problem is that in your first snippet, the center.y component got "dirty" before it could be used in your center.z computation. It's simple matrix-vector multiplication.

UPDATE

If one wishes to devise a transformation chain in which the x axis moves together with the y axis, then this is achievable through the following set of transformations: enter image description here

If the point to be transformed is (x,y,z), then it has to undergo a series of frame transformations: from F2 to F1 you have a rotation against the x by an angle alpha, then from F1 to F0 = world system, you have a rotation against the y axis by an angle beta. Chaining the transforms together, you should get the final position of your point in the world system.

You can see it as a double rotation joint system, the camera being attached to the x axis, which is in term attached to the y joint.

\$\endgroup\$
5
  • \$\begingroup\$ I understand what you say, but unfortunately it didnt help. :( \$\endgroup\$
    – Pillum
    Commented Apr 20, 2012 at 14:24
  • \$\begingroup\$ Axes that move together are specific to gimbal mechanisms. Are you sure that is what you want? If so, I'll be back with a description of what can be done. Do be aware that such things are bad due to the excessively mentioned "gimbal lock".. \$\endgroup\$
    – teodron
    Commented Apr 20, 2012 at 16:28
  • \$\begingroup\$ Yes, this is what I want or do you know any better method for a fps camera with lookat? \$\endgroup\$
    – Pillum
    Commented Apr 21, 2012 at 18:27
  • \$\begingroup\$ Yes, I used both angle descriptors and quaternions to implement camera followers for 3rd and 1st person systems. Quaternions achieve smoother rotations.. If you want the full solution (it's D3D, check it out here dhpoware.com/demos/d3dCamera2.html). If you want to work with just two angles, try and check whether my answer is in the direction you want to go. \$\endgroup\$
    – teodron
    Commented Apr 22, 2012 at 8:02
  • \$\begingroup\$ Thank you for the update and link, but isn't this the same in OpenGL dhpoware.com/demos/glCamera2.html ? \$\endgroup\$
    – Pillum
    Commented Apr 22, 2012 at 15:30

You must log in to answer this question.

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