Camera en vol libre sous opengl

Signaler
Messages postés
29
Date d'inscription
lundi 5 septembre 2005
Statut
Membre
Dernière intervention
23 novembre 2005
-
 Utilisateur anonyme -
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

5 réponses

Messages postés
2023
Date d'inscription
mardi 24 septembre 2002
Statut
Membre
Dernière intervention
28 juillet 2008
5
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.
Messages postés
65
Date d'inscription
dimanche 27 juillet 2003
Statut
Membre
Dernière intervention
21 avril 2006

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à.
Messages postés
2023
Date d'inscription
mardi 24 septembre 2002
Statut
Membre
Dernière intervention
28 juillet 2008
5
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).
Messages postés
29
Date d'inscription
lundi 5 septembre 2005
Statut
Membre
Dernière intervention
23 novembre 2005

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