Discussion :

[seeme]

Bonsoir à tous!

Bon, mon moteur avance bien, mais je bloque sur une question de conception.

Comment représenter les transformations dans mon moteur? Pour le moment, je stock un vecteur pour la position, un pour la rotation et un pour l'échelle.

J'utilise ensuite tout ça à coup de glTranslate/Rotate/Scale. Tout fonctionne.

Maintenant, durant mes cours, mes profs insistent sur l'importance et la vitesse de l'algèbre linéaire. OK, c'est bien beau tout ça, mais au final, par exemple si je veux appliquer une rotation à un objet, vaut-il mieux appliquer un quaternion? Une matrice?

Bref, même si je comprend bien les matrices de transformation, les quaternion, les angles d'Euler, je n'arrive pas à voir lequel/lesquels de ces outils utiliser pour représenter mes objets ou comment les faire fonctionner ensemble....

Si j'ai une classe Objet par exemple avec la liste des points/faces dans l'espace local, quel est le plus efficace pour représenter les transformations qu'ils doivent subir avant l'affichage et mettre à jour cela?

Ce que je vois:
* Continuer avec des vecteurs, pas pratique quand on arrive à implémenter des rotations
* Utiliser uniquement une matrice
* Utiliser un mélange de tout ça.

Bref, je nage...

Merci d'avance,
seeme

[pyros]

Salut,

Je te conseil d'utiliser des matrices et de tous passer en coordonnées homogènes (google est ton amis si tu ne sais pas ce que c'est ). Très grossièrement, les coordonnées homogène te permettent de gérer toutes les transformations (rotation, homothétie, translation, etc...) grâce à des matrices 4x4. Appliquer une transformation à un vecteur revient à multiplier ce vecteur par la matrice. Composer 2 transformations revient à multiplier 2 matrices, etc...

Les moteurs graphiques évolué utilisent en général des quaternions surtout pour des raisons de performances et stabilité numérique. Etant donné que tout quaternions peut être modélisé par une matrice de transformation (l'inverse n'étant pas vrai !), autant utiliser uniquement des matrice qui sont plus simple à manipuler.

Donc fait des recherches sur les coordonnée homogène et préfère des appels glMultMatrix au lieu des glTranslate, rotate etc... Ca te donne plus de maitrise et de compréhension sur ce que tu fait.

Bon courage

[oxyde356]

Pour stocker les transformations, utilise des matrices homogènes (4x4) comme expliqué ci-dessus (côté OpenGL ça te simplifie la tâche tu n'as qu'à faire un glMultMatrixf(...) au lieu de glTranslatef, glRotatef, glScalef).

Par contre, et c'est là ou je diverge de pyros, je t'encourage vivement à utiliser les quaternions pour gérer tes rotations. Si le format final d'une transformation est une matrice, l'application d'une rotation doit être un quaternion. En gros si tu as un objet qui à une matrice "model" (la matrice qui contient les transformations de ton objet) et que tu dois lui appliquer une rotation, alors tu dois passer par un quaternion pour calculer la matrice résultante.
model *= quaternion;
Outre les qualités des quaternions décrites précédemment, leur intérêt majeur est d'éviter le gimbal lock lors des rotations, qui peut être un effet vraiment indésirable lorsque l'on tourne sur plusieurs axes.

[pyros]

alors tu dois passer par un quaternion pour calculer la matrice résultante.

Cela marche aussi en utilisant une matrice de rotation.

De plus, le gimbal lock est un problème lié aux angle d'Euler, et non au matrices. L'argument avancé en général est qu'un quaternion défini une rotation atour d'un axe précis, alors qu'une matrice défini une rotation autour d'un des axe X, Y ou Z. Ce qui est faux, une matrice peut très bien définir une rotation autour d'un axe arbitraire (Ok, ça demande plus de boulot mais il suffit d'exprimer la matrice de rotation dans un repère adéquat).
Le problème vient du fait que bien souvent on utilise des matrices de rotation calquées sur les angles d'Euler, d'où le problème de gimbal lock qu'on attribut trop hativement aux matrices.

Je reste cependant d'accord avec oxyde356 pour dire que les quaternions sont particulièrement bien adapté aux rotations, mais je pense qu'il faut d'abord maitriser les matrices de transformations avant de passer aux quaternions qui restent, pour moi, seulement une optimisation.

[oxyde356]

Oui, c'est histoire d'éviter cette erreur qui tient plus à l'oubli de la réelle puissance des matrices qu'autre chose. Erreur qui risque d'arriver si seeme est débutant dans ce domaine.