Des matrices sans ou avec openGL
cs_theidiot
Messages postés
56
Date d'inscription
lundi 16 août 2004
Statut
Membre
Dernière intervention
27 août 2005
-
4 juin 2005 à 02:58
cs_theidiot Messages postés 56 Date d'inscription lundi 16 août 2004 Statut Membre Dernière intervention 27 août 2005 - 8 juin 2005 à 20:42
cs_theidiot Messages postés 56 Date d'inscription lundi 16 août 2004 Statut Membre Dernière intervention 27 août 2005 - 8 juin 2005 à 20:42
A voir également:
- Des matrices sans ou avec openGL
- Matrices c++ - Forum C++ & C++ .NET
- Opengl version - Forum C++ & C++ .NET
- Matrices en c - Forum C / C++ / C++.NET
- Rotation opengl - Conseils pratiques -C / C++ / C++.NET
- Comparer deux matrices ✓ - Forum C
12 réponses
Pamaury
Messages postés
341
Date d'inscription
jeudi 3 avril 2003
Statut
Membre
Dernière intervention
17 juin 2008
3
4 juin 2005 à 09:27
4 juin 2005 à 09:27
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
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
luhtor
Messages postés
2023
Date d'inscription
mardi 24 septembre 2002
Statut
Membre
Dernière intervention
28 juillet 2008
6
4 juin 2005 à 13:17
4 juin 2005 à 13:17
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.
++
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.
++
cs_theidiot
Messages postés
56
Date d'inscription
lundi 16 août 2004
Statut
Membre
Dernière intervention
27 août 2005
4 juin 2005 à 19:19
4 juin 2005 à 19:19
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é!!! )
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é!!! )
luhtor
Messages postés
2023
Date d'inscription
mardi 24 septembre 2002
Statut
Membre
Dernière intervention
28 juillet 2008
6
4 juin 2005 à 21:57
4 juin 2005 à 21:57
"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. :)
++
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. :)
++
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Pamaury
Messages postés
341
Date d'inscription
jeudi 3 avril 2003
Statut
Membre
Dernière intervention
17 juin 2008
3
5 juin 2005 à 09:31
5 juin 2005 à 09:31
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
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
cs_theidiot
Messages postés
56
Date d'inscription
lundi 16 août 2004
Statut
Membre
Dernière intervention
27 août 2005
7 juin 2005 à 00:00
7 juin 2005 à 00:00
ah bon, parce qu'il a une version hardware en plus??
(Programmeur un jour programmeur toujours...
arg la fatalité!!! )
(Programmeur un jour programmeur toujours...
arg la fatalité!!! )
cs_theidiot
Messages postés
56
Date d'inscription
lundi 16 août 2004
Statut
Membre
Dernière intervention
27 août 2005
7 juin 2005 à 00:06
7 juin 2005 à 00:06
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é!!! )
(Programmeur un jour programmeur toujours...
arg la fatalité!!! )
Pamaury
Messages postés
341
Date d'inscription
jeudi 3 avril 2003
Statut
Membre
Dernière intervention
17 juin 2008
3
7 juin 2005 à 10:45
7 juin 2005 à 10:45
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
->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
cs_theidiot
Messages postés
56
Date d'inscription
lundi 16 août 2004
Statut
Membre
Dernière intervention
27 août 2005
7 juin 2005 à 15:19
7 juin 2005 à 15:19
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é!!! )
« 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é!!! )
Pamaury
Messages postés
341
Date d'inscription
jeudi 3 avril 2003
Statut
Membre
Dernière intervention
17 juin 2008
3
7 juin 2005 à 21:50
7 juin 2005 à 21:50
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!!)
en effet avec certain angle on peut avoir ce qu'on appelle le
Gimbal lock
Le seul moyen 'efficace' de l'éviter ce sont les quaternions .
De plus l'avantage des quaterniosn c'est que déjà:
->c'est bcp plus rapide car moins de calcul(comparé aux matrices)
->après avoir déterminé le quaternions que l'on veut il suffit(après quelques calc de faire)
glRotatef(rot,xamout,yamout,zamout) et c'est fini !!
http://etudiant.univ-mlv.fr/~mbrunet/index.php?mod=math&smod=quat
http://skal.planet-d.net/demo/matrixfaq.htm
PS:avec çà le débat est clos: pas de matrices mais des quaternions lol
A m a u r y
a une problematique technique: l'ordre des rotation!( C'est la raison
pour laquel la memorisation des matrices de transformation est
importante!!)
en effet avec certain angle on peut avoir ce qu'on appelle le
Gimbal lock
Le seul moyen 'efficace' de l'éviter ce sont les quaternions .
De plus l'avantage des quaterniosn c'est que déjà:
->c'est bcp plus rapide car moins de calcul(comparé aux matrices)
->après avoir déterminé le quaternions que l'on veut il suffit(après quelques calc de faire)
glRotatef(rot,xamout,yamout,zamout) et c'est fini !!
http://etudiant.univ-mlv.fr/~mbrunet/index.php?mod=math&smod=quat
http://skal.planet-d.net/demo/matrixfaq.htm
PS:avec çà le débat est clos: pas de matrices mais des quaternions lol
A m a u r y
Pamaury
Messages postés
341
Date d'inscription
jeudi 3 avril 2003
Statut
Membre
Dernière intervention
17 juin 2008
3
7 juin 2005 à 21:56
7 juin 2005 à 21:56
j'oubliais:
"
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.
"
=>archi faux car x influence y et y influence z donc z est influencé
par y et donc indirectement par x . Le risque c'est que cos(90)=0 ou
sin(0)=0 -> tu te retrouve avec des 0 dans ta matrice qui seront le
resterons à cause de la multiplication quelque soit la transformation
qui suit: -> blocage sur l'axe des X et pire parfois: la rotation
sur l'axe X se fait sur l'axe Z !! C'est çà le Gimbal Lock et la seul
solution ce sont les quaternions .
A m a u r y
"
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.
"
=>archi faux car x influence y et y influence z donc z est influencé
par y et donc indirectement par x . Le risque c'est que cos(90)=0 ou
sin(0)=0 -> tu te retrouve avec des 0 dans ta matrice qui seront le
resterons à cause de la multiplication quelque soit la transformation
qui suit: -> blocage sur l'axe des X et pire parfois: la rotation
sur l'axe X se fait sur l'axe Z !! C'est çà le Gimbal Lock et la seul
solution ce sont les quaternions .
A m a u r y
cs_theidiot
Messages postés
56
Date d'inscription
lundi 16 août 2004
Statut
Membre
Dernière intervention
27 août 2005
8 juin 2005 à 20:42
8 juin 2005 à 20:42
ok, va pour les quaternions mais je connais tres peu de chose a ce sujet. Alors je ne sais pas comment réellement l'appliquer. Est-ce que tu pourrais me donner un exemple stp. Je te remerci grandement de ton aide.
p.s. merci pour les liens mais j'ai deja des sources qui me permette d'avoir le calcul complet des quaternions.
(Programmeur un jour programmeur toujours...
arg la fatalité!!! )
p.s. merci pour les liens mais j'ai deja des sources qui me permette d'avoir le calcul complet des quaternions.
(Programmeur un jour programmeur toujours...
arg la fatalité!!! )
