Find content
Not Telling
There are several problems mentioned in the OP. My advices are:
1. You should stay away from using Euler angles if possible.
2. You should apply delta rotations and translations, but store the current placement as either a matrix or a pair of position vector and orientation quaternion.
3. You should not integrate too much responsibility into a single class. E.g. the camera class stores and grants read access to the placement of the camera as well as some simple manipulators (in extreme just a setter) for this placement, but it should not provide higher level control like a concept of 1st person and 3rd person camera. Instead, provide a basic CameraControl class and derive FPCameraControl and others from it.
4. When switching the active CameraControl, the next active control may need to alter the camera's placement to get it into a prescribed state. If you want to avoid sudden changes, then make a soft transition so that the current placement (i.e. those stored in the camera object, usually as left from the previous control) and the new required placement are interpolated over a short time, e.g. a second or so, before actually granting control to the following CameraControl object. Notice please that this can be integrated into the schema nicely: Define a TransitionalCameraControl class that is parametrized with the CameraControl that should become active. Let the former one do the interpolation (it asks the camera for the current placement and the given CameraControl for the required placement), and let it replace itself by the given CameraControl when done.
So that means that there is no way to switch from one camera control to another without interpolating between them ?
I thought it was possible to just accumulate in the right order (based on the current camera control type) to be consistent to one camera control or
another without sudden changes to show up.
Plus, currently I'm calculating my orientation like this and it works stable with no gimbal lock or numerical instabilities, but I do not understand why I should work with delta rotations instead of absolute angles (it works anyway).
Here is a code snippet:
//create orientation QuatfFromAxisAngle(Vec3f(1.f,0.f,0.f),mPitch,&mRotX); QuatfFromAxisAngle(Vec3f(0.f,1.f,0.f),mYaw,&mRotY); QuatfFromAxisAngle(Vec3f(0.f,0.f,1.f),mRoll,&mRotZ); QuatfMult(mRotX,mRotY,&mRotXY); QuatfMult(mRotZ,mRotXY,&mOrientation); //normalize quaternion QuatfNormalize(mOrientation,&mOrientation); //now extract the orientation part of the view matrix Mat44fInitFromQuaternion(mOrientation,&mViewMatrix.mat44f); mViewMatrix.mat44f.v03 = -Vec3fDot(cameraPos,mRight); mViewMatrix.mat44f.v13 = -Vec3fDot(cameraPos,mUp); mViewMatrix.mat44f.v23 = -Vec3fDot(cameraPos,mForward);
It works smooth and perfect (I keep Roll == 0 all the way).
Pitch, Yaw are just accumulated absoulte angles:
Pitch += dPitch; same for yaw
What I'm thinking is It possible to make just one class that gives just very bare bones operators to implement different camera behaviours without having to implement a class for every camera type ?
I saw some implementation showing something like:
rotateXCameraRelative
or rotateXWorldRelative blabla
which leads me to think they are just basic operators and there is no reference to first person or third or track ball ... and the idea is that a very specific combination of them can implement for example a first person behaviour or a trackball if you use a different combination of them.
I
