Blog de Frédéric Bonometti

ANIMATION, RIGS et SCRIPTS sur XSI

XSI, Maya et Max ?

Posted by Frédéric Bonometti on 3 juin 2010

Il y a quelques temps, si on m’avait demandé quel logiciel était le meilleur entre XSI, Maya et 3DSMax, ma position aurait été sans appel sur 3DSMax mais je n’aurai pas tranché entre les 2 autres considérant qu’ils ont chacun des qualités et des inconvénients qui équilibrent l’ensemble. Aujourd’hui, je casse ma réserve et je me lâche car Autodesk semble tirer des ficelles commerciales dans un but lucratif qui lui appartient et il semble que tout le monde marche dans son sens de plein gré. Il me semble qu’il est plus que temps de se faire entendre si on veut pouvoir continuer à évoluer professionnellement dans le bon sens.

Avant de commencer, sachez que je m’exprime sur ces 3 logiciels en matière d’animation, de rigs, de développement d’outils, d’interfaces et de pipeline. Je n’aborderai pas le côté rendu, FX, textures, compositing et toutes les autres matières que je n’ai pas citées, simplement parce que je ne parle qu’en m’appuyant sur mes propres expériences et compétences et que je ne suis pas expert dans tous les domaines.

3DSMAX – Paillettes et pacotilles

Avec un titre comme cela, vous me voyez venir. Mais commençons par mes expériences passées sur ce logiciel.

La première fois que j’ai rencontré ce logiciel, c’était dans sa version 1 (c’est pas d’hier). On m’avait demandé une évaluation de sa capacité à produire une série dans le cadre d’un appel d’offre. Bien sûr, j’avais derrière moi toute l’influence des logiciels “Unix” de l’époque tel que Softimage. Et donc je me suis naturellement attaché à ne voir que ce qui était commun à cette ancienne génération sans aborder Character Studio. Et les manques de ce point de vue étaient très importants. Par exemple, on ne pouvait pas dissocier une clé d’animation d’un axe à un autre. Pour être plus clair, quand on mettait une clé d’animation par exemple en translation, il mettait une clé sur chaque axe (X, Y et Z). Quand on venait éditer les courbes et qu’on déplaçait la clé en X sur une autre image, les clés en Y et en Z suivaient à cette même image.  Un animateur digne de ce nom sait combien il est important de pouvoir décaler les clés d’un axe à l’autre. On est en droit de se dire alors que les développeurs n’avaient aucune idée de ce que pouvait être le travail d’un animateur.
Ça n’a l’air de rien comme anecdote, surtout que ça a été corrigé très vite dans la version suivante. Je ne le savais pas à cette époque mais lors de ma seconde rencontre avec le logiciel, j’ai compris toute la gravité de ces petits détails qui n’étaient que le sommet de l’iceberg.
Un autre exemple ? Vous qui connaissez au moins un peu la 3D, vous savez ce qu’est l’animation par Shapes qu’on appelle aussi Morpher ou Blend Shapes. Il s’agit d’enregistrer des positions de point du maillage de l’objet et de les appeler dans le but d’animer une déformation de l’objet. C’est une technique très utilisée en particulier pour les animations faciales. Dans la version 1 de 3DSmax, on animait non pas les différentes formes mais chaque translation sur les points. Donc si vous aviez 250 points pour former votre maillage, vous vous retrouviez avec 250X3=750 courbes d’animation… Bonjour le travail ! Là aussi, ça a été très vite corrigé.

Vous me direz : “Oui et alors ? Tout ça a été corrigé.”
Certes. Mais pour conclure il faut attendre ma deuxième expérience sur ce logiciel.
Il y a 10 ans, on me demande de préparer une production cinématographique sur 3DSMax. Mon antipathie est mise de côté parce que je n’ai pas le choix: 3DSMax est imposé (version 3). Et donc me voilà parti à préparer des rigs et des solutions pipeline.

Première chose, il y a Character Studio et son célèbre Bipede. Commençons par là, puisque c’est son point fort. Premièrement, dans la version utilisée pas de courbe d’animation. Pour des animateurs qui viennent des autres softs, ça va être dur. Mais bon, on s’y fera peut-être…
Pas de système de torsion des membres. Pour un système de rig, c’est quand même un comble. Il faut donc le faire à la main. Problème les rotations du Bipede ne sont accessibles qu’en quaternion. Pour faire de simple expressions, c’est quand même très compliqué. Devoir développer un plug-in C++ pour une chose si commune, c’est beaucoup d’énergie dépensée. Au final, trop de barrières pour pouvoir arriver à mes fins, et comme je refusais des compromis sur la qualité, j’ai abandonné Character Studio.
Je me tourne alors vers un rig conventionnel. Nous sommes sur un logiciel 3D, on devrait pouvoir faire un rig à la main. Le système IK ? Il y en a un. Je le teste. Il n’ai pas fiable… inexploitable. C’est grave pour un logiciel qui se dit pouvoir faire de la production. J’ai donc dû en développer un  moi-même (et à l’époque je n’étais pas un développeur chevronné,  c’est dire que ce n’est pas compliqué à faire). Heureusement, entre temps,  le système IK est arrivé avec la version 4. (Les infographistes ont dû s’en passé quand même pendant 3 versions)
A côté de ça, je dois préparer des outils pour optimiser le travail des animateurs (et des riggers, ne les oublions pas) ainsi que le pipeline (tout ça est étroitement lié). Pour cela, j’explore, je scripte, j’exploite le logiciel à fond et non sans mal. Autant aujourd’hui, j’ai tout oublié, autant à l’époque j’avais toute la structure de Max dans la tête: un vrai foutoir. Et c’est là que les petits détails du début prennent toute leur signification. Par exemple, les clés indissociables, on les retrouve dans le script… indissociables. Pour définir une position par exemple, il faut définir le trio à chaque fois.
Cela signifie que la structure est très directive. On ne peut pas faire librement ce qu’on veut et donc on est très limité.

On peut donc dire clairement que Max a été très mal conçu à la base. Les développeurs ont sans doute voulu se mettre à la place des infographistes en leur proposant des outils ciblés et donc limités (Character Studio) sans comprendre qu’ils étaient loin d’imaginer ce qu’était le travail de ces infographistes, d’autant plus que ce travail évolue sans cesse avec le temps. Moralité, on a une structure du logiciel certes très spécialisée, mais très limitée et loin d’être souple. Tous les manques du départ trahissent une politique contestable: l’infographiste doit s’adapter tant bien que mal à l’outil et non l’inverse.

Pour bien comprendre le problème, éloignons nous un instant de ce logiciel pour venir dans les généralités. Un logiciel, surtout s’il a des fins professionnels, doit venir assister les utilisateurs dans leurs travaux. Ces derniers ont des objectifs de productions, des besoins, des contraintes qu’ils sont les seuls à pouvoir véritablement définir car chaque prod ou chaque studio a sa propre identité. Et même s’ils apportent un soin à tout bien définir avant la prod, les intervenants manqueront toujours le détail auquel personne n’avait penser, celui qu’on ne découvre qu’une fois en situation. Pour cela, un bon logiciel doit savoir s’adapter aux exigences de ceux qui l’utilisent et pouvoir évoluer sans remettre en question sa structure. Plus la structure de base prend en compte cette possibilité, plus le logiciel répondra aux attentes. En d’autres termes, on peut bien se creuser la tête pendant des années mais on ne pourra jamais tout prévoir. Donc il faut laisser le champ libre aux évolutions de toutes sortes.

Max ne semble pas avoir été développé dans cette logique. Les évolutions, il y en a eu mais quand on regarde sa structure (aujourd’hui encore), on comprend que ces évolutions n’étaient pas prévues à la base. D’ailleurs la base est à peu près toujours la même aujourd’hui. Les évolutions ont été faites tant bien que mal sur la même structure. Et donc quand on fouille, c’est un peu comme de l’archéologie, on trouve des couches et des couches d’évolutions qui se superposent avec, il faut le dire, un manque certain de cohérence.  Tout ne s’interconnecte pas, il y a un gros déficit de connectivité, de communication ou d’uniformité. En fait, au lieu de construire des structures universelles capables d’englober à peu près tout, il a été fait plutôt des évolutions très spécifiques pour répondre à des besoins très ciblés sur une structure qui s’est vite montrée inadaptée. Le pire, c’est qu’on ne parle pas la même langue dans tout le logiciel (ou en tout cas, on n’utilise pas les mêmes unités ou les mêmes normes. Par exemple, à un endroit c’est le radian, à un autre c’est le degré)

Bon, et en quoi tout ça intéresse les utilisateurs ? Simplement par le fait qu’ils utilisent un logiciel très limité et qu’ils sont obligés de se formater à lui et à surtout à ses limites.

Pourtant 3DSMax se défend pas mal sur le marché !
En Europe, oui. Pourquoi ? C’est parce que les outils présentés sont très tape-à-l’œil. On a un résultat très vite et sans grande formation. C’est un peu le bouton qui fait tout et tout de suite. Donc ce côté-là, il est très réussi, en tout cas d’un point de vue marketing. En plus 3DSMax a bénéficié d’avoir été le premier des 3 softs à exister sur PC, donc facilement crackable, et le premier des 3 aussi à présenter la possibilité de scripter. Reconnaissons-lui ce mérite.
Il a permis de formater très vite, avant l’arrivée des autres, une grande partie de la population infographiste qui a appris avec lui à faire avec et pas à aller au-delà de leurs besoins car dès qu’on veut aller plus loin, il ne s’adapte pas bien du tout à nos conditions…

Pour finir avec les petites anecdotes, à l’époque, on avait fait descendre au studio le responsable technique d’Autodesk France. L’objectif était de négocier un partenariat puisque nous avions quand même l’objectif de leur commander beaucoup de licences pour réaliser notre film et nous voulions savoir si on pouvait bénéficier de leur aide en cas de problèmes techniques. Nous avons présenté notre développement en cours, notamment en terme de pipeline. Mon patron lui a naturellement demandé ce qu’il pouvait faire pour nous et sa réponse a été : “C’est plutôt vous qui pouvez faire quelque chose pour nous!”. C’était assez  surprenant. On pouvait comprendre entre les lignes qu’on avait pousser le logiciel au-delà de ce qu’il avait prévu de faire. Ou en d’autre terme, le logiciel en lui-même n’était pas à la hauteur de nos attentes.

En fait, nous avons changé de logiciel en pleine pré-prod, non à cause des problèmes évoqués ci-dessus mais plus pour des problèmes de rendu. De mon côté, j’étais rassuré car mes prévisions avaient été que nous pouvions produire le film sur 3DSMax, mais qu’on ne pourrait pas tenir les délais. Pourquoi ? D’abord pour son inadaptation à un pipeline efficace (quoique je l’avais bien fait évoluer de ce côté là mais c’était quand même très lourd) et aussi pour de petits détails plus futiles. Par exemple, en comparaison avec XSI, il faut cliquer 3 à 4 fois plus avec la souris dans 3DSMax pour réaliser une chose similaire. C’est bête et ça a l’air anodin mais sur une journée de travail, ça pèse et ça ralentit pas mal les choses.
Les défenseurs de Max me diront, oui, mais il y a des choses qui font gagner du temps comme la marche automatique du bipède de Character Studio et d’autres trucs vraiment sympa. Mais je leur répondrai que dans XSI, on peut très bien avoir les mêmes outils et même en mieux, c’est-à-dire adaptés et optimisés aux besoins précis des utilisateurs aussi bien d’un point de vue technique qu’artistique. Le tout est de savoir à quel niveau de professionnalisme on parle. Et concrètement, je peux comparer des productions équivalentes d’aujourd’hui et dire que produire en qualité est moins cher sur XSI que sur Max (mais là je n’entre pas dans les détails, c’est confidentiel…)

Voilà pour Max. En fait, il croise encore ma route professionnelle de temps en temps, juste assez pour me rendre compte qu’aujourd’hui, mes remarques sont hélas toujours d’actualité…

Maya – Un essai presque réussi

Avec Maya, on pouvait s’attendre à quelque chose de plus construit puisqu’il bénéficiait d’une plus solide expérience en production avec Alias/WaveFront/TDI. Et c’est le cas.
J’ai connu Alias en modeling et Maya en Animation mais malheureusement très peu en rig et développement. En tout cas, dans un contexte professionnel.
Je connais quand même ce logiciel en matière de Rig pour l’avoir travailler comme beaucoup à la maison mais pas autant que Max ou XSI. Je serai donc plus timide sur mes propos et j’y reviendrai peut-être plus en détail le jour où j’aurai l’expérience suffisante pour en faire ma critique.
Toutefois mon avis sur ce logiciel est qu’il est déjà plus ciblé production que Max. C’est sûr. Sa structure est mieux conçue. On peut certainement arriver à tout ce qu’on veut. Malheureusement on assiste quand même à des limitations qui trahissent le fait que les développeurs imposent malgré tout une manière de travailler aux infographistes. L’exemple le plus flagrant est l’obligation de mettre au moins un objet de type bone dans une enveloppe. C’est peut-être un détail mais pour un rigger/TD comme moi, c’est très dommage car ça ne permet pas de rester libre sur un choix de méthodes de travail. Ou en tout cas, ça limite beaucoup. Ca me donne une impression comme d’avoir les chevilles attachées quand je marche.

Reconnaissons toutefois que Maya nous propose des outils tout prêts très pratiques comme les muscles. C’est limité mais c’est pratique.

XSI – Une efficacité qui demande à aller encore plus loin

J’ai commencé ma carrière en tant qu’animateur sur Softimage 2.64 en août 1994. En animation, ce logiciel était déjà très bien structuré. Ce qui a permis de faire évoluer la structure de base vers une meilleure productivité avec XSI. Malheureusement l’accouchement de la version 1.0 a été difficile à cause d’un rachat malencontreux et d’un développement mis en parenthèse. Quoiqu’il en soit, le logiciel est parvenu sur le marché mais son retard a été un sérieux handicapes puisque les autres logiciels ne l’avaient pas attendu en ce qui concerne les parts de marché.

La philosophie de XSI qu’on peut deviner dans sa structure serait à l’inverse de Max: “On vous propose des outils de base puissants, très accessibles et ouverts, à vous de définir les techniques pour les utiliser”. En d’autre terme, XSI n’impose pas la manière de travailler aux infographistes mais au contraire il offre une flexibilité sur ses outils telle que c’est le logiciel qui s’adapte aux utilisateurs et aux productions. L’avantage, c’est qu’on peut y faire tout ce qu’on peut imaginer (même ce qui n’existe pas encore) et l’inconvénient c’est qu’en apparence, il ne propose pas beaucoup de paillette à qui le découvre pour la première fois. Il y a bien quelque rig tout prêt mais qui ont été surtout fait pour aider les débutants. Tout professionnel qui se respecte dira que c’est à proscrire.

Le secret de XSI, c’est sa structure. Tout est compatible avec tout.  Tout est accessible. Pour reprendre, le défaut des enveloppes que je citais sur Maya, avec XSI, on ne parle pas de Bones qui déforment les enveloppes mais plutôt de Deformers, ce qui permet d’utiliser n’importe quel objet 3D pour déformer un objet. Et ça ouvre des perspectives qui ne se limitent qu’à celles de l’imagination des infographistes. Je dis toujours: dans le setup, il y a les outils mais ils ne sont pas si nombreux que ça, ensuite ce n’est plus qu’une question de techniques et donc d’idées. Et des idées, il en faut, autant que d’imagination, pour aller toujours de plus en plus loin.
Pour prendre un exemple, l’avantage de ne pas avoir de système tout prêt de muscle est qu’on va pouvoir faire celui qu’on souhaite sur mesure, optimisé parfaitement à nos besoins et ça, très simplement, avec seulement quelques outils de base bien solide. La difficulté ici n’est pas l’outil mais bel et bien la technique pour le faire et donc l’idée de cette technique qu’il faudra apprendre ou même inventer.

Prenons un autre exemple avec la Netview. C’est une vue dans laquelle apparaît Explorer internet (que Maya a fini par intégrée tardivement ne voyant probablement pas au départ tout l’intérêt).
A première vue, à quoi ça sert de naviguer sur internet depuis sont logiciel 3D ?  C’est bien souvent la réaction des néophytes. Même aujourd’hui, personnellement, je répondrai: à pas grand chose. Mais il faut voir les choses autrement. A travers des pages internet, on bénéficie d’un environnement dynamique et graphique (HTML, DHTML, PHP, etc.) qui plus est, peut accéder très simplement au cœur du logiciel. On peut donc y développer des outils en tout genre avec un graphisme dynamique facile et puissant. Mieux, on peut faire coexister des outils présents à la fois dans XSI et en dehors du logiciel. C’est-à-dire qu’une même page peut très bien se connecter à une scène XSI si elle est ouverte dans le logiciel et être indépendante si elle est ouverte en dehors dans un simple navigateur internet, par exemple pour gérer un pipeline. Et il n’y a absolument pas de limite. On peut vraiment tout faire et répondre à tous nos besoins.
De même, en prenant le parti de n’utiliser que des langages de script non propriétaire, XSI s’est ouvert naturellement à des horizons qui n’étaient pas prévus à la base comme le WxPython. On peut donc s’attendre plus tard à des ouvertures dont nous ignorons tout à l’heure d’aujourd’hui.

Je parlerai aussi d’un autre outil qui trahit l’esprit d’XSI: les Referenced Models. Un outil de production très puissant qu’on retrouve aussi dans les autres logiciels. Il permet d’utiliser des modèles (personnages, éléments de décor, etc.) en référence. C’est-à-dire que le modèle n’est pas enregistré dans la scène mais fait référence à un fichier externe. Avec la version 6, le contenu même des informations appliquées dans la scène est entièrement accessible et transparent . Ça augmente la puissance du système de sorte, qu’entre autre, on peut très bien débuguer des problèmes qui dans d’autres systèmes seraient complètement inaccessibles si ce n’est agir dessus pour plus de flexibilité. (Je parle bien évidemment des Deltas pour ceux qui connaissent)

Aller, pour la route, un défaut:
A force de trop vouloir rendre tout le plus puissant possible, XSI a opté pour que les shapes (morpher) soient individuellement des objets et non des paramètres. Bien sûr, ça offre beaucoup plus de possibilité et de puissance mais dans le fond, les shapes ne sont utilisés pratiquement que comme des paramètres. Donc ça complique un petit peu leur gestion en devant passer par le Mixer d’Animation. Mais dans le fond, est-ce vraiment un défaut ou cela va dans le sens de XSI ?

Vous l’aurez compris, je défends avec ferveur XSI car en tant que professionnel, c’est le seul de ces 3 logiciels qui m’en offre le plus pour préparer mes productions. Il ne m’offre pas du tape à l’œil, du “tout-cuit” ou du “m’as-tu vu”. Il m’offre la liberté d’aller où je veux, dans le sens  de la qualité ET du rendement, c’est-à-dire que je ne suis pas obligé de faire un compromis entre qualité et petits prix de fabrications. Les 2 sont parfaitement compatibles. Par contre, cela nécessite des compétences importantes qui ne se limitent pas seulement à la connaissance du logiciel. Ça va beaucoup plus loin. Il y a un vrai savoir faire qui n’est pas inscrit dans les manuels d’utilisation. C’est un vrai métier qui s’apprend bien au-delà, hélas, que ce qu’on peut apprendre aujourd’hui dans les écoles.

Mais alors pourquoi je parle dans mon titre de  “qui demande à aller encore plus loin” ?

En fait, de part ma position, j’ai la chance d’avoir entre aperçu des nouvelles générations de logiciels qui arrivent dans le milieu professionnel où c’est le logiciel qui s’adapte complètement et sur mesure aux utilisateurs et non l’inverse, où il suffit d’imaginer un outil pour l’utiliser. Et à côté, Maya et surtout 3DSMax font figures de vieux dinosaures. A la rigueur même XSI mais c’est encore celui qui s’en rapproche le plus dans sa structure. J’estime qu’XSI a très peu de lacunes, surtout comparés aux 2 autres mais par rapport aux possibilités qu’on pourrait avoir en regard de ces nouvelles générations, XSI a encore de l’évolution devant lui. Je ne sais pas si Maya pourrait suivre mais 3DSMax avec sa structure, c’est sûr que non. Il serait plus que temps d’ailleurs pour Max de partir sur une 3ème génération.
Or Autodesk semble défendre coute que coute ses logiciels adorés (quoi qu’avec la dernière version foireuse de Maya, on peut se poser la question pour celui-ci !?!) et délaisser un logiciel comme XSI en le préservant juste dans son arrière boutique pour satisfaire ceux qui le réclamerait. Est-ce une politique commerciale en vue de perdre ce logiciel ? Je ne sais pas mais on pourrait s’en douter car XSI actuellement est le moins cher des 3 alors qu’il n’a jamais été aussi bon dans sa version 2011. Mais si cette politique s’avèrerait alors ce serait une véritable catastrophe pour nous autres infographistes condamnés à ne pouvoir évoluer que sur des vieilles carcasses. Peut-être alors Blender viendrait-il à notre secours ? Je ne sais pas mais qui sait ?

En tout cas, en Europe, et surtout en France, nous sommes condamnés à évoluer dans un certain sens si nous voulons associer qualité et productivité. Nous n’avons pas le choix si nous ne voulons pas voir toutes nos productions partir en Inde ou en Chine, n’en déplaise aux producteurs qui trompent leur monde pour bénéficier de plus de bénéfices. Avec XSI, c’est très possible mais si on nous l’enlève, seul ceux qui pourront bénéficier de logiciels propriétaires pourront résister.

A tous ceux qui débutent dans le métier, je donnerai ce conseil: ne vous laissez pas guider par la poudre aux yeux. Voyez toujours au-delà des apparences et ne perdez jamais votre objectif de vue. Rien n’est établit, rien n’est impossible mais la concurrence est rude.

Posted in DIVERS | 15 Comments »

To bone or not to bone ?

Posted by Frédéric Bonometti on 24 mai 2010

Certains sont étonnés que dans mes rigs, je n’utilise pas d’objet de type bone ou très peu mais à l’inverse je suis surpris que beaucoup les utilisent pour tout et n’importe quoi.

Tout d’abord, je parlerai d’objet de type “bone” et non pas de bone car ce seul mot peut désigner plusieurs choses. Pour moi, un bone, c’est un élément de squelette du personnage. Un os, quoi ! Or il peut être défini par n’importe quel type d’objet 3D.
Ici, par objet de type “bone”, je veux parler des objets 3D présents dans la plupart des logiciels 3D et dont l’aspect ressemble en général à l’illustration ci-dessous.

Objets de type 'bone'

Objets de type 'bone'

Dans beaucoup de rigs qu’on peut trouver sur internet, la structure du squelette des personnages est définie entièrement par ce type d’objets et bien souvent, c’est souvent influencé par les documentations des logiciels. Mais leur utilisation est-elle vraiment justifiée ?

Rig classique des documentations des logiciels

Rig classique

Pour commencer, une petite anecdote que je raconte à tous mes élèves car elle illustre bien le sujet.
Il y a 10 ans, j’étais sur 3DSMax et je faisais mes squelettes comme tout le monde, avec des objets de type “bone” (je n’utilisais pas Character Studio pour diverses raisons, j’y reviendrai peut-être dans un autre article). Un jour, un animateur fraichement débarqué dans la 3D (il venait de la 2D) me demanda si ce n’était pas possible de faire des “bones” en forme du personnage. Ma première réaction a été de répondre que non, que c’était comme ça que tout le monde  faisait. Mais en y réfléchissant, je m’apercevais que ma position n’avait pas suffisamment d’arguments pour tenir la route. On pouvait très bien s’en passer et ça pouvait amener beaucoup d’avantages.

Pour bien comprendre, distinguons 3 parties dans notre structure: le squelette, les muscles et la peau.
- Le squelette sert à définir les axes des mouvements possibles du personnage.
- Les muscles influencent sur les déformations de la peau en fonction des mouvements du squelette. On pourrait les assimiler aux structures qui participent à déformer les enveloppes
- La peau, c’est simplement le résultat final, les objets qu’on voit au rendu (ça englobe aussi les habits). Ce sont en fait les enveloppes.
Ainsi détaillé, la structure est plus simple à comprendre et chaque objet à sa place dans l’organisation globale.

Revenons sur le squelette, ce que nous avons besoin, c’est simplement de définir les positions des axes de chaque objet capable de subir une transformation (rotation, translation et pourquoi pas homothétie). Tout objet 3D (Polygon Meshes, Surfaces, cameras, lights, curves, nulls, etc.) est capable de ça puisque tout objet est muni d’un centre. Alors pourquoi utiliser des bones plutôt qu’autre chose ?

La raison principale est bien sur la possibilité d’animer en FK/IK. C’est une bonne raison puisque XSI nous propose un excellent système FK/IK clé en main sur ces fameux bones. Mais ce n’est pas obligé car on peut très bien développer son propre plug-in ou encore depuis la version 2011, utiliser directement ICE. Mais bon, considérons que nous ne sommes pas trop développeur et que nous voulons utiliser le système FK/IK que nous propose les objets “bones” (qui est d’ailleurs excellent). D’accord pour les bras, pour les jambes mais pour le reste ? En a-t-on besoin sur les doigts ? sur les épaules ? sur la tête ? Je ne vais pas dire Non car c’est à chacun de choisir en fonction de ses préférences mais dans la plupart du temps, on n’utilise pas partout des IK. Des rotations peuvent bien souvent suffir. Donc si je souhaite animer la tête seulement en rotation, pourquoi utiliserais-je un objet de type “bone” comme élément du squelette de la tête si je sais que je ne vais l’animer qu’en rotation alors qu’un simple Null beaucoup plus léger pour l’ordinateur ferait l’affaire ?
Il ne faut pas avoir peur de se poser ce genre de question quand on fait un rig. Il ne faut pas faire “comme ça” parce que tout le monde le fait ou parce que c’est écrit dans la doc. Si on fait quelque chose, c’est parce que ça marche mieux ou c’est plus adapté à notre environnement de travail, etc. Soyons professionnel et non sous-fifre.

Mais revenons à notre tête. Il y a mieux qu’animer un Null en rotation pour tourner la tête: on peut très bien utiliser un Polygon Mesh en forme de tête. Quoi de plus simple pour un animateur que d’animer un objet en forme de tête pour animer la tête. Pas besoin de mode d’emploi. Reconnaissons que c’est plus ergonomique pour l’animateur.
Pour l’affichage, on peut choisir de ne visualiser que les bones (ici les éléments du squelette du personnage) si on veut un rig léger (et donc notre bone en forme de tête) sinon on peut décider de voir et le bone de la tête (en forme de tête) et l’enveloppe de la tête (celle du rendu) simplement en affichant le bone en Bounding Box.

Exemple de rig utilisant des PolyMeshes comme Bones

Exemple de rig utilisant des Polygon Meshes comme Bones

Et si on veut quand même animer la tête en translation (donc en IK), ce n’est pas obligé de mettre un système FK/IK. Il suffit de mettre une contrainte de distance par rapport à la position de l’axe du cou. Ca a le même effet et c’est plus léger. Le cou sera, lui, animé automatiquement à l’aide d’une contrainte de direction vers la tête.  Restons sobre en ressource.

L’autre avantage de ne pas utiliser des objets de type “bone” est de pouvoir choisir l’orientation de ses axes de rotation. Les systèmes de type “Bone” imposent l’orientation en alignant l’axe longitudinal avec la position de l’objet suivant. C’est un inconvénient de taille quand on ne veut animer des objets qu’en rotation.
En fait, on peut modifier l’orientation des axes via les offsets mais ce n’est pas très pratique à régler.

En revanche, l’un des arguments en faveur de l’utilisation des objets de type “bone”  est de dire qu’on en a besoin pour déformer les enveloppes.
Faux ! On peut très bien se servir de n’importe quel objet comme Deformer d’une enveloppe. (Sauf sur Maya où une enveloppe nécessite au moins un objet de type ‘bone’! Zut !… Ce manquement trahit à mon sens la différence entre XSI et Maya mais j’y reviendrai dans un autre article)

Donc utiliser des objets de type “bone” ? ou ne pas utiliser des objets de type “bone” ?
C’est à vous de voir mais au moins poser vous la question. Ne faite pas les choses seulement parce que les autres le font.

Posted in RIG | Tagged: , , , , , | 5 Comments »

Nouveau site, nouvelle adresse

Posted by Frédéric Bonometti on 15 mai 2010

Mon nouveau site vient d’être mis en ligne à cette adresse: www.fre3d.fr
Il n’y a pas beaucoup plus de contenu que l’ancien (c’est en préparation) mais la présentation est originale.

La page d’accueil est développée uniquement en HTML et JScript (donc sans aucun plugin ou autre Flash) et montre que la 3D n’est après tout que de la 2D qui interprète des données 3D.
Je ferai dès que j’aurai le temps un petit tutoriel pour expliquer ce développement mais en attendant pour ceux que ça intéresse, vous pouvez regarder le code source de par vous-même.

N’oubliez pas de cliquer sur le rectangle vert et de déplacer la souris de gauche à droite pour déplacer la roue latéralement.

Posted in DIVERS | No Comments »

Hierarchical (Softimage) Scaling

Posted by Frédéric Bonometti on 20 mars 2010

Quelques petites explications et conseils sur cette option active par défaut sur les nouveaux objets créés.

Tout d’abord pour accéder à ce paramètre, il faut ouvrir la fenêtre des transformations locales de l’objet.
     CS-ListeObjet

On trouve cette option dans la tabulation Scaling.
     CS-LocalTransform

Cette option indique à l’objet de quelle manière il doit recevoir l’homothétie (scale) de son parent quand celle-ci n’est pas uniforme. C’est donc important de bien la définir si on compte préparer une structure sur laquelle on pourra animer les scales.

ClassicScalingOff

Option cochée

ClassicScalingOn

Option décochée

Si l’option est cochée:
Le scale du parent sera transmis sur l’objet suivant ses axes locaux.
Exemple: Dans l’illustration à gauche, la sphère (parent du cube) est scalé sur l’axe Y. Le cube (qui est l’enfant) applique ce scale sur son propre axe Y.

Si l’option n’est pas cochée:
L’objet est configuré selon le mode “Classic Scalling” pour ceux qui se rappelle du logiciel Softimage 3D.
Dans ce mode, l’objet subira le scale de son parent suivant l’axe de son parent.
Exemple: Dans l’illustration à droite, le cube (enfant de la sphère) est déformée de la même manière que son parent.

En général, mieux vaut décocher cette option sur tous les objets si on veut un effet classique du scale.

Mais  il existe des “bugs” ou plutôt des limites qu’il faut connaître. Le plus courant est visible sur les éléments d’un “skeleton” (chaine FK/IK). Sur les bones et le root, mieux vaut garder cocher l’option car en cas de scale non uniforme sur un parent des effets indésirables rendront fous les animateurs. A chaque fois qu’on mettra une clé en translation sur l’effecteur de la chaine, ce dernier se déplacera involontairement  à une position non voulue qui ne cessera de changer à chaque renouvèlement de l’opération. Il faudra donc renoncer à un effet Classic Scaling sur ce type d’objet.

Dernière chose: par défaut, l’option est cochée mais on peut très bien décider de désactiver cette option à chaque création de nouveaux objets. Pour cela, il suffit de changer le réglage dans les préférences (voir illustration suivante).
CS-Preference
Attention! Dans les préférences, l’option n’est pas présentée de la même manière et donc quand la préférence est cochée, l’option sera désactivée sur tout nouvel objet et vice-versa.

Posted in RIG | Tagged: , , , , | 1 Comment »

Formation Rigger/TD XSI

Posted by Frédéric Bonometti on 22 février 2010

Formation professionnelle en ligne aux métiers de Rigger et de TD sur XSI

http://www.dailymotion.com/videoxcbfda

PROCHAINE SESSION AVRIL 2010

Si vous aimez créer des structures d’animation (rigs), développer des interfaces pour aider les animateurs à utiliser vos personnages, programmer des outils de toute sorte dans l’environnement 3D d’XSI, sachez que je dirige un atelier de formation et de mise à niveau professionnelle en ligne autour des métiers de rigger et de TD (développeur technique). C’est un atelier ouvert à tous, débutants ou professionnels, très intense et de haut niveau comme il en existe malheureusement trop peu en Europe (c’est d’ailleurs en tant que recruteur en manque de ressource compétente que je propose cette formation

Setup2-400

La prochaine session se déroulera à partir de mars 2010 sur une durée de 4 mois. Les cours se suivent de chez soi via internet.
C’est une formation complète et avancée sur les métiers de développeurs de rigs, d’interfaces et d’outils divers tournant autour des domaines liés à l’animation sur XSI. Elle aborde bien sûr les multiples possibilités du logiciel mais va plus loin en proposant des techniques évoluées utilisées concrètement en production et d’autres complètement nouvelles et inédites.

Au programme:
- Rigs de base et rigs évolués (muscles, peaux, détection de colisions, etc.)
- Développement d’interfaces et d’outils (Synoptic, CPS, Plugins, NetView, etc.)
- Apprentissage Python, JScript, VBScript
- Adaptation à un milieu de production (pipeline, ergonomie, méthodes, productivité, etc.)
- Développement dynamique de rigs et d’interfaces automatiques
Le programme complet est sur cette page de mon site. Vous y trouverez aussi une description plus complète.

Bras

Pour en savoir plus sur la formation ou sur moi-même, vous pouvez suivre les “liens perso” dans la partie droite du blog.
Inscription et renseignements administratifs auprès de l’école : www.e-tribart.fr
Renseignements sur le programme et sur le contenu des cours directement auprès de moi : m’envoyer un mail

Posted in RIG, SCRIPTS | Tagged: | No Comments »

 
Network :
ico_magazine
Magazine
ico_boutique
Boutique
ico_cgjobs
Portail Emploi
ico_upload
Hébergement d'images
ico_blog
Blogs
progiss
Progiss
ico_social
Social