First of all, it''s quaternion, not quantion (the term quantion actually exists, btw, but it is used in the field of particle physics... )

About your problem, well, I have to admit that I don''t really understand what you mean. There is something ''wrong'' with your rotations. OK. But what exactly ? We need more information to be able to help you.

Generally, if your camera computation are solely based on quaternions, and no Euler angles come into play at any moment (and that includes things like roll, pitch and yaw), then the gimbal lock should not occur. A conversion from quaternion to angle/axis should not be a problem either.

Now, you apply two different glRotate() commands on two different angle/axis pairs. This can lead to a gimbal lock. You can actually visualize the two distinct angle/axis pairs as two (from 3) vectors forming an Euler coordinate triple: your are rotating your coordinate frame twice, around different axes. Given the (in-)appropriate values for such an axis/angle pair, the last rotation can possibly lock.

The trick to avoid gimbal lock-like situations, is to do *all* the rotation in quaternion space. Only the final rotation can then be safely transfered to a rotation matrix (perhaps through an intermediate angle/axis conversion). Any subsequent coordsys rotation you apply to this system can produce a gimbal lock.

But your problem can very well be somewhere else. There is not enough information. For further help, you''ll need to describe your problem in greater detail, and provide some more insight in what you are trying to achieve with those rotations.

/ Yann

quote:
So Yann L, is it now easier to understand my problem?

Honestly, I''m still not quite sure what you want I guess you''re writing a multiplayer game, where each player has his local camera position. And you want the player character''s mesh objects to be oriented in the right direction, when viewed from another player. Is that right ? If not, kannst Du dein Problem auch kurz auf Deutsch erklären, um weiteren Mißverständnissen vorzubeugen

So let''s assume that this is what you want. The standard way of doing that is as follows: Player A moves around in a 3D scene. His camera matrix gets transfered to Player B. B''s system applies A''s transfered camera matrix as local transformation matrix onto A''s character mesh object. That''s pretty much it. The local camera view of B should, and will not interfere with the local object matrix of A''s character.

In pseudocode, that would look like this:



There won''t be any gimbal lock problems. The local object transform matrix is just normally concatenated with the view matrix, pretty much standard. You should also directly extract the camera matrix from the quaternion you use for your camera model. Not using Euler angles at any point is the best way to avoid gimbal locks of any sort.

/ Yann