2

I have successfully implemented Arcball rotation through quaternions, but am confused at what to do when the direction vector of the camera is parallel to up vector. Currently I am just restricting the rotation along the x-axis (the pitch) when the dot product of the direction vector and the up vector exceeds 0.99. In Maya (or Max, XSI where arcball rotation is used) for example, you can rotate around in a full circle very smoothly. I am hoping for a solution similar to that of Maya's rotation.

Thankyou

Samaursa
  • 16,527
  • 21
  • 89
  • 160

1 Answers1

0

You need to adjust both the view normal vector (VNV) and the view up vector (VUV) and rotate both of them together so they always remain orthogonal to each other. It is sometimes useful to keep track of a "right" (or "left") vector as well which is just the cross product of the normal and up vectors.

andand
  • 17,134
  • 11
  • 53
  • 79
  • I initially did do that, unfortunately there is a problem with this solution (not seen in Maya for example). The problem is that when you try rotating, the view also does a roll and this is due to the new direction and up vector calculations (you have to move the mouse in circles to correct it). Some programs like Luxology Modo still exhibit that behavior and did not bother to solve it. I have yet to figure out how Maya accomplishes this. I know that they use a fixed up vector to calculate their new orthogonal vectors. It may be as simple as _skipping_ the angles that will break the camera... – Samaursa Feb 16 '11 at 18:24
  • Can you post some code? It sounds like you're encountering gimbal lock, but that's something quaternion rotations are supposed to avoid. Also, have you looked at http://www.tecgraf.puc-rio.br/~mgattass/fcg/material/shoemake92.pdf? – andand Feb 16 '11 at 19:14
  • It is not gimbal lock. The problem is encountered when the camera is looking straight down or straight up, in which case the camera's direction vector is parallel to its (fixed) up vector. When that happens, the camera no longer works (as its rotation matrix is no longer ortho-normal) and consequently, the correct dir/up/right vectors cannot be calculated. However, if every frame, I calculate a new up axis so that it is no longer fixed, the the camera will naturally undergo a roll. I will post an example soon. – Samaursa Feb 21 '11 at 22:38
  • Thanks for the paper, I did read it when I was originally programming the arcball rotation, but I will give it a read again. – Samaursa Feb 21 '11 at 22:39
  • @Samaursa: Again, it would help to see some source code. You really shouldn't be fixing the "up" vector relative to your scene, but it should be fixed relative to your camera position. When the normalized inner product of your VNV and VUV is less than 1, your graphics package is orthonormalizing them. Once the normalized inner product becomes 1, the up and normal vectors are linearly dependent and they cannot be used to create an orthonormal basis needed for properly orienting your scene. – andand Feb 22 '11 at 01:26