FORUM PS3, PSP & PS2 » Making Of » OSG, les rotations... le monde et plus si affinités

Etant en vacances depuis quelques jours jusqu'à septembre, je me suis dit que j'allais faire ce que j'ai pas vraiment eu l'occasion de faire en cours jusqu'à présent: de la 3D (on a eu un cours théorique de synthèse d'image bien sympathique mais c'est pas avec ça que je vais pourvoir coder). Pour le coup je suis parti sur un jeu de simulation aérienne (même si pour l'instant mes avions sont des pavés, et que ca va etre très arcade). Je fais ca en C++ avec OSG (OpenSceneGraph: bibliothèque de gestion de graphe de scène qui se place en surcouche d'OpenGL)... et c'est la que commencent les problèmes

OSG c'est très sympathique à l'usage, mais c'est documenté à l'arrache: y'a une doc html généré par doxygen sur laquelle il doit y avoir 70% des méthodes non commentées. Mais au moins y'a des tutoriaux. Donc pour ce qui est de la géométrie de base ça se passe plutôt bien, par contre j'ai deux problèmes: ma gestion du framerate et les déplacements.

Pour la gestion du framerate, en fait je pensais que OSG le gérait. Il le fait peut être... mais j'ai pas trouvé dans la doc. Donc j'ai cherché un peu dans les tutoriaux et je suis tombé là dessus:
http://www.cs.clemson.edu/~malloy/ [...] timer.html
A défaut de mieux j'ai utilisé ça en mettant le tout dans un singleton... avec un do while pour éviter des problèmes d'init. Mais le problème c'est qu'à moins que je sois fou ça reste de l'attente active et ça m'énerve. Est-ce que y'a un équivalent à wait dans OSG (genre le wait de SDL...)? Ca m'embêterait un peu de passer par un wait plus bas niveau parce que dans mes souvenirs ça devient dépendant du système et que pour le moment mon code est portable sans modifs...

Pour les déplacements ça fait deux jours que je suis dessus je comprends toujours pas... enfin il paraît que tout le monde galère au début mais quand même...
J'ai mon osg::Geode avec le modèle du vaisseau centré en 0 qui va dans la direction 0y.
Je cherche à faire des déplacements un peu à la Ace combat 3 (pas testé les plus récents):
- la rotation selon l'axe 0y fait seulement pivoter le vaisseau.
- les rotations selon les axes 0x et 0z dépendent de la rotation en 0y.

Donc j'ai balancé mon osg::Geode dans un osg:ositionAttitudeTransform chargé de faire les rotations et le déplacement. J'ai un vecteur qui représente la direction du vaisseau. Quand les touches haut ou bas sont enfoncées je le modifie et je recalcule les angles pour 0x et 0z en fonction de ce vecteur. Les problèmes c'est que d'une part même quand je touche seulement aux touches gauche et droite, au bout d'environ un demi-tour mon vaisseau arrete de tourner sur lui-même (je croyais avoir reglé le problème et que ça venait d'une mauvaise comprehension de ma part des quaternions mais apparemment c'est revenu automagiquement), et d'autre part que les rotations en 0x et 0z partent en freestyle (mais apparemment ca vient pas des rotations mais de la façon dont je mets à jour la direction puisque la direction m'a l'air d'etre correcte vis à vis des rotations). Bref si quelqu'un a une idée de ce qui déconne je suis preneur... voila en gros le code (disons qu'il est en travaux... j'ai rajoute un deuxième osg:ositionAttitudeTransform entre le premier et l'osg::Geode pour y mettre la rotation en 0y)

Bon, je ne connais pas du tout OSG, mais je tente de répondre quand même
 

Alors, je ne joue plus trop sur PC, mais à l'époque où je le faisais, je ne pense pas que qui que ce soit ne se souciait de faire de l'attente passive...  En gros, on tournait à fond dans la boucle d'affichage, ce qui faisait un nombre d'images par secondes de fou si la scène n'était pas trop compliquée.  Après, si le système est configuré pour attendre la v-sync avant d'échanger les buffers (si tu fait du double-buffering), ça doit provoquer de l'attente passive le temps que le swap ait bien lieu (enfin en théorie OpenGl est asynchrone si je ne m'abuse, mais même dans ce cas, si tu vas plus vite que le rafraîchissement de ton écran, ça finit forcément par saturer -> attente passive).
 
Si tu as vraiment besoin d'attendre un timer ou le clavier par exemple, ce n'est pas vraiment à une bibliothèque graphique de te proposer ce genre de fonctions...  Par contre, tu dois pouvoir trouver des bibliothèques portables qui le permettent (genre SDL ?), et que tu peux utiliser en plus d'OSG.
 

Arf, problème pour moi là : je n'ai pas Ace Combat 3, et j'ai du mal à voir à quoi correspond cette distinction des rotations selon (Oy) d'une part, et (Ox) et (Oz) d'autre part (ok, l'une fait seulement pivoter le vaisseau, mais les autres font quoi ?  tout pivoter ?  Ça me paraît bizarre comme truc, va falloir que j'essaie AC3 un jour ^^)...
 

Bein c'est effectivement un problème avec les quaternions, je pense...  En gros, dans ce code :

n'est valable que quand ton angle "rotation_" est petit.  La formule générale serait plutôt l'une de ces deux là :

(les deux étant équivalentes, la première définit directement le quaternion à partir de ses 4 composantes, la seconde donne l'angle et le vecteur directeur de la rotation).  Quand rotation_ est petit, tu as bien sin(rotation_) ~ rotation/2, et cos(rotation_) ~ 1, ce qui fait que ton code marchait bien pour les petits angles.
 

Oui, là tu as plusieurs problèmes :

Tout d'abord, ton calcul de rot_x et rot_z (lignes 1-2) n'est pas bon (du moins si ton but est bien de trouver les angles selon x et z).  Les composantes x,y et z du quaternion définissent les coordonnées d'un vecteur directeur de l'axe de rotation, et non pas des angles (si les angles sont petits en revanche, ça marche à peu près).  Et normaliser en divisant par w n'a aucune raison d'aider.  Après, si tu veux absolument récupérer les angles, les formules sont un peu plus compliquées, et ça dépend de ce que tu veux exactement.  Si ce sont les angles d'Euler, ça donne ça (formules trouvées sur le net, je n'ai pas vérifié mais ça me semble correct à première vue) :
  tan(rot_x) = 2(xy + zw) / (w² + x² - y² - z²)
  sin(rot_y) = -2(xz - yw)
  tan(rot_z) =  2(xw + yz) / (w² - x² - y² + z²)  
 
Mais le plus génant je pense, ce sont les formules des lignes 4-7 par exemple.  Déjà avec des cos à l'intérieur des cos, on se dit qu'il y a un truc louche.  De plus, je ne pense pas que tu puisses obtenir une rotation simplement en ajoutant un cos/sin de quelque chose à ton vecteur (pense que le vecteur nul par exemple ne doit pas bouger après rotation).  Grosso modo, chaque composante du vecteur doit devenir une combinaison linéaire des composantes, ie pour tourner le vecteur (x,y,z), tu doit appliquer une formule de la forme x' = ax + by + cz, ou a,b, et c sont à déterminer en fonction de ta rotation (en général, c'est des sinus, cosinus ou des produit de sin et/ou cos), et pareil pour les autres coordonnées...
 
Cela dit, puisque tu utilises des quaternions, tu peux sans doute t'en servir pour tourner ton vecteur, ce qui doit être bien plus simple (et ça t'évite d'avoir à recalculer les angles de rotation rot_x et rot_z)...  En fait, j'aurais même tendance à faire le contraire de ce que tu fais, c'est à dire calculer d'abord la rotation (en multipliant les quaternions pour composer ton ancienne rotation avec celles produites par la pression des touches), puis, si tu en as besoin, calculer la direction en appliquant la rotation au vecteur direction initial.
 
Je t'aurais bien proposé un bout de code, mais j'ai vraiment du mal à voir à quoi correspondent tes rotations (et aussi direction_ d'ailleurs : tu dis que c'est la direction du vaisseau, mais il ne change pas quand tu presses haut/bas alors que le vaisseau est sencé tourner ?)

Bein disons que OSG propose des timers que j'utilise pour la boucle d'attente (et que j'utiliserais volontier pour de la gestion clavier et cie) mais pas d'équivalent à SDL_wait à ma connaissance. En fait je voulais forcer le jeu à tourner à 60fps pour me simplifier la vie vis à vis des vitesses de déplacement mais plus je code plus je me rends compte que de toute façon je mets la fréquence d'affichage dans tous les calculs donc bon...
 

Je voulais justement essayer éviter la chose. Je sais que la SDL est sensé permettre de balancer de l'OpenGL et d'après ce que j'en ai lu on peut utiliser OSG dans SDL. Mais pour le coup faut faire la gestion de la fenêtre en SDL ce qui me paraît un peu extrême pour juste utiliser SDL_wait au final. Donc je commence par essayer de me renseigner pour voir si y'a pas déjà un équivalent portable dans OSG.
 
 

J'vais tenter de le réexpliquer pour que ce soit compréhensible
Si on part sur du (0x, 0y, 0z), a l'init mon vaisceau à son centre en (0, 0, 0) et se dirige vers (0, 1, 0).
Quand j'appuie sur la fleche gauche ou la droite, je fais varier la rotation suivant l'axe 0y (dans le repère du vaisceau).
Quand j'appuie sur bas ou sur haut, je change la direction de l'appareil en prenant en compte la rotation en 0y.
 
 

Effectivement ça explique des choses... encore que j'ai du mal avec ta première formule. Faut que me trouve un bon tutorial sur les quaternions ^^;
 
 

Le cas du vecteur était pas sensé se présenter en fait. L'idée c'était que direction_ soit un vecteur normalisé que j'aie plus qu'à multiplié par ma vitesse de déplacement puis à additionner à la position courante. Mais clairement la formule de mise à jour est empiriquement en freestyle...
 
 

C'est ce que je faisais à la base. Seulement avec ma compréhension limitée des quaternions ça me donnait une direction fantaisiste  
 

Si justement, direction_ est modifié que quand haut ou bas sont appuyés.

Ah oui, je crois que j'ai compris
En gros, Oy est l'axe de roulis, et quand tu disais qu'une rotation selon Oy faisait seulement pivoter le vaisseau c'était dans le sens "ne change pas sa direction" ?  Je ne sais pas pourquoi, j'étais persuadé que c'était l'axe de lacet, et forcément je trouvais ça bizarre.
 
En fait, dans ce cas, je pense que tu n'as même pas à traiter de manière différente la rotation selon l'axe Oy des autres rotations.  Logiquement, même si tu tournes ton vecteur direction selon Oy (dans repère de l'avion), il ne changera pas de toute façon.  Bref, l'idée c'est de garder un quaternion pour la rotation en cours, et de le multiplier par la nouvelle rotation à chaque changement...  En reprenant ton code du début, ça donnerait un truc comme ça :

Bon, j'ai normalisé rot en le divisant par sa longueur (en espérant que length fait bien ce qu'il faut), après ce n'est peut être pas nécessaire.  L'idée, c'est qu'un quaternion utilisé pour la rotation doit être unitaire, ce qui peut ne plus être le cas après les multiplications s'il y a eu des erreurs d'arrondi.  Maintenant, ça dépend de comment tout ça est implémenté, si ça se trouve le quaternion est automatiquement normalisé quand on l'utilise pour une rotation par exemple...
 
Sinon, toutes les rotations sont contenues dans le transf_, et il n'y a pas besoin du orient_ (à moins que ces deux rotations s'appliquent à deux choses différentes, auquel cas je n'ai pas tout compris).  Pour retrouver ta direction, il faut trouver le conjugué de ton vecteur d (pris comme un quaternion dont la composante en w est nul) par le quaternion r correspondant à la rotation : d' = r d r^-1.   Si je ne me plante pas l'opérateur * des quaternions appliqué sur un vecteur dans OSG semble effectuer la conjugaison, donc il suffit d'effectuer r*d (ou d est la direction initiale, ie. (0,1,0)) pour obtenir ton vecteur direction correctement orienté (sinon, tu peux le faire à la main, ie. avec un truc du genre  rot*osg::Quat(0,1,0,0)*rot.inverse()  et ignorer la composante w du résultat, mais c'est plus lourd ^^).
 
EDIT: Par contre, si tu appuis à la fois sur haut et gauche par exemple, ça va d'abord appliquer la rotation à gauche (selon Oy), puis celle vers le haut (selon Ox, enfin ça dépend de comment sont définis tes axes), ce qui est purement arbitraire.  Si les rotations élémentaires sont petites, ça ne pose pas de problème, sinon il faudrait faire un cas spécial avec une seule rotation selon un axe transversal je pense (enfin c'est du détail pour l'instant je pense, c'est comme le coup d'avancer dans la direction de l'avion sans tenir compte de la gravité et de la portance ).
 
EDIT2: Ah oui, bien sur rot doit être initialisé comme la rotation identité (rotation d'angle nul), ie par le quaternion (0,0,0,1), si tu ne veux pas commencer avec une rotation dès le départ.
 

Bein il y a toute une théorie derrière, très intéressante si tu aimes bien l'algèbre
 
Pour ma formule, l'idée c'est que les composantes (x,y,z,w) d'un quaternion "de rotation" sont définies comme suit :
- (x,y,z) définit un vecteur directeur de l'axe de la rotation
- w vaut cos(angle/2)
- le quaternion doit être unitaire, ce qui implique que la longueur du vecteur directeur (x,y,z) vaut sin(angle/2)
Donc pour une rotation d'axe défini par le vecteur directeur unitaire (u,v,w), et d'angle a, le quaternion a les coordonnées (u sin(a/2), v sin(a/2), w sin(a/2), cos(a/2)).  C'est un peu comme avec les nombres complexes en 2D si tu veux : une rotation d'angle a est représentée par le complexe unitaire e^(ia), dont les coordonnées sont (cos(a), sin(a)).
 
Après pour retrouver les angles autour d'axes fixés (par exemple Ox, Oy et Oz) et non de l'axe de rotation lui même, il faut faire un peu de trigo
 

Oups, je voulais dire gauche/droite et non pas haut/bas
Mais si j'ai bien compris ton mode de déplacement, c'est effectivement normal.

J'ai bricolé un peu mon code ce matin... la nouvelle fournée donne ça:

Ca m'a l'air de marcher pas trop mal mais j'ai encore des comportements bizaroïdes sur les rotations selon 0x et 0z de temps en temps...
 

Voila, donc 0y axe de roulis, 0x axe de tangage et 0z axe de lacet dans mon cas  
 

C'est ce que je faisais au début... je l'ai remis comme ça maintenant. Mais ce qui m'embête c'est que je comprends pas trop comment je suis sensé gérer le quaternion. J'ai besoin dans un premier temps d'une rotation que sur 0x et 0z pour faire tourner mon vecteur de direction. Après il faut que j'ajoute la rotation en 0y pour le vaisseau. Le problème c'est que selon que je multiplie le quaternion d'origine à gauche ou à droite j'ai pas l'impression d'avoir le même résultat ce qui me paraît bizarre (du coup par rapport au code au dessus j'ai rajouté un makeRotate après la rotation du vecteur direction_ pour avoir la paix mais je trouve ça moche). Mais plus j'y pense plus je me dis qu'en fait comme j'ai un décor sans source de lumière et sans textures c'est juste la géométrie du décor qui joue avec mes nerfs...

Oui, sauf que tu dois toujours orthogonaliser de temps en temps si je ne m'abuse (je vois pas trop comment opengl t'en dispenser sachant qu'il accepte (à peu près) n'importe quoi comme matrice de transformation, et qu'il ne peut pas être à l'abri d'erreurs d'arrondi).  Enfin, ça reste plus rapide que de faire tous les calculs à la main, je le reconnais...
 
Cela dit, je pense que la seule véritable raison pour laquelle il utilise des quaternions ici, c'est que la bibliothèque qu'il utilise (OSG) semble n'utiliser que ça en natif...
 

La multiplication des quaternions n'est pas commutative, sauf dans certains cas particulier (ex. deux rotations autour du même axe).  Si tu as l'impression qu'elle l'est, c'est que tu es sans doute tombé sur l'un de ces cas particuliers
Si tu as deux quaternions q1 et q2, qui représentent deux rotations r1 et r2, le produit q1*q2 représente la composé r1 o r2 de tes deux rotations (ie. tu appliques r2, puis r1 dans cet ordre, ce qui est différent de r1 puis r2 en général).  Pour appliquer une rotation dans le repère local de ton avion, il faut effectuer cette rotation en premier (avant que le repère n'ait été changé par l' "ancienne" rotation).  Donc pour résumer :
- Si q représente la rotation en cours de ton avion (avant d'appuyer sur une touche)
- Si r représente la rotation autour de l'axe (Oy) (ou (Ox) ou (Oz), c'est selon) local à l'avion que tu veux "ajouter" à ta rotation en cours (suite à une pression sur gauche par exemple)
==> la nouvelle rotation pour ton avion sera  q' = q*r
 
Maintenant, je viens d'aller voir les sources de OSG (la doc étant complètement insuffisante), et l'opérateur * est défini à l'envers !!!
Donc en fait, dans ton programme, il faut calculer q' = r*q (et donc forcément le code que j'ai mis plus haut ne marche pas, ou plutôt multiplie dans le mauvais sens, ce qui implique une rotation dans le repère global et non dans le repère local)...
 
J'en ai profité pour faire un test avec un exemple tout simple (caméra fixe, avion qui fonce tout droit devant lui, gauche/droite modifient le roulis, et  haut/bas le tangage).   Je mets le code complet si tu veux voir ce que ça fait (mais bon, comme je ne connais pas OSG, c'est principalement du copier/coller de bouts de tutoriels modifiés jusqu'à ce que ça marche ^^), mais la partie qui t'intéresse est la méthode Scene::update (lignes 44 à 66).  En théorie le code compile sans warning, et j'ai fait l'édition de lien avec "-losgProducer -losg" sur un système Debian/sid (linux).
[EDIT : par contre, j'ai codé les pas de déplacement/rotation en dur et je ne les adapte pas au framerate, donc à modifier si ça va trop vite ou trop lentement]

Effectivement, il y a une classe MatrixTransform qui semble faire la même chose que PositionAttitudeTransform mais avec des matrices (j'ai pas regardé en détail cela dit).  C'est sans doute ce qu'il y a de mieux à utiliser effectivement...
 
Par contre, pour s'amuser à construire le quaternion à partir de la matrice dans ce genre de situation, faut vraiment ne pas supporter les quaternions (ok, ça simplifie le déplacement, mais ça doit entraîner pas mal de surcoûts en contre-partie)

OSG propose les quaternions, la représentation matricielle et de quoi faire des conversions. Après y'a tout une collection de méthodes pour générer des quaternions à partir des angles d'Euler. Mais comme ces fonctions sont justement jamais commentées dans la doc
Par contre pour ce qui est de la caméra c'est purement de la matrice... j'avais galéré par mal dessus a début puis j'ai fini par trouver un tutorial où en gros ils expliquent qu'il suffit de placer un PositionAttitudeTransform à la position voulu en fils du noeud suivi par la caméra et de récupérer ses coordonnées dans le monde à coup de visitor.

Ouais... en fait plus sérieusement je voulais utiliser une bibliothèque qui me gère uniquement le graphe de scène (pour pas me faire chier avec les rotations justement ) et les entrées pour faire par dessus une bibliothèque évènementielle (d'où aussi mon trip sur la synchronisation vis à vis du framerate). Fin d'année on a fait un peu de théorique sur les langages acteurs et à la rentrée on va attaquer les SMA. Donc c'est histoire de voir un peu toutes les problématiques de synchronisation planquées tout en faisant de la 3D...

Pis bon... DirectX fallait que je code sous Windows pour finir avec du code pas portable et Ogre je peux plus le voir depuis que j'ai vu que les noeuds du graphe de scène sont indexés sur des chaînes de caractères...

Si tu veux on m'avait toujours dit de justement faire de l'absolu plutôt que du relatif parce que les erreurs d'arrondis sont sensés finir par te pourrir complètement la scène. Maintenant faut croire que ceux qui m'ont dit ça utilisent pas de quaternions

Donc je suis pas fou
Merci pour l'explication je comprends déjà mieux mes problèmes de rotations

Shao Onos > Y'a un truc que j'ai du mal à comprendre dans ton code en fait. Tu fais jamais de rotation selon l'axe 0z pourtant ça m'a l'air de marcher quand je teste le code. Elle est faite plus ou moins toute seule par la multiplication des quaternions?

En gros, c'est les histoires d'interpolation foireuses qui font que d'un coup ton modèle contorsioniste quoi
(me souviens de choses bizarres dans le genre sur le projet de motion capture sur lequel j'avais bossé... le gars qui s'occupait de la 3D a pas eu le temps de résoudre le problème ce qui fait que de temps en temps les pieds du modèle faisaient des tours complets sur eux-mêmes )

Je comprends l'idée... par contre je comprends plus comment j'arrivais à faire des sauts dans les premiers Tomb raider

J'appuie et j'enfonce, mais quelque part je préfère ça aux pointeurs cachés de DirectX. Pis bon... ça reste mieux documenté que la bibliothèque interne de mon dernier stage

+1 vu que je l'ai écrite
faut que je la change... le problème c'est que les blagues de geeks classiques sont déjà sur-utilisées en général (il n'y a que 10/11 types de personnes dans le monde, tout ça). Après si je vais chercher dans les japanimes c'est pareil et les privates jokes avec les gens que je connais ça fera rire que moi. Repomper du bash ou du bashfr représente un intérêt limité aussi. Quoter du Douglas Adams ou du Tolkien... déjà vu et revu...
Je vais finir par écrire en l33tsp34k un aiku lui même étant une traducion en elfique d'une citation d'un anime de geek genre Battle Programmer Shirase ou Genshiken

A la premièr lecture j'ai eu l'impression d'être enduit d'erreur
Enfin en y réfléchissant vu que c'est la composée je comprends la logique de la chose. Par contre ce qui m'ennuit c'est que maintenant que la direction du vaisseau est bonne j'essaye de lui mettre une tourelle de tir. Pour le coup elle tourne selon 0x et 0z, mais avec ces histoires de conjugués ça tourne tout seul selon selon 0y aussi si je fais des multiplications de quaternions
Enfin bon... avec un peu de bol l'opérateur + surchargé pour les quternions fait l'addition des rotations (oui je sais j'ai beaucoup d'espoir )...
 

Bein dans Tomb raider pour réussir un saut: tu t'approches du bord en marchant, tu t'orientes dans la direction du point de réception, tu fais un pas en arrière... tu cours puis tu sautes. Mais tout ça ça me semble intimement dépendant de la séquence des mouvements précédent le saut  
 

A ce compte là y'a des choses sympathiques sur bash... en traduction approximative ça donne ça:
"Y'a 5 ans mon pote était vierge, aujourd'hui il est marié et il a deux enfants. Vous allez le sortir un jour Duke Nukem Forever?"  

Non, comme l'a dit koren, l'opérateur + risque de ne pas te servir à grand chose.  Si par "ajouter" des rotations, tu entends faire l'une puis l'autre, c'est juste une composition (opérateur * donc).
 
Dans le cas de ta tourelle de tir, le plus simple, c'est de profiter de la structure arborescente de la scène sous OSG.  En gros, tu peux utiliser quelque chose comme ça (hum, avec la gestion des fontes à pas fixe du forum, je sens que ça ne va pas être super lisible, mais bon on fait avec ce que l'on a ^^) :

En fonctionnant ainsi, la transformation pour l'avion s'applique à tout le groupe (avion et tourelle), de sorte que quand ton avion avance/tourne, la tourelle le suit correctement.  Pour tourner la tourelle, il suffit alors de ne changer que la transformation de la tourelle, et ce dans le repère de l'avion (ie. sans chercher à savoir comment est positionné ton avion) : il s'agit probablement d'une simple rotation selon l'axe (Oz).
 
Il faut juste faire attention à définir la tourelle de sorte que l'axe de rotation coïncide avec l'axe (Oz).  Si tu veux positionner ta tourelle sur une aile, ou l'avancer/la reculer sur l'avion, il faut quand même la définir au centre, puis faire une translation en plus (avec un setPosition, à n'utiliser qu'une seule fois au début, puisque la tourelle ne se déplace pas sur l'avion ensuite)...
 
J'ai fait une version modifiée de mon code en mettant deux tourelles (une sur chaque aile).  J'ai utilisé le même Geode pour les deux tourelles, vu qu'elles sont identiques, par contre il y a bien deux transformations différentes.  Je mets juste le source de la classe Scene, le reste n'ayant pas changé (enfin si, dans la gestion des touches, je mets à jour t1l, t1r pour tourner à gauche/droite la première tourelle, et t2l, t2r pour tourner la seconde).
 
[EDIT : J'ai rajouté une 3ème tourelle arrière sur l'aileron de l'avion (oui je sais c'est ridicule, mais bon ^^), que l'on peut tourner autour de deux axes (lattitude et longitude, ie (Oz) de l'avion et (Ox) de la tourelle, ça me semble être le mode de contrôle le plus naturel, mais on peut changer ça au besoin), avec des limitations sur les angles maximaux autorisés...  Il faut activer t3l, t3r, t3u, ou t3d pour activer la rotation.]

Pour tourner les tourelles, on peut utiliser principalement deux méthodes :
- Mémoriser l'angle, et effectuer une rotation "absolue" (sans tenir compte des anciennes valeurs de _transf1 et _transf2)
- Faire comme avec l'avion : multiplier l'ancien quaternion par celui représentant la rotation "relative"
Là, j'ai préféré utiliser la 1ere méthode, ça évite une multiplication de quaternions et la normalisation, et ça permet éventuellement d'imposer facilement des limitations sur l'angle par exemple.  Par contre, avec la formule que j'ai utilisé, l'angle "réel" des tourelles n'est pas angle1 ou angle2, mais le double (cf. les formules que j'avais mis au début).  Ce n'est pas génant, car ça revient à diviser les incréments par deux, mais c'est bon à savoir si tu veux limiter l'angle correctement (et ça explique que les tourelles font 2 tours quand l'avion n'en fait qu'un, alors que les incréments d'angle sont les mêmes).

C'est ce que j'ai fait. Là où ça se complique c'est que c'est que ma tourelle ne bouge pas que sur un seul axe. En gros dans la scène j'ai deux caméras: l'un qui suit le vaisseau et l'autre que en quelque sorte une vue subjective de la tourelle avec un viseur. La tourelle pouvant tourner en 0y et 0x est controlée idéalement à la souris. Mais bon je devrais pouvoir me débrouiller faut que je joue un peu avec les quaternions pour bien me mettre dedans...

En fait étant donné qu'on utilise des quaternions, je pensais essayer une troisième solution: définir les valeurs limites des rotations par des quaternions et retrouver l'inclinaison à coup de slerp. Maintenant je m'embarque ptet dans un truc tordu...

Bêtement question temps d'exécution, il vaudrait mieux faire quoi