Lors du Kitsu Submit, Axel Tillement, CG Supervisor chez Cube Creative, a pris la parole pour répondre à une question simple : comment produire un grand nombre d’assets, sur des projets très différents, tout en gardant une chaîne de production aussi stable que possible ? Sa réponse, appuyée par des années d’expérience de production, propose une feuille de route concrète pour tout studio d’animation qui souhaite passer à l’échelle sans tomber dans le chaos.
Cube Creative est un studio d’animation basé à Paris, avec un historique de séries produites à la fois sur commande et à partir de leur propre IP. Parmi leurs derniers travaux : Tangranimo pour France Télévisions, Pfffirates pour TF1, et 7 Bears, co-produit avec Folivari pour Netflix. Ces projets couvrent des besoins créatifs très différents : l’un met en scène de nombreux personnages, un autre ajoute une végétation dense, et le troisième superpose un défi de rendu de fourrure à tout le reste.
Ce qui rend l’expérience de Cube intéressante à étudier n’est pas l’ambition de chacun de ces projets, mais le fait que les trois ont traversé la même chaîne de production. Et cette chaîne n’est pas restée figée non plus : chaque production a nourri la suivante.
Comme l’a expliqué Axel : « Chaque projet apporte sa contribution à la chaîne de production, et chaque projet s’appuie sur le précédent. On ne repart pas de zéro sur chaque projet. Chaque projet alimente le suivant pour que ce soit plus simple. »
Les deux piliers : Blender et Kitsu
La chaîne de production de Cube repose sur deux outils. Blender gère le travail de production créative et technique. Kitsu, le gestionnaire de production open-source développé par CGWire, sert de ce qu’Axel appelle la « mémoire collective » du projet.
Pour les studios qui ne connaissent pas Kitsu : il s’agit d’un outil de gestion de production basé sur le web qui suit l’état de chaque asset et shot tout au long de la production. Les artistes et les superviseurs l’utilisent pour savoir si un asset est en modélisation, en attente de validation, ou prêt à être utilisé en aval. Chez Cube, Kitsu est la source de vérité faisant autorité sur la position exacte de n’importe quel asset à n’importe quel moment.
« Kitsu, c’est la mémoire collective du projet », a déclaré Axel. « Il connaît l’état de chaque asset, de chaque shot, et l’état global de la production. »
La chaîne de production inclut bien sûr d’autres outils. Maya prend parfois en charge la modélisation des voitures. Houdini apparaît encore pour le travail VFX, même si Cube le remplace de plus en plus par les Geometry Nodes de Blender. Fusion gère la sortie de compositing. Mais Blender et Kitsu constituent l’entrée principale, et tous les autres outils s’y alimentent plutôt que de fonctionner séparément.
Une histoire de deux espaces
Une fois que Kitsu crée un asset, la chaîne de production de Cube se divise en deux zones de travail distinctes.
La première, c’est l’espace utilisateur, où vivent toutes les étapes de production et les versions incrémentales. C’est là que les artistes font leur travail quotidien, et cela se connecte directement à Kitsu. Kitsu suit si un ensemble est validé, en cours de review, ou en attente d’approbation. Tous les changements de statut qui comptent pour la production se font ici.
La seconde, c’est l’espace push. C’est là que les assets sont rendus disponibles aux étapes en aval, même avant d’être totalement validés. Comme l’a formulé Axel, les assets dans l’espace push sont « assez sains pour passer aux étapes suivantes et être mis à jour plus tard sans être destructifs ». Point important : cet espace ne communique pas avec Kitsu. Il s’agit d’une couche séparée, pratique, conçue pour la continuité plutôt que pour le suivi formel.
En plus des fichiers Blender présents dans l’espace push, Cube pousse aussi des fichiers JSON de descripteurs. Ils contiennent des métadonnées comme les noms des meshes, les nombres de vertices, ainsi que les instructions de subdivision : en somme, une description lisible par machine de ce qui se trouve dans chaque fichier Blender.
Le système de niveau de détail : revenir aux bases de la production
Le cœur véritable de l’approche de Cube, c’est leur système de niveaux de détail (LOD). Plutôt que de le construire pour des raisons de confort technique, ils l’ont conçu en partant de ce dont chaque étape de production a réellement besoin.
- Pour le layout, les artistes doivent cadrer les shots et habiller les décors. Ils ont besoin de savoir à quoi ressemblent les assets, mais ils n’ont pas besoin de la qualité de rendu finale. Ils doivent avoir un contrôle complet de la caméra, mais les personnages et accessoires peuvent être relativement légers.
- Pour l’animation, la scène doit être suffisamment légère pour maintenir un bon taux d’images par seconde. Une scène qui ne rame pas est une scène qui s’anime mieux, et cela impacte directement la qualité du travail de l’animateur.
- Pour le rendu, la logique s’inverse complètement. L’animation est verrouillée et “baked”. La qualité visuelle devient la priorité, et tout est poussé au maximum de sa définition.
Cube a codifié cela en un système concret, avec plusieurs niveaux selon trois dimensions : modélisation, shading et rigging.
Côté modélisation, le mesh de base se trouve au centre. C’est la version retopologisée validée par le modélisateur, la production et les directeurs. En remontant dans le niveau de détail, les artistes peuvent accéder à une version subdivisée pour le rendu, ainsi qu’à une version encore plus subdivisée avec displacement. En redescendant, on trouve une version décimée pour les personnages éloignés, et un plan plat pour les figures d’arrière-plan très lointaines qui n’ont besoin d’aucun volume.
Côté shading, l’équivalent va de l’image du plan plat à un mode couleur par objet (pas de vrai shader, uniquement des informations de couleur), en passant par un shader de viewport optimisé pour l’animation, le shader de rendu complet, et enfin un shader avancé avec des displacement maps et des textures haute résolution.
Le rigging fonctionne différemment. Le niveau de détail pour le rigging n’est pas toujours un fichier séparé, mais souvent une instruction sur la manière d’importer l’asset. Au niveau le plus bas, l’asset est simplement référencé et verrouillé dans la scène. En montant, les artistes obtiennent un accès au niveau objet, puis un « short rig » simple pour le timing du layout, ensuite le rig complet pour l’animation, et dans certains cas un rig lourd spécialisé utilisé uniquement pour des shots spécifiques.
De la théorie au projet Pfffirates
Pour rendre tout cela concret, Axel a détaillé le projet Pfffirates. L’univers de Pfffirates met en scène des personnages en plastique gonflable, ce qui a introduit un défi de shading spécifique : une displacement map était parfois nécessaire pour ajouter de petites rides aux surfaces gonflables.
Pour chaque personnage, la plage LOD de modélisation couvrait le mesh de base retopologisé, une version avec displacement activé, une version décimée pour la mi-distance, et un plan plat pour l’arrière-plan. La plage de shading allait de l’image du plan à un shader basique avec une carte JPEG légère (nécessaire, car les personnages gonflables mono-mesh rendaient le shading couleur par objet “pur” plus délicat), le shader de rendu, et enfin le shader lourd avec displacement activé.
Pour le rigging, chaque personnage disposait de cinq niveaux : une référence pure (verrouillée dans la scène), un import au niveau objet pour appliquer des caches et des références de position, un short layout rig, le rig complet d’animation, et un rig “superpouvoir” spécial propre à chaque personnage. Ce dernier niveau n’était pas chargé dans chaque shot, à cause de son coût en temps réel (framerate).
La même structure s’applique aux accessoires. Même le bateau, qui sert à la fois d’accessoire et de décor, a suivi la même logique. Comme il faisait office d’espace de jeu pour les personnages, Cube l’a limité à quatre niveaux de détail et a utilisé un asset séparé de “dress” pour une définition plus élevée quand c’était nécessaire.
Tout configurer avec Ronald Reglages
Traduire ce système de LOD en paramètres de production concrets se fait grâce à un outil interne que Cube appelle Ronald Reglages. Pour les studios qui n’ont pas d’équivalent, imaginez un fichier de configuration au niveau projet, avec une interface graphique. Il contient la version de Blender, les versions des add-ons, les noms des files de la render farm, les conventions de nommage des caméras, et surtout une section qui définit exactement comment chaque type d’asset doit être importé à chaque étape de la chaîne de production et à quel niveau de détail.
Pour le layout, Ronald Reglages indique au système d’importer les décors au niveau objet pour le set dressing, les personnages et accessoires avec un rig basique, mais les caméras avec un rig complet, car les mouvements de caméra doivent être finalisés à ce stade. Pour le rendu, les décors arrivent en références afin de garder les tailles de fichiers sous contrôle, tandis que les personnages et accessoires arrivent au niveau objet pour que des modificateurs comme la subdivision puissent toujours être appliqués.
« Tout cela est ajustable selon le projet et selon l’étape », a précisé Axel. Il a pris l’exemple d’un futur projet de voiture de course Xilam, où le layout exigera probablement des rigs complets dès le départ, car placer les personnages dans des poses par défaut à l’intérieur des véhicules pourrait dérouter les clients qui évaluent le travail.
Des overrides non destructifs au niveau du shot
L’une des fonctionnalités les plus puissantes, Axel l’a décrite comme la capacité de remplacer les réglages de LOD par shot (ou en batch), sans perdre le travail.
Lors de la transition entre le layout et l’animation, les artistes peuvent mettre à niveau en batch tous les rigs vers un niveau de définition supérieur. Dans un shot donné, le gestionnaire d’assets liste chaque asset avec son LOD actuel et permet aux artistes de mettre à niveau ou de rétrograder des éléments individuels. Si un palmier au premier plan nécessite un niveau de modélisation légèrement plus élevé pour valider le cadrage, un artiste peut mettre à niveau cet élément seul tout en laissant le reste avec le réglage plus léger du layout.
La fonctionnalité clé, c’est que ce processus est non destructif. Lorsque le niveau de rig d’un asset change, le système enregistre les données d’action d’animation et les informations de contrainte, puis les réapplique à la nouvelle version de rig. Pour que cela fonctionne proprement, les noms des os doivent correspondre entre les versions de rig, et une rétrogradation implique forcément une perte de données, mais le système conserve autant que possible.
Où les Geometry Nodes prennent la suite
Dans Piggy Builder, la série la plus récemment terminée de Cube, ils ont commencé à évoluer vers une approche plus procédurale grâce aux Geometry Nodes de Blender.
Au lieu de maintenir des fichiers Blender séparés pour chaque LOD, Cube a consolidé tous les niveaux dans un seul fichier de scène maître. Les fichiers séparés existent toujours sur le disque et sont importés dans cette scène maître, mais à partir de là, les Geometry Nodes peuvent assembler procéduralement des décors en appliquant différents intervalles de LOD à différents assets selon leur distance à la caméra ou leur rôle dans l’action. Un micro-rig ajouté au niveau du shot peut redéfinir dynamiquement le comportement des Geometry Nodes, en déplaçant des éléments selon ce dont la scène a besoin.
Le compromis, c’est la mémoire. Comme toutes les représentations se chargent simultanément, l’utilisation de la RAM augmente de façon notable et les temps d’ouverture de scène deviennent plus longs : « Le coût en RAM était réel, mais ça valait le coup par rapport à la facilité d’utilisation pour les artistes. Ils pouvaient vraiment s’amuser et créer des décors authentiquement magnifiques. »
L’objectif est d’intégrer correctement cette approche à tous les futurs pipelines de décors.
À retenir pour le studio
Axel a conclu sa présentation en distillant l’ensemble du système en trois principes :
- Le premier, c’est d’avoir une source de vérité unique et claire. Pour Cube, c’est Kitsu. L’état de chaque asset, l’état de chaque shot et chaque décision de production vivent là. Les artistes n’ont pas besoin de deviner où se trouve “quelque chose”.
- Le deuxième, c’est de construire des assets qui s’adaptent aux besoins de la production. Le système de LOD n’existe pas comme un simple “plus technique”, mais parce que le layout, l’animation et le rendu exigent réellement des choses différentes. Intégrer cette flexibilité dès le départ évite les ralentissements à chaque étape.
- Le troisième, c’est de considérer la chaîne de production comme un investissement vivant. Chaque production chez Cube ajoute quelque chose à l’infrastructure partagée. Le travail réalisé sur Tangranimo a rendu Pfffirates plus facile. Le travail réalisé sur Pfffirates a rendu 7 Bears plus gérable. Les studios qui abordent chaque projet comme un nouveau départ renoncent à cette valeur cumulative en totalité.
Pour les studios d’animation qui s’orientent vers des pratiques de production plus professionnelles, l’expérience de Cube apporte un argument clair : les outils comptent moins que la philosophie qui les sous-tend. Kitsu ne rend pas à lui seul une chaîne de production stable. Ce qui rend une chaîne stable, c’est la discipline de définir des états clairs pour chaque asset, de communiquer ces états de manière cohérente, et de concevoir des workflows qui répondent aux besoins de production à chaque étape, plutôt que de forcer chaque étape à utiliser la même définition de “terminé”. C’est précisément là que Kitsu aide énormément, grâce à son architecture flexible et à son caractère open-source.
