Dorian Fevrier's blog

Note

Bien que le contenu de ce blog soit sous licence Créative, toutes les images présentes sur ce billet sont la propriété de leurs auteurs respectifs. Tout contrevenant s'expose à des poursuites judiciaires et pourra se voir kidnappé dans son sommeil, lapidé sur la place publique et privé de bonbons. :gniarkgniark:

Mon arrivé sur le projet

Tout d'abord, une remise en place du contexte me semble intéressante.

Tout commence fin 2009, je suis à Def2Shoot sur le long métrage d'animation Yona Yona (nom du projet à l'époque). A la suite de plusieurs réunions de prod franco-japonaises, le choix de faire l'animation des personnages principaux sous Maya et les décors sous XSI est fait. Je me retrouve à être le seul TD sous Maya (D2S étant sous XSI).

Franck Malmin (lire son témoignage, très sincère, sur le film), alors directeur du studio, propose au Surfacing TD du projet d'aider "une production" à se lancer. Celui ci commence ainsi à passer quelques après midi à Nord Ouest Film, ou une partie de "l'équipe de Michel" est déjà en place.

A ce moment là je n'en savais pas plus. Mais les difficultés qu'allaient rencontrer Yona Yona commençaient à se faire ressentir et la production demande le retour à plein temps de son surfacing TD sur le projet.

A Def2Shoot, la partie sous Maya posant de moins en moins de soucis (grâce notamment à l'arrivé d'un second TD), Franck me demande de continuer le travail commencé chez Nord Ouest.

C'est à ce moment là que je rencontre ceux que je connaissais sous l’appellation "l'équipe de Michel", tous des gens formidables. :sourit:

Au début, mon travail ne devait pas durer longtemps et était très basique. Il fallait prendre connaissance des besoins du projet et les aiguiller vers des solutions rapides (aide pour convertir les .map de mental ray car les plans des décors étaient monstrueusement grand, définir une hiérarchie de dossier et expliquer le pourquoi du comment de chaque dossier, etc...).

Malgré les besoins techniques assez limité que nécessitait ce projet (Les Contes de la Nuit, ce n'est pas Transformers avec du raytracing partout), l'équipe, finalement assez réduite et composé de peu pas de techniciens, pouvait, à long terme, se retrouver à passer plus de temps à régler des soucis techniques qu'à vraiment travailler sereinement. :reflechi:

Il y avait quand même, à ce moment là, 10 épisodes de 13 minutes en Full HD à sortir.

Cette inquiétude était partagée avec le reste de l'équipe et au bout de quelques conversations entre Franck et la production, il fut décidé que je continuerai le projet jusqu'à la fin (le projet durait un an et demi et il est à noter que les délais furent respectés).

Je faisais donc officiellement partie de l'équipe!

:youplaBoum:

Les grands moyens

Cette décision allait pas mal changer mon implication sur le projet et je pouvais voir "plus loin", faire des choses plus avancées, gérer des cas plus complexes etc...

L'assistant réal de Michel Ocelot venait de la 2D et avait l'habitude faire un travail de préprod conséquent monstrueux. Ainsi, le storyboard et la mise en scène est déjà faite et un dépouillement technique et d'intention était déjà dans les fichiers Excel de la directrice de production avant même qu'un épisode ne parte en Layout.

Ce genre de chose m'a pas mal rassuré car la perspective de devoir tout changer au dernier moment (mentalité très trop présente dans la pub et le cinéma dit "à l'américaine") ne m'aurait pas incité à prendre certains risques pour améliorer la prod et ces conditions. Forcément quand on a une certaine assurance que ce qu'on souhaite faire est bien ce qu'on va faire, on se prend moins la tête à prévoir du temps pour le bricolage.

C'est à ce moment que j'ai pu commencer à définir les grandes lignes du workflow.

L'usage du script

N'y allons pas par quatre chemins: Le script était partout ou personne n'osait s'aventurer. :sourit:

L'importance d'une hiérarchie de fichier techniquement cohérente était donc primordiale pour pouvoir automatiser des taches, tout en gardant à en tête qu'elle allait aussi être manipulé par des "humains" et, de ce fait, devait également rester compréhensible.

Le langage de prédilection fut le MEL pour tout ce qui touche Maya (Je n'étais pas encore à l'aise avec "Python de Maya" à ce moment là) et du Python pour tout ce qui touche la manipulation de fichiers (os et re sont tes amis).

L'utilisation du scripting c'est surtout faite aux "points de passages" des informations/fichiers. J'y ferais souvent référence durant le reste de ce billet car j'ai quasiment passé cette prod mes doigts sur le clavier. :pafOrdi:

Résumé du pipeline

Un plan qui résume grosso modo les différentes étapes du pipeline

Les décorateurs

Les "décorateurs" ("mappeurs") faisaient leurs décors sous Photoshop (dans des fichiers très grands et très lourds ^^ ), ils exportaient le fruit de leur travail sous différentes couches en tiff dans un dossier dédié et suivant une convention de fichier défini à l'avance.

Au début, il convertissaient eux même leurs .tiff en .map (et .dds) mais cette manipulation leur prenait du temps. J'ai donc rapidement fait un script qui passait sur tout le projet en cours et vérifiait que chaque .map (ou .dds) était plus vieille que son .tiff. Dans le cas contraire, il effectuait une conversion. :dentcasse:

Les personnages

Je n'étais pas directement impliqué dans la création des personnages.

Un graphiste 2D faisait les versions Photoshop des personnages, "les éclatait" sur un plan, un character TD, rejoint temporairement par un animateur avaient mis en place un système de rig automatique pour générer les personnages.

Les images des personnages étaient converties de la même façon que les décors.

Ma partie, dans le pipeline commençait au niveau du Layout avec un outil pour les lister et les importer dans la scène en fonction de l'épisode.

Ce fut donc un gros travail de communication pour savoir qui lister et dans quel cas ne pas lister tel ou tel personnage.

Note sur le format .dds

Michel Ocelot validait l'animation sur les playblasts. Il fallait donc que les playblasts soit "le plus proche possible" du rendu final.

Ceci est un playblast. :sourit:

Pour ça, les textures utilisées dans les scènes Maya devaient être celles utilisées dans le rendu, moyennant un redimensionnement.

J'ai donc codé un shader cgfx auquel je donnais les version .dds des textures pour diminuer leur charge dans la mémoire du GPU.

Cette technique à très bien fonctionné concernant les décors mais un bug que je n'ai pu résoudre faisait disparaitre certaines textures lors des mouvements des contrôleurs des personnages.

J'ai du bricoler une sorte de surface shader pour le viewport mais on perdait l’intérêt des texture en .dds car il m'a semblé que Maya décompressait puis plaçait entièrement la texture dans la mémoire du GPU. :pasClasse:

C'est dommage car c'était justement les personnages qui prenaient le plus de place en terme de texture. J'ai du faire des version "low" des .dds (qui étaient déjà de la basse def) ainsi qu'un outil pour switcher rapidement entre .dds normal et .dds "low", certains plans ayant pas mal de personnages.

Le layout

J'ai donc fait l'importeur de personnage mais aussi le "générateur de décors". Chaque plan du film est en fait une superposition de couches de décors:

Comme la nomenclature des fichiers était claire, il était très simple, via un script, de savoir ou étaient les différentes couches du plan en court.

Il suffisait alors de préciser le numéro de l'épisode ainsi que le numéro du plan qu'on souhaite générer, de valider.

Un rig de décor était importé puis adapté au plan. Les couches du décor étaient chargées sur leur plan respectif et l'image plane de la camera affichait l'animatique exportée du montage.

Il ne restait "plus qu'à" placer les personnages.

J'ai également scripté un "transfert de plan" pour que les "layouteurs" n'ait pas à remplacer tous les personnages alors que deux plans plus tard ils sont dans la même position.

L'animation

Il n'y avait rien de "pipeliné" concernant la publication des scènes de layout. Les animateurs copiaient la scène de layout de leur plan et commençaient à animer.

J'ai codé un panel de personnage qui était surtout utilisé pour les mains des personnages. Les mains étaient des textures plaquées sur des faces affichées/masquées au fil de l'animation.

Les textures des mains ainsi que les numéros des attributs à "afficher/masquer" respectaient une nomenclature. Ainsi, à chaque ajout d'une main, il suffisait d'ajouter une ligne pour que le tout apparaisse dans le panel.

En revanche, répondre à la contrainte d'automatisation du rendu nécessitait que les scènes soient publiées dans un dossier ou le script allait pouvoir les récupérer.

J'ai donc fait un outil de publication des animations qui sauvait la scène en cours ainsi qu'un petit fichier vide qui jouait le role de "marqueur" pour préciser que cette scène venait d'être republiée.

Le rendu

Sur cette partie il n'y avait quasiment aucune intervention humaine. Tout avait été scripté par mes soins.

jEdit était mon copain! :laClasse:

Je lançais un script qui reprenait toute les scènes des animateurs ayant un marqueur, les ouvrait et leurs appliquait un script qui faisait pas mal de choses (liste non exhaustive):

• Changer les chemins de texture (remplaçant ".dds" par ".map" entre autre).
• Modifier les options des textures (pour utiliser le filtrage elliptique).
• Setter des bon paramètres de rendu.
• Aller chercher, dans un fichier texte, si le plan en question avait du motion blur et l'activer si c'était le cas.
• Appliquer certaines modifications (décalage de l'animation des mains de 0.5 frame en cas de rendu avec motion blur pour éviter d'avoir des sautes durant les rotations sur une image, masquer certains contrôleurs visibles au rendu, etc...).
• Faire quelques bricolages propres à l'épisode (Appliquer un blur différent au mains du Garçon Tamtam par exemple).
• Générer les fichier de job contenant les lignes de commande à lancer (nous utilisions Smedge) ainsi qu'un .bat en cas de rendu en local.
• Supprimer le fichier marqueur.
• Sauver la scène prête à rendre dans le bon dossier.

Les lanceurs de job généré par mon script

Les graphistes, quand ils quittait leur poste le soir ou durant la pause de midi, lançait un client de Smedge et leur machine calculait les rendus.

Mental ray était le moteur utilisé et a très bien joué son rôle (c'était mon moteur de prédilection aussi). Une fois les .map et le filtrage elliptique mis en place, tout à roulé!

Le compositing

Le compositing était fait sous After Effect et se divisait en deux parties.

• Une première contenant tout les "trucs un peu spéciaux" (effets de fumé, transformations, certaines animations aussi) était assuré par un animateur 2D.
• La seconde partie représentait le plus gros des plans (80% je dirais) et était principalement de la retouche rapide (patates), des effets globaux (profondeur de champ), etc...

J'ai fait un script After Effect (une première expérience) qui créait une compo pour le plan, importait toutes les couches, les empilait dans l'ordre et créait un set d'export.

C'était aussi grâce à ce script qu'on pouvait avoir un retour rapide des rendus "bruts": On lançait le script pour tout les plans rendus, on cliquait sur "Rendu" et le calcul de toute les couches se faisait. Il ne restait plus qu'à vérifier dans le projet de montage (Final Cut) qui se mettait automatiquement à jour.

Un second script (utilisé dans le premier en fait) générait les set d'export depuis les compos sélectionnés dans After Effect ce qui simplifiait le travail des graphistes qui n'avaient plus à perdre de temps sur l'export de leur travail.

Tout le reste

Bien entendu, il y avait tout pleins de petites taches qu'il fallait remplir au fil du projet:

• Backup des épisodes.
• Gestion de la place sur le serveur.
• Dépouillement technique.

Passage du stade de série au stade de long métrage en relief

Et oui! Parce que c'est ça qui est particulièrement intéressant sur ce projet. L'idée partait d'une série full HD pour Canal+ et se finit en un long métrage en relief, ce n'est pas un truc qu'on voit tout les jours. :redface:

Je me rappel que c'est suite à une projection pour Canal+ que l'idée d'un long métrage (on ne parlait pas de relief à ce moment là) à commencer à se faire entendre, sans jamais être réellement officielle. Concrètement, cela changeait peu de choses pour nous.

Mais quand on a commencé à parler de relief, les choses ont un peu évolué. Mac Guff était dans le coup. Nous leur avions donné quelques plans suffisamment représentatif de l'ensemble et ils en ont fait du "vrai" relief.

J'insiste sur le terme "vrai" relief car Mac Guff disposait de toute les couches (et nos fichiers After Effect en fait) et a put travailler le relief sans avoir à recréer artificiellement de la profondeur.

Lors de la première présentation nous étions 5-6 et je dois dire que j'étais particulièrement impressionné par le résultat. La profondeur et le noir donnait un véritable effet de théâtre à l'ensemble. L'équipe du relief avait fait de l'excellent travail et je pense que tout le monde était conquis. (Avatar pouvait aller se rhabiller, il venait de se prendre un low kick rotatif inversé là! :baffed: )

Une fois le relief officiellement validé, le nombre de couche à explosé. Il arrivait que les compos After Effect plombe notre petit réseaux. Finalement, calculer les images en local s'est révélé une solution simple, pas cher, et qui solutionnait, en partis, le problème.

La production c'est donc très bien fini, sans douleurs et c'est assez rare pour être précisé.

Ce que j'aurais aimé faire mieux

Forcément, avec le recul, je me dis que quelques points aurait mérité un peu plus d'attention.

• J'aurai aimé résoudre le problème des textures (cgfx + .dds) qui popaient dans le viewport lorsque les animateurs bougeaient leur contrôleurs. La solution trouvé n'était pas optimale et alourdissait la charge de Maya quand il y avait beaucoup de persos. Les seg faults étaient fréquent...
• J'ai choisi d'utiliser le .png pour l'ensemble des images du projet (sauf export Photoshop car le .tiff était le seul format qui conservait bien les alphas lors d'une conversion en .map) car ce format était particulièrement "clair" (RGBA et pis c'est tout!) et je voulais éviter le tiff qui était beaucoup plus "opaque" (plusieurs type de compressions possible, nombre de channel, ne s'ouvre pas partout, etc...). C'est quelque chose que je considère comme une erreur de débutant maintenant car le .png est un format de fichier extrêmement lourd à ouvrir. Le .tiff, si il est bien géré, à tout les endroits du pipeline (au moins au rendu), offre un bien meilleur confort.
• Surement d'autres choses...

Conclusion

Vous l'aurez surement compris, ce fut une belle expérience autant professionnel que personnel. Bosser avec Michel Ocelot c'est presque un cadeau.

Ce fut aussi une première supervision technique sur un long métrage pour moi.

Le film sera nominé 8 fois au festival international de Berlin ce qui est quand même un grande réussite quand je me remémore le nombre de personnes finalement assez faible qui a travaillé sur ce projet (comparé à d'autres productions d'animation cinématographique).

Les critiques de la presse sont très bonnes et j'espère que ce billet un peu technique vous aura donné envie de voir ce film fait avec amour. :sourit:

Mes contes préféré?

• Le Loup-Garou: Parce que le travail fait sur les feuilles rend le relief magnifique.
• L'élue de la ville d'or: Parce que dans une salle de cinéma, avec la musique et tout, votre cœur d'adulte lâchera obligatoirement quelques larmes de bonheur.

A bientôt!

Dorian

Liens

• Page IMDb des Contes de la nuit
• Page IMDb de Dragons et Princesses
• Page allocine
• Page Wikipedia de Dragons et Princesses