Twinuts
Messages postés5375Date d'inscriptiondimanche 4 mai 2003StatutModérateurDernière intervention14 juin 2023
-
24 août 2006 à 12:35
9287
Messages postés3Date d'inscriptionsamedi 30 décembre 2006StatutMembreDernière intervention 6 janvier 2007
-
6 janv. 2007 à 21:58
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
La solution éliminant le gimbal lock pour calculer la composition de rotations est:
R(R(R(Ox,∆)Oy,Ω)*R(Ox,∆)Oz,∂)*R(R(Ox,∆)Oy,Ω)*R(Ox,∆)
C'est une transformation non Eulerienne.
Ceci marche très très bien mais ne suffit pas. Pour éviter de cumuler des erreurs avec les produits successifs de quaternions, il faut TOUJOURS revenir au quaternion neutre puis recombiner les rotations axiales exprimées à partir des angles globaux. J'ai travaillé 6 mois principalement sur ce problème l'an passé, j'espère que ça pourra t'éviter pas mal de galères que j'ai moi-même connues.
Ceci vous parait sûrement très simple et tout à fait correct et pourtant...
public void applique(){
T_Finale.mul(T_RX);
T_Finale.mul(T_RY);
T_Finale.mul(T_RZ);
TG_Parent.setTransform(T_Finale);
}
Tu utilises des transformations eulériennes ce qui peut causer du gimbal lock (verrou de Cardan). Il faudrait plutôt utiliser des transformations non eulériennes qui sont plus faciles à exprimer en s'appuyant sur des quaternions.
Sérieusement, je rejoins entièrement TWINUTS. Ca vaudrait vraiment le coup de passer à JOGL qui est vraiment plus rapide que Java 3D. Je pense que je vais reprendre ton code pour essayer de faire bouger mes humanoïdes les moins réalistes (zombies par exemple). Je vais essayer de voir si c'est relativement simple à optimiser. En revanche, JSDL est plutôt adéquat pour la 2D mais pas pour la 3D à mon avis.
omcougar
Messages postés152Date d'inscriptionmardi 4 mai 2004StatutMembreDernière intervention 8 octobre 20081 12 oct. 2006 à 16:43
Vu que ce code est super méga facile à comprendre mais que java3d et peu efficace, il n'y aurait pas un courageux pour faire la même chose en open GL que je comprenne le truc ? :)
bouge32
Messages postés1Date d'inscriptionmercredi 11 octobre 2006StatutMembreDernière intervention11 octobre 2006 11 oct. 2006 à 23:45
ces un beau code et je le sugerre
Twinuts
Messages postés5375Date d'inscriptiondimanche 4 mai 2003StatutModérateurDernière intervention14 juin 2023111 24 août 2006 à 16:44
Salut,
je suis du meme avis que toi concernant le peux de complexité du code deplus il est super lisible ce qui j'avoue est assez rare donc congratulation rien que pour ça :D, maintenant les commentaires aide pour savoir ce qui ce passe dans la tete du developpeur lors de la creation du code :P
concernant les optimisations je pense qu'a la longue elle devrait valoir le coup.
omcougar
Messages postés152Date d'inscriptionmardi 4 mai 2004StatutMembreDernière intervention 8 octobre 20081 24 août 2006 à 16:02
Je viens d'ajouter des commentaires, et je pense que l'on peut facilement créer un objet à articulations multiples sans même comprendre le code? même pas besoin de se casser la tête à calculer les vecteurs je déteste ca.
Pour l'optimiser je vois plusieurs directions:
1/ commencer par ajouter des méthodes pour dessiner des objets plus complexes que sphères et carré.
2/ pour chaque articulation il est possible de définir sur les 3 axes les angles de rotations min/max ainsi lorsqu'on appelle le mouvement de course à 0% tous les angles sont à leur minimum et à 100% tous les angles sont au max mais en réalité un mouvement de course est beaucoup plus complexe il faudrait pouvoir définir des positions intermédiaires.
3/ quand on appelle le mouvement de course à x% je commence par tout remettre aux positons de départ puis effectuer toutes les rotations de x%... on devrait avec un peu de réflexion pouvoir se débarrasser de la moitié des calculs :)
Pour opengl je suis preneur surtout si c'est plus performant mais j'ai surtout trouvé des exemples java3D... ou puis-je trouver des exemples jogl ou javasdl suffisamment "basic" pour qu'un noob comme moi puisse les comprendre?
Twinuts
Messages postés5375Date d'inscriptiondimanche 4 mai 2003StatutModérateurDernière intervention14 juin 2023111 24 août 2006 à 12:35
Salut,
le résultat est sympas :D, cependant merci de commenter ta source (les commentaires sont super important surtout pour une source utilisant java3D qui est une usine à charbon à lui seul).
sinon j'ai rien contre java3D si ce n'est sa lenteure d'éxecution et étant plus habitué à opengl je voulais juste t'informer de l'existance de jogl(implentation opengl en java) et de javasdl(implementation de sdl en java) qui sont apres les avoirs testé, plus performant (ca reste mon avis perso donc...)
6 janv. 2007 à 21:58
30 déc. 2006 à 20:06
25 déc. 2006 à 15:48
R(R(R(Ox,∆)Oy,Ω)*R(Ox,∆)Oz,∂)*R(R(Ox,∆)Oy,Ω)*R(Ox,∆)
C'est une transformation non Eulerienne.
Ceci marche très très bien mais ne suffit pas. Pour éviter de cumuler des erreurs avec les produits successifs de quaternions, il faut TOUJOURS revenir au quaternion neutre puis recombiner les rotations axiales exprimées à partir des angles globaux. J'ai travaillé 6 mois principalement sur ce problème l'an passé, j'espère que ça pourra t'éviter pas mal de galères que j'ai moi-même connues.
25 déc. 2006 à 15:14
public void reset(){
T_Finale = new Transform3D();
T_RX = new Transform3D();
T_RY = new Transform3D();
T_RZ = new Transform3D();
}
Ecris plutôt ça :
public void reset(){
T_Finale.setIdentity();
T_RX.setIdentity();
T_RY.setIdentity();
T_RZ.setIdentity();
}
25 déc. 2006 à 15:00
public void applique(){
T_Finale.mul(T_RX);
T_Finale.mul(T_RY);
T_Finale.mul(T_RZ);
TG_Parent.setTransform(T_Finale);
}
Tu utilises des transformations eulériennes ce qui peut causer du gimbal lock (verrou de Cardan). Il faudrait plutôt utiliser des transformations non eulériennes qui sont plus faciles à exprimer en s'appuyant sur des quaternions.
25 déc. 2006 à 14:54
12 oct. 2006 à 16:43
11 oct. 2006 à 23:45
24 août 2006 à 16:44
je suis du meme avis que toi concernant le peux de complexité du code deplus il est super lisible ce qui j'avoue est assez rare donc congratulation rien que pour ça :D, maintenant les commentaires aide pour savoir ce qui ce passe dans la tete du developpeur lors de la creation du code :P
concernant les optimisations je pense qu'a la longue elle devrait valoir le coup.
pour jogl (c'est comme opengl (meme non, meme parametre casiment)) voici ma recherche sur google :
http://www.google.fr/search?q=jogl+sample+code&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:fr:official
tu tombe sur :
http://today.java.net/pub/a/today/2003/09/11/jogl2d.html
http://www.cs.umd.edu/~meesh/kmconroy/JOGLTutorial/
24 août 2006 à 16:02
Pour l'optimiser je vois plusieurs directions:
1/ commencer par ajouter des méthodes pour dessiner des objets plus complexes que sphères et carré.
2/ pour chaque articulation il est possible de définir sur les 3 axes les angles de rotations min/max ainsi lorsqu'on appelle le mouvement de course à 0% tous les angles sont à leur minimum et à 100% tous les angles sont au max mais en réalité un mouvement de course est beaucoup plus complexe il faudrait pouvoir définir des positions intermédiaires.
3/ quand on appelle le mouvement de course à x% je commence par tout remettre aux positons de départ puis effectuer toutes les rotations de x%... on devrait avec un peu de réflexion pouvoir se débarrasser de la moitié des calculs :)
Pour opengl je suis preneur surtout si c'est plus performant mais j'ai surtout trouvé des exemples java3D... ou puis-je trouver des exemples jogl ou javasdl suffisamment "basic" pour qu'un noob comme moi puisse les comprendre?
24 août 2006 à 12:35
le résultat est sympas :D, cependant merci de commenter ta source (les commentaires sont super important surtout pour une source utilisant java3D qui est une usine à charbon à lui seul).
sinon j'ai rien contre java3D si ce n'est sa lenteure d'éxecution et étant plus habitué à opengl je voulais juste t'informer de l'existance de jogl(implentation opengl en java) et de javasdl(implementation de sdl en java) qui sont apres les avoirs testé, plus performant (ca reste mon avis perso donc...)