Calcul des rotations a partir des translations

[Dlzlogic]

Bonjour fatal_error,
C'est pourtant évident "angles d'Euler", ça fait tellement commun. :ptdr:

[Skullkid]

Les "vrais" angles d'Euler c'est, un repère (x,y,z) étant choisi au début, la première rotation par rapport à l'axe z, la deuxième par rapport à l'axe x' (transformé de l'axe x par la première rotation) et la troisième par rapport à l'axe z'' (transformé de l'axe z par les deux premières rotations). En gros on tourne deux fois par rapport au "même" axe.

Avec heading/yaw, elevation/pitch et roll/bank (qui en français s'appellent les angles nautiques : roulis, tangage et lacet) on tourne par rapport à x, y' et z'', donc "trois axes différents".

Après on désigne souvent par le terme générique "d'angles d'Euler" ou de "systèmes eulériens" tous les systèmes de coordonnées qui décrivent des rotations autour d'axes liés au solide. Mais dans beaucoup de domaines encore, l'appellation "angles d'Euler" est réservée, bah, aux angles d'Euler.

[ebkc]

Salut !

Je me remet un peu decu aujorudh'ui.

voila un apercu de ce a quoi ressemble ce que je fais

http://s7.postimage.org/toty0j8rd/image.png

sur la fenetre de gauche, on peut voir une colonne de 3 cubes transparent pointer le la cible, le cube B. ca a donc l'air de bien fonctionner dans certaines zones, pas toutes. Il y a des coins ou ca bloque carrement, mais je penses que c'est du au fait que mon logiciel ne prends pas de negatif dans les calcul de puissance et de racines et du coup ca fait des erreurs, je vais regler ca rapidement.

Et par contre quand le cube cible va derriere, les directions s'inversent pour le cube A, je vais voir si une condition ferait l'affaire.

capture : http://s12.postimage.org/ma1j979i3/image2.png

Les "vrais" angles d'Euler c'est, un repère (x,y,z) étant choisi au début, la première rotation par rapport à l'axe z, la deuxième par rapport à l'axe x' (transformé de l'axe x par la première rotation) et la troisième par rapport à l'axe z'' (transformé de l'axe z par les deux premières rotations). En gros on tourne deux fois par rapport au "même" axe.

Avec heading/yaw, elevation/pitch et roll/bank (qui en français s'appellent les angles nautiques : roulis, tangage et lacet) on tourne par rapport à x, y' et z'', donc "trois axes différents".

Après on désigne souvent par le terme générique "d'angles d'Euler" ou de "systèmes eulériens" tous les systèmes de coordonnées qui décrivent des rotations autour d'axes liés au solide. Mais dans beaucoup de domaines encore, l'appellation "angles d'Euler" est réservée, bah, aux angles d'Euler.

[ebkc]

hello !

J'ai réglé le soucis du blocage a cause des valeurs negative.

Mais pour le deuxieme probleme, les directions qui s'inversent quand le cube cible va derriere le cube A, en fait c'est plus généralisé que ca. par exemple quand X = -Z il y a un bug. quand les angles de rotation se rapprochent de 90° le cube prends des directions bizares...

ton code est censé marché tel quel ou il peut par exemple rencontrer un problem de gimbal lock ?

[Skullkid]

Normalement il ne devrait pas y avoir de gimbal lock puisqu'on ne s'intéresse pas au mouvement et qu'on part toujours de la même position non verrouillée, et même s'il y en avait il ne devrait pas survenir quand x = -z...

Donc j'ai peut-être mal compris comment cinema 4D fait ses rotations... Normalement tu dois pouvoir afficher les cadrans de rotation au lieu des axes, et ainsi voir si deux d'entre eux se retrouvent parallèles. Si oui, c'est qu'il y a gimbal lock.

[ebkc]

Hop hop hop me revoila !

En repostant un mail sur une liste dédié a un des softwares que j'utilise (puredata), quelqu'un m'a montré une "fonction" qui fait exactement ca :)

donc ... ca marche.

le calcul :

r=sqrt(x^2+y^2+z^2);
phi=atan2(y, x);
theta=atan2(z, sqrt(x^2+y^2))

aussi simple que ca ... :)

mais je ne sais pas ce qu'est r ...

autre point je ne suis pas sur que sur ce soft il sagisse de heading banking et elevation.

J'ai changé du cube maintenant c'est un ptit cone, qui pointe donc exactement la ou pointe mon bras. c'est beau.

Mais si je fais un cone parent qui montre la direction de l'epaule au coude, et un autre enfanté du coude a la main, le resultat est comme previsible, pas bon. Serait il possible de resoudre ce probleme par une simple soustraction des angles du parents a ceux de l'enfant ?

:ptdr:

[Skullkid]

C'est le même calcul que celui que je t'ai donné (j'ai juste normalisé les arguments de atan2 au cas où), mais si tu changes de logiciel - et donc de conventions - à tout va et sans le préciser, ne t'étonne pas que ça bloque...

[ebkc]

héhé ! bravo alors, et désolé pour les infos qui circulents mal .

Dernier petit point une idée a propos de hierarchie avec tout ca ?

si j'ai une cone representant epaule->coude parent d'un cone coude->main, la deuxieme ne reagit pas comme elle devrait, j'ai essayé de soustraire les valeurs de rotation du cone parent a celui de l'enfant mais ca ne marche pas mieux.

en tout cas encore merci a toi pour les solutions, et aux autres pour l'interet !

C'est le même calcul que celui que je t'ai donné (j'ai juste normalisé les arguments de atan2 au cas où), mais si tu changes de logiciel - et donc de conventions - à tout va et sans le préciser, ne t'étonne pas que ça bloque...

[Dlzlogic]

C'est le même calcul que celui que je t'ai donné (j'ai juste normalisé les arguments de atan2 au cas où), mais si tu changes de logiciel - et donc de conventions - à tout va et sans le préciser, ne t'étonne pas que ça bloque...

Bonjour,
Je crois (même, je suis sûr) que la fonction atan2(y,x) est partout la même.
Par contre, je crois que le gros problème de Ebkc, n'est pas tant de changer de logiciel mais de ne pas définir ce qu'il cherche à faire. D'ailleurs, Fatal_error l'a bien précisé, "on s'en t... du logiciel que tu utilises".
Tant qu'on répondra à Ebkc avec des formules, il n'arrivera à rien.

[Skullkid]

Bonjour,
Je crois (même, je suis sûr) que la fonction atan2(y,x) est partout la même.

Il est vrai que ma normalisation relevait davantage d'un réflexe de matheux, superflu ici (même si sans incidence).

Par contre, je crois que le gros problème de Ebkc, n'est pas tant de changer de logiciel mais de ne pas définir ce qu'il cherche à faire. D'ailleurs, Fatal_error l'a bien précisé, "on s'en t... du logiciel que tu utilises".
Tant qu'on répondra à Ebkc avec des formules, il n'arrivera à rien.

Sur le principe, je suis d'accord, mais dans les faits ebkc n'a pas l'air d'avoir la formation suffisante en géométrie/modélisation 3D pour comprendre comment bien poser son problème. Face à cette situation, on peut soit essayer de lui soutirer laborieusement les informations dont on a besoin, soit abandonner et lui dire d'acquérir la formation nécessaire. J'ai essayé de suivre la première voie, en sachant pertinemment que je devrais me focaliser uniquement sur le côté "utilitaire", c'est-à-dire lui cracher ce que je crois être la solution. Mais il est vrai que dans ce cas ça marche moins bien que ce que j'aurais espéré...

Bref, pour ce qui est de ton nouveau problème, ebkc, c'est à nouveau flou mais je vais essayer de persévérer. Si je comprends bien, dans ton problème courant, l'épaule E est le point à l'origine (coordonnées (0,0,0)) et la caméra enregistre les coordonnées de deux autres points C et M (coude et main). Ton programme doit d'abord orienter le segment (cône) parent [EC] et ensuite orienter le segment fils [CM]. Si c'est bien ça, pour calculer les angles nécessaires à la rotation de [CM], utilise les mêmes formules que pour [EC] mais en prenant en compte que [CM] doit pivoter autour de C et non pas autour de E. Autrement dit, dans les formules pour [EC] tu remplaces xC, yC et zC respectivement par xM-xC, yM-yC et zM-zC.

[ebkc]

Tant qu'on répondra à Ebkc avec des formules, il n'arrivera à rien.

Pourtant ca m'interesse

ebkc n'a pas l'air d'avoir la formation suffisante en géométrie/modélisation 3D pour comprendre comment bien poser son problème.

:rulaiz:

Il y a eu un mix entre je n'ai pas les connaissances, et je n'explique pas clairement de quelle partie de mon probleme je parle, et je fais un blocage sur le fait que meme si c'etait pas la bonne solution, je voulais finir le calcul comme ca

Face à cette situation, on peut soit essayer de lui soutirer laborieusement les informations [...] J'ai essayé de suivre la première voie

Merci !

dans les formules pour [EC] tu remplaces xC, yC et zC respectivement par xM-xC, yM-yC et zM-zC.

Je test de suite !

[ebkc]

@Skullkid :

Tu as bien compris la situation, a quelques choses pres.

Je recois les coordonnées de 3 points.

Aucune n'est a 0.

Quand je veut calculer l'orientation d'un vecteur, je soustrais les coordonées du point source au point cible pour avoir le point source en pos 0 0 0 et garder les bonnes distances entre les deux points.

Du coup quand je calcul EC, e_posXYS = 0,0,0
et quand je calcul CM, c_posXYZ = 0,0,0

et je reaplique les valeurs de rotation a chaque element de la chaine hierarchique de cube (qui n'a dans cette situation que 2 cubes ... )

Avec tout ca si je fais ce que tu me dis de remplacer C.coord par (M.cood-C.coord) pour le 1er vecteur de la chaine, le vecteur EC, il ne bouge presque plus...

[Skullkid]

Non je t'ai dit que la formule pour CM s'obtient en remplaçant C.coord (en fait C.coord - E.coord puisque tu me dis que E n'est pas à (0,0,0) d'office) par M.coord - C.coord dans la formule pour EC. La formule pour EC reste évidemment la même puisqu'elle fonctionne déjà.

Mais si je comprends bien, tu l'avais déjà fait et que ça ne marchait pas. Pourtant ça doit marcher. Peut-être confonds-tu les rotations que tu dois appliquer avec les coordonnées angulaires du point cible. Les commandes que tu rentres dans ton programme ce sont les angles à appliquer pour faire tourner tel segment ou alors les angles à atteindre en tournant le segment ?

Les formules avec atan2 te donnent les angles (= les coordonnées angulaires) à atteindre. Si tu veux calculer les angles des rotations à appliquer il faut d'abord redonner à CM son orientation de départ (puisque j'imagine que l'orientation de CM a changé en même temps que celle de EC), c'est-à-dire appliquer à CM la transformation inverse de celle qui a servi à orienter EC. Et ça demande (encore !) de savoir comment ton programme gère les rotations, en particulier dans quel ordre il les applique. Par exemple, si ton programme fait d'abord la rotation en phi et ensuite la rotation en theta et si les coordonnées angulaires à atteindre sont phiC, thetaC, phiM et thetaM, on applique les rotations dans l'ordre suivant :

Rotation_phi de C d'angle phiC
Rotation_theta de C d'angle thetaC
Rotation_theta de M d'angle -thetaC
Rotation_phi de M d'angle -phiC
Rotation_phi de M d'angle phiM
Rotation_theta de M d'angle thetaM

Alors que les deux lignes en italique peuvent se combiner en une seule rotation_phi de M d'angle phiM-phiC, les deux lignes en gras ne peuvent pas se combiner en une seule rotation_theta de M, puisque l'axe de rotation n'est pas le même d'une ligne à l'autre.

[ebkc]

Les commandes que tu rentres dans ton programme ce sont les angles à appliquer pour faire tourner tel segment ou alors les angles à atteindre en tournant le segment ?

Je crois qu'il sagit de la premiere option. Je n'ai pas encore testé ce que tu me dis de faire (boulot boulot ...) mais je m'y met ce week end !

@DLZlogic : j'ai trouvé ca sur Mathlab http://www.mathworks.fr/help/techdoc/ref/cart2sph.html , c'est exactement la meme fonction que j'utilise

[Dlzlogic]

Je crois qu'il sagit de la premiere option. Je n'ai pas encore testé ce que tu me dis de faire (boulot boulot ...) mais je m'y met ce week end !

Mais c'est justement là la question. C'est pas des tests qui vont vous donner la réponse, c'est ce que vous voulez faire, ce que vous cherchez à faire, quel est votre but.
Dans mon esprit, il plusieurs hypothèses :
1- vous avez acheté ce substitut de manette de jeu et vous cherchez à l'utiliser pour ce qu'il est prévu.
2- Vous voulez l'utiliser pour autre-chose, et il serait plus simple de l'expliquer
3- Vous cherchez à comprendre comment ça marche et pour cela, vous avez fait des recherches, ce qui vous ont conduit à utiliser certains termes (translation, rotation, matrice, quaternions etc.) puis à utiliser certains logiciels plus ou moins en rapport avec la 3D, d'où les essais avec le cube etc.