un petit peu de script ?! ca faisait longtemps...

Bonjour à tous,

Je cherche à lier par code, un solide à un objet nul qui serait son 'parent'

Plus concret, j'ai un solide que je veux lier par code à un tracking fait sur une vidéo.

On peut savoir par code si un calque à un parent (hasParent), ou encore on peut servir des données du parent (parent.width par exemple). Mais ca ne m'aide pas ca.

A mon avis, ca n'existe pas et je ne vois pas sur quel paramètre je passerais un code du type : thisComp.thisLayer.parent('Nul_Track")...
Une solution serait de lier chaque paramètre (position, echelle, rotation) du solide à chaque paramètre de l'objet Nul_Track qui doit être son parent.

Sauf que je ne veux pas que mon solide soit à la même place que mon Nul_Track, ca serait trop simple, je veux que mon solide se déplace comme mon Nul_Track.


Du style, pour la position ca serait un truc comme ca :

X = transform.position[0]+thisComp.layer("Nul_Track").transform.position[0];
Y = transform.position[1]+thisComp.layer("Nul_Track").transform.position[1];
[X,Y]

Et encore ca ne marche pas super... Je suis loin d'être un spécialiste....
Et pour l'échelle ?
Et la rotation ?

Et pour simplifier l'affaire, il faut que savoir que mon Nul_Track, est lui aussi l'enfant d'un autre Nul_Track01, qui est l'enfant du Nul_Track02, etc...



Bon..... je suppose que j'ai perdu les 3/4 des lecteurs à la ligne 5 de ce problème très passionnant. Donc pour les courageux qui ont compris quelque chose à mon problème, je vous remercie pour tout avis sur la question.

 

salut, magna

ton expression fonctionne, pourquoi tu trouves pas ça super ?

Par contre, tu peux simplifier :
value + thisComp.layer("Null_Track").transform.position

"value" englobe toutes les valeurs (x,y et z si tu es en 3D)

pour la taille :
thisComp.layer("Null_Track").transform.scale

pour la rotation
thisComp.layer("Null_Track").transform.rotation

non ?

 

petite digression: pour avoir écrit quelques expressions un peu longues et galéré à remettre mon nez dedans, je crée maintenant plein de variables au départ, je trouve ça plus lisible.

genre ton
X = transform.position[0]+thisComp.layer("Nul_Track").transform.position[0];

devient
positionNul= thisComp.layer("Nul_Track").transform.position[0];
X =transform.position[0]+positionNul;

gyomh, peut-on utiliser le "value" dans ce cas là ? il va bien distribuer les valeurs et ajouter le x au x et y au y ?

 

oh, et aussi.

Tu veux lier ton solide au Nul_Track, c'est ça ?
Donc est-ce vraiment un problème qu'il soit l'enfant de deux autres tracks vu que ça se passe en amont ? Tant qu'il a hérité de toutes les infos on est contents, non ?

 

si tu sépares les variables, ça ne marche plus.

ça, par exemple, ne marche pas:

positionNullX=thisComp.layer.transform.position[0];
positionNullY=thisComp.layer.transform.position[1];
value + positionNullX + positionNullY

il va additionner les deux valeurs de position à x ( value[0] ) et non à x et y.

dès que tu sépares les variables, il faut les séparer dans ton code:

[value[0] + positionNullX;value[1] + positionNullY]


Ah, je viens de voir un truc. Je ne m'en étais jamais servi :
si tu veux déclarer une variables à plusieurs valeurs (ou coordonnées, je ne sais pas trop comment on dit...), tu fais:

NomVariable=[premiereValeur,deuxiemeValeur]

comme ça, tu peux aditionner NomVariable à value; il répartiras les valeurs.

Dans le cas présent:

positionNul=[thisComp.layer("Nul_Track").transform.position[0],thisComp.layer("Nul_Track").transform.position[1]];
value + positionNul

cool, j'ai découvert un truc (sûrement de base, mais ça va me faciliter la tâche)

 

j'ai testé vos différentes propositions.
pour le test, j'ai :
un nul "Nul_Track"
un solide "Enfant_Biologique" lié au nul par le petit escargot
un solide "Enfant_Artificiel" lié par nos lignes de code

les 2 enfants ne réagissent pas pareil, dans le sens où en échelle,
"Enfant_Biologique" se resize avec comme ancrage, l'ancrage du Nul_Track
"Enfant_Artificiel" se resize par rapport a son propre point d'encrage.
idem pour la rotation.

je remarquais aussi au moment ou je tapais ENTREE pour valider mon code, mon "Enfant_Artificiel" va changer de size (idem pour position) selon où est placé mon Nul_Track à cet insant T. ce qui est plutôt logique.
alors qu'avec parentage par l'escargot, l'"Enfant_Biologique" ne bouge pas et attends juste les infos du Nul_Track pour la suite.

et enfin...
si mon Nul_Track est lui aussi tracké par un "Nul_Track01" et bien ca change ses valeurs de positions dans l'espace car il se réfère au son parent "Nul_Track01". ce qui rend les valeurs des paramètres de "Enfant_Biologique" inexactes.


et pour l'info, vous vous demandez peut-être pourquoi je potasse ca.

j'ai une vidéo que j'ai remappé. j'accélère, je reprends la vitesse original, j'accelère, etc...
sauf qu'on ne peut pas faire de suivi de track sur un métrage remappé. j'ai donc précomposé, et hop, j'ai fais mon petit tracking. je lie mon objet graphique a ce Nul_Track, parfait....
jusqu'à ce que ma cliente, me demande de ralentir un peu plus à tel endroit, accélérer à d'autres. ce qui fout en l'air mon track que je suis obligé de refaire. 2 fois-3 fois-6 fois- et là, j'en ai marre.

donc là, idée, je me suis dis, 'tu fais tout tes tracks dans la precompo avec la vidéo à vitesse normale. et ensuite tu lieras ton objet graphique (animé dans la compo globale), à ce track. ah !... facile...ah.. bah non en fait.

bon, ca dépasse mes compétences.

"plus rapide ?! vous êtes sur ?... oui, oui, c'est envisageable, mais j'ai peur que cela casse le rythme et la dynamique de la vidéo. de plus la bande son se cale parfaitement aux rythmes actuelles des animations."
[...]
"oui, oui...plus rapide.. j'ai bien compris.... je vous envoie une nouvelle valid dans 2 h....

 

>> et tu recherche quoi ? l'ancrage au centre du calque ou du null ?

sinon, j'ai un doute quand tu parle de size. Tu traques en 3D ? c'est pour ça que tu scales aussi ?

>>ça c'est pas simplement parce que le parentage est relatif au moment de la timeline ou tu lies le calque ? Quelle que soit la valeur du parent, l'enfant aura la taille préparentage relative à la valeur du parent à ce moment. [boudiou c'est pas très clair.]
genre, si l'enfant fait 100 px, tu lies à un moment ou scaleParent = 50%
alors 50 % = 100px
mais si tu lies à un moment ou scaleParent = 100%, alors 100%=100px
c'est le principe même du parentage.

alors que si tu ajoutes à value avec ton expression, ça va forcément updater en permanence, il n'y a rien de relatif.


Après… je suis perdue. je ne suis plus ce qui te convient ou pas.
Les expressions fonctionnent mieux car les valeurs de position restent absolues ?
dans ce cas en quoi

?


(pas fait beaucoup avancer le shmilblick)

 

Le problème de base est que mélanger parentages et expressions: c'est mal!
Le modèle: value+(gnagnagna) est le plus simple et le plus souple.

 

je ne track pas en 3D, mais j'ai mis le suivi de track en position, rotation et échelle.
pour le reste, je reviens dessus la semaine prochaine. je vous tiens au courant.

et désolé, je comprends bien que tout ca n'est pas très clair.

j'ai mis un projet AE que vous pouvez télécharger.
bon... vous prenez pas la tête non plus.

merci pour votre aide et pour avoir pris le temps d'appréhender le schimblick.

 

yeah ! j'ai remis le mot shmilblick à la mode \o/

 

oh putain je suis con.

je viens de me rendre compte que mon idée de parentage par code, ne peut pas, dans tous les cas, pas marcher.

je suis en train de vouloir parenter/tracker un solide à un nul, qui se trouve dans un compo remappé.
conclusion leur instant T ne corresponde pas.

l'instant T=2sec pour mon solide, correspond pour mon track à son instant T=3.24 disons.

oui je me doutes que vous ne comprenez pas grand chose. et bien laissez tomber les mecs ! ahah !

 

mmmh... tu ne peux pas récupérer tes valeurs de time remap et les multiplier par tes info temporelles de position ?

[je ne sais pas si c'est techniquement possible. c'est une question ouverte]

 

si ça existe, je suis preneur !

En attendant, le mieux, c'est de poser les expressions dans une precomp que tu remap dans ta compo finale.

 

ca marche en fait, aaah ca fait du bien

et bien si justement avec :
.valueAtTime(thisComp.layer("Precomp_Video_Enfant_Artificiel").timeRemap)

pour récuperer la valeur temporelle de ma précomp. nickel !

et j'ai rajouté des nuls qui chopent les infos des autre nuls, blabalbalbalbla... compliqué à expliquer, je vous mettrai le projet.

 

valueAtTime.timeRemap

cool, c'est bon ça.

Je cherchais justement ce genre d'expression pour récupérer les valeurs de la caméra d'une precomp remappée pour les appliquer à celle de la compo finale.

nickel