Au Kitsu Summit, Félix David, responsable pipeline chez Normaal Studio, a expliqué comment ils ont construit, de zéro, une chaîne 3D prête pour la production au sein d’un studio qui n’avait jamais produit de série 3D auparavant.
Son intervention portait sur les outils, la philosophie et les dures leçons qui ont façonné la chaîne pour « Woolly Woolly », une série animée de 52 épisodes.
Les studios d’animation qui souhaitent faire évoluer et accélérer leurs processus de production trouveront son expérience particulièrement intéressante à étudier de près !
À propos de l’intervenant
Félix David a travaillé pendant plusieurs années en tant que TD pipeline, auparavant chez Super Prod, avant de rejoindre Normaal Studio comme développeur pipeline principal.
Normaal Studio est un studio d’animation français profondément ancré dans la production 2D. Quand le studio a décidé de produire « Woolly Woolly », une série 3D inspirée du stop-motion avec 52 épisodes de 11 minutes chacun, il n’existait aucune infrastructure 3D en place.
Félix a été recruté pour construire cette infrastructure depuis le sol, avec une équipe qui a fini par atteindre cinq TD pipeline, travaillant aux côtés d’environ 80 animateurs répartis dans trois sites à Angoulême, Paris et Québec.
Le défi central : un studio 2D qui s’attendait à ce que le 3D ressemble au 2D
Le brief de production reçu par Félix contenait une exigence inhabituelle.
Comme les directeurs et superviseurs de Normaal Studio venaient d’horizons 2D, ils s’attendaient à voir quelque chose de très proche d’un rendu final à chaque étape de la production.
En animation 2D, ce que vous dessinez correspond essentiellement à ce que vous voyez.
En 3D, ce n’est que rarement vrai : il y a des passes de shading, des configurations d’éclairage, des corrections caméra, des files de rendu… l’écart entre le travail d’un animateur et une image finale peut être jour et nuit.
Comme Félix l’a expliqué : « Ils voulaient une chaîne capable d’afficher des aperçus aussi proches que possible des rendus finaux, tout le temps. »
Pour résoudre cela, l’équipe a intégré un rendu en basse définition mais entièrement éclairé directement dans l’étape de publication côté animation.
Lorsqu’un animateur envoyait son travail, la chaîne déclenchait automatiquement non seulement un playblast (un aperçu rapide dans le viewport), mais aussi un rendu réel, en utilisant les lumières déjà intégrées à la scène.
Comme « Woolly Woolly » adoptait un style visuel plat, face caméra, inspiré de la mise en scène théâtrale, les lumières étaient toujours calées sur le décor et n’avaient pas besoin d’être déplacées d’un plan à l’autre. Résultat : le rendu en basse définition était à la fois peu coûteux à produire et réellement représentatif du rendu final.
La philosophie de la chaîne : automatiser sans ajouter de douleur
Avant de choisir un logiciel précis, Félix a établi un principe directeur pour l’ensemble de la chaîne : l’automatisation doit supprimer des étapes, pas en ajouter.
Les studios qui construisent des chaînes sans cette contrainte finissent souvent par obliger les artistes à cliquer à travers des boîtes de dialogue supplémentaires, à remplir des formulaires de métadonnées, ou à attendre des processus qu’ils ne comprennent pas avant de pouvoir reprendre leur travail.
« La philosophie principale, c’est d’éviter d’ajouter davantage de douleur au processus », a déclaré Félix. « La liberté face aux contraintes que l’ordinateur ajoute à la production. »
Cette façon de cadrer a influencé toutes les décisions techniques qui ont suivi.
Pourquoi ils ont choisi des outils open-source : Kitsu et AYON
Pour le suivi de production, l’équipe a choisi Kitsu. Pour la gestion de la chaîne, ils ont choisi AYON (OpenPype), un framework de chaîne open-source qui gère la publication des fichiers, la gestion des versions, le chargement des assets et la synchronisation entre plusieurs sites. Blender a servi d’application DCC principale (création de contenu numérique) pour le travail 3D.
Félix a pris cette décision de manière réfléchie : utiliser des outils open-source existants plutôt que de développer des scripts sur mesure. « Vous ne pouvez pas anticiper tous les besoins auxquels vous serez confronté. Utiliser quelque chose qui a déjà été testé et développé vous aide, car la plupart des cas d’usage que vous aurez à gérer ont déjà été résolus. »
Pour un studio qui réalise sa première production 3D, cet argument pèse lourd. Construire une chaîne propriétaire de zéro implique de passer des mois à résoudre des problèmes que d’autres studios ont déjà traités. Des outils open-source comme AYON et Kitsu apportent des solutions intégrées à bon nombre de ces problèmes.
L’une des contributions de Normaal Studio à AYON pendant la production a été un système de synchronisation entre Kitsu et AYON, permettant aux données de suivi de production dans Kitsu d’informer automatiquement l’état de la chaîne dans AYON. Cette contribution a été soumise en retour au codebase principal d’AYON.
Félix a décrit ce processus de contribution comme plus lent, mais finalement plus fiable : « Quand c’est accepté, fusionné et utilisé dans le codebase principal, vous savez que c’est testé. Ça restera là longtemps, donc ça vous force à concevoir votre code avec soin. »
Publication non destructive & accès aux données par chemin
Deux principes ont déterminé la manière dont les données circulaient dans la chaîne de Normaal Studio.
Le premier est la publication non destructive : une fois les données publiées, elles ne sont jamais modifiées. Si quelque chose doit changer, une nouvelle version est publiée. Cela garantit que n’importe quel plan peut toujours être retracé vers les versions exactes d’assets utilisées, et qu’aucune donnée publiée ne peut être cassée silencieusement par une modification ultérieure.
Le second principe est la résolution des chemins plutôt que le transfert de données. Au lieu de servir des fichiers via un serveur central, AYON résout les chemins de fichiers à la demande : lorsqu’un artiste ou un processus automatisé a besoin d’un fichier, AYON renvoie le chemin vers l’emplacement où ce fichier vit sur le système de fichiers. Le transfert réel des données se fait via des mécanismes standard de synchronisation de fichiers, plutôt qu’en utilisant le serveur de chaîne plus lent.
Félix a décrit le bénéfice concret en termes d’infrastructure : « Si vous ne demandez qu’un chemin vers quelque chose, c’est beaucoup plus léger et ça ne nécessite pas une infrastructure large et lourde pour faire tourner votre production. » Un autre avantage était la résilience. Chaque poste de travail mettait en cache ses propres données localement : si le serveur tombait, les artistes pouvaient continuer à travailler sur leurs copies locales jusqu’à son retour.
Workflow d’assets vs workflow de plans
Un des enseignements les plus précieux de l’intervention de Félix concernait sa distinction entre la manière de traiter les assets et les plans dans une chaîne, car les deux ne se comportent pas du tout de la même façon.
Un asset est composable par conception. Un personnage, par exemple, peut être constitué de produits publiés séparément pour la géométrie, le shading et le rig. Le rig référence à la fois la géométrie et le shading, mais vous pouvez aussi charger uniquement la géométrie, ce qui est utile pour placer un personnage en arrière-plan sans le surcoût d’un rig complet.
Félix a expliqué que, au départ, le workflow de plans suivait cette approche composable : la géométrie, les rigs et les données caméra étaient disséminés dans des produits publiés distincts à chaque étape.
Dans la pratique, cette approche n’a pas tenu : « Ça pouvait fonctionner, mais c’était inutile, parce que l’animation arrive juste après le layout et utilise la même configuration pour la plupart des choses. »
Le workflow de plans sur lequel ils se sont stabilisés est incrémental, plutôt que composable. Chaque étape de la chaîne de plans s’appuie directement sur le fichier de travail de l’étape précédente. Le layout produit un fichier de travail qui devient le point de départ pour l’animation. L’animation produit un fichier de travail qui devient le point de départ pour les effets et le rendu. Rien n’est décomposé puis reconstruit à chaque étape.
Garder les plans à jour lorsque les assets évoluent
Un problème qu’on ne peut pas éviter dans une production longue, c’est l’évolution des assets.
Les personnages gagnent de meilleurs shaders. Les rigs sont corrigés. Les décors sont repensés. Sur « Woolly Woolly », l’équipe de production demandait régulièrement d’appliquer des assets mis à jour à des plans qui étaient déjà animés mais pas encore approuvés.
Normaal Studio a résolu cela avec une notion appelée hero versions.
Une hero version n’est pas une version numérotée précise d’un asset ; elle pointe toujours vers la version publiée la plus récente. Les scènes de layout faisaient référence à la hero version de chaque personnage, plutôt qu’à une version numérotée particulière.
Cela signifiait que lorsqu’un nouveau shader était publié pour un personnage, toute scène de layout utilisant la référence hero de ce personnage intégrait automatiquement la mise à jour la prochaine fois qu’elle était ouverte.
Pour les plans déjà en animation, l’équipe a construit un outil d’automatisation basé sur Blender : il pouvait ouvrir des fichiers de travail, remplacer les rigs ou assets mis à jour, conserver les transformations et modificateurs d’animation existants, puis republier automatiquement une nouvelle version de l’animation. Cet outil tournait sur de nombreux plans à la fois, sans exiger que des artistes mettent à jour manuellement chaque scène.
Dépendances de fichiers & pré-synchronisation pour les artistes distants
Avec des artistes répartis sur trois villes, garder les caches de fichiers de chacun à jour était un autre défi. Les scènes de production volumineuses dans Blender dépendent de nombreux fichiers liés (personnages, décors, accessoires, etc.) et attendre que ces fichiers se synchronisent à la demande fait perdre du temps.
La solution de Normaal Studio a été un service de synchronisation en arrière-plan qui utilisait les données de la fonctionnalité breakdown de Kitsu. Lorsqu’un plan était assigné à un artiste, la chaîne pouvait lire le breakdown pour déterminer quels personnages et décors apparaissaient dans ce plan, puis pré-synchroniser tous les fichiers pertinents vers le poste de travail de l’artiste avant même qu’il n’ouvre la tâche.
Au moment où l’artiste cliquait pour commencer à travailler, tout ce dont il avait besoin était déjà en place.
La même logique de pré-construction s’appliquait aux fichiers de travail. Au lieu d’exiger qu’un artiste layout clique sur un bouton « build » et attende que le système assemble sa scène de départ, la chaîne construisait ce fichier de travail en arrière-plan dès que la tâche était assignée. Ouvrir une tâche revenait à ouvrir un fichier entièrement préparé.
Rendre sans ferme de rendu
Normaal Studio ne disposait pas du budget pour le rendu cloud ni pour une ferme de rendu dédiée.
À la place, l’équipe a utilisé OpenCue, un outil open-source de gestion de rendu développé par Google et Sony Pictures, pour distribuer le rendu entre les postes de travail des artistes pendant leurs temps d’inactivité.
Chaque minute où un poste n’était pas utilisé par un artiste, OpenCue pouvait le mettre à contribution sur une tâche de rendu ou une tâche de build automatisée.
À retenir
Félix a conclu son intervention avec une réflexion qui dépasse largement ses choix techniques spécifiques : « On ne peut pas avoir une chaîne universelle parfaite que tout le monde pourrait utiliser. Mais on peut en construire une bonne qui correspond à la culture du studio et aide à rendre la production plus fluide. »
Pour Normaal Studio, s’adapter à la culture du studio signifiait accepter qu’un directeur formé au 2D devait voir des rendus éclairés, et non des playblasts OpenGL. Cela signifiait construire de l’automatisation qui enlève aux artistes des charges techniques, sans changer la façon dont ils pensent leur travail. Et cela signifiait choisir des outils comme Kitsu et AYON, qui avaient déjà absorbé des années de connaissances de la communauté, afin que l’équipe pipeline puisse se concentrer sur les problèmes réellement uniques à leur production.
