PDA

Voir la version complète : Rig qui vibre - Bug de l'affichage ou problème de hiérarchie ?



Ruben_S
12/06/2013, 22h25
Hello tout le monde !!

Pour le coup je suis assez fier du titre de mon post, il résume bien mon problème.
Je suis sur un rig d'un petit perso.

Je commence par les jambes, tout va bien. Le rig répond bien bref le bonheur.
J'attaque les mains, sa roule impec...mais...(et oui y'en a toujours un). Le rig fonctionne bien, la hiérarchie est logique, mais lorsque je déplace le contrôleur de la main tout vibre. De plus en faisant un ctrl+z le contrôleur se repositionne bien mais le bras est fracturé en quelque morceau. Un clic n'importe ou et il redevient normale.

J'ai tester en anim, pas de soucis tout fonctionne bien, c'est plus dans l'affichage ou sa merdouille.
Alors j'ai pas d'image la tout de suite à montrer mais si je vois que personne n'a rencontrer le même soucis alors je filerais quelque vizu voir le fichier entier.


Merci et à bientôt.

:afro:

valkaari
13/06/2013, 00h52
Ce que tu décris est le fonctionnement type d'une hiérarchie qui aurait un problème de priorité/ordre de calcul.


Le problème est souvent facile à régler, parfois problématique, rarement insoluble.

Il faut comprendre le fonctionnement de mise à jour de la scène. Cinema4D vas parcourir l’ensemble des objets qui se trouvent dans le gestionnaire d'objets, de haut en bas et les tag de gauche à droite. (pour les tags xpresso par exemple c'est important)


Si on prends une scène avec 3 objets A,B,C ou l'objet B possède une contrainte PSR pour suivre l'objet A. L'objet C lui a une contrainte pour suivre l'objet B.

Une nouvelle frame arrive, il faut donc mettre à jour l’ensemble des objets :

Dans le gestionnaire d'objet, de haut en bas on a bien A,B,C :
Si l'objet A a bougé, cinema le mets à jour à la nouvelle position. Il passe à l'objet B qui s'appuie sur A (qui est à jour) puis à C qui s'appuie sur B (qui vient d'être mis à jour aussi). Donc tout marche bien.

Dans le gestionnaire d'objet, tu as de haut en bas, B, C, A :
B vas se mettre à jour sur les coordonnées actuelles de A, C vas se mettre à jour sur B et A vas se mettre à jour et donc bouger. Et tu es donc dans le cas où B et C vont se mettre à "laguer" derrière A, puisque ils vont se mettre à jour une frame en retard.


Idem si tu mets A, C, B là B vas bien suivre A, mais C vas avoir un retard d'une frame sur B.

Si maintenant tu considères que l'objet A est ton contrôleur, l'objet B ta hiérarchie de joints et le C ton personnage déformé, tu devrais comprendre dans quel ordre il faut mettre tes objets.


Dans certains cas, il n'est pas possible de changer l'ordre des objets uniquement en changeant un peu la hiérarchie. C'est dans ces cas que tu peux utiliser (s'ils existent) les champs "priorité"

La liste est dans l'ordre d'exécution:
initial --> animation --> expression --> dynamics 11.5 --> generators allant de -499 à 499
Donc un objet dont la priorité est réglé à expression -499 vas quand même s'exécuter après un objet qui est réglé à animation 499

Même si ton objet A est placé dans la hiérarchie avant l'objet B, si sa priorité est supérieure à l'objet B, il sera mis à jour après l'objet B.

Pour finir, identifier un problème de priorité est simple, il suffit de bouger un truc et d'appuyer sur la touche A (ça rafraîchi les vues) et de voir si un élément bouge. (cliquer n'importe où ça fonctionne aussi ou avoir un refresh auto etc etc). La fonction annulé ça marche aussi, si tu vois que des éléments reviennent après avoir appuyé sur la touche A c'est que tu as un soucis de priorité.

C'est facile à comprendre mais pas facile à expliquer ^^ j'espère que c'est un peu clair.

Aurety
13/06/2013, 08h56
Super clair ! Merci Val :icon_eek:

Ruben_S
13/06/2013, 10h37
Waou, je ne pensais pas être clair dans ma demande mais tu as tout à fait saisi mon problème, chapeau !!!

Merci pour cette explication bien précise, je te rassure ton explication est très clair.
Juste une dernière question, qu'en es-t-il des sous objet ?

Disons que A à un sous objet B et que C se trouve dans la hiérarchie en dessous de A.
B ou C sera prioritaire ?

Edit : en fait je pose la question parcque je n'ai pas eu le résultat escompté. Une fois la hiérarchie remise en place je n'ai pas dévolution du coté des vibrations donc je me dis que peut être...

Merci à toi !!


:icon_clap:

valkaari
13/06/2013, 15h12
Pour des objets parent/enfant c'est un peu plus "spéciale"

Si c'est des objets de même nature (objet neutre par exemple) il doit mettre à jour le parent puis les enfants. (ce qui reste logique, si le parent bouge, les enfants suivent après et non avant)

Par contre, il y a des objets dans cinema4D qui n'ont pas de champs priorité dans l'onglet de base mais qui en ont quand même une en interne. C'est le cas des générateurs (HN, cloner, fracture, bref tous les objets dont l'icône est verte) qui s'exécutent à la priorité "générateur" (les choses sont bien faites parfois)

Du coup pour les générateurs, les enfants ont plus de chance de se mettre à jour avant le générateur lui même, c'est ce qui fait que si tu animes une spline en mode point par exemple et que ta spline est dans un sweep nurbs, il n'y aura pas de "décalage"
d'une frame à l'autre.

initial --> animation --> expression --> dynamics 11.5 --> generators
ben oui les animation sont calculée avant les générateurs.

D'ailleurs d'après cet ordre de calcul, on aurait tendance à penser qu'une clef d'animation serait moins forte qu'un xpresso, sauf que c'est pas le cas. Si tu mets une clef d'animation pour bouger un objet et un xpresso, c'est les clefs qui gagnent.


edit :

et je n'entre pas dans les histoires de cache des objets de cinema4D qui peuvent être interrogé par les générateurs etc etc pour le système de mise à jour, histoire de rester simple.

Mais si tu es curieux, il y a un exemple dans la doc python avec des images pour comprendre (http://chicagoc4d.com/C4DPythonSDK/modules/c4d/C4DAtom/GeListNode/BaseList2D/BaseObject/index.html?highlight=cache#BaseObject.GetDeformCac he)

D'ailleurs on peut aussi comprendre pourquoi cinema4D n'aime pas du tout du tout le fait d'avoir beaucoup d'objets.

Ruben_S
13/06/2013, 17h49
Bon je pige pas, c'est la chaleur, la conjoncture économique... je sais pas...

Je met en pièce jointe un fichier du bras, j'ai tout virer pour aller à l'essentiel et sa fonctionne toujours pas...:icon_wip:


Merci pour les explications.


:afro:

fredmartin
13/06/2013, 18h42
J'ai fait un test en réorganisant la hiérarchie des joints,
apparemment il faut éviter de "briser" la chaine d'os avec un objet null intermédiaire.

http://fredmartinlesite.free.fr/FC4D/test-bras15-bis.c4d

Ruben_S
13/06/2013, 20h29
Merci pour les essaie c'est cool mais.... (pas tapé).

En effet le soucis se fait beaucoup moins sentir, j'applique cette méthode comme le fait le grand maître clemz dans le DVD Wipix.
Dans ton test regarde bien en faisant "a" comme le précise Val ou bien un simple ctrl+z, on voit qu'il y'a quand même un petit mouvement...

Bref le mystère réside, merci en tout cas.

valkaari
13/06/2013, 21h13
j'ai pris ton fichier et j'ai :
- réorganisé la hiérarchie pour avoir contrôleurs, joints, objets séparés.
- sélectionné tous les joints pour passer leur priorité par défaut (expression 0)
- changé la cible de ton IK. Tu ne peux pas avoir le contrôleur cible enfant d'un joint de la chaine qu'il pilote, ça n'a pas de sens. S'il bouge la chaine IK bouge, et si la chaine IK bouge, il bouge etc etc.
- j'ai vérifié que ton tag contrainte est à la bonne priorité

ça vas déjà mieux.

la remarque de fred est bonne remarque, il ne faut pas placer d'objet entre le point de départ et d'arriver du calcul de ta chaine IK (sinon l'objet sera pris en compte) et mettre les joints (ou ce qui te sert dans ta chaine) en premier enfant.

petit lien vers une vidéo pour les modifs avec l'utilisation de l'oeuil pour sélectionner tous les joints d'un coup

http://valkaari.com/forum/cinema/ik_priority.mov

Ruben_S
13/06/2013, 22h04
Yes merci Val !!

Ben tout fonctionne et merci pour le tip de l'oeuil que je ne connaissait pas.

Donc finalement y'a des petits trucs à savoir pour la hiérarchie...


Merci pour l'aide, à bientôt.


:afro: