Au Kitsu Summit, Félix David, responsable pipeline chez Normaal Studio, a partagé la manière dont ils ont construit, de zéro, une pipeline 3D prête pour la production dans un studio qui n’avait jamais produit de série 3D auparavant.
Sa présentation a couvert les outils, la philosophie et les leçons difficiles qui ont façonné la pipeline pour "Woolly Woolly", une série animée de 52 épisodes.
Les studios d’animation qui cherchent à faire passer leurs processus de production à l’échelle trouveront que son expérience mérite d’être étudiée de près !
À propos du conférencier
Félix David a travaillé pendant plusieurs années comme pipeline TD ; auparavant chez Super Prod, puis il a rejoint Normaal Studio en tant que développeur pipeline principal.
Normaal Studio est un studio français d’animation, fortement ancré dans la production 2D. Lorsque le studio a décidé de produire "Woolly Woolly", une série 3D inspirée du stop-motion comptant 52 épisodes de 11 minutes chacun, il ne disposait d’aucune infrastructure 3D existante.
Félix a été recruté pour construire cette infrastructure de A à Z, avec une équipe qui a fini par atteindre cinq pipeline TD, travaillant aux côtés d’environ 80 animateurs répartis sur trois sites à Angoulême, Paris et Québec.
Le défi central : un studio 2D qui attendait que la 3D ressemble à la 2D
Le brief de production reçu par Félix contenait une exigence inhabituelle.
Comme les directeurs et superviseurs de Normaal Studio venaient d’un parcours en 2D, ils s’attendaient à voir quelque chose de 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, c’est rarement le cas : il y a des passes de shading, des setups d’éclairage, des corrections caméra, des files de rendu… La différence entre le travail d’un animateur et une image finale peut être jour et nuit.
Comme l’a expliqué Félix : "Ils voulaient une pipeline capable d’afficher des prévisualisations aussi proches que possible des rendus finaux, tout le temps."
Pour résoudre cela, l’équipe a intégré un rendu basse définition mais entièrement éclairé directement dans l’étape de publication côté animation.
Lorsqu’un animateur soumettait son travail, la pipeline déclenchait automatiquement non seulement un playblast (une prévisualisation rapide dans la vue), mais aussi un vrai rendu, en utilisant les lumières déjà intégrées à la scène.
Comme "Woolly Woolly" adoptait un style visuel plat, de face, inspiré de la mise en scène théâtrale, les lumières étaient toujours calées sur la scène et n’avaient pas besoin d’être déplacées entre les plans. Résultat : le rendu basse définition était à la fois peu coûteux à produire et réellement représentatif du rendu final.
La philosophie de la pipeline : automatiser sans ajouter de douleur
Avant de choisir n’importe quel logiciel en particulier, Félix a établi un principe directeur pour l’ensemble de la pipeline : l’automatisation doit supprimer des étapes, pas en ajouter.
Les studios qui construisent des pipelines sans cette contrainte finissent souvent par forcer 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é vis-à-vis des contraintes que l’ordinateur ajoute à la production."
Cette façon de formuler les choses a ensuite guidé toutes les décisions techniques.
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 pipeline, ils ont choisi AYON (OpenPype), un framework 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 (digital content creation) principale pour le travail 3D.
Félix a pris une décision volontaire : utiliser des outils open-source existants plutôt que de développer des scripts sur mesure. "On ne peut pas anticiper tous les besoins qu’on va rencontrer. Utiliser quelque chose qui a déjà été testé et développé vous aide, car la plupart des cas d’usage que vous devrez gérer ont déjà été résolus."
Pour un studio qui réalise sa première production 3D, cet argument a un poids considérable. Construire une pipeline propriétaire à partir de zéro signifie 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 prêtes à l’emploi à une grande partie 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 : il permettait aux données de suivi de production dans Kitsu d’informer automatiquement l’état de la pipeline dans AYON. Cette contribution a été soumise à nouveau dans le codebase principal d’AYON.
Félix a décrit ce processus de contribution en retour comme plus lent, mais finalement plus fiable : "Quand c’est accepté, fusionné et utilisé dans le code principal, vous savez que c’est testé. Ça restera là longtemps, donc ça vous oblige à concevoir votre code avec soin."
Publication non destructive & accès aux données par chemins
Deux principes ont façonné la manière dont les données circulaient dans la pipeline de Normaal Studio.
Le premier, c’est la publication non destructive : une fois les données publiées, elles ne sont jamais modifiées. En cas de besoin de changement, une nouvelle version est publiée. Cela garantit que chaque plan peut toujours être retracé vers les versions exactes des assets qu’il utilisait, et qu’aucune donnée publiée ne peut être cassée silencieusement par une modification ultérieure.
Le deuxième principe, c’est la résolution des chemins plutôt que le transfert de données. Au lieu de servir les fichiers via un serveur central, AYON résout les chemins des fichiers à la demande : quand un artiste ou un processus automatisé a besoin d’un fichier, AYON renvoie le chemin vers l’emplacement de ce fichier sur le système de fichiers. Le transfert de données effectif se fait via des mécanismes classiques de synchronisation de fichiers, plutôt que d’utiliser le serveur de pipeline (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 grande et lourde pour faire tourner votre production." Un autre avantage était la robustesse. Chaque poste de travail mettait en cache ses propres données localement, ce qui signifiait que si le serveur tombait, les artistes pouvaient continuer à travailler sur leurs copies locales jusqu’à son retour.
Workflow Asset vs workflow Shot
Parmi les enseignements les plus précieux de la présentation de Félix, il y avait sa distinction entre la manière de traiter les assets et les plans dans une pipeline, car les deux se comportent de façon très différente.
Un asset est, par conception, composable. Un personnage, par exemple, peut être composé 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 : c’est utile pour placer un personnage en arrière-plan, sans le coût et la lourdeur d’un rig complet.
Félix a expliqué que, dans un premier temps, le workflow de plan a reproduit cette approche composable, en dispersant la géométrie, les rigs et les données caméra dans des produits publiés séparés à chaque étape.
Cette approche ne tenait pas dans la pratique : "Ça pouvait marcher, mais c’est 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 finalement retenu était incrémental plutôt que composable. Chaque étape de la pipeline de plan construit directement à partir du fichier de travail produit lors de l’étape précédente. Le layout produit un fichier de travail qui devient le point de départ de 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é et reconstruit à chaque étape.
Maintenir les plans à jour quand les assets évoluent
Un problème qu’on ne peut pas éviter dans une production au long cours, 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 l’application d’assets mis à jour à des plans déjà animés mais pas encore validé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 spécifique 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 précise.
Ainsi, quand 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 ouverture.
Pour les plans déjà en animation, l’équipe a créé un outil d’automatisation basé sur Blender : il pouvait ouvrir des fichiers de travail, remplacer les rigs ou assets mis à jour, préserver les transforms 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 les artistes mettent à jour chaque scène manuellement.
Dépendances de fichiers & pré-synchronisation pour les artistes à distance
Avec des artistes répartis sur trois villes, garder les caches de fichiers locaux de tout le monde à jour était un autre défi. Les grandes scènes de production 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, utilisant les données de la fonctionnalité de breakdown de Kitsu. Lorsqu’un plan était assigné à un artiste, la pipeline pouvait lire le breakdown pour déterminer quels personnages et quels 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, 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’obliger un artiste de layout à cliquer sur un bouton "build" et à attendre que le système assemble la scène de départ, la pipeline 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 n’avait pas le budget pour du 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 les rendus sur 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 sur une tâche de build automatisée.
À retenir
Félix a conclu sa présentation par une réflexion qui s’applique bien au-delà de ses choix techniques spécifiques : "Vous ne pouvez pas avoir votre pipeline universelle parfaite que tout le monde pourrait utiliser. Mais vous pouvez 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 réalisateur formé à la 2D devait voir des rendus éclairés, pas des playblasts OpenGL. Cela signifiait construire de l’automatisation qui retire des contraintes techniques aux artistes 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 communautaires, afin que l’équipe pipeline puisse se concentrer sur les problèmes réellement uniques à leur production.
