1
\$\begingroup\$

I am taking a course in computergraphics and we talk a lot about OpenGL and the math you need to do everything OpenGL does "by hand". A Question which was asked in an old exam (I am preparing at the moment) was:

Why is the following Cameraposition considered problematic? eye = (0,0,0), at=(0,-2,0) and up = (0,1,0)

Is it because the eye-at = (0,2,0) and therefore the cross product of up x (eye-at) = (0,0,0) and that means, that no real transformation matrix can be constructed?

I found a post where someone asked a similiar question ( https://gamedev.stackexchange.com/a/45328/50476 ), but the explanation is somehow strange for me, because he says that he wants to calculate the cross product of the eye vector and the up vector. But there is no need for that, if you want to be able to calculate the transformation matrix?

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Yes... Just follow your nose. I mean, literally, point your nose ("at") at 0,-2,0 (say, South) and the top of your head ("up") at 0,1,0 (North). No solution! Even if "up" isn't 90 degrees from "at", as long as it's not in line with "at" (angle between them 0 or 180) is unambiguous enough. \$\endgroup\$ – david van brink Dec 10 '14 at 22:53
2
\$\begingroup\$

Well, that is the mathematical reason why it's problematic, but I'd prefer an analytical explanation.

A LookAt(pos, look, up) transform (you call it "cameraposition") is meant to represent a camera located at pos, pointing at look. However, with just pos and look, there are an infinite amount of possibilities for your camera, as you rotate it through the axis between pos and look.

Enter up. up is meant to disambiguate between the infinite cameras that can be placed at pos and pointing at look, by setting a vector to point up. In principle you need a vector orthogonal to the axis between pos and look, but in practice, any vector that you can use to disambiguate, and choose a rotation for your camera is acceptable.

If pos = (0, 0, 0), look = (0, -2, 0) and up = (0, 1, 0), You are placing the camera in the origin of the world and looking straight down. Now you need a vector to choose the rotation of that camera. Almost any vector would do, but (0, 1, 0) happens to be one of those that doesn't work. The vector is pointing straight up, is parallel to the axis between pos and look, and cannot be used to choose a rotation for the camera.

Any other vector where x != 0 or z != 0 would work though.

\$\endgroup\$
0
\$\begingroup\$

Is it because the eye-at = (0,2,0) and therefore the cross product of up x (eye-at) = (0,0,0) and that means, that no real transformation matrix can be constructed?

Exactly, the actual values in the resulting matrix is just the coordinates of the view direction (at-eye), up and right vectors next to each other;

result = [[right.x up.x view.x]
          [right.y up.y view.y]
          [right.z up.z view.z]]

They have to be orthogonal to each other so that's why the cross products need to happen. Some libraries provide a arbitrary up should the user supplied one be invalid.

\$\endgroup\$
1
  • \$\begingroup\$ I have never seen a lookat-like function that doesn't compute a new up basis vector from the forward and right vectors. Using the user-supplied up directly is almost guaranteed to be non-orthogonal. It might be worth mentioning this process of two cross products to generate an orthogonal basis. \$\endgroup\$ – Lars Viklund Aug 9 '15 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.