Camera en vol libre sous opengl

Bonjour a tous,

Je suis en train d'ecrire un moteur 3D sous OpenGL et j'ai quelque dificulte avec la camera. (Langage: C++)
En fait mon soucis, c'est que je ne tient pas a limiter les mouvement au sol. donc je voudrait que ma camera puisse se balader dans n'importe quelle direction.
cela marche, ma camera est defini par deux angles seulemet (un angle de tete orientant de droite a gauche et un anglet de roll orientant de haut en bas) Grace a ces deux angle je me deplace bien dans la bonne direction, tout marche bien jusqu'au moment ou la direction dans laquelle regarde ma camera est proche de la direction y du monde. La, au lieu de tourne la tete de droite a gauche, la camera pivote sur elle meme (rotation autour d'y)

Ca fait un moment que je cherche et j'ai un peu de mal a savoir comment ressoudre ce probleme.

voici le code qui calcule la matrice de vue:

void CCamera::GetViewMatrixFP()
{
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();

// applying transformations on the camera
glRotatef(mPhiAngle, 1, 0, 0);
glRotatef(mThetaAngle,0, 1,0);
glTranslatef(-mPosition.GetX(), -mPosition.GetY(), -mPosition.GetZ());

CalculateVectors();
}

La fonction calculate vectors calcul les valeurs pour les vecteur de la camera (direction, droite et haut)

si vous avez une idee, je suis preneur
Merci

Utilise plutot gluLookAt( pos_x, pos_y, pos_z, point_vue_x, point_vue_y, point_vue_z, vecteur_normal_x, y, z)

En gros, voila:
gluLookAt(pos_x,pos_y,pos_z,
                    pos_x+cos(alpha)*cos(beta), pos_y+sin(alpha)*cos(beta),pos_z+sin(beta),
                    -cos(alpha)*sin(beta),-sin(alpha)*sin(beta),cos(beta));

Ca doit etre ca, si ca bug, faudra refaire le calcul pour le vector normal.
Ici, alpha, c'est l'angle de rotation horizontal, et beta, l'angle vectical. Je te laisse l'adapter a tes besoins.

Hé ouai, c'est normal que ça ne marche pas.
Tu sais les mathématiques sont allergiques aux M_PI/2.0;
lol
En fait, tu utilises là les angles d'euler...
qui dit angle d'Euler dit Gimbal Lock.
Qui dit Gimbal Lock dit Quaternions.

Bref, soit tu bloques à pi/2, soit tu utilise les quaternions (cherche sur google).

PS : la solution a luhtor est une autre solution mais au final, c'est toujours les angles d'euler qui sont utilisés... donc le problème est toujours là.

Non il n'y a pas de problème avec ma solution. L'utilisation des angles d'Euleur est inutile pour tout ce qui est doom like. (angle d'euler utile seulement pour les simulations d'avions ou autre).
De plus, pour les doomlike, l'ordre des rotations n'a pas d'importance.

Pour ce qui est des angles d'euler, c'est vraiment pas pratique, mieux vaut appliquer brutale une formule qui donne la matrice de rotation d'angle quelconque suivant un vecteur particulier. On créer des erreurs minimes, au fur et a mesure des calculs matricielles. Il est donc nécessaire de renormaliser la base sur laquelle on applique la matrice. (voir normalisation de schmidt).

Merci a tout les deux pour vos reponses.

Je penses effectivement que mon probleme est du au angles d'euler et a un gimbal lock. Etant donne qu'il s'agit d'une camera en premiere persone qui se deplace dans les trois dimensions (genre simulation d'avion... ou shoot spacial).

Il faut que je regarde plus en profondeur les quaternions mais je pensais pouvoir determiner la matrice de vue directement a partir des angles et des vecteurs, sans passer par des transformations.

Merci encore pour voter aide, et si vous avez plus d'infos sur les quaternions, je veux bien.

Bonjour

As-tu résolu ton problème? Les quaternions ne peuvent pas tout résoudre. Tu peux avoir du gimbal lock avec des quaternions. C'est ce qui m'arrive. Tout dépend da la façon de les utiliser. Les caméras d'Euler, Cardan et UVN  posent des problèmes d'imprécisions  plus importants  que les quaternions  surtout  si  tu veux faire des interpolations (cf. SLERP). Ils demandent même plus de calculs. Bon courage. Moi ça fait deux mois que je rame là-dessus

yeah! vive java