Quote:hhmmm... I was thinking this. Though I thought the order in which you applied Euler Angle rotation would cause gimble lock, while creating a Quaternion in one shot with all three Euler Angles would avoid it.
Like swiftcoder said, just throwing a quaternion or two into the mix won't prevent gimbal lock. In fact, you can think of quaternions as being functionally equivalent to matrices as far as rotations are concerned. (Obviously there are differences, or else no one would bother with quaternions; however, the differences have more to do with efficiency and elegance than they do with fundamental behavior.)
Quote:I've tried accumulating Quaternions: I took Euler Angles in, immediately converted them to a Quaternion, then multiplied the Camera's internal Quaternion by the newly created one, thus adding the new rotation to the current.
But extremely quickly, I get bleed over into another axis, and my camera begins to roll, when it should only be pitching & yawing.
It sounds like you were implementing 6DOF motion here, which behaves exactly as you describe; that is, accumulated pitch and yaw will (usually) result in perceived roll.
I think the real question here is what kind of motion you want. If you only want pitch and yaw, then 'from scratch' Euler angles should work fine, and gimbal lock should not be a concern.
As for the 'look at' function, a typical implementation will compute the orientation using vector cross products rather than axis-angle rotations. However, this method will still fail when looking more or less straight along the reference axis. This has to be handled as a special case with any method though, simply because if the target is directly above or below the viewer, there's no unique orientation that will satisfy the constraints.
