Rendu de scènes Maya utilisant USD sur une render farm

Universal Scene Description est passé d'un format interne de Pixar à l'épine dorsale de nombreux pipelines Maya. Si votre studio compose des plans à partir de stages USD en couches, référence des assets publiés entre départements et transmet le résultat au moteur de rendu via un procedural, vous savez déjà qu'USD n'est plus une expérience secondaire — c'est la colonne vertébrale de la scène. Ce qui est moins évident jusqu'à ce qu'une échéance approche, c'est qu'une scène qui se rend parfaitement sur une station de travail ne garantit pas un rendu correct sur la render farm de quelqu'un d'autre. La render farm doit disposer du bon build MayaUSD, de la bonne prise en charge USD du moteur de rendu, et d'un moyen de résoudre chaque chemin d'asset vers lequel le stage pointe. Lorsque l'un de ces éléments est absent, vous n'obtenez pas d'erreur claire — vous obtenez des frames échouées, des fallbacks silencieux ou de la géométrie qui n'est tout simplement pas là.

Nous exploitons une render farm gérée, et les jobs Maya avec USD font partie des workflows que nous voyons les studios peiner à déplacer de leurs stations de travail. Ce guide explique pourquoi USD est plus difficile à rendre à distance qu'un fichier .ma autonome, ce qui doit réellement s'aligner pour que cela fonctionne, et comment nous le gérons de notre côté — y compris les parties faciles à rater.

Pipeline de rendu Maya USD : stages USD en couches vers le plugin MayaUSD vers l'Arnold USD procedural vers les frames rendues, avec résolution des assets et correspondance d'environnement.

Pourquoi USD est plus difficile à rendre à distance qu'une scène autonome

Une scène Maya traditionnelle est en grande partie auto-descriptive : ouvrez-la, les meshes et les matériaux sont là, pointez le moteur de rendu dessus, et les frames sortent. Une scène pilotée par USD ressemble davantage à une recette qu'à un plat fini. Les fichiers .usd, .usda ou .usdc constituent un ensemble d'instructions en couches — sous-couches, références, payloads et variantes — qui se composent en un stage final au chargement. Cette composition est puissante, mais elle signifie que trois éléments distincts doivent tous être présents et compatibles sur la machine qui effectue le rendu.

Le premier est le plugin MayaUSD lui-même. MayaUSD est le pont qui permet à Maya de lire, composer et transmettre des stages USD au rendu. Si le Maya de la render farm ne dispose pas de MayaUSD chargé, ou possède une version qui compose le stage différemment de celle avec laquelle vos artistes ont créé, la scène échoue à s'ouvrir ou s'ouvre avec les parties manquantes qui provenaient d'USD.

Le deuxième est la résolution des chemins d'assets. Un stage USD référence d'autres fichiers — géométrie, textures, couches USD imbriquées — par chemin. Sur votre station de travail, ces chemins se résolvent parce que les données se trouvent là où le stage les attend. Sur une render farm, à moins que la même structure de répertoires et le même comportement du résolveur ne soient reproduits, la moitié de ces références ne mènent à rien. C'est la raison la plus courante pour laquelle une scène USD qui « fonctionne chez soi » revient vide d'une render farm : les pixels se sont rendus correctement, les références n'ont tout simplement pas été trouvées.

Le troisième est la prise en charge USD du moteur de rendu. Le moteur de rendu doit comprendre les données USD que Maya lui transmet. Pour Arnold, ce chemin passe par l'Arnold USD procedural, qui lit le contenu USD au moment du rendu plutôt que d'étendre l'ensemble du stage dans Maya au préalable. Si le procedural n'est pas installé, ou si sa version ne correspond pas aux données, le moteur de rendu ignore ce qu'il ne peut pas lire — silencieusement.

C'est aussi là qu'apparaît la lacune bien connue dans certains services de rendu cloud. Le propre tracker de Deadline Cloud d'AWS pour Maya comporte un problème ouvert (aws-deadline/deadline-cloud-for-maya#409) couvrant la prise en charge de MayaUSD dans leur outil de soumission, ce qui est exactement le type de plomberie qui doit être résolu de bout en bout avant que les scènes USD se rendent de manière fiable. C'est une bonne illustration du problème : le rendu USD n'est pas une fonctionnalité que l'on active, c'est une chaîne de versions et de chemins qui doivent tous s'accorder.

Un stage USD en couches dans l'éditeur de couches USD de Maya — sous-couches et références visibles — à côté de la sortie Arnold RenderView.

Comment nous rendons Maya + USD sur notre render farm

Notre approche commence avant qu'une seule frame ne soit mise en file : nous adaptons l'environnement à votre scène plutôt que de demander à votre scène de s'adapter à une image de render farm fixe. Lorsqu'un studio nous envoie un job Maya basé sur USD, nous confirmons la version de Maya, le build MayaUSD, le moteur de rendu et la version USD dans laquelle les assets ont été créés, puis nous configurons les nœuds pour correspondre. L'objectif est que le stage se compose sur nos nœuds exactement comme il se compose sur les machines de vos artistes — même comportement du plugin, même résolution, même procedural.

Du côté du rendu, les deux éléments qui comptent le plus pour Maya USD avec Arnold doivent tous deux s'initialiser correctement : MayaUSD pour composer le stage dans Maya, et l'Arnold USD procedural pour lire le contenu USD au moment du rendu. Nous avons rendu des jobs Maya de production où les deux se chargent et s'exécutent correctement sur l'ensemble du pool de nœuds, ce qui est le test pratique qui compte — non pas « la render farm prétend-elle prendre en charge USD » mais « ce stage, avec ces références, produit-il les frames que l'artiste attend ». Arnold fonctionne ici sur nos nœuds CPU, ce qui convient à la façon dont de nombreux studios utilisent Arnold pour le travail USD en qualité finale ; les mêmes scènes peuvent également s'exécuter sur GPU si le projet le requiert.

Un détail à mentionner, car il pose souvent problème : les scènes USD qui ont traversé plusieurs pipelines portent souvent des références de plugins résiduelles et des attributs de nœuds parasites issus de moteurs de rendu que le projet n'utilise plus. Nous voyons des scènes qui demandent encore un plugin abandonné par le studio il y a des mois, ou qui portent des attributs d'un moteur qui ne fait pas partie du chemin de rendu final. Sur nos nœuds, ces éléments résiduels sont inoffensifs — Maya les dépasse directement et rend avec le moteur que vous utilisez réellement. Si vous voulez des logs propres, vous pouvez supprimer les demandes de plugins inconnus et les nœuds résiduels dans Maya avant l'envoi, mais c'est cosmétique ; ce n'est pas ce qui bloque un rendu. Savoir distinguer « résidu inoffensif » de « ce qui échoue réellement » constitue la majeure partie de ce qui fait qu'un rendu USD se passe bien.

Une contrainte honnête pour définir les attentes concernant le matériel : nos nœuds GPU sont construits sur des cartes RTX 5090 avec 32 Go de mémoire par GPU, et cette mémoire est par carte — elle n'est pas mise en commun entre les deux cartes d'une machine. Pour le travail Arnold-USD sur CPU que la plupart des studios nous apportent, ce plafond est rarement atteint, mais si vous utilisez un chemin GPU sur des scènes avec des textures très volumineuses ou des volumes denses, il vaut la peine de vérifier l'empreinte mémoire par GPU à l'avance. Nous préférons qualifier cela avec vous avant un job plutôt qu'une frame échoue à tenir en mémoire en cours d'exécution.

Rendez depuis votre filespace existant, sans re-téléchargement

Le problème de résolution des assets décrit précédemment a une solution propre lorsqu'un studio conserve déjà son projet sur un filespace monté. Si vos assets se trouvent sur LucidLink, nous pouvons monter ce même filespace sur les nœuds de rendu, de sorte que le stage USD résolve ses références par rapport aux données exactes que voient vos artistes — pas de re-téléchargement d'une bibliothèque d'assets de plusieurs gigaoctets, et pas de reconstruction manuelle de la structure de répertoires. Le stage se compose par rapport aux chemins réels parce que les chemins réels sont montés.

Cela importe davantage pour USD que pour une scène à fichier unique packagé précisément parce qu'USD s'appuie sur ces références externes. Le montage de la source de vérité élimine toute une catégorie de défaillances « référence introuvable », car il n'y a rien à copier incorrectement — la render farm lit le même arbre que le studio. Pour les équipes déjà native LucidLink, cela tend à faire la différence entre un cycle laborieux d'upload-et-priez et un rendu qui se résout simplement.

Un filespace LucidLink de studio monté en direct sur les nœuds de rendu, qui lisent les assets en place — sans re-téléchargement.

Ce qui est inclus — licences et DCC, pas seulement des machines

Lorsque vous louez une capacité dédiée chez nous, les licences de moteur de rendu et les applications DCC sont comprises. Maya, le moteur de rendu — Arnold, V-Ray, Redshift, Octane, Cycles — et les plugins associés font partie de ce que nous approvisionnons, plutôt que quelque chose que vous apportez et licenciez par nœud vous-même. Pour un job USD, cela signifie généralement que la licence Arnold est gérée de notre côté dans le cadre de l'exécution, de sorte que vous n'avez pas à vous procurer séparément des licences de rendu pour chaque nœud du bloc.

Cela vaut la peine d'être mis en balance avec une approche bare-metal ou « construire le vôtre », où le tarif par machine peut paraître moins élevé jusqu'à ce que vous ajoutiez les licences de moteur de rendu par-dessus — celles-ci coûtent de quelques centaines à bien plus d'un millier de dollars par nœud, par an, par moteur sur un hôte en apport-propre. Les regrouper fait le travail silencieux : la scène qui se rend est celle où Maya, MayaUSD, le procedural et la licence du moteur sont tous présents en même temps, et les approvisionner ensemble est la façon de maintenir cette chaîne intacte.

Une migration concrète : USD sur Maya, loin d'un planificateur cloud qui ne pouvait pas le faire tourner

Pour concrétiser : nous avons récemment travaillé avec un studio d'effets visuels britannique qui est venu nous voir parce que sa configuration de planificateur cloud existante échouait sur exactement ce problème — Maya ne parvenait pas à travailler avec ses assets USD dans cet environnement. Son pipeline était Maya avec Arnold, sur un filespace LucidLink. Nous avons monté leur filespace sur les nœuds, adapté l'environnement à leur scène, et confirmé dans les logs que MayaUSD et l'Arnold USD procedural s'initialisaient et se rendaient correctement sur les machines. La scène portait quelques références résiduelles d'une période antérieure de sa vie ; celles-ci ont été dépassées directement, et les frames sont sorties. Le studio est passé de « nos rendus USD continuent d'échouer » à une exécution propre, et a étendu son utilisation à partir de là. Nous gardons le studio anonyme, mais le workflow — Maya, USD, Arnold, LucidLink — est de plus en plus la norme plutôt que l'exception.

Une liste de contrôle de préparation avant d'envoyer un job USD à une render farm

Que vous rendiez avec nous ou ailleurs, voici les points à confirmer à l'avance pour qu'une scène USD ne vous réserve pas de surprises sur une render farm :

La plupart des rendus USD échoués remontent à l'une des trois premières lignes. La raison pour laquelle nous les parcourons avant un job plutôt qu'après est qu'avec USD, la différence entre une exécution propre et une frame vide est généralement une seule version incorrecte ou un chemin non résolu — et il est bien moins coûteux de l'identifier sur une frame de test que sur la frame 480 d'une échéance.

C'est précisément pour cette raison que la façon dont nous démarrons généralement un engagement Maya USD est avec une frame représentative : nous en exécutons une avant le bloc complet afin que le studio puisse voir le stage se composer et les frames arriver sur nos nœuds, et confirmer le pipeline de bout en bout, avant tout engagement plus important. Avec USD, prouver la chaîne sur une frame vaut plus qu'une liste de fonctionnalités.

Si vous souhaitez avoir une vue d'ensemble du fonctionnement du rendu Maya sur une render farm au-delà d'USD spécifiquement, notre guide de rendu Maya dans le cloud couvre le workflow général, et notre aperçu du choix d'une render farm pour Maya couvre la façon d'en évaluer une. La location de nœuds dédiés sur lesquels ce travail USD s'exécute est décrite sur notre page de location de render farm. Pour le format lui-même, la documentation OpenUSD de Pixar est la référence canonique sur la façon dont les stages se composent.

FAQ

Q: Votre render farm prend-elle en charge les scènes Maya utilisant USD ? A: Oui. Nous rendons des jobs Maya utilisant USD en faisant correspondre le build MayaUSD et la prise en charge USD du moteur de rendu à votre scène. Dans les exécutions de production, nous avons confirmé dans les logs que MayaUSD et l'Arnold USD procedural s'initialisent et se rendent correctement sur l'ensemble du pool de nœuds. L'essentiel est que le même build MayaUSD, la même version USD et les mêmes chemins d'assets utilisés par vos artistes soient reproduits du côté du rendu.

Q: Quelles versions de Maya et USD prenez-vous en charge ? A: Plutôt que de vous contraindre à une image fixe, nous faisons correspondre la version de Maya, le build MayaUSD et la version USD dans laquelle vos assets ont été créés. La composition USD est sensible aux différences de version dans la façon dont les couches, les références et les variantes se résolvent ; faire correspondre l'environnement de création est ce qui permet au stage de se composer de la même façon que sur vos stations de travail.

Q: Prenez-vous en charge l'Arnold USD procedural ? A: Oui — pour Maya avec Arnold, l'Arnold USD procedural est le chemin qui lit le contenu USD au moment du rendu, et nous le fournissons avec Arnold. Il doit être présent et compatible en version avec vos données, sinon le moteur de rendu ignore ce qu'il ne peut pas lire. Nous confirmons qu'il s'initialise avant d'exécuter un bloc complet.

Q: Dois-je apporter ma propre licence Arnold ? A: Non. Les licences de moteur de rendu, y compris Arnold, font partie de la capacité dédiée que nous approvisionnons — elles sont incluses plutôt que quelque chose que vous licenciez par nœud vous-même. Avec une configuration en apport-propre, vous ajouteriez ces licences par-dessus le coût de la machine ; les regrouper fait partie de la façon dont nous maintenons la chaîne de rendu intacte.

Q: Pouvez-vous monter notre filespace LucidLink pour que nous n'ayons pas à re-télécharger les assets ? A: Oui. Si votre projet se trouve sur LucidLink, nous pouvons monter ce filespace sur les nœuds de rendu afin que le stage USD résolve ses références par rapport aux données exactes que voient vos artistes. Pour USD en particulier, cela élimine un mode de défaillance courant, car la render farm lit le même arbre d'assets que vous plutôt qu'une copie qui pourrait être structurée différemment.

Q: Nous utilisons un planificateur cloud qui ne peut pas faire tourner nos scènes Maya USD. Pouvons-nous migrer ? A: C'est une raison courante pour laquelle les studios nous rejoignent. Nous adaptons l'environnement à votre scène, montons votre filespace si vous en utilisez un, et vérifions sur une frame représentative que le stage USD se compose et se rend avant de s'engager dans une exécution complète. La migration consiste principalement à reproduire fidèlement votre environnement de création du côté du rendu.

Q: Notre scène contient des références résiduelles d'un moteur de rendu que nous n'utilisons plus — est-ce un problème ? A: Généralement non. Les scènes USD qui ont traversé plusieurs pipelines portent souvent des demandes de plugins parasites et des attributs de nœuds résiduels. Sur nos nœuds, Maya les dépasse directement et rend avec le moteur que vous utilisez réellement. Vous pouvez les supprimer dans Maya pour des logs propres, mais c'est cosmétique — les éléments résiduels sont rarement ce qui bloque un rendu.

Q: Devrions-nous rendre Maya USD sur CPU ou GPU ? A: Les deux sont disponibles, et la bonne réponse dépend de votre moteur de rendu et de votre scène. De nombreux studios utilisent Arnold pour le travail USD en qualité finale sur CPU, pour lequel nos nœuds CPU sont conçus. Le GPU est disponible lorsque le projet le requiert — notez simplement que nos cartes GPU disposent chacune de 32 Go de mémoire, non mise en commun, donc pour les scènes GPU très lourdes, il vaut la peine de vérifier l'empreinte mémoire par GPU au préalable.