Corriger les erreurs XGen et .tx sur une render farm Maya

Introduction

Une scène qui s'affiche parfaitement sur un poste de travail et revient fausse depuis une render farm est l'une des pannes les plus déroutantes d'un pipeline Maya : rien dans le journal ne pointe vers « vous », et rien dans le fichier de scène lui-même n'est cassé. Deux des coupables les plus courants sont XGen et les caches de textures .tx. Tous deux fonctionnent, par conception, en dehors du fichier de scène principal : XGen stocke les données de groom et de description dans des dossiers collections et archives séparés, et le plugin MtoA d'Arnold peut générer silencieusement son propre cache de textures .tx tuilées à côté de vos textures source. Aucun des deux problèmes n'apparaît quand vous ouvrez le fichier .ma ou .mb en local, car localement, ces fichiers externes se trouvent déjà là où Maya les attend.

Nous observons ce schéma assez souvent sur des projets Maya freelance et petits studios pour qu'il mérite d'être documenté correctement : les cheveux ou la fourrure qui « disparaissent » sur un rendu en render farm, et la texture qui déclenche une erreur OpenImageIO inexpliquée en plein milieu d'une frame, ne sont presque jamais des bugs logiciels. Ce sont des problèmes de collecte d'assets et de caches obsolètes, et les deux sont évitables avec un court passage de préflight avant l'envoi.

Diagramme montrant les données de groom et de cache correctement résolues sur un poste de travail local mais absentes sur un nœud de render farm, provoquant la disparition des cheveux ou de la fourrure dans le rendu.

Pourquoi XGen casse sur une render farm (même quand la scène « a l'air » correcte)

XGen ne stocke pas un groom ou une description sous forme de géométrie intégrée au fichier .ma/.mb. Il la stocke sous forme de référence : un fichier palette .xgen, plus, selon la configuration de la description, un dossier collections (données de groom par description) et un dossier archives (point-cache ou données Alembic figées si la description est réglée pour rendre depuis une archive plutôt que générer en direct). Quand vous ouvrez la scène en local, Maya résout ces références par rapport à des chemins qui existent déjà sur votre machine ou votre partage réseau local. Quand la même scène arrive sur un nœud de render farm, ces mêmes chemins n'existent souvent pas - parce qu'ils étaient absolus, parce qu'ils pointaient vers un partage UNC auquel le nœud de la farm n'est pas mappé, ou parce que seul le fichier .ma/.mb a été envoyé et que le dossier xgen/ qui l'accompagne n'a jamais fait le trajet.

Le résultat est rarement une erreur franche. XGen échoue généralement à résoudre la description en silence, et le rendu se termine - simplement sans les cheveux, la fourrure ou les plumes qui auraient dû être présents. C'est ce mode de défaillance précis qui rend le débogage frustrant : tout le reste de l'image se rend correctement, les lecteurs sont signalés comme mappés, et la version de Maya et de XGen sur la farm correspond exactement à celle du poste de travail - le groom a simplement disparu, parce que les fichiers qui le génèrent ne sont jamais arrivés.

Une seconde cause, liée à la première : même quand le dossier xgen/ est collecté, le réglage « générer au moment du rendu » par rapport à « en cache/archivé » de la description a son importance. Si une description est réglée pour lire depuis une archive et que ce chemin d'archive est relatif à une structure de projet que le nœud de la farm ne partage pas, la description ne résout rien du tout, au lieu de revenir à un groom généré en direct.

Panneau générique de type éditeur de description mettant en évidence les champs de chemin collection et archive, illustrant où résident les références de données de groom XGen en dehors du fichier de scène principal.

Pourquoi les fichiers de texture .tx cassent sur une render farm

.tx est un format de texture tuilée et mipmappée produit par l'outil maketx d'OpenImageIO. Arnold lit les textures .tx plus rapidement et avec une empreinte mémoire plus faible que les formats source bruts, ce qui explique pourquoi MtoA (le plugin Maya d'Arnold) propose l'option « Auto-Convert Textures to TX Files » - à l'enregistrement ou au rendu, il génère silencieusement un cache .tx à côté de vos textures source.

Ce comportement d'auto-conversion est pratique sur un poste de travail unique avec un seul disque local et une seule version cohérente d'OpenImageIO. C'est un comportement beaucoup moins fiable sur une render farm distribuée, pour trois raisons distinctes :

Cache obsolète. Si une texture source est modifiée après la génération du fichier .tx, et que la vérification d'horodatage censée déclencher une reconversion ne se déclenche pas (ou que l'emplacement accessible en écriture dont le nœud de la farm a besoin n'est pas le même que celui où le fichier a été généré), Arnold peut charger un fichier .tx obsolète sans aucun avertissement.
Incompatibilité de version. Les versions de maketx/OpenImageIO diffèrent selon les versions d'Arnold et de MtoA. Un cache .tx généré par une version d'OIIO peut produire des erreurs de lecture - se manifestant généralement par une erreur OIIO non spécifiée qui interrompt la frame - lorsqu'il est relu par une version différente côté farm.
Conflit d'écriture sur des chemins partagés ou en lecture seule. L'auto-conversion suppose qu'elle peut écrire un fichier .tx à côté de la texture source. Sur une render farm, cet emplacement peut être en lecture seule, partagé entre plusieurs jobs concurrents, ou tout simplement ne pas correspondre au chemin physique utilisé par le poste de travail, si bien que la conversion échoue soit silencieusement, soit deux nœuds se disputent l'écriture du même fichier de cache.

Ce cas est suffisamment fréquent pour que la documentation des render farms dans toute l'industrie - pas seulement la nôtre - recommande systématiquement aux utilisateurs Maya/Arnold de désactiver « Auto-Convert Textures to TX Files » précisément pour l'éviter, plutôt que d'essayer de corriger le comportement d'auto-conversion lui-même. Le schéma le plus fiable consiste à faire un choix délibéré : soit pré-convertir les textures en .tx avec une version maketx connue et figée, puis livrer ces fichiers .tx avec la collecte d'assets, soit désactiver totalement l'auto-conversion, envoyer les textures source brutes et laisser le moteur de rendu de la farm gérer la conversion de façon cohérente de son côté.

Diagramme de pipeline montrant une texture source convertie par maketx en cache .tx, avec une seconde branche montrant un cache obsolète ou incompatible en version menant à une erreur de lecture de texture.

Ce que l'archivage de scène de Maya ne collecte pas pour vous

L'archivage de scène intégré à Maya (Send To / archive project) est construit autour du modèle de référence standard : textures fichier connectées via les propres nœuds file de Maya, et géométrie qui vit dans le graphe de scène. XGen ne correspond pas totalement à ce modèle, ce qui explique pourquoi ses données sont l'un des éléments les plus souvent oubliés dans une collecte d'assets par ailleurs « complète ». Avant de soumettre une scène XGen à une render farm, prévoyez d'empaqueter explicitement :

Le fichier palette .xgen lui-même
Le dossier xgen/collections/<description>/ pour chaque description référencée dans la scène
Le dossier xgen/archives/, si une description est réglée pour rendre depuis une archive figée
Toute courbe guide externe, carte de densité ou carte de longueur qu'un modificateur XGen référence en dehors des nœuds file-texture standard de Maya - ces éléments contournent parfois les outils d'archivage qui capturent les textures classiques
La version exacte de Maya et de MtoA (Arnold pour Maya) dans laquelle la scène a été créée, afin que la render farm charge la description avec une version de plugin correspondante plutôt qu'une version proche mais différente

Rien de tout cela n'exige de logiciel particulier - cela exige de traiter les données XGen comme une partie à part entière de la collecte d'assets, et non comme un effet secondaire implicite de l'enregistrement de la scène.

Checklist de préflight Maya + Arnold pour les jobs XGen et .tx

Étape	Ce qu'il faut vérifier	Pourquoi c'est important
1. Correspondance des versions	Vérifiez que la plage de versions Maya et Arnold/MtoA prise en charge par la render farm couvre exactement la version de votre scène	Une incompatibilité de version peut casser la compatibilité de la description XGen même quand les chemins de fichiers sont corrects
2. Collecter les dossiers XGen	Empaquetez explicitement `xgen/collections/`, `xgen/archives/` et le fichier `.xgen` - ne vous fiez pas uniquement à un outil d'archivage de scène générique	Ce sont les fichiers le plus souvent oubliés, provoquant la disparition silencieuse des cheveux/de la fourrure
3. Vérifier le réglage génération vs archive	Vérifiez si chaque description génère en direct ou lit depuis une archive figée, et que le chemin d'archive accompagne bien le job	Un chemin d'archive qui ne se résout pas ne rend rien, sans aucune erreur
4. Choisir une seule stratégie de texture	Désactivez « Auto-Convert Textures to TX Files » et envoyez les textures brutes, ou pré-convertissez avec une version `maketx` figée et incluez les fichiers `.tx`	Laisser l'auto-conversion activée suppose un accès en écriture côté farm et une version OIIO correspondante - des hypothèses qui ne tiennent pas toujours
5. Re-router les références UNC et lettres de lecteur	Remplacez tout chemin `\\server\share\...` ou lettre de lecteur local dans les nœuds XGen et texture par des chemins relatifs accessibles depuis la farm	Les chemins qui se résolvent en local n'existent souvent pas sur un nœud de rendu
6. Lancer un test d'une frame	Soumettez une seule frame de test avant la séquence complète, et vérifiez le journal de rendu spécifiquement pour les avertissements de chargement de texture et de résolution XGen, pas seulement l'achèvement du rendu	Permet de détecter les cheveux manquants, les textures manquantes et les erreurs OIIO avant qu'elles ne coûtent une séquence complète
7. Décider CPU ou GPU pour le plan	Pour les grooms XGen lourds, une couverture dense de cheveux/fourrure et des réseaux de shading personnalisés, prévoyez le chemin de rendu CPU d'Arnold pour les frames finales - les scènes lourdes en procédural et en shaders personnalisés sont la catégorie de travail pour laquelle les recommandations d'Arnold pointent elles-mêmes vers le CPU en rendu final	Décider du routage CPU/GPU avant l'envoi évite de découvrir une contrainte matérielle en plein rendu

Problèmes courants et solutions

Symptôme	Cause probable	Solution
Cheveux ou fourrure absents du rendu sur la farm, présents en local	Dossier XGen `collections`/`archives` non collecté, ou chemin non accessible depuis la farm	Empaquetez explicitement les dossiers XGen et re-routez toute référence UNC/lettre de lecteur
Le rendu s'interrompt avec une erreur OpenImageIO non spécifiée en plein milieu d'une frame	Cache `.tx` obsolète ou incompatible en version	Régénérez le `.tx` avec une version `maketx` figée, ou désactivez l'auto-conversion et envoyez les textures brutes
La texture ou le bitmap ne se résout pas sur le nœud de rendu (également observé dans les pipelines Arnold sous 3ds Max, une catégorie de défaillance liée mais distincte - voir notre guide sur les bitmaps manquants Arnold dans 3ds Max)	Chemin de texture non résolvable depuis le nœud de rendu	Vérifiez que les chemins sont relatifs et accessibles depuis la farm avant l'envoi
Le job se rend correctement lors d'un nouvel envoi mais échouait la première fois	L'auto-conversion a écrit le cache `.tx` en cours de rendu lors de la première passe ; la seconde passe a lu le cache désormais complet	Pré-convertissez les fichiers `.tx` avant l'envoi, ou désactivez totalement l'auto-conversion
Erreurs de chargement du plugin Arnold ou MtoA	La version de MtoA sur la farm ne correspond pas à la version dans laquelle la scène a été créée	Vérifiez la plage de versions Maya/Arnold cible avant l'envoi

Maquette de console de journal de rendu montrant une erreur de lecture de texture au niveau avertissement, illustrant le type de message que produit un cache .tx obsolète ou incompatible sur un nœud de rendu.

Checklist récapitulative

Versions de Maya et Arnold/MtoA vérifiées par rapport à la plage prise en charge par la render farm
xgen/collections/ et xgen/archives/ explicitement inclus dans la collecte d'assets
Le réglage génération vs archive de chaque description XGen vérifié, et son chemin confirmé comme accessible depuis la farm
Une seule stratégie de texture choisie : .tx pré-converti (version maketx figée) ou textures brutes avec auto-conversion désactivée - pas les deux
Tous les chemins UNC et lettres de lecteur remplacés par des chemins relatifs accessibles depuis la farm
Une frame de test envoyée et son journal de rendu vérifié pour les avertissements XGen et texture avant la séquence complète
Chemin de rendu CPU vs GPU décidé pour les plans lourds en XGen ou en shaders personnalisés

Sur notre farm, les versions récentes de Maya (2022 et ultérieures) passent automatiquement la correspondance de version à l'envoi ; les versions plus anciennes, dans la plage prise en charge 2014-2027, sont routées via une vérification de provisioning et de compatibilité avant le début du rendu, de sorte qu'une incompatibilité est détectée avant de consommer des frames plutôt qu'en plein job. Les éléments liés aux chemins, aux caches et aux réglages d'archive restent propres à chaque scène et méritent d'être vérifiés quelle que soit la farm de destination du job.

Pour une configuration générale du rendu cloud Maya au-delà de XGen et des textures spécifiquement, consultez notre guide du rendu cloud Maya et notre guide complet du moteur de rendu Arnold. Pour les plages de support logiciel derrière la correspondance de version de la farm, consultez nos pages Maya render farm et Arnold render farm. Côté texture, la documentation maketx d'OpenImageIO elle-même est la référence technique la plus claire sur ce que fait réellement la conversion .tx et quels indicateurs contrôlent le comportement de mipmap et de tuilage.

FAQ

Q: Pourquoi les cheveux ou la fourrure XGen disparaissent-ils quand je rends sur une render farm cloud, alors que tout fonctionne en local ? A: Cela signifie généralement que les dossiers collections et archives de XGen n'ont pas été collectés avec le reste de la scène. XGen lit les données de groom et de description depuis ces fichiers externes au moment du rendu - si seul le fichier .ma ou .mb est envoyé, le nœud de rendu n'a rien à partir de quoi générer les cheveux ou la fourrure, et il rend une scène chauve au lieu de générer une erreur explicite.

Q: Qu'est-ce qu'un fichier .tx et pourquoi Arnold en a-t-il besoin ? A: Un fichier .tx est une texture tuilée et mipmappée créée par l'outil maketx d'OpenImageIO. Arnold et MtoA utilisent les textures .tx plutôt que les formats source bruts, car les mipmaps tuilés se chargent plus vite et consomment moins de mémoire pendant le rendu, ce qui compte davantage à l'échelle d'une farm que sur un poste de travail unique.

Q: Faut-il laisser « Auto-Convert Textures to TX Files » activé lors de l'envoi vers une render farm ? A: Le laisser activé est une source courante d'erreurs de texture côté farm. Cela fonctionne bien sur un poste de travail unique avec un seul disque, mais sur une farm distribuée, cela peut produire un cache .tx obsolète ou incompatible en version, ou se heurter à une différence de permission d'écriture sur le nœud de rendu. Pré-convertir avec une version maketx connue et livrer les fichiers .tx, ou désactiver l'auto-conversion et envoyer les textures brutes, évite les deux modes de défaillance.

Q: Mes versions de Maya et Arnold correspondent déjà à celles de la farm - pourquoi le rendu manque-t-il quand même de textures ? A: La correspondance de version évite les défaillances au niveau du plugin, mais la plupart des erreurs XGen et .tx sur les farms viennent des chemins de fichiers, pas des versions. Si XGen référence un chemin UNC ou une lettre de lecteur local qui n'existe pas sur le nœud de rendu, ou si le cache .tx a été généré par rapport à un emplacement de texture que la farm ne peut pas atteindre, le rendu échoue même avec des versions logicielles correspondantes.

Q: Comment savoir quelles versions de Maya et Arnold une render farm prend en charge ? A: Vérifiez la plage de versions Maya et Arnold/MtoA prise en charge par la farm avant l'envoi - des versions correspondantes éliminent toute une catégorie d'erreurs de rendu. Notre farm prend en charge Maya 2014-2027 : les versions 2022 et ultérieures passent automatiquement la correspondance de version à l'envoi, et les versions plus anciennes sont routées via une vérification de compatibilité avant le rendu.

Q: Les plans XGen doivent-ils être rendus via le chemin CPU ou GPU d'Arnold ? A: Les plans lourds en XGen, avec une couverture dense de cheveux ou de fourrure et des réseaux de shading personnalisés, relèvent du chemin CPU d'Arnold pour le rendu final - c'est la catégorie de travail pour laquelle les recommandations d'Arnold pointent elles-mêmes vers le CPU. Quel que soit le chemin utilisé pour un plan, prenez la décision matérielle au moment de l'envoi, dans le cadre du préflight, plutôt que de découvrir une contrainte en plein rendu.

Q: Que faut-il vérifier avant de soumettre une scène Maya avec XGen à une render farm ? A: Effectuez un court préflight : vérifiez la correspondance des versions Maya/MtoA, empaquetez explicitement les dossiers xgen/collections et xgen/archives, choisissez une seule stratégie de texture (.tx pré-converti ou brut avec auto-conversion désactivée), re-routez toute référence UNC ou lecteur local, et envoyez une frame de test avant la séquence complète.

Q: Est-ce un problème propre à XGen, ou se retrouve-t-il aussi avec d'autres DCC ? A: Le même schéma sous-jacent - des données qui vivent en dehors du fichier de scène principal, plus des données de texture en cache qui deviennent obsolètes - se retrouve aussi ailleurs. Les utilisateurs de 3ds Max rencontrent un problème lié mais distinct, avec des nœuds bitmap manquants dans Arnold quand les chemins de texture ne se résolvent pas sur le nœud de rendu ; voir notre guide sur les bitmaps manquants Arnold dans 3ds Max pour cette variante du problème.