Présentation Pipeline USD
05/06/2023
C'est avec enthousiasme que je vous présente le pipeline USD que nous avons développé en collaboration avec Raphaël GIMARD.
Ce pipeline a été utilisé avec succès dans nos films de fin d'études à l'ESMA, intitulés "Spurs Out" et "Ratzia". Afin de partager nos connaissances et nos expériences, nous avons créé des documents détaillant ce pipeline, accompagnés de templates et de scripts qui vous donneront une meilleure idée de notre travail.
Nous sommes impatients de partager ces ressources avec vous et d'échanger sur notre expérience.
I am thrilled to present to you the USD pipeline that we have developed in collaboration with Raphaël GIMARD.
This pipeline has been successfully used in our graduation films at ESMA, titled "Spurs Out" and "Ratzia". In order to share our knowledge and experiences, we have created detailed documents outlining this pipeline, along with templates and scripts that will give you a better understanding of our work.
We are excited to share these resources with you and engage in discussions about our experience.
Matéo MARIE
ABSTRACT
Ce document retrace le processus de recherche et de mise en œuvre d’un pipeline USD dans le contexte de la réalisation d’un court-métrage d’animation 3D. Ce pipeline est centré sur le logiciel SOLARIS de SideFX, le dispatcher Tractor et le moteur de rendu Renderman. Il intègre également d’autres logiciels tels que Maya, Substance Painter.
Nous abordons également le fonctionnement de scripts Python que nous avons développés pour fluidifier nos process.
I: INTRODUCTION
Nous sommes ravis de vous présenter le pipeline USD que nous, Raphaël GIMARD et Matéo MARIE, avons mis en place pour nos films de fin d'études à l'ESMA, respectivement intitulés 'Spurs Out' et 'Ratzia', avec l’aide de Philippe LUNEAU et Yann PANNETIER que nous remercions.
Ce document est une occasion pour nous de partager notre expérience et notre approche dans l'utilisation de ce format encore jeune qu’est l’USD (Universale Scene Description), afin d'aider d'autres artistes et techniciens 3D dans leurs projets. Nous souhaitons mettre en lumière les avantages et les possibilités qu'offre l’USD dans le processus de création de films d'animation.
En développant notre propre pipeline USD, adapté aux besoins spécifiques de nos films et de notre équipe, nous avons acquis des compétences techniques précieuses. Nous sommes convaincus que ce partage d'expérience pourra susciter l'intérêt des professionnels du secteur et les inciter à explorer les potentialités de l'utilisation de USD dans leurs propres projets.
Sans plus tarder, plongeons dans les détails de notre pipeline USD, en mettant l'accent sur les fonctionnalités personnalisées que nous avons développées et les bénéfices qu'elles ont apportés à nos films. Nous espérons que cette présentation vous sera utile et enrichissante dans votre propre parcours artistique.
II: NOTRE PIPELINE USD
Nous avons opté pour Maya pour la modélisation, les UVs et le rigging, car il s'agit du logiciel avec lequel nous sommes le plus familiarisés. Par la suite, nous avons exporté nos modèles au format USD.
Pour le lookdev et le set dressing, nous avons opté pour Solaris, qui nous a permis de créer et d'ajuster les matériaux et les décors. Les décors ont été exportés en fichiers USD pour faciliter la collaboration avec les animateurs, qui ont pu les importer dans Maya. Ces fichiers USD ont pu être ouverts dans Maya par les animateurs, en y effectuant des ajustements de set si nécessaires. Les modifications apportées aux décors pouvaient être récupérées grâce aux systèmes de sublayers USD.
Les animations finales ont été exportées en fichiers Alembic et importées dans Solaris pour le lighting et le rendu des plans.
Cette combinaison de Maya, Solaris et de l’USD nous a permis de bénéficier des avantages de chaque outil tout au long de notre pipeline. Dans les sections suivantes, nous détaillerons davantage chaque étape de notre pipeline USD et les fonctionnalités personnalisées que nous avons mises en place.
(Maya 2023, Houdini 19.0, Renderman 24.4, Dispatcher Tractor 2.4)
1: Modeling et UVs Layout
Dans Maya, nous effectuons la modélisation et les UVs avant de les exporter au format USD. Pour mieux comprendre le fonctionnement du format, nous avons choisi d'utiliser l'extension de fichier .usda (en ASCII), ce qui nous permet de visualiser et de manipuler le contenu dans un éditeur de texte. Cela nous a permis de nous familiariser avec la structure du format et d'explorer les différentes propriétés et hiérarchies des objets. (Les formats en ASCII sont lisibles avec un éditeur de texte mais sont donc lourds. Un fichier en format binaire est donc souvent plus pratique car plus léger, si vous n’avez pas la nécessité de lire ou modifier votre fichier)
Lors de l'export, nous nous assurons que l'option 'Output' est configurée avec le 'USD File Format' en mode ASCII. De plus, nous réglons immédiatement la méthode de subdivision sur 'Catmull-Clark' et décochons l'option 'USD Preview Surface' (cette dernière n'étant pas nécessaire provenant de Maya, car il s'agit pour l’instant que d'un matériau Lambert).
Il est important de noter que Maya ne nous permettait pas d'écrire directement les fichiers USD sur le serveur. Par conséquent, nous exportons d'abord le fichier sur notre propre machine, puis nous le copions dans le dossier du projet sur le serveur.
2: LookDev
Pour le LookDev, nous avons développé deux templates.
-
Le premier template est conçu pour un LookDev 'standard' et nous permet de créer des shaders et de les assigner aux modèles.
-
Le second template est basé sur une approche par 'Component', ce qui nous offre la possibilité d'ajouter facilement des variantes de textures et/ou de géométrie. Ce template se révèle particulièrement utile lors du set dressing, car nous pouvons utiliser le node 'Layout' pour placer rapidement et efficacement de nombreux objets.
Dans le template de lookdev 'Standard', nous devons tout d'abord effectuer un “set project”, car certains paramètres dépendent de la valeur de la variable $JOB. Ensuite, nous réduisons l'échelle de l'objet par 100 pour passer de l'échelle utilisée dans Maya (1 unité =1cm) à celle utilisée dans Houdini (1 unité = 1m). Nous créons nos shaders dans le node 'Material Library' et les assignons à notre objet à l'aide du node 'Assign Material'. Enfin, nous exportons l'objet au format USD, ce fichier étant utilisé ultérieurement lors du set dressing. Le reste du template permet d'importer la scène de lookdev afin d'obtenir un éclairage approprié, de faire tourner l'objet sur lui-même et de le replacer si nécessaire.
Pour le template de LookDev en Components, le principe est similaire, mais avec une différence principale : ce template est conçu pour créer des components, c'est-à-dire des éléments optimisés pour être dupliqués avec des variations de formes et de textures, tels que des fruits, des éléments de mobilier ou d'autres objets.
Nous commençons en entrant dans le node 'Component Geometry' où nous importons notre objet. Nous profitons également de cette étape pour créer un proxy, une version au maillage simplifié de l'objet qui ne servira qu'à l'affichage dans les logiciels. Plus tard, lors du set dressing, nous pouvons choisir de visualiser nos objets en haute résolution, en proxy pour économiser des ressources, ou même de les cacher complètement. Ensuite, dans le 'Material Library', nous créons tous nos shaders, y compris les variations (un shader par variant). Pour assigner nos shaders, nous utilisons un node 'Component Material' qui fonctionne comme un 'Assign Material', à la différence que chaque node 'Component Material' correspond à une variante de matériau. Par exemple, si notre objet doit avoir une variante verte et une variante rouge, nous aurons deux nodes 'Component Material'.
Il ne nous reste plus qu'à exporter nos objets à l'aide du node 'Component Output', et nous en profitons pour ajouter notre props à notre 'Layout Asset Gallery'. Ce node crée un dossier ('Location') dans lequel il exporte nos objets sous différents fichiers (géométrie, matériaux, payload) ainsi qu'un fichier de liaison ('File Name'). Une fois que nous avons tout exporté, nous utilisons la fonction 'Add To Asset Gallery' pour retrouver nos objets dans l’Asset Gallery, illustrés par des icônes rendues. Il est important de noter que le 'Layout Asset Gallery' ne stocke pas les objets eux-mêmes, mais seulement les chemins vers les fichiers .usd correspondants.
Pour nos films, nous n'avons pas utilisé de ‘variants’ de géométrie, uniquement des ‘variants’ de matériaux. Mais nous avons tout de même des variations de formes pour nos géométries, que nous avons exportées individuellement. Chaque variations de formes a donc été exportées comme des objets distincts, avec chacun ses ‘variants’ de textures. Cette approche a considérablement augmenté le nombre d'objets dans notre galerie d'assets. Cependant, cette approche nous a permis, lors du set dressing, d'utiliser les collisions et d'empiler nos props les uns sur les autres sans risquer qu'ils flottent entre eux (par exemple, deux objets empilés qui risque de léviter ou se pénétrer si nous modifions la variante de géométrie de la prop située en dessous).
3: Set Dressing
Lors du set dressing, la partie la plus complexe réside dans la compréhension de la hiérarchie et la division de votre set en plusieurs sous-groupes. Par exemple, vous pouvez avoir la cuisine comme parent, avec la table et les chaises comme enfants, et les assiettes et les fourchettes comme enfants de la table.
Il n'y a pas de démarches spécifiques à conclure dans cette étape, car il s'agit principalement d'une question d'organisation en fonction du set lui-même. Il est important de bien comprendre la structure du set et de réfléchir à la manière dont les différents éléments s'emboîtent les uns dans les autres pour créer une hiérarchie claire et logique.
4: Rigging et Animation
Le Rig et l’Animation seront effectués sous Maya. Afin de permettre aux animateurs de travailler dans le bon set dress, nous leur fournissons le set exporté en format USD : depuis Houdini, il suffit de mettre à l'échelle le set x100 (pour re-passer de l’échelle Houdini à l’échelle Maya), puis de l'exporter à l'aide du node ‘USD ROP’. (Il est préférable de sortir le set en format .usd plutôt qu'en .usda, cela permet d'économiser de l'espace disque et du temps de lecture).
Pour importer le set USD dans une scène Maya, il faut se rendre dans le menu "Create" -> "Universal Scene Description (USD)" -> "Stage From File" et importer le fichier USD du set. Pour afficher les objets USD dans l'Outliner, il faut sélectionner "Display" -> "Shapes".
Si les animateurs souhaitaient déplacer des accessoires placés lors du set dressing pour adapter les plans à la démarche artistique, ils pouvaient créer un layer USD qui enregistrait uniquement les modifications. Ces modifications se retrouvaient ensuite utilisées lors de l'étape de lighting.
Voici la procédure que nous avons suivi :
-
Ouvrir le set depuis le serveur.
-
Dans la fenêtre de l'USD Layer Editor, désactiver l'option "Auto-Hide Session Layer".
-
Clic droit sur "Session Layer", puis "Add Sublayer".
-
Activer le nouveau Anonymous Layer créé et déplacer les éléments comme souhaité.
-
Une fois terminé, double-cliquer sur l’Anonymous Layer, lui donner un nom explicite pour indiquer les modifications spécifiques à un plan, puis l'enregistrer (Dans notre cas, nous devons d’abord l’enregistrer sur notre ordinateur, maya n’arrivant pas à écrire de fichier usd directement sur le serveur.
-
Lors de la première sauvegarde de la scène, enregistrez également les fichiers USD. Par la suite, il suffit d'enregistrer uniquement le fichier Maya, rien d'autre.
-
Si vous souhaitez apporter d'autres modifications, assurez-vous de sélectionner le sub-layer que vous avez enregistré sur votre ordinateur, puis cliquez sur l'icône de sauvegarde des modifications USD (vous devrez peut-être recharger votre layer USD de modifications lorsque vous ouvrez une nouvelle session Maya, donc au lieu de choisir "Add Sublayer" sur le Session Layer, choisissez "Load").
(Etant donné que nous devions enregistrer ces fichier USD sur nos ordinateur, les animateurs devaient penser à se partager les fichiers si un autre animateur continuait le shot).
Nous récupérions ce sublayer lorsque nous préparions la scène de lighting, afin de pouvoir récupérer les transformations des objets déplacés.
Etant donné que Solaris et l’USD supportent très bien les alembics, et que l’USD dans Maya n’est pas suffisamment optimisé, nous exportons tous les éléments animés en format .abc (Nous avons réalisé des scripts pour exporter les personnages. Les scripts sélectionnent uniquement les mesh nécessaires et règlent déjà toutes les options d’export des alembics, il n’y a plus qu'à donner le frame range et cliquer sur EXPORT).
5: Groom et Cloth
Dans notre pipeline, nous avons utilisé Houdini pour réaliser le groom. La création du grooming n’a rien eu d’inhérent à l'USD, jusqu’à l’étape d'exportation : pour exporter nos caches de groom, nous les avons enregistrés sous forme de séquences de fichiers .usd. Cela génère un grand nombre de fichiers, mais dans le contexte d’un rendu distribué cela évite d'avoir un seul fichier volumineux et long à charger.
Nous avons exporté les autres simulations avec la même méthode.
6: Lighting
Pour la scène de lighting, nous avons mis en place un template avec des automatisations pour faciliter le processus. Ces automatisations permettent d’importer rapidement tous les fichiers alembic fournis par les animateurs, ainsi que les simulations de vêtements et de grooming spécifiques au plan. De ce fait, nous avons gagné du temps et évité les erreurs lors de l'import. Une fois cette étape terminée, nous pouvons lighter notre shot, et préparer nos render layers à l'aide de la take list. Les render layers principaux sont déjà définis dans nos templates (par exemple : BG, MG, FG, et un pour chaque personnage), ce qui facilite l'exportation vers la scène de rendu en batch.
Après avoir finalisé le lighting et la préparation des render layers, nous retirons les caches de grooming (nous les ré-appliquerons ultérieurement) et nous exportons un fichier USD par render layer en utilisant la fonction "flatten stage". Cela signifie que ces fichiers contiennent toutes les informations nécessaires au rendu et n'ont plus besoin de référencer d'autres fichiers. Cette approche nous a en partie permis de résoudre le problème de batch fantômes rencontré sur la render farm évoqué plus loin.
7: Batch
Pour le template de batch, le principe est le même que le template de lighting: le node ‘Charger_TOUT’ nous permet de rapidement définir le plus gros des attributs de la scène en cherchant tous les fichiers correspondant au shot assujetti. C’est maintenant que nous récupérons définitivement les grooms. Ils sont à ce stade déjà mit en place, nous n’avons qu'à faire glisser le node ‘Graft Stage’ de chacun des groom là où nous en avons besoin (généralement sur le render layer du personnage, mais parfois sur d'autres render layers pour les ombres ou les reflets, afin d'éviter que ces render layers ne contiennent les ombres d'un personnage chauve par exemple). Il nous reste a mettre la bonne caméra et nous pouvons envoyer en batch sur la farm grâce à l’utilitaire ! Cependant nous parlerons de la farm de rendus et de cet utilitaire dans un prochain chapitre.
A noter que nous avons intégré des scripts Python dans nos nodes Hdprman. Bien que ces scripts ne soient pas indispensables, dans notre cas, ils étaient utilisés pour éliminer les husk "fantômes" qui restaient lorsque nos batch se bloquaient à 98%. Lorsque cela se produisait, nous devions effectuer manuellement une opération de "resume" sur chaque job, ce qui relançait uniquement la frame suivante sans éliminer le husk fantômes qui consommait encore 8% du CPU. Ainsi, le script permet d'éviter l'accumulation de ces husk fantômes et de prévenir une occupation excessive du CPU.
III: DEVELOPPEMENT / TRACTOR
1: Utilitaire de batch Solaris
Le rendu Tractor nous a posé de nombreux défis. C'était certainement la partie la plus technique et complexe de la mise en place du pipeline, mais aussi la plus importante. Nous travaillons avec RenderMan 24.4 et sur la version 19.0.589 de Houdini, cette dernière ne nous permet pas d'envoyer directement nos requêtes de batch vers le dispatcher Tractor 2.4 de RenderMan. Nous avions seulement la possibilité limitée d’envoyer les requêtes une image à la fois, de manière manuelle. Par conséquent, nous avons dû développer un outil automatisé.
Cet outil permet de traduire notre scène Houdini, d'identifier les nodes de rendu, puis de générer et envoyer des commandes “hbatch” aux serveurs. Tout cela est optimisé en créant des sous-scènes pour éviter tout conflit d'écriture ou de lecture entre les différentes machines.
À l'origine, notre outil envoyait des commandes "husk" référençant la scène en format .usd. Cependant, nous avons réalisé que ce n'était pas la meilleure solution, car nous ne pouvions pas lancer de plage d'images de manière optimisée. Nous avons donc opté pour des commandes "hbatch", lancées depuis une scène Houdini dédiée dans laquelle les fichiers USD sont référencés. Ces commandes “hbatch” génèrent à chaque fin d'image une nouvelle ligne de commande "husk". Cela réduit une étape significative dans le processus de rendu, ce qui devient alors avantageux.
Pour installer l'utilitaire, vous devez exécuter le fichier "Intall_env_02.bat". Ce script installe toutes les ressources nécessaires au bon fonctionnement de l'utilitaire. Sans cela, l'utilitaire ne fonctionnera pas.
Nous utilisons le gestionnaire de packages Python appelé pip, qui me permet d'installer PyQt5. Cependant, pour le reste de l'utilitaire, vous devez avoir Houdini installé, car j'utilise la bibliothèque hython. Assurez-vous de déclarer le chemin "path=C:\Program Files\Side Effects Software\Houdini 19.0.589\bin" dans vos variables d'environnement pour pouvoir utiliser hython, hbatch et husk. Sans cela, les commandes ne fonctionnent pas non plus.
Dans le script d'installation "Intall_env_02.bat", vous devez modifier les chemins pour qu'ils correspondent à votre environnement Windows. Une fois toutes ces étapes terminées, l'utilitaire devrait fonctionner correctement.
Ci-dessous vous trouverez toutes les explications concernant l’utilisation de l’utilitaire.
Pour ce qui est du code je ne vais pas rentrer dans les détails, mais vous expliquer les modifications à faire dans le code pour qu’il soit utilisable pour votre environnement :
-
Ligne 124 : Vous devrez mettre l'adresse IP de votre serveur Tractor. Cela permettra de savoir si le service Tractor est accessible ou non. Cette étape est facultative pour le fonctionnement du script.
-
Ligne 136 : Remplacez "//XXXXXX/Prod" par l'adresse de votre projet sur votre serveur. Cela évitera les erreurs de chemin et permettra de pointer automatiquement vers l'emplacement correct de votre scène. Encore une fois, cette étape est facultative.
-
Ligne 148 : Cette ligne permet de remplacer "P:/" par "//votre-serveur/". Cela permet de pointer uniquement vers votre serveur plutôt que d'utiliser une lettre de lecteur. Cette étape était très utile dans notre cas, mais est elle aussi facultative.
-
Ligne 151 : Dans ce bloc, vous devez entrer les noms des projets que vous souhaitez lancer dans Tractor. Cette étape se fait automatiquement par la suite en fonction du chemin spécifié.
-
Ligne 163 : Nous récupérons les nodes de rendu Hdprman (RenderMan) et Karma. Vous pouvez ajouter n'importe quel autre node à cette liste.
-
Ligne 252 et 295 : Dans "--user=_3d4", remplacez "_3d4" par votre propre nom. Assurez-vous de ne jamais commencer par un chiffre, sinon une erreur se produira au niveau de l’interprétation du fichier JSON généré.
Pour le reste, il est ouvert à des modifications selon les besoins spécifiques aux productions abordées.
2: Optimisation Tractor
Sur ce constat, nous ne pouvions pas en rester là. Nous avons alors développé les outils suivants pour automatiser la sortie de nos images sur le dispatcher en créant des scripts qui nous permettent d’ouvrir les logs Tractor, de les analyser et de relancer automatiquement certains jobs en fonction des erreurs. Cela nous a évité une majorité de maintenance et nous a fait gagner un temps précieux
Le premier script a pour objectif de détecter les batch encore en cours, mais bloqués et incapables de passer à l'étape suivante en raison de divers problèmes liés à l'ordinateur en cours de rendu. Le script vérifie les logs et identifie les batch bloqués, puis les relance.
Le deuxième script, quant à lui, a pour objectif d'identifier tous les batch "Done" donc terminés. Il les repère et vérifie également les logs afin de détecter toute éventuelle erreur. Si tout est correct, il les archive. Dans le cas contraire, il les relance.
Le dernier permet de relancer automatiquement les batch qui ont été mis en erreur par le dispatcher lui-même.
3: CPU Limiter
CPU LIMITER est une application que nous avons conçue pour limiter l'impact d'un batch sur un ordinateur en cours d'utilisation par un technicien.
Il détecte automatiquement si un batch est en cours d'exécution , notamment les programmes "mayabatch" et "husk".
Selon les préférences ajustées par l'utilisateur lui-même, il réduira ou augmentera automatiquement le nombre de cœurs alloué au batch.
Cette application permet de laisser les calculs s'exécuter tout en permettant de continuer à produire. En outre, CPU LIMITER offre des fonctionnalités telles que le contrôle de votre nimby sur tractor et la possibilité de supprimer automatiquement les batch en cours sur la machine dédiée (kill process), et les prochains batches qui surviendraient.
CPU LIMITER s'éteint et rétabli l'utilisation du processeur à 100% au bout de 30 minutes si aucune activité utilisateur n’est détectée.
IV: CONCLUSION
Ces expériences plurielles de développement de pipeline ont été une recherche passionnante qui nous a poussés à effectuer d'innombrables réflexions prospectives et itérations. Nous nous sommes plongés dans diverses technologies, méthodes et scripts, en cherchant à mieux comprendre le fonctionnement des logiciels et à explorer des domaines qui nous étaient auparavant inconnus.
Malgré les défis auxquels nous avons été confrontés, nous avons réussi à mettre en place un pipeline fonctionnel en tirant parti des ressources à notre disposition. Bien que ces modules présentés nécessite un approfondissement technique, elles ont grandement contribuées au développement de nos savoir-faire.De plus, la réalisation de nos films respectifs s'est vue enrichie par des outils adaptés à la production.
Nous espérons que ce retour d'expérience trouvera son chemin vers des artistes et techniciens 3D dans leurs propres projets, en les poussant à explorer et à innover dans l'utilisation de technologies complexes et émergentes à l'instar de l’USD. Nous sommes fiers du chemin que nous avons parcouru et sommes enthousiastes à l'idée de poursuivre notre évolution dans l’industrie du cinéma d’animation numérique.
