Discussion :

[Ange_blond]

Bonjour,

Je suis sur OpenSceneGraph, et je bosse en ce moment sur un petit systeme permettant de maintenir la camera fixe (statique) par rapport à un element de la scene, qui lui est mobile (rotation et translation).

Ma cible bouge donc en 3D.

Mon approche est de récuperer les données de mouvement/rotation de ma cible pour ensuite les appliquer à ma camera.

En translation tout se passe tres bien.
En rotation les choses se compliquent : dans l'état actuel, et sans comprendre pourquoi, mon code ne permet à ma camera d'etre vraiment fixe que si ma cible ne pivote que selon un axe "pur" (donc (1,0,0) ou (0,1,0) ou (0,0,1) ).
Si l'axe de rotation de la cible se décompose selon 2 ou 3 composantes, ma camera montre un réel décalage entre le mouvement de la cible et son mouvement.

Note importante : la rotation de la camera doit obligatoirement se décomposer en 2 phases : rotation et translation. En effet la rotation permet d'avoir la meme orientation, et la translation permet de se repositionner au meme point que la frame d'avant.
Imaginez que la camera est à une certaine distance de la cible... quand la cible tourne, la camera va tourner selon le meme angle, mais va aussi devoir se translater pour revenir aux meme coordonées relatives du point de vue de la cible.

Si vous n'arrivez pas à suivre n'hesitez pas je ferai plus clair...

Bon, voilà le bout de code qui calcule la rotation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
//ROTATION
			osg::Quat qq ;
 
			//Target node have to be a PAT or a MT. Else no rotation will be applied		
			if((pat || mt) && _setRefRot)
			{
 
				if(pat)
					qq = pat->getAttitude();
				else
					qq = mt->getMatrix().getRotate();	
 
				osg::Quat _q_ = qq * _QuatActual.inverse(); // = rotation from qq to QuatActual			
 
				_q_.inverse();
 
				osg::Matrix matrot = osg::Matrix::identity();
				osg::Matrix mattrans = osg::Matrix::identity();
				osg::Matrix mattransi = osg::Matrix::identity();
 
				mattrans.makeTranslate(mat.getTrans() - getEyePoint()); //DISPVECT("CamToNode",(mattrans.getTrans()));
				mattransi.invert(mattrans);
				matrot.makeRotate(_q_);	
 
				osg::Matrix Rot = mattransi * matrot * mattrans; 
 
				_eye -= Rot.getTrans(); //add vector of translation to keep camera motionless relative to the node
 
				_rotation *= _q_; //apply rotation to camera
 
				_QuatActual = qq;
			}

Voilou.

Si vous avez des idées.... je prend !

Merci

(Merci à Loka pour sa restauration )

[loka]

[Réponses apportés]

Message de raptor70 24/07/2008 à 11h10:

2 petites choses :
- attention aux rotations car ton axis up va peut être changé.. (je ne sais pas si c'est ce que tu veux)
- il est beaucoup plus facile, pour une caméra, de gérer sa position et sa target et de calculer les rotation en fonction de ca. Pour une rotation simple, tu aura soit la position soit la target qui vont translater. Dans le cas d'une translation, les deux vont translater.

[loka]

Message de Ange_blond 24/07/2008 à 11h16:

2 petites choses :
- attention aux rotations car ton axis up va peut être changé.. (je ne sais pas si c'est ce que tu veux)

Ce n'est pas un soucis, la camera peut subir toutes les rotations qu'elle veut, y'a pas de restrictions.

- il est beaucoup plus facile, pour une caméra, de gérer sa position et sa target et de calculer les rotation en fonction de ca. Pour une rotation simple, tu aura soit la position soit la target qui vont translater. Dans le cas d'une translation, les deux vont translater.

C'est exactement ce que je fait...
Ma target est déplacée & pivotée, et ensuite ma camera récupere ces données de transformation, et se les applique (apparement pas tres bien).

Le fait que ça marche tres bien si la rotation ne se fait que sur un axe simple me dérange particulierement... je ne vois pas la logique là dedans ! soit tout est bon soit tout est faux...

si on tente de partir de zero, comment vous feriez ce genre de calculs ?

Merci

[loka]

Message de raptor70 24/07/2008 à 11h51:

Ce n'est pas un soucis, la camera peut subir toutes les rotations qu'elle veut, y'a pas de restrictions.



C'est exactement ce que je fait...
Ma target est déplacée & pivotée, et ensuite ma camera récupere ces données de transformation, et se les applique (apparement pas tres bien).

Le fait que ça marche tres bien si la rotation ne se fait que sur un axe simple me dérange particulierement... je ne vois pas la logique là dedans ! soit tout est bon soit tout est faux...

si on tente de partir de zero, comment vous feriez ce genre de calculs ?

Merci

Si ca marche pour des rotations d'axes "simple", c'est que tu as peut être un problème pour traduire ta rotation en matrice de transformation ( tu as l'air de passer par un quaternion pourtant)

[loka]

Message de Ange_blond 24/07/2008 à 11h58:

C'est justement tout l'illogisme de la question : l'utilisation de matrices et de quaternions me garantit normalement un calcul sans failles.

Et le fait que ça ne marche qu'a moitié n'est pas un indice interessant pour trouver mon soucis... si ce n'est que le probleme est difficile à trouver

Si tu devais faire en sorte que ta camera soit completement statique par rapport à un element de ta scene, ce dernier subissant des rotations et translations sur les 3 axes, tu ferai comment ?

(j'essaye de m'extraire du probleme, avoir un point de vue différent...)

Merci

[loka]

Message de raptor70 24/07/2008 à 12h16:

C'est justement tout l'illogisme de la question : l'utilisation de matrices et de quaternions me garantit normalement un calcul sans failles.

Et le fait que ça ne marche qu'a moitié n'est pas un indice interessant pour trouver mon soucis... si ce n'est que le probleme est difficile à trouver

Si tu devais faire en sorte que ta camera soit completement statique par rapport à un element de ta scene, ce dernier subissant des rotations et translations sur les 3 axes, tu ferai comment ?

(j'essaye de m'extraire du probleme, avoir un point de vue différent...)

Merci

Je laisserais la target en permanence sur l'objet et je changerais seulement la position de la camera. Ensuite je calculerais mon orientation (quaternion) a partir du vecteur direction (target - position) et j'utiliserais ce quaternion et le position de la camera pour paramétré ma caméra

[loka]

Message de Ange_blond 24/07/2008 à 12h29:

Je laisserais la target en permanence sur l'objet et je changerais seulement la position de la camera.

si je comprend ce que tu veux dire, tu parle d'une sorte de lookat + une une translation, mais je ne peux pas mettre mon objet pour "target" car ma camera doit etre statique par rapport à lui, mais pas forcément le regarder en permanence... le but final est de placer la camera dans le repere local de l'objet cible. histoire qu'on puisse la déplacer sans prendre en compte les transformation subies par l'objet.

Ensuite je calculerais mon orientation (quaternion) a partir du vecteur direction (target - position) et j'utiliserais ce quaternion et le position de la camera pour paramétré ma caméra

je comprend là dedans le fonctionnement d'un lookat amélioré.

Je le précise car je n'ai pas été précis au départ : mon but est de faire que la cemera se comporte comme si elle était dans le referenciel de l'objet. l'objet et la camera ne doivent bouger l'un par rapport à l'autre que si l'utilisateur choisit de bouger la camera, dans le referentiel local de l'objet cible.

Merci.

[loka]

Message de raptor70 24/07/2008 à 12h40:

Dans ce cas, prenons un exemple...

Tu veux, par exemple, que la camera se trouve à une position fixe derrière un personnage mais qu'elle regarde un peu sur la gauche du personnage ( vers un objet interressant par exemple)

Dans ce cas, tu places la position de la camera a une position fixe derrière ton personnage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
camera_position.x = perso_position.x + offset_x; 
camera_position.y = 2; // exemple d'une camera se trouvant toujours a une hauteur de 5m
camera_position.z =perso_position.z + offset_z;

Ensuite, ta target doit se trouver sur ce que tu veux regarder :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
target_position.x = objet_position.x; 
target_position.y = objet_position.y;
target_position.z = objet_position.z;

Enfin, tu peux obtenir la direction de ta camera par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
camera_direction = target_position - camera_position;
camera_direction.Normalize(); //eventuellement

Ensuite, tu as tout pour configurer ta camera; ue position (camera_position) et une direction (camera_direction).

Si le paramétrage de ta caméra nécessite angle de rotation + axe, il faut convertir ta direction en quaternion.

[loka]

Message de Mat007 24/07/2008 à 13h27:

Salut,

Tu peux pas plus simplement attacher la caméra à un nœud fils du nœud de ton objet ?

MAT.

[loka]

Message de Ange_blond 24/07/2008 à 13h33:

ok, alors pour la translation de mon "referenciel" pas de soucis elle suivra,

par contre si je fait tourner le perso de pi/2 selon Z, et que ma camera est à un offset de 10,10,10 du perso, elle ne va pas pivoter comme il faut.

en fait, ta "target" me perturbe... ma camera n'a pas de "target" a proprement parler... elle se contente de se placer dans le referenciel de mon objet, et de le suivre dans toutes ses transformations...

La translation est déjà bonne, mais la rotation est le probleme.

j'ai peur qu'on s'emmele les pinceau en étant a coté de la plaque en fait, donc je prefere expliquer simplement.

Imagine ta main comme camera, dirige là vers le plafond, et alonge le bras (pas trop sinon tu va tout peter ^^ ). Ensuite tourne sur toi meme. la camera reste bien statique par rapport à toi, mais en réalité elle subit une rotation(axe vertical) et une translation (dans le repere absolu) (dans le plan du sol/plafond).
C'est ce que je cherche à reproduire.
Y'a pas de notion de lookat.

(Le tout en temps réel bien sur, donc necessité de mesure des différences de translation et de rotation, pour les ajouter aux autres parametres qui influencent la camera, mais ça c'est du détail.)

Edit for MAT : non je ne peux pas l'attacher au niveau du noeud... je cherche à faire un équivalent comportemental donc.

[loka]

Message de raptor70 24/07/2008 à 13h46:

Bon, je crois que je vois le problème .

Ton design de camera défini tout a fait la position de ta camera, mais pas où elle regarde.

Le cas de la position, j'ai effectivement fait une petite erreur, les formule que j'ai donné sont dans le référentiel local de ton perso (orienté comme ton perso). Si ton perso est dirigé dans une direction perso_direction (seulement en X/Z, unitaire ), les formule deviennes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
camera_position = perso_position - recul * perso_direction;
camera_position.y = perso_position.y + 2;

Ce code position ta camera à recul m de ton perso, et a 2m de hauteur (par rapport au perso).

Ensuite, maintenant que tu as placé ta camera en position. Il faut savoir ce quel regarde... Si elle doit regarder dans la meme direction que ton perso :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
camera_direction = perso_direction;

[loka]

Message de Ange_blond 24/07/2008 à 14h07:

On entre dans le vif du sujet !

je travaille en mouvement relatif, donc je me contente de mesurer les angles à l'instant T, et le comparer à l'instant t-1 pour calculer la différence d'angle.

De cette différence, je sais de combien mon referenciel a pivoté (axe et angle quelconques).

Ce que je fait moi dans ce cas là, de maniere plus détaillée, c'est de calculer mon vecteur de décalage entre la camera et mon referenciel, j'applique la rotation mesurée à ce vecteur ( de maniere à avoir mon "futur" vecteur). Je fait la différence entre les deux, et j'ai mon vecteur offset de rotation.

Ensuite comme toi j'applique cette rotation à la caméra.

en théorie (et c'est là qu'on commence à se marrer) c'est fiable.

en pratique, j'ai ce fameux soucis, de décalage dans le referenciel... ma camera ne suit pas tout à fait les transformations !

Une autre idée pour calculer le nouveau positionnement/rotation de la camera avec les données d'angle a jouter ?

[loka]

Message de TanEk 24/07/2008 à 14h47:

Je n'ai pas trop saisi ton code. Tu fais des inversions de matrices, j'ai l'impression que tu annules la translation de ton objet, tu appliques une rotation et tu remets la translation... Bref peux-tu le mettre en "pseudo-code" ?

Sinon voici ce que j'aurai fais (je suis pas encore un expert des changements de repère donc ce que je dis n'a peut-être pas de sens mais bon ) mais qui nécessite une chose : avoir la matrice qui permet de passer du repère local à l'objet au repère monde (pas la modelView...). L'as-tu ? Normalement oui... On l'appellera M.

Si oui je ferais comme ça :

Ensuite on définit la matrice qui permet de passer du repère monde au repère vue par Mc-1 (l'inverse de la matrice de la caméra). Tout ceci est standard donc la matrice de modelview est donc égale à Mc-1 * M en rawMajor.

Toi tu veux que Mc = Mcamera * M avec Mcamera la matrice définit par un gluLookAt dans le repère M. Donc tu as :

MmodelView = (Mcamera * M)-1 * M

Ce qui donne :

MmodelView = M-1 * Mcamera -1 * M

Ce qui est bien une multiplication donnant un changement de repère. Donc tu n'as qu'à faire :
Mc = Mcamera * M

Et à inverser tout ça et tu auras ton repère caméra openGL (en faisant un transpose... raw major...) définit dans le repère local à l'objet (ce qui est bien ce que tu veux ?).

[loka]

Message de Mat007 24/07/2008 à 15h12:

non je ne peux pas l'attacher au niveau du noeud... je cherche à faire un équivalent comportemental donc.

A ce moment-là tu ajoutes un nœud au-dessus de ta caméra pour y recopier telle quelle la transformation de l'objet visé, et ça va se combiner tout seul avec la transformation existante de la caméra.

C'est quand un des gros intérêts d'un scenegraph que de pouvoir régler plein de problèmes juste en combinant les nœuds différemment...

MAT.

[loka]

Message de Ange_blond 24/07/2008 à 16h00:

A ce moment-là tu ajoutes un nœud au-dessus de ta caméra pour y recopier telle quelle la transformation de l'objet visé, et ça va se combiner tout seul avec la transformation existante de la caméra.

C'est une idée oui, mais de dupliquer le noeud de transformation est pas tres fair-play si je puis dire d'autant plus que la reference (ou l'objet reference) change souvent... et donc la gestion du noeud de trasnsformation se complique un tantinet...

De plus, il est selon moi lpus propre de faire des petits calculs tout mignons pour arriver à mes fins plutot que d'arranger le scenegraph. Dans ce cas là en tout cas.

Bref peux-tu le mettre en "pseudo-code" ?

En fait voilà ce que je fait :
je récupere la position et l'orientation de ma reference (ou noeud reference).
je calcul la différence de position et de rotation par rapport à la derniere frame.

J'ajoute la translation calculée à ma camera (facile, et ça marche tres bien)
J'ajoute ma rotation à ma camera et pour ce faire :
- Je fait pivoter ma camera de l'angle calculé (normal quoi...)
- Je calcule et je translate ma camera du vecteur correspondant à la rotation, en fonction de la position relative de la camera par rapport à la reference, de maniere à bien rester fixe par rapport à ma reference.

C'est ce dernier point qui semble est incorrect. Peut etre meme tout le calcul de la rotation...

Pour faire le calcul de différence de rotation je fait :
rotation = rotation_courante * rotation_ancienne.inverse() (ce sont des quaternions bien entendu)

Pour faire le calcul de la translation correspondant à la rotation, je calcule le vecteur entre la camera et le referentiel (simple translation), je le pivote en lui appliquant le quaternion, et je fait la différence entre le vecteur d'avant et celui pivoté.
Je l'ai aussi fait avec des matrices, en fesant la combinaison de la translation, rotation, translation inverse, puis je récuperait ma translation sur la matrice résultat. il semble qu'au final ça donne la même chose.

Mais voilà... toujours ce décalage... ça ressemble à un manque de précision, mais c'est trop visible pour etre ça, c'est un vrai manque dans le calcul.


Voilou.


Merci TanEK pour ta proposition, mais ce n'est pas qu'un changement de repere, c'est l'application des modification subies par un noeud, à la camera, de telle sorte à ce qu'elle devienne statique par rapport à ce noeud.

[loka]

Message de DzzDDzzD 24/07/2008 à 17h25:

je bosse en ce moment sur un petit systeme permettant de maintenir la camera fixe (statique) par rapport à un element de la scene, qui lui est mobile

désolé si je dis une betise car je rentre juste dans le sujet mais ta methode me semble un peu trop complexe.

si tu connais l'orientation et la position de ton objet (celui qui tien la cam) pourquoi tu ne fais pas ca :

1 - positionnement de la cam dans l'espace de l'objet qui tiens la cam :
- rotation de la cam suivant le decalage souhaité (tout zero pour commencer, regarde en face)
- translation de la cam (permet de positionner la cam dans l'axe local de l'objet qui la tient, tout à zero pour commencer)

2 - placement de la cam dans l'espace monde:
- rotation de la cam (utilisation de l'orientation de l'objet qui tiens la cam)
- translation de la cam (utilisation de la position de l'objet qui tiens la cam)

j'ai dis une betise ?

apres pour que la cam regarde un objet de la scene :

A - transformation de la position de l'objet à regarder dans l'espace de l'objet qui tiens la cam:
- translation inverse de la cible (avec la pos de l'objet qui tiens la cam)
- rotation inverse de la cible (avec l'orientation de l'objet qui tiens la cam)
(sinon , il existe une method bcp plus simple pour calculer la pos d'un objet dans l'axe local d'un autre objet, si necessaire j'expliquerais plus tard, peu etre utile lorsque l'objet est le fils du fils du fils etc... d'un objet et ou il est difficile de revenir en arriere)

B - Calcul de la rotation à appliquer à la cam pour l'étape 1 ci-dessus:
- calcul des deux angles rx,ry pour que la cam pointe vers la cible dans l'espace de l'objet qui la tien)

pour que la cam soit tenue par un objet et en regarde un autre ca donne :
étape A
étape B
étape 1 (appliquer la rotation calculée en B)
étape 2


j'ai dis une bétise ?

[loka]

Message de TanEk 24/07/2008 à 18h32:

C'est une idée oui, mais de dupliquer le noeud de transformation est pas tres fair-play si je puis dire d'autant plus que la reference (ou l'objet reference) change souvent... et donc la gestion du noeud de trasnsformation se complique un tantinet...

De plus, il est selon moi lpus propre de faire des petits calculs tout mignons pour arriver à mes fins plutot que d'arranger le scenegraph. Dans ce cas là en tout cas.

A mon avis c'est bien plus propre et visible de rajouter un noeud dans le graphe que des petits calculs comme tu dis que t'as mis plusieurs jours à faire (imagine qu'on doit modifier ton code par quelqu'un d'autre ou que t'y reviennes dans plusieurs années, ce sera plus simple avec un noeud rajouté et qui pointe par un autre noeud qu'une liste de lignes de calculs...

Mais voilà... toujours ce décalage... ça ressemble à un manque de précision, mais c'est trop visible pour etre ça, c'est un vrai manque dans le calcul.

Ne cherche pas plus loin c'est ça. J'avais fais un algorithme qui travaillé sur des différences comme tu fais et la visibilité de l'erreur se voyait au bout de quelques secondes. De plus il me semble que les quaternions c'est bien mais c'est déjà des interpolations donc erreur obligé (alors que moi ce n'était que des erreurs sur des flottants... je n'avais aucune interpolation).

Merci TanEK pour ta proposition, mais ce n'est pas qu'un changement de repere, c'est l'application des modification subies par un noeud, à la camera, de telle sorte à ce qu'elle devienne statique par rapport à ce noeud.

Je ne vois pas la différence... Ta caméra a son propre repère définit simplement sur un autre repère (principe du scene graphe où un objet peut être définit dans le repère d'un autre... c'est ce qui fait que cet objet devient statique par rapport à l'autre... si tu déplaces l'autre... celui-ci est forcément entraîné...).

Tu le dis toi-même dans ton algo : tu prends comme référence (égale repère) l'objet. donc ton repère est définit par rapport à ce dernier. Après si tu ne veux pas que la caméra se déplace quand tu changes d'objet de référence il faut faire quelques calculs en plus :

Mc = Mcamera * Mobjet1

Donc jusqu'à maintenant Mcamera était définit par rapport à l'objet 1. Supposons que tu veuilles prendre comme référence l'objet 2 mais que t'as caméra ne bouge pas d'un poil, il faut donc que :

Mc = Mcamera' * Mobjet2 = Mcamera * Mobjet1

Avec Mcamera' le nouveau repère de la caméra. De là tu as :

Mcamera' * Mobjet2 = Mcamera * Mobjet1
=> Mcamera' = Mcamera * Mobjet1 * Mobjet2-1

Et voilà tu as ton nouveau repère caméra dans le repère de Mobjet2. Et tu peux recommencer ce qui se passe avant : des que Mobjet2 bougera ça bougera automatiquement ton repère caméra, ce qui est l'effet voulu je suppose non ?.

Le seul soucis de cette méthode sera que si tu génère ton repère caméra avec un gluLookAt il faudra retrouver les paramètre du gluLookAt (vecteur position, up et direction) à partir de la matrice Mcamera mais ça il me semble que ce n'est pas très compliqué et qu'il existe des fonctions toutes pretes.

Dis-moi si tu n'es toujours pas d'accord avec moi ou alors indique-moi en quoi ma méthode n'est pas ce que tu recherches (en gros du point de l'utilisateur qu'est-ce qui va changer au niveau du comportement). Parce que de ce que j'ai compris de ce que tu veux faire, ma méthode fait exactement ce que tu demandes.

[loka]

Message de Ange_blond 25/07/2008 à 09h05:

j'ai dis une bétise ?

Heuu je ne pense pas, mais on est petit peu à coté du probleme

A mon avis c'est bien plus propre et visible de rajouter un noeud dans le graphe que des petits calculs comme tu dis que t'as mis plusieurs jours à faire (imagine qu'on doit modifier ton code par quelqu'un d'autre ou que t'y reviennes dans plusieurs années, ce sera plus simple avec un noeud rajouté et qui pointe par un autre noeud qu'une liste de lignes de calculs...

Certes, mais c'est la 2eme fois que je retouche cette partie du code, la tentative avec un noeud parent ayant déjà été tentée par le passé mais avait échoué pour je en sais plus quelle raison...

Tu le dis toi-même dans ton algo : tu prends comme référence (égale repère) l'objet. donc ton repère est définit par rapport à ce dernier. Après si tu ne veux pas que la caméra se déplace quand tu changes d'objet de référence il faut faire quelques calculs en plus

Mc = Mcamera * Mobjet1

Ok donc on c'est compris, je veux juste que ma camera soit dans le referentiel de mon objet cible, y'a pas de notion de lookat ou de regarder dans une direction précise...

C'est justement ce qui complique un peu la chose.

Sous OSG, ma camera est dirigée par un manipulator, qui permet que je dirige ma camera avec pour variables un quaternion et un vecteur. Pas directement la matrice.

Donc pour se faire je suis obligé de décomposer ma matrice de mon referentiel en translation & rotation, et de les appliquer sur mes variables...
Et c'est là que ça foire.

D'une part, ma camera doit rester mobile : les variables ne doivent pas etre redéfinies, mais juste affectés (vecteur += ... Quat *= ... ).
d'autre part ceci m'oblige à n'ajouter que la différence de transformation entre la derniere frame et la courante, d'où mes calculs de différence sur les vecteurs et les quaternions....

Je doit faire avec ces données là et dans ces conditions là. Le gros du boulot est fait (fonctionne tres bien dans certains cas, cf mes precedents posts) et donc il me manque "juste" à regler ce soucis de manque de précision du à une composante ignorée ou un truc du genre...

question : si je veux décomposer mon quaternion en " rotations élémentaires " selon (1,0,0) (0,1,0) et (0,0,1), comment vous feriez ? j'avoue que je n'ai pas encore réfléchi à la question pour le moment, mais j'envisage de décomposer mes composantes pour pouvoir les tracer au bas niveau et trouver mon fichu décalage...

PS : Merci à vous tous pour ces réponses constructives et précises, c'est vraiment sympa d'avoir un tel interet de votre part

[loka]

Message de TanEk 25/07/2008 à 10h43:

Sous OSG, ma camera est dirigée par un manipulator, qui permet que je dirige ma camera avec pour variables un quaternion et un vecteur. Pas directement la matrice.

T'es vraiment vraiment sûr ? Je ne connais rien à OSG mais ça m'étonne beaucoup que tu ne puisses pas accéder directement à la matrice de la caméra.

D'une part, ma camera doit rester mobile : les variables ne doivent pas etre redéfinies, mais juste affectés (vecteur += ... Quat *= ... ).
d'autre part ceci m'oblige à n'ajouter que la différence de transformation entre la derniere frame et la courante, d'où mes calculs de différence sur les vecteurs et les quaternions....

Je ne comprends pas ton lien entre ce que la caméra doit rester mobile et le fait de ne pas devoir redéfinir les variables ? Peux-tu expliciter ?

Dernièrement :
un vecteur + un quaternion est équivalent à une matrice 4x4. Donc tu peux passer du vecteur + quaternion à la matrice assez facilement (l'inverse je n'en suis pas aussi sûr mais y'a de bonnes chances).

Je suis allé dans la doc API et j'ai trouvé :

http://www.openscenegraph.org/docume...01292.html#a10

C'est bien de ce manipulator là que tu parles ? Il a une méthode setMatrix donc tu peux lui envoyer la matrice directement.

Je doit faire avec ces données là et dans ces conditions là. Le gros du boulot est fait (fonctionne tres bien dans certains cas, cf mes precedents posts) et donc il me manque "juste" à regler ce soucis de manque de précision du à une composante ignorée ou un truc du genre...

Avec ces conditions ok mais rajoute une autre condition : ne pas travailler avec des différences. Il faut toujours que tu travailles de façon absolue à ton repère et non pas sur les différences de ce dernier, quitte à calculer une différence par la suite basée sur ce dernier...

Donc c'est pour ça, vérifie bien que tu ne puisse pas accéder directement à la matrice de ta caméra, ou la calculer...

Si tu dois vraiment travailler sur les différences. Penses que dans :
Mc = Mcamera * Mobjet

Quand l'utilisateur bouge la caméra il ne fait que modifier Mcamera et quand l'objet bouge ça ne fait que modifier Mobjet. Déjà tu as accès en permanence à Mobjet donc son calcul ne pose pas de problème : tu l'as.

Tu as accès normalement aux modifications faites sur Mcamera donc tu peux reproduire toi-même ces modifications et créer en même temps que OSG la matrice Mcamera. Donc tu as Mc et tu veux que la matrice de la caméra soit égale à Mc. Et tu connais aussi le Mc d'avant (vu que tu l'as aussi calculé...). On l'appelera McOld.

Toi tu dois envoyer à OSG le vecteur et le quaternion qui vont te permettre de passer de McOld à Mc n'est-ce pas ? Il suffit de faire la "différence" de transformation entre McOld et Mc. A partir d'ici je ne suis plus vraiment sûr de ce que je fais donc à prendre avec des pincettes :p.

Mc = M * McOld

Tu recherches M. Donc M = Mc * McOld-1. De là t'en déduis ton vecteur et ton quaternion.

La différence fondamentale est que tu ne pars pas des différences pour calculer les vecteurs et quaternions mais tu pars des matrices réelles pour calculer la différence et ensuite les vecteurs et quaternions. De cette manière tu as un calcul qui ne cumule pas les erreurs de calculs mais qui est toujours basé sur tes matrices.

Remarque : Il peut y avoir des erreurs de calculs qui se cumulent si tu ne fais pas exactement le même calcul de la matrice Mcamera que OSG. Quand j'entends par le même calcul, j'entends par le même calcul AVEC les mêmes erreurs de calcul... .

[loka]

Message de Ange_blond 28/07/2008 à 14h50:

Re

Merci de ton aide.

Alors oui en effet j'utilise bien un matrix manipulator d'OSG.

J'ai tenté la technique qui consiste à d'abord utiliser les matrices pour calculer les mouvement relatif, puis à le décomposer en vecteur et rotation.
Mais ça en donne rien.

En fait je ne sais pas si mon calcul est bon quoi...

Qui saurait comment calculer la matrice qui permet de passer d'une matrice 1 à une matrice 2 ?
Ce serait un bon début car j'ai des doutes sur mon calcul.

Merci.