Full horizontal axis rotating camera

[napard]

Is it possible to implement a 'ISceneNodeAnimator' for a FPS like camera to bypass the horizontal axis rotation limit? I've tried playing with the MaxVerticalAngle value reimplementing my own CSceneNodeAnimatorCameraFPS, but it will not allow me to rotate passing from -88 to 88 even when I put a higher limit. My idea es to implement a full horizontal rotation view for a spaceship-like movement. Something like

if(relativeRotation.X > 360) relativeRotation.X = relativeRotation.X - 360;
else if(relativeRotation.X < 0) relativeRotation.X = 360 - relativeRotation.X;

Any help would be really appreciated.

[CuteAlien]

Phew, I'm always a bit afraid of giving wrong information when talking about gimbal lock troubles. Especially when it's about something I've not coded yet myself. So in the hope I'm not wrong, here's what I would try (and no guarantees)...

I would not work directly with Euler angles. I have to set them in the end, but not use them for calculations. Instead I'd work with the view matrix probably. And then calculate a matrix for the rotation I want to add to the current view matrix (simple: use a new matrix and just set rotations in that one) . Then I'd multiply those matrices (which adds their rotations, careful A*B is not B*A so if one fails try the other). And then I'd get the euler rotation from the resulting matrix and set that one for the camera.

But think first about what kind of camera you really want. There are different options what rotating a camera means. For example in FPS cameras you keep the camera position fixed and rotate camera itself (so the camera target moves). While in third person cameras you keep the target fixed and rotate the camera position around that (or around some point in between camera and target like around the player head). And that matters because for FPS camera you can set euler rotation when you called bindTargetAndRotation(true) first. While for 3rd person camera you have to calculate the new target based on the rotation you got. Or target and position.

OK, I hope I gave at least some useful information. Otherwise just ask again.
As for your original idea - I think there's probably no way to get away by simply adding stuff to euler angles and then trying to fix them.

[napard]

Yeah, I knew I was on the wrong path, but better trying than nothing. When working with raw opengl I would build a model*view transformation matrix and apply it to a model through vertex shader, it always worked flawlessly. I'd like to achieve the same conceptually, but I'm afraid I can't find a way through the API, even there is not possible to set a new tx matrix to a camera node, so I'm rather lost on this subject.

[CuteAlien]

Basically use matrixes - then get the rotation and position from those again for the nodes. Or in the case of the camera - you can also use it to calculate target (position + 3rd row in matrix) and up vector (second row in matrix).

Luckily cameras don't have scale involved.And I really wish matrix4::getRotationDegrees wouldn't be the top task of my todo-list right now while I tell someone to use it. Because at some point it seems we tried to improve that and make it handle some matrix decomposition, and it's not likely that was a good idea (but I still have to write some more test-cases and debug this to be sure if it's a problem or not). But my guess is - if you are on svn trunk you should probably call the version which takes a scale parameter and set that one to 1,1,1 (and no clue right now about 1.8, sorry - just typing this over lunch).

[Mel]

I made a custom maya camera animator that could freely rotate in any direction, just needed the CTRL key to do so. Take a look and see if it could serve you of something. For a spaceship like motion, it could prove a useful code. Matrices not involved!

viewtopic.php?t=51582