Des matrices sans ou avec openGL

J'ai remarquer qu'un bon nombre de programmeur creait leur propre petite bibliotheque de matrice en utilisant openGL.

Je suis moi meme en train de faire un petit moteur de jeu gerant mes propres matrices.

Mais la question est: est-ce nécéssaire?

OpenGL posède ses propres matrices (de transformation glRotate*() glTranslate*() glScale()). Alors pourquoi bon nombre de programme reinvente la roue. Cela veut-il dire que les matrice interne de openGL ne sont pas assez optimisé?

J'aimerai comprendre...

Si non, j'ai fais une gaffe en voulant moi-meme reinventé la roue...

(Programmeur un jour programmeur toujours...
arg la fatalité!!! )

Bonjour,
en fait cela dépend de ton moteur et si par exemple tu veux faire abstraction de OpenGL, alors tu peux recoder une classe matrice en utilisant OpenGL et en rajoutant des fonctions .
Mais sinon je ne pense pas que ce soit réellement utile car les Matrice OpenGL on un grand avanatage:
->soit ta carte graphique ne sait pas faire du calcul matriciel(il y en a peu) et dans ce cas OpenGL sera aussi rapide qu'un implémentation logiciel
->soit ta carte graphique qait le faire et là il n'y a pas photo :)

Sinon une pseudo-classe matrice peut être nécessaire par exemple si tu travaille avec des quaternions et que tu veux obtenir une matrice depuis ce quaternions mais là encore avec OpenGL cela n'est pas nécessaire grâce à la fonction glRotatef qui prend exactement les paramètres du quaternions(avec une petite modif) .

Donc je pense que si ton moteur est uniquement OpenGL cela n'est pas nécessaire . De toute façon tu ne l'aura pas codé pour rien car peut-être que tu en sentira le besoin plus tard dans ton moteur .

Bonne journée .

A m a u r y

Faire des calculs matricielles avec openGL c'est un peu la "mrd" non ? De toute facon, créer sa propre classe de matrice, c'est absolument nécessaire (a mon gout) des que tu commences, meme très peu, un moteur physique. Donc de toute facon, une classe matrice, c'est toujours utile.

++

Pamaury>> Oui mais, je que openGL ne multipliait ses matrices par lui meme.

C'est a dire que si j'ai a faire une translation
puis une rotation ...

Exemple:

glRotate*(un degree quelconque)

glTranslate*(une mesure quelque)

OpenGL calcul d'abort pour chaque iteration de boucle le vecteur avec la rotation
puis le vecteur avec la translation: cela fait deux calculs par boucle!!!

Alors que si on multipliait la matrice de rotation et la matrice de translation on gagnerait le double du temps ou voir  plus si on utilise des transformation succesive.

Afin c'est a verifier... je vais faire un systeme fps (frame par seconde) afin de conter l'optimisation des mouvements vectoriel.

Programmeur un jour programmeur toujours...
arg la fatalité!!! )

"glRotate*(un degree quelconque)

glTranslate*(une mesure quelque)

OpenGL calcul d'abort pour chaque iteration de boucle le vecteur avec la rotation
puis le vecteur avec la translation: cela fait deux calculs par boucle!!!"

T'es sur ? Ca m'étonnerait que ca marche comme ca. OpenGL multiplit plutot la matrice de rotation par celle de translation. Enfin il me semble que c'est l'intéret meme des matrices, sinon elles servent a rien. :)

++

Excuse moi mais permet moi d'émettre un énorme doute sur ce que tu dis: les gars qui ont fait et qui font OpenGL ont une connaissance telle de la 3D qu'il sont plus à même que nous d'optimiser et jamais il ne ferais un truc aussi lent que tu le décrit et comme le dit luhtor dans ton cas les matrices ne servent à rien . çà c'est en mode software parce que en mode hardware c'est encore plus optimisé lors de la multiplication des matrices .

Enfin c'est vrai que si tu veux faire un moteur physique, une classe matrice sera nécessaire .

A m a u r y

ah bon, parce qu'il a une version hardware en plus??

(Programmeur un jour programmeur toujours...
arg la fatalité!!! )

Finalement, oui mes matrices sont utile car opengl ne personalise pas la memorisation matriciel d'un object. Je suis donc obliger de faire le produit de toute mes transformations puis de les passer par glLoadMatrix(matrice en question) atribuer a un object. J'ai ainsi la memorisation de l'object transformé.

(Programmeur un jour programmeur toujours...
arg la fatalité!!! )

OpenGL:
->soit tu n'a pas récupéré la version du constructeur de ta carte graphique et il fait tous les calcul en software (peut-être optimisé pour 3DNow ! SSE, SSE2, SSE3) .
->soit tu as récupéré la version du constructeur de ta carte graphique et dans ce cas il fait tout les calcul possible en hardware: matrice, Transform&Lighting, texturing(un moins une texture mais les plus récentes supporte 2 ou 3 unité de texturage)....

Voilà ceci dit il me parait plus judicieux de stocker la transformation d'un objet par un vecteur position et un vecteur direction puisque c'est BEAUCOUP plus facile à utiliser . Pour le coup une classe Vector est indispensable dans tout project 3D . ensuite il suffit de déterminer les angles que fait le vecteur direction avec le vecteur profondeur et ensuite faire
glTranslatefv(obj.pos);
glRotatef(obj.rot.z,0.0,0.0,1.0);
glRotatef(obj.rot.y,0.0,1.0,0.0);
glRotatef(obj.rot.x,1.0,0.0,0.0);

Enfin je tient à dire que
glLoadMatrix est dangereux car il faut faire attention à la représentation de la matrice: en colonne ou en ligne . Je crois qu'openGL le fait en ligne mais c'est à vérifier .

Pour moi une clasxse matrice c'est utile: pour la physique et pour les objet animé(encore que un quaternion est plus efficace) .

A m a u r y

Pamauly>> 

« Voilà ceci dit il me parait plus judicieux de stocker la transformation d'un objet par un vecteur position et un vecteur direction puisque c'est BEAUCOUP plus facile à utiliser . Voilà ceci dit il me parait plus judicieux de stocker la transformation d'un objet par un vecteur position et un vecteur direction puisque c'est BEAUCOUP plus facile à utiliser . »

Oui, j'ai fais un object vecteur avec les fonctionnalité qui me permet de facilité la tache. Oui... je sais que c'est important.

«ensuite il suffit de déterminer les angles que fait le vecteur direction avec le vecteur profondeur et ensuite faire
glTranslatefv(obj.pos);
glRotatef(obj.rot.z,0.0,0.0,1.0);
glRotatef(obj.rot.y,0.0,1.0,0.0);
glRotatef(obj.rot.x,1.0,0.0,0.0);»

Niet! Je suis pas d'accord. J'ai fait de cette maniere et je me heurte a une problematique technique: l'ordre des rotation!( C'est la raison pour laquel la memorisation des matrices de transformation est importante!!)

Je m'explique. Lorsque tu d'eclare les rotation. Il y a toujours une qui influence la suivante... mais pas la derniere! Ainsi comme tu as déclarer Rotatef de l'axe z, elle influence la rotation y et x: ca c'est correcte. Mais la rotation y et x, ne peut influencer z.  Et encore pire, la rotation x ne peut influencer y.

Il faut donc une succesion de rotation une appres l'autre comme exemple:

rotation x...
rotation y...
rotation x...
rotation z...
rotation x...

Mais en applant glRotate*() autant fois que nous avons une transformation peut devenir lourd lors de l'application. Ainsi si l'utilisateur cumule environs 65 000 rotation cela commence a faire lourd (65 000 appelle de rotation pour cheminer a transformation actuelle!) En faite a ce stade c'est inaccetable pour mon moteur.

J'ai reglé ce probleme tous simplement en memorisant la derniere matrice transforme puis calculer la suivante.

«glLoadMatrix est dangereux car il faut faire attention à la représentation de la matrice: en colonne ou en ligne . Je crois qu'openGL le fait en ligne mais c'est à vérifier .»

J'ai essayer et ca marche. Je ne vois pas en quoi c'est si dangereux. Et oui openGl fait c'est matrice en ligne mais ce n'est pas difficile a adapter. Deplus par rapport a glTranslate*() et glRotate*() en appelant glLoadMatrix je trouve que cela fait un travail plus propre.

Voily vooilu en

(Programmeur un jour programmeur toujours...
arg la fatalité!!! )