Blog de Frédéric Bonometti

Voici un tutoriel “rapide” destiné principalement aux animateurs ne connaissant pas encore Softimage

Il fait le tour des outils et des manipulations de base permettant la réalisation d’une animation de A à Z.

Les points abordés sont :
- Description de l’organisation générale de l’interface
- Préparation d’une scène
- Navigation dans les vues 3D
- Manipulation d’un personnage
- Edition des courbes d’animation
- Création de contraintes animées
- Calculer une preview (vidéo)
- Ajouter une bande son

Voici une petite astuce simple et pratique pour stocker des données de manière souple dans une scène ou un model en python.

Il est très simple de créer un paramètre dans une propriété (CPS) et d’y stocker des données. Mais il peut arriver qu’on veuille stocker une liste de données (tableau) ou de paramètres facilement modulable.

Avec python, il suffit de créer un paramètre de type String et d’y stocker le contenu d’une variable quelqu’elle soit (list, tupple, dict, etc.) en la convertissant en String. Pour la récupérer, il suffit de l’évaluer avec eval().

Exemple:
Dans un CPS, on crée un paramètre de type String appelé “datas”.
Nous voulons y enregistrer la série de paramètres suivante:
- shot=’001′
- duration=125
- characters=(‘riri’, ‘fifi’, ‘loulou’)
Voici un exemple de code:

datas = {}
datas["shot"] = "001"
datas["duration"] = 125
datas["characters"] = ("riri", "fifi", "loulou")
cps.Parameters("datas").Value = str(datas)
# où cps = l'objet représentant la propriété

Et pour relire les données, c’est l’inverse:

datas = eval(cps.Parameters("datas").Value)
shot = datas["shot"]
duration = datas["duration"]
characters = datas["characters"]

C’est une idée simple mais qui peut simplifier la gestion des données dans une scène 3D en tout cas dans certains contextes.

Vous avez peut-être déjà voulu afficher dans Softimage via Python un message du type “Procédure non trouvée” ou encore écrire dans un bouton “Définir un accès” et vous vous êtes retrouvé avec “Procédure non trouvée” et “Définir un accès”. Voir même vous avez eu un message d’erreur pour avoir simplement écrit un commentaire avec un accent. Nous allons comprendre ici pourquoi les caractères avec accent peuvent être mal interprétés par Softimage et nous en déduirons comment les afficher en toute circonstance.

La clé de tout cela réside dans le fait que depuis quelques versions (sans doute depuis la V6 mais je ne suis pas très sûr), Softimage utilise pour coder ses chaînes de caractères le système “unicode”. C’est quoi ça ? Tout est expliqué sous ce lien dans Wikipédia.

Pour ce qui nous concerne, cela va dépendre de la version de Python utilisée:
- Version 2.x: l’unicode est reconnu mais n’est pas utilisé directement dans les chaines de caractères de type  “string”
- Version 3.x: l’unicode est le format utilisé pour les chaînes de caractère de type  “string”
En gros, vous aurez moins de problème avec Python 3.x mais vous n’êtes pas pour autant à l’abri de problèmes. Le mieux est d’abord de bien comprendre et on verra que ce n’est pas compliqué à corriger.

Avec Python 2.x

Par défaut, si vous tapez et lancez ce script:
Application.LogMessage(“pépé”)
Softimage affiche:
# INFO : pépé
Moralité, on sait que Sotimage n’aime pas les accents (en tout cas, pour l’instant…)

Retirons les accents pour un moment le temps de voir autre chose :
name = “null”
Application.LogMessage(name)
Application.LogMessage(type(name))
Softimage affiche:
# INFO : null
# INFO : <type ’str’>
Jusque là, rien d’étrange. Tout est normal.

Créons maintenant un null (appelé “null”) et tapons le script suivant
oNull = Application.dictionary.GetObject(“null”)    #oNull représente notre Null
Application.LogMessage(oNull.Name)
Application.LogMessage(type(oNull.Name))
Softimage affiche:
# INFO : null
# INFO : <type ‘unicode’>
Tiens, ça change ! Dans le premier exemple, nous avions une chaine de type “string” et dans l’autre, nous avons une chaine de type “unicode”.

Bien que les 2 exemples renvoie en apparence la même chose, ils ne renvoient pas la même chose puisque les types sont différents. Si on compare les 2, on devrait avoir une différence. Pourtant…

oNull = Application.dictionary.GetObject(“null”)
name = “null”
Application.LogMessage(oNull.Name == name)
Pourtant Softimage nous renvoie bien:
# Info : True

En fait, Python parle en 2 langages sans qu’on s’en rende compte et permet de comparer des type ’string’ avec des types ‘unicode’ sans problème, en tout cas tant qu’il n’y a pas de caractères spéciaux. Pourtant il m’est arrivé que la comparaison entre un nom d’objet et une chaine de caractère de type ’string’ ne me renvoie pas True alors que cela aurait dû être le cas puisqu’en apparence c’était le même texte. Sans doute était-ce parce que j’étais dans un contexte particuliers puisque dans PyQt mais ayant corrigé le problème depuis, je ne puis dire avec certitude que c’était à cause de cela. Quoiqu’il en soit, vous êtes prévenu…

Donc, si on veut être “clean” et parfaitement dans les règles, il vaut mieux convertir nos “strings” en “unicode” (puisque Softimage ne comprend que l’unicode). Et pour se faire, c’est très simple: il suffit d’ajouter  un ‘u’ devant toute chaine de caractère comme ceci :
name = u”null”
Application.LogMessage(name)
Application.LogMessage(type(name))
Softimage affiche :
# INFO : null
# INFO : <type ‘unicode’>

Et d’une pierre, deux coups, puisque ainsi on peut très bien écrire des accents:
Application.LogMessage(u”pépé”)
Softimage affiche:
# INFO : pépé

Avec Python 3.x

Et bien là, c’est beaucoup plus simple puisque nos chaines de caractères de type ’string’ sont déjà en unicode. Donc toujours avec notre Null si on écrit :
oNull = Application.dictionary.GetObject(“null”) #oNull représente notre Null
Application.LogMessage(oNull.Name)
Application.LogMessage(type(oNull.Name))
Softimage affiche:
# INFO : null
# INFO : <type ’str’>

Dans Python 3, le type ‘unicode’ n’existe plus et donc on n’a plus besoin de mettre ‘u’ devant une chaîne de caractères (ça devient même une erreur de syntaxe). De ce fait, on n’a plus à y penser :
Application.LogMessage(“pépé”)
Softimage affiche:
# INFO : pépé

Problème résolu ? pas tout à fait…

Si vous écrivez votre code dans un éditeur externe, vous pouvez quand même avoir des erreurs une fois exécuté dans Softimage. Pour cela, il faut vérifier avec quel encodeur le texte de votre script est codé.

Si vous utilisez comme moi Notepad++ (qui entre nous est très bon), vous avez un menu Encodage dans le menu supérieur. Si vous l’ouvrez, il vous indique l’encodage de votre texte.  Par défaut: ANSI . En principe, ça devrait fonctionné dans Softimage mais si vous encodez avec ISO 5589 – 1 par exemple qui est celui préconisé en France, là, ça va poser des problèmes puisque les caractères avec accent ne seront pas reconnu dans Softimage. Vous aurez beau convertir en unicode votre chaine , il ne saura même pas lire le code brut correctement (d’où des erreurs possibles même dans les commentaires).

Le mieux, et c’est mon conseil, est de choisir directement un encodage unicode. Ainsi vous serez tranquille et à l’abri de tout problème avec Softimage. Pour ce faire, vous pouvez choisir un encodeur de type UTF comme par exemple UTF-8.

Vous l’aurez certainement compris, la ligne d’encodage à indiquer en début de script de type :
# -*- coding: iso-8859-1 -*-
est maintenant vivement déconseillée puisque non comprise pas Softimage.

Les rendez-vous gratuits Softimage continue toujours sur un rythme mensuel.

Venez rejoindre les soirées que j’organise sur le net en vidéo conférence au CAFE DE L’INFOGRAPHIE. On y parle Rig, développement d’outils, d’interfaces et pipelines dans Softimage (outils et techniques).

C’est gratuit et ouvert à tous: les débutants, les professionnels ou les simples curieux. Une simple inscription suffit qui vous permettra de recevoir par mail les paramètres de connexion. Le nombre de participants n’est pas limité donc pensez à vous inscrire à tout moment (une inscription suffit pour tous les rendez-vous).

Prochain rendez-vous : consultez la page spéciale sur ce blog
(accès en haut de cette page)

RENSEIGNEMENTS ET INSCRIPTION SOUS CE LIEN

N’hésitez pas à me proposer à l’avance les questions que vous voulez aborder pendant les soirées.  Je vous invite aussi à intervenir vous-même sur un outil Softimage ou une technique, que ce soit sur un niveau débutant ou avancé, car je souhaite avant tout que ce rendez-vous soit un échange plutôt qu’une succession de mes interventions unilatérales. Donc un grand merci à tous ceux qui collaborent déjà ou prochainement à ces rendez-vous chacun à leur manière.

Pour répondre aux problèmes de décalages horaires et autres empêchements de pouvoir assister en direct aux rendez-vous, une solution de mise en ligne de ces rendez-vous est étudiée. En attendant des extraits sont visibles sur Vimeo. Voir les liens sur la page spéciale Cafe de l’Infographie de ce blog.

PS: Le site http://cgtalkcafe.com/ n’est pas toujours à jour. Mieux vaut se référer à la page de mon blog.

Les paramètres de Neutral Pose (présents dans la fenêtre Local Transform d’un objet) permettent de mettre à zéro les transformations locales d’un objet en leur ajoutant des valeurs d’offset. Mais cela peut-il avoir des effets secondaires sur l’objet ?

La réponse est oui et non.
Oui parce que cela peut nuire aux manipulations de l’animateur et non parce que l’outil fonctionne très bien. Mais pour comprendre expliquons depuis le début.

Pour un animateur, il est très intéressant que les objets qu’il anime soient tous à zéro par défaut (coordonnées de scale à 1, coordonnées de rotation et position à 0). Et ce pour deux raisons principales :
- Cela donne un repère aux objets par rapport à leur position par défaut (on peut y revenir très facilement)
- Vu que les coordonnées animées (locales) dépendent de leur parent (à l’exception du scale), plus ils évoluent sur des coordonnées proche d’eux (surtout en rotation) mieux c’est.

Pour ce faire, il y a la vieille école qui consiste à ajouter un Null caché, parent de l’objet animé et aligné sur sa position par défaut.
L’autre méthode consiste à utiliser le Neutral Pose en faisant Set Neutral Pose dans le menu Transform quand l’objet est dans sa position par défaut.

En théorie, les 2 systèmes semblent équivalents. Au niveau des courbes d’animation, nous aurons la même chose et les 2 techniques sont très stables et fiables.

Pourtant une différence apparait à la manipulation qui peut rendre les animateurs rétifs à la solution Neutral Pose.

Pour comprendre, il faut manipuler:

- Créons 2 Nulls dont l’un sera le parent de l’autre et appelons-les respectivement “Parent” et “Enfant” pour bien les différencier.

- Décalons l’enfant en translation et en rotation par rapport à son parent (il aura donc des coordonnées locales non nulles en translation et en rotation)

- Décidons que cette nouvelle position de l’enfant sera sa position neutre. Faisons donc Transform > Set Neutral Pose sur l’Enfant. Ses coordonnées locales sont mises à zéro.
- A l’image 1, créons une clé en translation
- Allons un peu plus loin dans le temps, par exemple à l’image 50, mettons nous en mode Local (pour le manipulateur ou Gizmo) et déplaçons l’Enfant sur son seul axe X. Ajoutons des clés en translation

A ce stade, si vous regardez les courbes d’animation, seule la courbe de translation sur l’axe X présente une variation. Sur Y et Z, les courbes (si elles existent sont plates).

- Revenez à l’image 1 et tourner l’objet de manière à l’orienter différemment de sa position par défaut (les coordonnées en rotation doivent avoir des valeurs comprises entre 30 et 60° pour bien mettre en valeur le phénomène)
- Rejouez l’animation: c’est toujours la même chose.

Mais maintenant essayez d’afficher l’axe de translation correspondant aux courbes d’animation. Comme ici, l’objet ne bouge que sur l’axe X, l’axe X doit être aligné avec le sens de déplacement.
En fait, en mode Local, on a bien l’orientation de l’axe local de l’objet et en mode Parent, on voit bien l’orientation du parent. Mais le problème est que l’animateur qui voudrait manipuler une translation le long des axes correspondant aux courbes d’animation, il lui manque l’affichage de l’axe généré par l’offset du Neutral Pose.

Mode Local : l'axe X ne correspond pas au déplacement sur X

Mode Parent : l'axe X ne correspond pas au déplacement sur X

Ce n’est pas vraiment un défaut mais plus un manque puisqu’il suffirait de pouvoir manipuler la translation sur l’axe généré par l’offset du Neutral Pose pour que le problème soit résolu. Toutefois tous les animateurs ne souhaitent peut-être pas cette option et dans ce cas, la technique ne les gênera pas. Pour les autres, il sera conseillé d’ajouter un Null caché au dessus de chaque objet destiné à être animé et aligné avec celui-ci.