XGen- und .tx-Fehler auf der Maya-render-farm beheben

Einführung

Eine Szene, die auf einer Workstation einwandfrei rendert und von einer render farm falsch zurückkommt, gehört zu den verwirrendsten Fehlern in einer Maya-Pipeline - nichts im Log weist auf „Sie" hin, und an der Szenendatei selbst ist nichts kaputt. Zwei der häufigsten Übeltäter sind XGen und .tx-Textur-Caches. Beide arbeiten konzeptionell außerhalb der Hauptszenendatei: XGen speichert Groom- und Description-Daten in separaten Collection- und Archive-Ordnern, und Arnolds MtoA-Plugin kann stillschweigend einen eigenen gekachelten .tx-Textur-Cache neben Ihren Quelltexturen erzeugen. Keines der beiden Probleme zeigt sich, wenn Sie die .ma- oder .mb-Datei lokal öffnen, denn lokal liegen diese externen Dateien bereits dort, wo Maya sie erwartet.

Dieses Muster sehen wir bei Freelance- und Kleinstudio-Maya-Jobs so häufig, dass es sich lohnt, es sauber festzuhalten: Das Haar oder Fell, das beim Farm-Render „verschwindet", und die Textur, die mitten im Frame einen unerklärten OpenImageIO-Fehler wirft, sind fast nie Softwarefehler. Es sind Probleme der Asset-Sammlung und veralteter Caches, und beide lassen sich mit einem kurzen Preflight-Check vor dem Einreichen vermeiden.

Diagramm, das zeigt, wie Groom- und Cache-Daten auf einer lokalen Workstation korrekt aufgelöst werden, auf einem Rendernode der render farm jedoch fehlen, wodurch Haar oder Fell im Render verschwindet.

Warum XGen auf einer render farm bricht (selbst wenn die Szene „in Ordnung" aussieht)

XGen speichert einen Groom oder eine Description nicht als in die .ma/.mb-Datei eingebackene Geometrie. Es speichert sie als Referenz: eine .xgen-Palettendatei plus, je nachdem, wie die Description konfiguriert ist, einen collections-Ordner (Groom-Daten pro Description) und einen archives-Ordner (gebackene Point-Cache- oder Alembic-Daten, falls die Description so eingestellt ist, dass sie aus einem Archiv rendert statt live zu generieren). Wenn Sie die Szene lokal öffnen, löst Maya diese Referenzen anhand von Pfaden auf, die auf Ihrem Rechner oder Ihrer lokalen Netzwerkfreigabe bereits existieren. Landet dieselbe Szene auf einem Rendernode der render farm, existieren dieselben Pfade oft nicht - weil sie absolut waren, weil sie auf eine UNC-Freigabe verwiesen, der der Farm-Node nicht zugeordnet ist, oder weil nur die .ma/.mb-Datei hochgeladen wurde und der xgen/-Ordner daneben nie mitgereist ist.

Das Ergebnis ist selten ein harter Fehler. XGen löst die Description meist still und leise nicht auf, und das Rendering wird trotzdem fertig - nur ohne das Haar, Fell oder die Federn, die eigentlich da sein sollten. Genau das macht diesen Fehlermodus so frustrierend beim Debuggen: Alles andere im Frame rendert korrekt, Laufwerke werden als zugeordnet gemeldet, und die Maya- und XGen-Version auf der Farm stimmt exakt mit der Workstation überein - der Groom ist einfach weg, weil die Dateien, die ihn erzeugen, nie angekommen sind.

Eine zweite, verwandte Ursache: Selbst wenn der xgen/-Ordner mitgesammelt wird, kommt es auf die Einstellung der Description an - „bei Render-Zeit generieren" versus „gecacht/archiviert". Ist eine Description so eingestellt, dass sie aus einem Archiv zieht, und ist dieser Archivpfad relativ zu einer Projektstruktur, die der Farm-Node nicht teilt, löst sich die Description ins Nichts auf, statt auf einen live generierten Groom zurückzufallen.

Allgemeines Panel im Stil des Description-Editors, das Felder für Collection- und Archive-Pfade hervorhebt und zeigt, wo XGen-Groom-Datenreferenzen außerhalb der Hauptszenendatei liegen.

Warum .tx-Texturdateien auf einer render farm brechen

.tx ist ein gekacheltes, mipgemapptes Texturformat, das mit dem maketx-Tool von OpenImageIO erzeugt wird. Arnold liest .tx-Texturen schneller und mit geringerem Speicherbedarf als rohe Quellformate - deshalb bietet MtoA (Arnolds Maya-Plugin) die Option „Auto-Convert Textures to TX Files": Beim Speichern oder Rendern erzeugt es still und leise einen .tx-Cache neben Ihren Quelltexturen.

Dieses Auto-Convert-Verhalten ist praktisch auf einer einzelnen Workstation mit einer lokalen Festplatte und einem einheitlichen OpenImageIO-Build. Auf einer verteilten render farm ist es ein deutlich weniger zuverlässiges Verhalten - aus drei getrennten Gründen:

Veralteter Cache. Wird eine Quelltextur bearbeitet, nachdem die .tx-Datei erzeugt wurde, und löst die Zeitstempelprüfung, die normalerweise eine Neukonvertierung auslösen würde, nicht aus (oder stimmt der beschreibbare Speicherort, den der Farm-Node braucht, nicht mit dem überein, unter dem die Datei erzeugt wurde), kann Arnold eine veraltete .tx-Datei laden, ohne dass eine Warnung erscheint.
Versionskonflikt. maketx/OpenImageIO-Versionen unterscheiden sich zwischen Arnold- und MtoA-Releases. Ein .tx-Cache, der mit einer OIIO-Version erzeugt wurde, kann Lesefehler verursachen - typischerweise als unspezifizierter OIIO-Fehler, der den Frame abbricht -, wenn er auf der Farm-Seite mit einer anderen Version gelesen wird.
Schreibkonflikte auf freigegebenen oder schreibgeschützten Pfaden. Auto-Convert geht davon aus, dass es eine .tx-Datei neben der Quelltextur schreiben kann. Auf einer render farm kann dieser Speicherort schreibgeschützt sein, von mehreren gleichzeitigen Jobs gemeinsam genutzt werden oder schlicht nicht derselbe physische Pfad sein, den die Workstation verwendet hat - die Konvertierung schlägt dann entweder still fehl, oder zwei Nodes wetteifern darum, dieselbe Cache-Datei zu schreiben.

Das kommt branchenweit so häufig vor - nicht nur bei uns -, dass die Dokumentation von render farms Maya/Arnold-Nutzern routinemäßig rät, „Auto-Convert Textures to TX Files" gezielt zu deaktivieren, statt zu versuchen, das Auto-Convert-Verhalten selbst zu reparieren. Zuverlässiger ist eine bewusste Entscheidung: entweder Texturen mit einer bekannten, fest verankerten maketx-Version vorab in .tx konvertieren und diese .tx-Dateien als Teil der Asset-Sammlung mitliefern, oder Auto-Convert komplett abschalten, rohe Quelltexturen einreichen und die Konvertierung dem Renderer der Farm überlassen, der sie auf seiner eigenen Seite konsistent handhabt.

Pipeline-Diagramm, das zeigt, wie eine Quelltextur von maketx in einen .tx-Cache konvertiert wird, mit einem zweiten Zweig, der einen veralteten oder versionskonflikt-behafteten Cache zeigt, der zu einem Texturlesefehler führt.

Was Mayas Szenenarchiv nicht für Sie sammelt

Mayas eingebautes Szenen-Archivierungswerkzeug (Send To / Archive Project) basiert auf dem Standard-Referenzmodell: Dateitexturen, die über Mayas eigene File-Nodes eingebunden sind, und Geometrie, die im Scene Graph liegt. XGen passt nicht vollständig in dieses Modell - deshalb sind seine Daten eines der am häufigsten übersehenen Elemente in einer ansonsten „vollständigen" Asset-Sammlung. Planen Sie vor dem Einreichen einer XGen-Szene bei einer beliebigen render farm, explizit Folgendes zu paketieren:

Die .xgen-Palettendatei selbst
Den Ordner xgen/collections/<description>/ für jede in der Szene referenzierte Description
Den Ordner xgen/archives/, falls eine Description so eingestellt ist, dass sie aus einem gebackenen Archiv rendert
Alle externen Guide Curves, Density Maps oder Length Maps, auf die ein XGen-Modifier außerhalb von Mayas Standard-File-Texture-Nodes verweist - diese umgehen manchmal die Archivierungswerkzeuge, die reguläre Texturen erfassen
Die exakte Maya- und MtoA-Version (Arnold für Maya), in der die Szene erstellt wurde, damit die render farm die Description mit einem passenden Plugin-Build lädt statt mit einem ähnlichen, aber abweichenden

Nichts davon erfordert spezielle Software - es erfordert, XGen-Daten als vollwertigen Teil der Asset-Sammlung zu behandeln statt als impliziten Nebeneffekt des Speicherns der Szene.

Maya + Arnold Preflight-Checkliste für XGen- und .tx-Jobs

Schritt	Was zu prüfen ist	Warum es wichtig ist
1. Versionsabgleich	Bestätigen Sie, dass der von der render farm unterstützte Maya- und Arnold/MtoA-Versionsbereich die exakte Version Ihrer Szene abdeckt	Ein Versionskonflikt kann die Kompatibilität der XGen-Description brechen, selbst wenn die Dateipfade korrekt sind
2. XGen-Ordner sammeln	Paketieren Sie `xgen/collections/`, `xgen/archives/` und die `.xgen`-Datei explizit - verlassen Sie sich nicht allein auf ein generisches Szenen-Archivierungswerkzeug	Das sind die Dateien, die am häufigsten vergessen werden und dazu führen, dass Haar/Fell still und leise verschwindet
3. Generate-vs-Archive-Einstellung prüfen	Bestätigen Sie für jede Description, ob sie live generiert oder aus einem gebackenen Archiv liest, und dass der Archivpfad mit dem Job mitreist	Ein Archivpfad, der sich nicht auflöst, rendert nichts - ohne Fehlermeldung
4. Eine Texturstrategie festlegen	Deaktivieren Sie entweder „Auto-Convert Textures to TX Files" und reichen Sie rohe Texturen ein, oder konvertieren Sie vorab mit einer fest verankerten `maketx`-Version und liefern Sie die `.tx`-Dateien mit	Wenn Auto-Convert aktiviert bleibt, wird Schreibzugriff auf der Farm-Seite und eine passende OIIO-Version vorausgesetzt - Annahmen, die nicht immer zutreffen
5. UNC- und Laufwerksbuchstaben-Referenzen neu pfaden	Ersetzen Sie alle `\\server\share\...`- oder lokalen Laufwerksbuchstaben-Pfade in XGen- und Textur-Nodes durch farm-zugängliche relative Pfade	Pfade, die sich lokal auflösen, existieren auf einem Rendernode häufig nicht
6. Einzelbild-Test durchführen	Reichen Sie vor der vollständigen Sequenz ein einzelnes Testframe ein und prüfen Sie das Render-Log gezielt auf Warnungen zum Texturladen und zur XGen-Auflösung, nicht nur auf den Renderabschluss	Erkennt fehlendes Haar, fehlende Texturen und OIIO-Fehler, bevor sie eine ganze Sequenz kosten
7. CPU vs. GPU für den Shot entscheiden	Planen Sie bei XGen-lastigen Grooms, dichter Haar-/Fellabdeckung und individuellen Shading-Netzwerken für finale Frames mit Arnolds CPU-Renderpfad - stark prozedurale Szenen und Szenen mit individuellen Shadern sind genau die Art von Arbeit, für die Arnolds eigene Empfehlung CPU für das finale Output nennt	Die CPU/GPU-Entscheidung vor dem Einreichen zu treffen, vermeidet, eine Geräte-Einschränkung erst mitten im Rendering zu entdecken

Häufige Probleme und Lösungen

Symptom	Wahrscheinliche Ursache	Lösung
Haar oder Fell fehlt im Farm-Render, ist aber lokal vorhanden	XGen-Ordner `collections`/`archives` nicht mitgesammelt, oder Pfad nicht farm-zugänglich	Paketieren Sie die XGen-Ordner explizit und pfaden Sie alle UNC-/Laufwerksbuchstaben-Referenzen neu
Rendering bricht mitten im Frame mit einem unspezifizierten OpenImageIO-Fehler ab	Veralteter oder versionskonflikt-behafteter `.tx`-Cache	Erzeugen Sie `.tx` mit einer fest verankerten `maketx`-Version neu, oder deaktivieren Sie Auto-Convert und reichen Sie rohe Texturen ein
Textur oder Bitmap lässt sich auf dem Rendernode nicht auflösen (tritt auch in Arnold-in-3ds-Max-Pipelines auf, eine verwandte, aber eigenständige Fehlerklasse - siehe unseren Leitfaden zu fehlenden Bitmap-Nodes bei Arnold in 3ds Max)	Textur-Pfad kann vom Rendernode aus nicht aufgelöst werden	Bestätigen Sie relative, farm-zugängliche Pfade vor dem Einreichen
Job rendert bei erneutem Einreichen korrekt, ist aber beim ersten Mal fehlgeschlagen	Auto-Convert hat den `.tx`-Cache beim ersten Durchlauf mitten im Rendering geschrieben; der zweite Durchlauf hat den nun vollständigen Cache gelesen	Konvertieren Sie `.tx`-Dateien vor dem Einreichen vor, oder deaktivieren Sie Auto-Convert vollständig
Arnold- oder MtoA-Plugin-Fehler beim Laden	MtoA-Version auf der Farm stimmt nicht mit der Version überein, in der die Szene erstellt wurde	Bestätigen Sie den Ziel-Maya/Arnold-Versionsbereich vor dem Einreichen

Mockup einer Render-Log-Konsole, die einen Textur-Lesefehler auf Warnstufe zeigt und veranschaulicht, welche Meldung ein veralteter oder versionskonflikt-behafteter .tx-Cache auf einem Rendernode erzeugt.

Zusammenfassende Checkliste

Maya- und Arnold/MtoA-Versionen gegen den von der render farm unterstützten Bereich bestätigt
xgen/collections/ und xgen/archives/ explizit in die Asset-Sammlung aufgenommen
Die Generate-vs-Archive-Einstellung jeder XGen-Description geprüft und ihr Pfad als farm-zugänglich verifiziert
Eine Texturstrategie gewählt: vorkonvertiertes .tx (fest verankerte maketx-Version) oder rohe Texturen mit deaktiviertem Auto-Convert - nicht beides
Alle UNC- und Laufwerksbuchstaben-Pfade durch relative, farm-zugängliche Pfade ersetzt
Ein Testframe eingereicht und dessen Render-Log vor der vollständigen Sequenz auf XGen- und Textur-Warnungen geprüft
CPU- vs. GPU-Renderpfad für XGen-lastige Shots oder Shots mit individuellen Shadern entschieden

Auf unserer Farm bestehen aktuelle Maya-Versionen (2022 und neuer) den Versionsabgleich automatisch beim Einreichen; ältere Versionen im unterstützten Bereich 2014-2027 durchlaufen vor Renderbeginn eine Bereitstellungs- und Kompatibilitätsprüfung, sodass ein Konflikt erkannt wird, bevor Frames verbrannt werden, statt mitten im Job. Die Punkte zu Pfaden, Caches und Archiv-Einstellungen bleiben szenenspezifisch und lohnen sich unabhängig davon, an welche Farm ein Job geht.

Für die allgemeine Einrichtung von Maya-Cloud-Rendering über XGen und Texturen hinaus siehe unseren Leitfaden zu Maya-Cloud-Rendering und unseren vollständigen Leitfaden zum Arnold-Renderer. Für die Software-Support-Bereiche hinter dem Versionsabgleich der Farm siehe unsere Seiten Maya-render-farm und Arnold-render-farm. Auf der Texturseite ist OpenImageIOs eigene maketx-Dokumentation die klarste technische Referenz dafür, was die .tx-Konvertierung tatsächlich tut und welche Flags das Mipmap- und Kachelverhalten steuern.

FAQ

Q: Warum verschwindet XGen-Haar oder -Fell, wenn ich auf einer Cloud-render-farm rendere, funktioniert aber lokal einwandfrei? A: Das bedeutet meist, dass die XGen-Ordner collections und archives nicht zusammen mit dem Rest der Szene gesammelt wurden. XGen liest Groom- und Description-Daten zur Render-Zeit aus diesen externen Dateien - wird nur die .ma- oder .mb-Datei hochgeladen, hat der Rendernode nichts, woraus er das Haar oder Fell generieren kann, und rendert stattdessen kahl, statt einen offensichtlichen Fehler zu werfen.

Q: Was ist eine .tx-Datei, und warum braucht Arnold sie? A: Eine .tx-Datei ist eine gekachelte, mipgemappte Textur, die mit dem maketx-Tool von OpenImageIO erzeugt wird. Arnold und MtoA verwenden .tx-Texturen statt roher Quellformate, weil gekachelte Mipmaps schneller laden und beim Rendern weniger Speicher verbrauchen - das fällt im Farm-Maßstab stärker ins Gewicht als auf einer einzelnen Workstation.

Q: Sollte ich „Auto-Convert Textures to TX Files" beim Einreichen bei einer render farm aktiviert lassen? A: Es aktiviert zu lassen ist eine häufige Ursache für Texturfehler auf der Farm-Seite. Auf einer Workstation mit einer Festplatte funktioniert es einwandfrei, aber auf einer verteilten Farm kann es einen veralteten oder versionskonflikt-behafteten .tx-Cache erzeugen oder auf einen unterschiedlichen Schreibzugriff auf dem Rendernode stoßen. Vorab mit einer bekannten maketx-Version konvertieren und die .tx-Dateien mitliefern, oder Auto-Convert deaktivieren und rohe Texturen einreichen, vermeidet beide Fehlermodi.

Q: Meine Maya- und Arnold-Versionen stimmen bereits mit denen der Farm überein - warum fehlen im Render trotzdem Texturen? A: Der Versionsabgleich verhindert Fehler auf Plugin-Ebene, aber die meisten XGen- und .tx-Fehler auf Farms kommen von Dateipfaden, nicht von Versionen. Verweist XGen auf einen UNC-Pfad oder einen lokalen Laufwerksbuchstaben, der auf dem Rendernode nicht existiert, oder wurde der .tx-Cache anhand eines Texturspeicherorts erzeugt, den die Farm nicht erreichen kann, schlägt das Rendering fehl - selbst bei übereinstimmenden Softwareversionen.

Q: Woher weiß ich, welche Maya- und Arnold-Versionen eine render farm unterstützt? A: Prüfen Sie vor dem Einreichen den von der Farm unterstützten Maya- und Arnold/MtoA-Versionsbereich - passende Versionen eliminieren eine ganze Klasse von Renderfehlern. Unsere Farm unterstützt Maya 2014-2027: Versionen 2022 und neuer bestehen den Versionsabgleich automatisch beim Einreichen, ältere Versionen durchlaufen vor dem Rendering eine Kompatibilitätsprüfung.

Q: Sollten XGen-Shots über Arnolds CPU- oder GPU-Pfad gerendert werden? A: XGen-lastige Shots mit dichter Haar- oder Fellabdeckung und individuellen Shading-Netzwerken gehören für das finale Output auf Arnolds CPU-Pfad - das ist die Art von Arbeit, für die Arnolds eigene Empfehlung CPU nennt. Unabhängig davon, welchen Pfad ein Shot nutzt, treffen Sie die Geräteentscheidung bereits beim Einreichen als Teil des Preflights, statt eine Einschränkung erst mitten im Rendering zu entdecken.

Q: Was sollte ich vor dem Einreichen einer Maya-Szene mit XGen bei einer render farm prüfen? A: Führen Sie einen kurzen Preflight durch: Bestätigen Sie den Maya/MtoA-Versionsabgleich, paketieren Sie die Ordner xgen/collections und xgen/archives explizit, legen Sie eine Texturstrategie fest (vorkonvertiertes .tx oder rohe Texturen mit deaktiviertem Auto-Convert), pfaden Sie alle UNC- oder lokalen Laufwerksreferenzen neu, und reichen Sie vor der vollständigen Sequenz einen Einzelbild-Test ein.

Q: Ist das ein reines XGen-Problem, oder tritt es auch bei anderen DCCs auf? A: Das gleiche zugrunde liegende Muster - Daten, die außerhalb der Hauptszenendatei liegen, plus zwischengespeicherte Texturdaten, die veralten - taucht auch anderswo auf. 3ds-Max-Nutzer stoßen auf ein verwandtes, aber eigenständiges Problem mit fehlenden Bitmap-Nodes in Arnold, wenn sich Texturpfade auf dem Rendernode nicht auflösen; siehe unseren Leitfaden zu fehlenden Bitmap-Nodes bei Arnold in 3ds Max für diese Variante des Problems.