Cameras: the smart way?
category: general [glöplog]
Hi! I'm thinking about how to implement my cameras for my next 64k. Everyone knows the standard way of doing them: Take the camera position, view direction and up vector to create the view matrix, and then take the FoV, aspect ratio, near and far planes for the projection matrix.
I want to follow a different path so that I don't need the 3 vectors for the view matrix, instead only 2. I'd also like to avoid the gimbal lock problem.
I thought that I could represent the camera position with 3 floats, then the direction that the camera looks at with another 3 floats, and finally the roll angle along the view vector with another float, that makes 7 floats.
Does anybody know if that's sufficient information, and how to construct a view matrix out of those values? Any references would be gladly appreciated :)
Cheers!
I want to follow a different path so that I don't need the 3 vectors for the view matrix, instead only 2. I'd also like to avoid the gimbal lock problem.
I thought that I could represent the camera position with 3 floats, then the direction that the camera looks at with another 3 floats, and finally the roll angle along the view vector with another float, that makes 7 floats.
Does anybody know if that's sufficient information, and how to construct a view matrix out of those values? Any references would be gladly appreciated :)
Cheers!
Why store the direction and roll in 4 floats? Dir vector and roll? Just store pitch, yaw, roll; that reduces it to 3.
Ferris: That's equivalent to euler angles (http://en.wikipedia.org/wiki/Yaw,_pitch,_and_roll#Tait-Bryan_angles), which introduce singularities when two rotation planes become coplanar, aka gimbal lock. I'd like to avoid those :)
Quote:
I'd also like to avoid the gimbal lock problem.
Ah sorry, missed this :)
Your proposed solution won't work either because your "roll angle" isn't defined. You'll need a reference for "where is roll angle 0" and as soon as you introduce any such reference, there's your gimbal lock problem again.
You can of course store the rotation in a quaternion and have 7 floats for the camera (3 pos, 4 rotation). Perfectly gimbal lock free when playing back; but in any way you'll have to devise a way to avoid gimbal lock when _creating_ the rotation.
You can of course store the rotation in a quaternion and have 7 floats for the camera (3 pos, 4 rotation). Perfectly gimbal lock free when playing back; but in any way you'll have to devise a way to avoid gimbal lock when _creating_ the rotation.
up = cross(front, right);
kb_: I was thinking of quaternions as well, I'm using my several-years-old math classes where I have a conversion from an unit quaternion to a rotation matrix. Theoretically speaking, I can represent the camera orientation with a quaternion, where I just specify a rotation axis and an angle to rotate from. These 4 values are represented by a quaternion. I'm just not an expert in quaternion maths.
Besides the inner workings of my camera system, I want to be able to freely change the camera parameters on design time, that is, change the cam position and orientation, and other values such as fov and dof.
Assuming I want to go the quaternion way, the initial quaternion would be (0, 0, 1, 0), that is 0 degrees rotation along the y-axis. Now when I want too "look around", I would need some logic to modify my quaternion so that the camera looks to the new direction. kb_: could you enlighten me in how to do this?
And since I plan on keyframe animations, I'd need a way to interpolate from all those values. I've heard about spherical linear interpolation (slerp) for quaternions, I'm not sure if that'd be necessary or if cubic hermite spline interpolation would suffice.
Besides the inner workings of my camera system, I want to be able to freely change the camera parameters on design time, that is, change the cam position and orientation, and other values such as fov and dof.
Assuming I want to go the quaternion way, the initial quaternion would be (0, 0, 1, 0), that is 0 degrees rotation along the y-axis. Now when I want too "look around", I would need some logic to modify my quaternion so that the camera looks to the new direction. kb_: could you enlighten me in how to do this?
And since I plan on keyframe animations, I'd need a way to interpolate from all those values. I've heard about spherical linear interpolation (slerp) for quaternions, I'm not sure if that'd be necessary or if cubic hermite spline interpolation would suffice.
xernobyl: In your case I'd need a "right" vector :)
xTr1m: my experiences from 64ks is that storing orientations (which includes camera direction and roll) often can be best to do with the axis/angle representation. The axis-part needs limited precision, and the angle can support rotations above 360 degrees (unlike quaternions), so you can make long constant rotations with only two key-frames. You can convert the angle to a quaternion on the fly to be able to interpolate it smoothly.
