Houdini für Cloud-Rendering einrichten

Houdini auf unserer render farm ist eine Multi-Renderer-Umgebung, die auf der modernen USD-first-Pipeline basiert. Karma XPU ist der von SideFX empfohlene Weg für neue Projekte in Houdini 20.5 und der primäre Renderer auf unserer Landing-Page . Karma CPU und Mantra stehen weiterhin für Legacy-Produktionen zur Verfügung; Drittanbieter-Renderer — Redshift, Arnold, V-Ray für Houdini, Octane — werden für Studios mit etablierten Pipelines in diesen Engines unterstützt. Diese Seite behandelt die Projektverpackung (was bei Houdini HDAs und Simulations-Caches umfasst, nicht nur Texturen), den Solaris/USD-Asset-Workflow, renderer-spezifische Hinweise, den Einreichungsablauf und die houdini-spezifischen Fehlerdiagnosen, die wir am häufigsten in Support-Tickets sehen.

Ein Hinweis zur Lizenzierung vorab: Wir betreiben Houdini-Installationen auf der render farm unter Render-only-Nutzung, die das Ausführen von Houdini auf Render-Workern für das Offline-Rendering von Kundenprojekten erlaubt. Super Renders Farm ist kein SideFX-Partner — die Render-only-Nutzung ist der rechtliche Rahmen, der das Farm-Rendering von Houdini-Szenen ermöglicht, ohne einen SideFX-Seat aus dem Lizenz-Pool Ihres Studios zu belegen. Sie übertragen Ihre Houdini-Lizenz nicht an uns, und der Projekt-Tier-Metadaten auf der Künstlerseite (Indie, Core, FX) bestimmt nicht die Lizenzvereinbarung des Workers. Der Worker zieht auf seiner Seite aus dem Lizenz-Pool der Farm.

Für eine allgemeine Positionierung — unterstützte Houdini-Versionen, Hardware-Eignung, Preisbeispiele — ist die dedizierte Landing-Page die kanonische Referenz. Die Seite, die Sie gerade lesen, ist das Workflow-Dokument: was in Houdini zu tun ist, bevor Sie auf „Einreichen" klicken.

Unterstützte Versionen

Houdini 19.5, 20.0 und 20.5 sind auf jedem Worker der Farm vorinstalliert. Wir verfolgen den Release-Zeitplan von SideFX und stellen neue Major-Builds innerhalb von vier Wochen nach öffentlicher Verfügbarkeit bereit. Point-Releases (z. B. Houdini 20.5.410 vs. 20.5.487) werden kontinuierlich verfolgt; wenn Ihr Projekt aufgrund eines Node-Kompatibilitätsproblems an eine bestimmte Build-Nummer gebunden ist, geben Sie die Build-Nummer in den Job-Notizen beim Einreichen an — wir ordnen den Worker entsprechend zu.

Sowohl Houdini FX (der Produktionstier) als auch Houdini Indie-Szenendateien (.hip und .hipnc) werden auf dem Worker geladen und unter der Render-only-Nutzungsvereinbarung der Farm gerendert. Der Künstlertier (Indie vs. Core/FX) überträgt sich nicht auf den Lizenzseat des Workers — der Worker verwendet den Tier, den die Farm für das Rendering bereitstellt. Houdini-Apprentice-Dateien werden gerendert, erzeugen jedoch Wasserzeichen-Ausgaben gemäß den nicht-kommerziellen Lizenzbedingungen von SideFX; für bezahlte Produktionsarbeit speichern Sie die Szene vor der Einreichung aus einer Nicht-Apprentice-Lizenz. Für Bildungslizenzen gilt dieselbe Regel.

Ein Hinweis zum Release-Rhythmus von Houdini: SideFX veröffentlicht alle 12–18 Monate Major-Versionen und häufiger Point-Updates. Karma XPU hat sich insbesondere zwischen 19.5, 20.0 und 20.5 wesentlich verbessert — Features, die in 19.5 noch CPU-Fallback erforderten (dichte Volumes, bestimmte Shader-Netzwerke), sind in 20.5 nativ in XPU. Wenn Ihr Projekt von einem Karma-XPU-Feature abhängt, das in einem bestimmten Build eingeführt wurde, sperren Sie den Build in den Job-Notizen, anstatt den Worker den neuesten verfügbaren Build wählen zu lassen.

Houdini-Projekt verpacken

Ein Houdini-Projekt besteht aus mehr als der .hip- (oder .hipnc-) Szenendatei. Es umfasst typischerweise auch: HDAs (Houdini Digital Assets — .hda oder das ältere .otl-Format), Simulations-Cache-Dateien (.bgeo, .bgeo.sc, .vdb, .abc), USD-Asset-Layer und Referenzen (.usd, .usda, .usdc), Textur-Maps und jede externe Geometrie, die über File- oder Alembic-SOPs importiert wurde. Cloud-Rendering gelingt, wenn jede Abhängigkeit, die die Szene referenziert, auf dem Worker vorhanden ist; es schlägt fehl, wenn etwas lokal über einen nur auf der Workstation verfügbaren Pfad aufgelöst wird, aber auf der Farm keinen Auflösungspfad hat.

Houdinis Pfadkonventionen basieren auf Umgebungsvariablen — am häufigsten $HIP (löst zum Verzeichnis auf, das die .hip-Datei enthält), $HIPNAME (der Szenendatei-Basisname) und $JOB (das Projekt-Root, per Umgebungsvariable gesetzt). Für Cloud-Rendering ist die zuverlässige Konvention $HIP-relative Pfade überall. Die nachstehenden Verpackungsschritte wenden diese Konvention durchgängig an:

Projektordner festlegen. Wenn Sie ein neues Projekt speichern, setzt Houdini $HIP auf das Verzeichnis, das die .hip-Datei enthält. Überprüfen Sie dies in der Python-Shell mit hou.text.expandString('$HIP') — der Pfad sollte mit dem Speicherort Ihrer Szenendatei übereinstimmen.
Standard-Unterordnerstruktur verwenden. $HIP/cache/ für Simulationen, $HIP/geo/ für Alembic und externe Geometrie, $HIP/tex/ für Texturen, $HIP/hda/ für Digital Assets, $HIP/usd/ für USD-Layer und Referenzen, $HIP/render/ für die Ausgabe. Alle Pfade in den File-SOPs, File-COPs, ROP-Ausgaben und Textur-Referenzen Ihrer Szene sollten $HIP/... statt absoluter Laufwerkspfade verwenden.
Pfadauflösung prüfen. Datei → Alle aktualisieren. Houdini meldet nicht aufgelöste Dateireferenzen in der Konsole. Über die Python-Shell gibt hou.fileReferences() die vollständige Liste externer Referenzen zurück — prüfen Sie auf Pfade, die mit D:\, Y:\, einem UNC-Share wie \\server\ oder einem Pfad beginnen, den der Worker nicht erreichen kann.
Simulationen auf Festplatte baken. Die Farm führt keine Simulationen als Teil des Render-Jobs aus — Simulationen sind Workstation-Arbeit, und die Farm rendert gegen vorab gebakte Cache-Dateien. Baken Sie alle DOP-Netzwerke (FLIP-Fluide, Pyro, Vellum-Cloth, RBD-Bullet, Körner), Partikel-Solver und alle weiteren Simulations-Ausgaben in .bgeo.sc- oder .vdb-Dateien in $HIP/cache/ vor der Einreichung. Der File-Cache-SOP mit „Save to Disk" ist der Standard-Workflow.
HDAs einbetten oder einschließen. Wenn Ihre Szene benutzerdefinierte HDAs aus einer Studio-Bibliothek verwendet, betten Sie diese entweder in die .hip ein (Asset-Menü → Operator-Typ speichern → „Eingebettet") oder fügen Sie die .hda/.otl-Dateien in $HIP/hda/ ein, damit der Worker sie aus dem Projektordner laden kann. Studio-geteilte HDA-Bibliotheken auf Netzlaufwerken sind vom Worker aus nicht erreichbar.
USD-Layer abflachen oder bündeln. Wenn Ihre Szene Solaris/LOPs verwendet, baken Sie entweder die USD-Stage zu einer einzelnen zusammengesetzten USD-Datei über den USD-ROP vor der Einreichung, oder schließen Sie den gesamten $HIP/usd/-Verzeichnisbaum ein, damit jeder Layer auf dem Worker aufgelöst wird. USD-Asset-Auflösungsregeln werden im nächsten Abschnitt detailliert behandelt.
Den gesamten $HIP-Ordner archivieren. Verwenden Sie .tar, .tar.gz oder .7z. Wir akzeptieren keine .zip-Uploads für Houdini-Projekte (Houdinis Dateinamen-Konventionen enthalten manchmal Zeichen, die innerhalb von Windows-.zip-Archiven auf Linux-Workern Probleme verursachen).

Ein häufiges Houdini-spezifisches Problem: Die Felder „Pre-Render Script" und „Post-Render Script" auf ROP-Nodes referenzieren manchmal workstation-spezifische Python-Skripte — die Pipeline-Tools Ihres Studios, einen lokalen Houdini-Konfigurationspfad oder einen hou.ui.displayMessage-Aufruf, der einen Dialog öffnet, für den der Worker keine Anzeige hat. Das Cloud-Rendering schlägt entweder lautlos fehl oder hängt und wartet auf Eingaben, die nie eintreffen. Prüfen Sie alle Pre-Render-Python- oder HScript-Callbacks vor der Einreichung; deaktivieren oder portabilisieren Sie jeden Code, der nur lokale Pfade, UI-Aufrufe oder hou.system()-Shell-Aufrufe zu workstation-spezifischen Binärdateien berührt. Bevorzugen Sie print()-Protokollierung gegenüber interaktiven Callbacks.

Solaris, USD-Layer und Asset-Auflösung

Wenn Ihre Szene in Solaris (dem /stage-LOPs-Netzwerk) erstellt wurde, fügt die USD-Asset-Auflösungsschicht eine zusätzliche Dimension bei Cloud-Einreichungen hinzu, die bei reinen OBJ/SOP-Szenen nicht vorhanden ist. Houdinis USD-Resolver folgt den Standard-USD-Asset-Auflösungsregeln: Referenzen in einem Layer werden gegen den Identifikatorpfad des Layers aufgelöst, Suchpfade über houdini.env oder das Asset-Resolver-Plugin konfiguriert, sowie alle Kompositionsbögen, die die Stage verwendet (Referenzen, Sub-Layer, Payloads).

Für Cloud-Einreichungen funktionieren zwei Muster zuverlässig:

Stage abflachen. Verwenden Sie den USD-ROP-Node mit „Save to Disk" und aktivierter Option „Flatten Stage". Das Ergebnis ist eine einzelne zusammengesetzte .usd- (oder .usdc- für binär) Datei, die die gesamte Stage mit allen aufgelösten Referenzen enthält. Dies ist das einfachste Muster — der Worker liest eine Datei, keine Resolver-Indirektion — aber Sie verlieren die Schichtstruktur, die USD für die Zusammenarbeit wertvoll macht.
Den vollständigen Asset-Baum bündeln. Platzieren Sie alle USD-Layer unter $HIP/usd/ und verwenden Sie $HIP-relative Referenzen in Ihren Sub-Layern, Referenzen und Payloads. Der Worker löst $HIP zum Upload-Root auf, sodass Layer-Dateien an der gleichen relativen Position korrekt geladen werden.

Eine Feinheit: Der „Asset Reference"-LOP von Solaris und der Reference-SOP in /obj-Kontexten serialisieren beide den Referenzpfad so, wie er geschrieben wurde. Wenn Sie D:\studio_assets\char_robot.usd in einen Reference-LOP eingegeben haben, hat der Worker kein D:\ und die Referenz schlägt fehl. Verfassen Sie die Referenz neu als $HIP/usd/char_robot.usd (oder ${SRF_ASSETS}/char_robot.usd mit einer dokumentierten Umgebungsvariablen-Zuordnung, die die Farm berücksichtigt). Je einfacher der Pfad, desto zuverlässiger funktioniert er auf der Farm.

Eine zweite Feinheit: USD-Asset-Bibliotheken können eigene Versionierungsindirektionen tragen. Eine Solaris-Stage, die USD-Assets referenziert, die gegen USD 23.x kompiliert wurden, lädt möglicherweise nicht sauber auf einem Worker mit USD 22.x, das in einem älteren Houdini-Build gebündelt ist. Die Houdini-und-USD-Versionsmatrix ist wichtig — wenn Ihre Asset-Bibliothek für die USD-Version von Houdini 20.5 erstellt wurde, rendern Sie auf Houdini-20.5-Workern.

HDA-Verwaltung

Houdini Digital Assets (HDAs, manchmal noch mit der älteren .otl-Erweiterung zu sehen) sind wiederverwendbare Node-Netzwerke, die als eigenständige Asset-Dateien verpackt sind. Sie sind in Produktionspipelines weit verbreitet, insbesondere für prozedurale Assets — Gebäude, Vegetation, Crowd-Systeme, benutzerdefinierte Solver —, die separat von einzelnen Shots erstellt und szenenübergreifend geteilt werden.

Drei Muster für die HDA-Behandlung auf der Farm:

HDA in die .hip-Datei einbetten. Asset-Menü → Operator-Typ-Manager → Rechtsklick auf das HDA → „In Eingebettet speichern." Das HDA ist nun in der .hip gespeichert und reist mit der Szene. Dies ist das sicherste Muster für einmalige Jobs oder für HDAs, die Sie speziell für einen einzelnen Shot erstellen.
HDAs in $HIP/hda/ bündeln. Platzieren Sie alle .hda/.otl-Dateien in einem Unterordner Ihres Projekts, und stellen Sie dann in Houdini → Bearbeiten → Einstellungen → Dateispeicherorte sicher, dass $HIP/hda/ Teil des OTL-Suchpfads ist (alternativ setzen Sie HOUDINI_OTLSCAN_PATH so, dass es $HIP/hda/ in Ihrer houdini.env enthält). Der Worker liest HDAs beim Laden der Szene von diesem Ort.
HDAs aus einer gemeinsam genutzten Studio-Bibliothek referenzieren. Wenn Ihr Studio eine gemeinsam genutzte HDA-Bibliothek auf einem Netzlaufwerk verwendet (z. B. \\studio-fs\houdini\hda\), ist diese Bibliothek vom Worker aus nicht zugänglich. Kopieren Sie die relevanten HDAs entweder in $HIP/hda/ vor der Einreichung, oder betten Sie sie in die .hip ein.

Vor der Einreichung listen Sie die geladenen HDAs in der Szene über die Python-Shell auf:

text

for hda in hou.hda.loadedFiles():
    print(hda)

Jeder Pfad in der Ausgabe muss entweder unter $HIP aufgelöst werden oder ein Standard-SideFX-HDA sein, das mit Houdini selbst ausgeliefert wird (diese sind auf jedem Worker vorinstalliert). Jedes Drittanbieter-HDA, das außerhalb von $HIP liegt, wird nicht gefunden.

Cache-Datei-Verwaltung

Cache-Dateien sind in der Regel die größte Einzelkategorie bei einem Houdini-Projekt-Upload — FLIP-Simulationen, Pyro-Caches, Vellum-Cloth-Bakes, Alembic-Exporte und VDB-Volumes können jeweils Dutzende oder Hunderte von Gigabytes umfassen. Zwei Muster reduzieren die Upload-Zeit, ohne den Render zu beeinträchtigen:

Caches beim Baken komprimieren. .bgeo.sc (komprimiertes bgeo, blosc-komprimiert) ist für die gleiche Geometrie deutlich kleiner als .bgeo und ist der moderne Standard für File-Cache-SOPs. Bei VDB-Dateien ist das Volume bereits im OpenVDB-Container komprimiert, aber .tar.gz-Archive komprimieren die umgebenden Verzeichnis-Metadaten gut.
$HIP/cache/ konsequent verwenden. Houdinis File-Cache-SOP verwendet standardmäßig $HIP/cache/{node_name}/$F4.bgeo.sc, was das richtige Muster für farm-portable Szenen ist. Vermeiden Sie absolute Cache-Pfade wie D:\sim_cache\ — der Worker hat kein D:\ und das Rendering startet, protokolliert Warnungen „Cache-Datei nicht gefunden" und produziert leere Geometrie, wo die Simulation sein sollte.

Für sehr große Simulationen — Multi-Terabyte-FLIP- oder Pyro-Caches, die einen Browser-Upload übersteigen — verwenden Sie SFTP statt des Web-Upload-Formulars. Das Dokument behandelt den SFTP-Workflow, die Wiederaufnahme von Archivübertragungen und die praktischen Schwellenwerte für den Wechsel vom Web-Upload zu SFTP.

Eine Workflow-Anmerkung für Studios, die auf der Workstation cachen aber auf der Farm rendern: Wenn sich Ihr Cache-Verzeichnis auf einer schnellen lokalen SSD befindet und Ihre Projektdatei $HIP/cache/ verwendet, wandert der Cache mit dem Projekt beim Upload — kein manuelles Remapping erforderlich. Wenn Ihr Workstation-Muster das Cachen auf ein gemeinsam genutztes Netzlaufwerk und direkte Referenzierung dieses Laufwerks in der .hip ist, müssen Sie die Caches entweder in $HIP/cache/ kopieren und die File-Cache-SOP-Pfade aktualisieren, oder eine $JOB-Umgebungsvariable auf dem Worker setzen, die den Netzwerkshare der Workstation spiegelt (weniger zuverlässig; der relative Pfad-Ansatz wird bevorzugt).

Vor der Einreichung prüfen

Eine kurze Vorflug-Checkliste für jede Houdini-Einreichung:

Aktiver ROP-Node ist korrekt gesetzt. Ausgabe-Kontext → Rendern. Der ROP, den Sie zum Einreichungszeitpunkt auswählen, bestimmt, welchen Renderer der Worker aufruft. Nicht übereinstimmende ROPs (z. B. Auswahl eines Karma-ROP für eine Szene, deren Beleuchtung für Mantra erstellt wurde) sind die häufigste Ursache für „das Rendering sieht völlig anders aus"-Tickets.
Frame-Bereich entspricht den ROP-Einstellungen. Der auf dem ROP gespeicherte Frame-Bereich (f1, f2, f3-Parameter) ist das, was der Worker verwendet, nicht der Wiedergabebereich der Timeline oder der aktuelle Frame des Viewports. Bestätigen Sie, dass der Frame-Bereich des ROP dem entspricht, was Sie rendern möchten.
Ausgabepfad verwendet $HIP-relative Token. $HIP/render/$F4.exr ist der sichere Standard für mehrschichtiges EXR mit vierstelliger Padding. Vermeiden Sie absolute Laufwerkspfade im ROP-Ausgabeausdruck.
Alle File-SOPs und Textur-Referenzen werden aufgelöst. Datei → Alle aktualisieren. Beheben Sie alle „Lesen nicht möglich"-Fehler in der Konsole vor der Einreichung — der Worker meldet diese ebenfalls, aber zum Preis eines verschwendeten Render-Frames.
HDAs sind entweder eingebettet oder in $HIP/hda/. Überprüfen Sie, indem Sie die Szene vollständig schließen und aus einer anderen Houdini-Sitzung erneut öffnen; wenn HDAs lokal nicht geladen werden, wird der Worker sie ebenfalls nicht laden.
Caches sind gebakt. Führen Sie einen manuellen Cache-Bake auf jedem File-Cache-SOP über Rendern → Auf Festplatte speichern durch, bevor Sie einreichen. Verlassen Sie sich nicht auf „Auto-Bake bei Frame-Änderung" — baken Sie explizit und bestätigen Sie, dass die Cache-Dateien an den erwarteten $HIP/cache/...-Pfaden vorhanden sind.
USD-Layer (falls Solaris) sind gebündelt oder abgeflacht. Schließen Sie entweder den vollständigen $HIP/usd/-Baum ein oder schreiben Sie eine abgeflachte zusammengesetzte USD über den USD-ROP.
Keine interaktiven Pre-Render- oder Post-Render-Skripte. Prüfen Sie ROP-Python-Callbacks und Pre-Frame-Skripte auf UI-Aufrufe, Shell-Aufrufe oder workstation-spezifische Pfade.

Renderer-spezifische Hinweise

Karma XPU (empfohlen)

Karma XPU ist Houdinis hybrid CPU+GPU-Renderer, der in Houdini 20.5 den Status „produktionsreif" erreicht hat und der Standard-Vorwärtspfad für neue Houdini-Projekte ist. Er ist der primäre Renderer auf unserer Houdini-Landing-Page und der Weg, den die meisten neuen Kunden auf der Farm einschlagen.

Konfigurationshinweise:

Worker-Tier: Läuft auf unserem RTX-5090-GPU-Worker-Tier (32 GB VRAM pro Karte) für den GPU-Teil des Renderings, mit CPU-Fallback für alle Features, die der XPU-Code-Pfad noch nicht unterstützt.
VRAM-Einschränkungen: 32 GB VRAM pro Worker. Karma XPU ist VRAM-effizienter als reine GPU-Renderer, da Teile des Renderings (insbesondere Volumetrics) in den CPU-Speicher ausgelagert werden können, wenn VRAM knapp ist — aber sehr dichte USD-Szenen mit hochauflösenden Volumes profitieren dennoch davon, innerhalb des 32-GB-Rahmens zu bleiben.
USD-Pipeline-Integration. Karma ist der für die Solaris-USD-basierte Pipeline konzipierte Renderer. Wenn Ihr Projekt /stage (Solaris-LOPs-Kontext) verwendet, ist Karma die natürliche Renderer-Wahl, und der Worker löst USD-Asset-Referenzen genauso auf wie File-SOP-Referenzen — $HIP-relative Pfade gewinnen.
AOVs. Konfiguriert per Render-Produkt im Render-Settings-Prim auf der USD-Stage. Mehrkanal-EXR ist das Standard-Ausgabeformat und das, was wir für VFX-Pipelines empfehlen (bewahrt alle AOVs in einer einzigen Datei pro Frame).
Sampling. Karmas Pfad-Tracing-Samples werden pro Render-Settings-Prim konfiguriert. Kalibrieren Sie lokal an einem einzelnen Frame, bevor Sie eine Sequenz einreichen — die XPU-Sample-Konvergenz unterscheidet sich von CPU, und die Kalibrierung überträgt sich direkt auf den Worker.
Motion Blur. Karma XPU unterstützt Geometrie-Motion-Blur und Shutter-Window-Blur. Bestätigen Sie, dass Ihre Motion-Blur-Shutter-Einstellung auf dem USD-Kamera-Prim dem entspricht, was das Render-Settings-Prim erwartet — die Solaris-Shutter-Behandlung und Karma-Motion-Blur-Sampling stimmen bei ersten Prinzipien nicht immer überein, und das Symptom ist „das Rendering sieht gut aus, aber Motion Blur fehlt oder ist verdoppelt."

Karma CPU

Karma CPU ist die reine CPU-Variante von Karma. Funktionsumfang vollständig und stabil seit Houdini 19; der natürliche Fallback für Szenen, die GPU-VRAM übersteigen oder auf Features angewiesen sind, die im XPU-Code-Pfad noch nicht implementiert sind.

Konfigurationshinweise:

Worker-Tier: CPU-Worker-Tier (Dual Intel Xeon E5-2699 V4 Nodes, 96–256 GB RAM pro Node, über 20.000 aggregierte CPU-Kerne im Fleet).
Wann gegenüber Karma XPU zu verwenden: sehr schwere Geometrie (>50 Mio. Polygone), dichte Volumetric-Renderings, die 32 GB VRAM übersteigen, OSL-Custom-Shader, die noch kein XPU-Äquivalent haben, oder Projekte, die CPU-schwere Simulations-Passes in derselben Einreichung mischen.
Gleiche Solaris/USD-Integration wie Karma XPU. Die Render-Produkt- und AOV-Konfiguration ist identisch; nur das Rechen-Backend unterscheidet sich.

Mantra (Legacy)

Mantra ist Houdinis Vorgänger-Renderer vor Karma — SideFX's Micropolygon-Engine, die der USD-first-Pipeline vorausging. SideFX hat signalisiert, dass Mantra nicht der Vorwärtspfad ist; Karma ist es. Mantra bleibt im Houdini-Build aus Gründen der Abwärtskompatibilität mit Projekten, die vor der Viabilität von Karma erstellt wurden.

Konfigurationshinweise:

Worker-Tier: CPU-Worker-Tier.
Performance. Mantra ist für äquivalente Szenen generell langsamer pro Frame als Karma CPU und verfügt nicht über den GPU-Beschleunigungspfad, den Karma XPU bietet. Neue Projekte sollten Karma verwenden.
Wann zu verwenden. Wenn Ihre Projektdatei an Mantra gebunden ist (eine laufende Produktion, die vor der Viabilität von Karma begann, oder eine Shader-Bibliothek, die noch nicht portiert wurde), oder wenn Sie ein Mantra-spezifisches Feature benötigen (einige Mantra-Micropolygon-Sonderfälle haben noch kein genaues Karma-Äquivalent). Für neue Projekte in 2026 standardmäßig Karma verwenden.

Redshift für Houdini

Redshift für Houdini läuft auf unserem RTX-5090-GPU-Worker-Tier. Redshift ist die Wahl für Studios mit etablierten Redshift-Pipelines — oft Maya- oder Cinema-4D-Studios, die für FX auf Houdini wechseln und Shader-Bibliotheken über DCCs hinweg teilen möchten.

Konfigurationshinweise:

Lizenz-Rahmen. Redshift auf unserer Farm läuft unter unserer -Lizenz. Redshift ist jetzt ein Maxon-Produkt, und unsere Maxon-Partnerschaft deckt Redshift über alle von uns unterstützten DCCs ab (Cinema 4D, Houdini, Maya).
Out-of-Core-Speicher. Standardmäßig aktiviert. Erweitert den effektiven Szenenspeicher über die 32-GB-VRAM-Grenze pro Worker hinaus, was für dichte Szenen wichtig ist, die sonst auf der GPU OOM verursachen würden.
Houdini-spezifische Features. Redshift integriert sich direkt in Houdinis Volume-Primitive-Typen (VDB, Pyro-Caches) — kein spezieller Exportschritt für das Volume-Rendering erforderlich. Der Redshift-ROP exponiert houdini-native Parameter für Ray Bias, Sampling und AOV-Konfiguration.
Versions-Pinning. Redshift veröffentlicht in seinem eigenen 3.x-Zyklus, unabhängig von Houdinis Release-Kadenz. Größere Redshift-Versionen (3.0 → 3.5 → 4.0 wenn verfügbar) sind nicht garantiert abwärtskompatibel — eine mit Redshift 3.5.18 gespeicherte Szene lädt möglicherweise nicht sauber auf einem Worker, der Redshift 3.0.x ausführt. Notieren Sie die Redshift-Build-Nummer beim Szenenspecichern und bestätigen Sie die Worker-Kompatibilität, bevor Sie eine vollständige Sequenz einreichen.

Arnold für Houdini

Arnold für Houdini (manchmal HtoA genannt, derzeit im Arnold-7.x-Release-Zyklus) läuft auf unserem CPU-Worker-Tier. Es ist die Wahl für Studios mit gemeinsamen Maya/Houdini-Arnold-Pipelines, bei denen Lookdev in einem DCC erstellt und FX in einem anderen durchgeführt wird, der Shader- und Rendering-Layer jedoch vereinheitlicht ist.

Konfigurationshinweise:

Lizenz-Rahmen. Arnold auf unserer Farm läuft unter Autodesk-Render-Node-Lizenzierung.
AOVs. Arnolds AOV-System in Houdini funktioniert genauso wie in Maya. Konfigurieren Sie pro ROP und schreiben Sie in Mehrkanal-EXR oder pro-AOV-Dateien; das DCC-übergreifende Muster ist konsistent.
Versions-Pinning. HtoA-Versionen verfolgen Arnolds Release-Kadenz (HtoA 6.x für Houdini 19.5/20.0; HtoA 7.x für Houdini 20.5/21.0 wenn verfügbar). Größere HtoA-Sprünge (6 → 7) sollten niemals als kompatibel angenommen werden — bestätigen Sie, dass der Worker mindestens die Minor-Version hat, mit der Ihre Szene gespeichert wurde.

V-Ray für Houdini

V-Ray für Houdini läuft auf unserem CPU-Worker-Tier. Die Verbreitung in Houdini ist deutlich geringer als in 3ds Max oder Maya, aber die Integration wird für Studios mit V-Ray-zentrierten Pipelines unterstützt.

Konfigurationshinweise:

Lizenz-Rahmen. V-Ray auf unserer Farm läuft unter unserer -Lizenz.
VRayProxy-Assets. Werden unterstützt. Schließen Sie .vrmesh-Dateien in $HIP/geo/ ein, damit der Worker sie auflösen kann.
Houdini-spezifisches. Der V-Ray-für-Houdini-ROP exponiert dieselben Render-Einstellungen wie V-Ray in 3ds Max — Sampler-Typ, Render-Elemente (AOVs), Ausgabeformat. Die DCC-übergreifende Parameter-Zuordnung ist in Chaos' V-Ray-für-Houdini-Referenz dokumentiert.

Octane für Houdini

Octane für Houdini läuft auf unserem RTX-5090-GPU-Worker-Tier. Wird hauptsächlich von Motion-Design-Studios verwendet, die Houdini und Cinema 4D für stilisierte Ausgaben verbinden.

Konfigurationshinweise:

Lizenz-Rahmen. Otoy-Render-Node-Lizenzierung.
VRAM-Einschränkungen. Wie bei Octane für Cinema 4D — 32 GB VRAM pro Worker, mit einem aggressiveren Speicherprofil als Redshift (kein Out-of-Core-Pfad). Szenen, die in Redshift in 24 GB passen, benötigen möglicherweise Textur-Downsampling oder Geometrie-Dezimierung, um in 32 GB auf Octane zu passen.

Einreichungsablauf

Drei Einreichungskanäle funktionieren für Houdini-Projekte auf der Farm:

Web-Upload + Einreichen über das Dashboard. Archivieren Sie den $HIP-Ordner als .tar.gz oder .7z, laden Sie ihn über die Website hoch, konfigurieren Sie dann den Job (Renderer, ROP-Node, Frame-Bereich, Ausgabeformat) und reichen Sie ein. Dies ist der häufigste Weg für einmalige Houdini-Jobs und Projekte unter ~50 GB Gesamtupload-Größe.
SFTP für große Projekte. Houdini-Projekte mit Multi-Terabyte-Simulations-Caches sollten über SFTP für wiedereinsetzbare Übertragungen übertragen werden. Siehe für den SFTP-Workflow, Zugangsdaten und den Schwellenwert für den Wechsel vom Web-Upload zu SFTP.
Client App. Die Super Renders Farm Client App verpackt Upload, Einreichung und automatischen Download in einer Desktop-Anwendung. Nützlich für Studios mit wiederkehrenden Einreichungen, bei denen dieselbe Projektstruktur mit Parameteränderungen erneut gerendert wird. Siehe .

Ein Einreichungs-Plugin für Houdini, das sich direkt in die Houdini-UI integriert, ist in Entwicklung, aber noch nicht auf allen Workern vorinstalliert. Derzeit ist der Web-Dashboard-Einreichungsablauf der empfohlene Weg. Die DCC-übergreifende Einreichungs-Anleitung — was auszufüllen ist, wie der Frame-Bereich festgelegt wird, wo Ausgabedateien zu finden sind — findet sich im .

Im Hintergrund ruft der Worker Houdinis Batch-Rendering-Einstiegspunkte auf: hbatch für HIP-Datei-Einreichungen an OBJ/SOP-Kontext-ROPs (Mantra, Karma CPU, Redshift, Arnold, V-Ray, Octane), und husk für USD-Stage-Einreichungen an Karma (CPU oder XPU). Sie müssen die zugrunde liegende Invokation im Allgemeinen nicht kennen, aber wenn Sie unerwartetes Ausgabe-Naming oder Frame-Bereich-Verhalten debuggen, sind die ROP-Ebenen-Einstellungen das, was der Worker über Befehlszeilen-Flags an hbatch/husk übergibt.

Houdini-spezifische Fehler beheben

Für allgemeine DCC-übergreifende Fehlerbehebung (Asset fehlt, Rendering bei Frame N fehlgeschlagen, häufige Ausgabeformat-Probleme) siehe . Houdini-spezifische Fehlermuster, die wir am häufigsten in Support-Tickets sehen:

„Unable to find HDA" oder HDA lädt nicht mit einem veralteten Node-Platzhalter. Der Worker kann die HDA-Datei, die die Szene referenziert, nicht finden. Überprüfen Sie, ob HDAs entweder in die .hip eingebettet sind (Asset-Menü → Operator-Typ-Manager → „In Eingebettet speichern") oder in $HIP/hda/ mit konfiguriertem Suchpfad vorhanden sind. Wenn Sie HDAs aus einer gemeinsam genutzten Studio-Bibliothek referenzieren, kopieren Sie diese vor der Einreichung in den Projektordner.
Cache-Datei beim Rendering nicht gefunden / leere Simulations-Geometrie. Überprüfen Sie, ob die Cache-Dateien tatsächlich vor der Einreichung auf die Festplatte gebakt wurden — öffnen Sie jeden File-Cache-SOP und bestätigen Sie, dass der „Ausgabe"-Tab Dateien am angezeigten Pfad zeigt. Wenn der Pfad einen absoluten Laufwerksbuchstaben verwendet (D:\sim_cache\flip.0001.bgeo.sc), ändern Sie ihn auf $HIP/cache/{node_name}/$F4.bgeo.sc und baken Sie erneut. Die 60-Sekunden-Prüfung vor dem Upload — Datei → Alle aktualisieren, plus ein manueller Scan der File-Cache-SOPs — verhindert die größte Einzelkategorie von Houdini-Render-Fehlern, die wir sehen.
Render-Ausgaben sind komplett leer / schwarze Frames. Überprüfen Sie das „Render Settings"-Prim des ROP (für Karma auf einer Solaris-Stage) oder die Kamerareferenz (für Mantra, Redshift, Arnold, V-Ray, Octane auf /obj-Kontext-ROPs). Die häufigste Ursache ist eine Kamera, die im Viewport gesetzt ist, aber nicht im ROP referenziert wird — der Worker hat keinen Viewport, daher ist die ROP-Ebenen-Kamerareferenz maßgebend.
Karma XPU schlägt sofort mit „OptiX not available" oder „GPU not detected" fehl. Selten auf unserer Farm, da der GPU-Worker-Fleet bestätigte CUDA- und OptiX-Treiberabdeckung hat. Wenn es auftritt, ist die häufigste Ursache ein Worker mitten in einem Update oder einem Treiber-Rollback; reichen Sie 5–10 Minuten später erneut ein oder kontaktieren Sie den Support, wenn das Problem über mehrere Einreichungen hinweg anhält.
Pre-Render-Python-Skript schlägt auf dem Worker fehl. Deaktivieren Sie das Skript oder machen Sie es pfad-portabel. Benutzerdefiniertes Python, das workstation-spezifische Modul-Pfade referenziert (Pipeline-Tools Ihres Studios), UI-Dialoge öffnet oder über hou.system() lokale Binärdateien aufruft, wird nicht auf einem headless Linux-Worker ausgeführt.
Solaris / USD-Asset-Referenzen brechen. USD-Asset-Resolver-Pfade müssen $HIP-relativ sein, einen USD-Resolver-Kontext verwenden, den der Worker laden kann, oder vor der Einreichung über den USD-ROP in eine einzelne zusammengesetzte USD abgeflacht werden. Absolute Pfade in USD-Referenz-Layern sind das häufigste Fehlermuster hier.
Plugin-Versions-Mismatch / Szene lädt nicht. Lokale Plugin-Version unterscheidet sich vom Worker — am häufigsten HtoA 6 → 7 oder Redshift 3.0 → 3.5 Sprünge. Prüfen Sie die Plugin-Version beim Szenenspecichern (sichtbar über den HIP-Datei-Header-Text oder den Plugin-ROP-Menü-Versions-Stempel) und bestätigen Sie, dass der Worker mindestens diese Minor-Version hat. Größere Versions-Sprünge sollten niemals als kompatibel angenommen werden.
Houdini-Versions-Mismatch (20.5-Szene auf 20.0-Worker). Das HIP-Dateiformat enthält Versions-Metadaten; älteres Houdini kann neuere gespeicherte Szenen nicht öffnen. Bestätigen Sie, dass der Worker Houdini ≥ der Szenenspeicher-Version hat, oder speichern Sie die Szene in der Zielversion erneut, wenn absolut notwendig.
OpenCL-Simulation läuft beim Rendering nicht. OpenCL-Simulationen sind Bake-Zeit, nicht Render-Zeit. Baken Sie vor der Einreichung im Cache. Die Farm führt während des Renderings keine Live-OpenCL-Simulationen aus — dies ist beabsichtigt und gilt für FLIP, Pyro, Vellum und alle anderen OpenCL-beschleunigten Solver.
OCIO-Konfigurations-Drift zwischen Einreichung und Worker. Wenn Ihre lokale OCIO-Umgebungsvariable auf eine studio-spezifische Konfiguration zeigt, die auf dem Worker nicht vorhanden ist, rendert die Farbe unter der Standard-Konfiguration des Workers und sieht anders aus. Bündeln Sie die OCIO-Konfigurationsdatei mit dem Projekt, setzen Sie OCIO über den Einreichungs-Umgebungs-Override, oder verwenden Sie Houdinis eingebaute ACES-Konfiguration, die der Worker ebenfalls mitliefert.
Pyro/FLIP-Cache „fehlendes Feld"-Warnung über Houdini-Versionen hinweg. Das Cache-Dateiformat ändert sich gelegentlich über wichtige Houdini-Versionen; ein älterer Cache, der auf einem neueren Houdini geladen wird, lässt manchmal Felder fallen. Cachen Sie die Simulation in der Ziel-Houdini-Version erneut, oder bestätigen Sie, dass der Worker denselben Houdini-Build verwendet, der den Cache geschrieben hat.

Querverweise

— Upload-, Einreichungs- und Download-Workflow (DCC-übergreifend)
— Wie Houdini-Job-Kosten berechnet werden (GPU- vs. CPU-Tier)
— SFTP-Leitfaden, Archivformate, Übertragungen großer Projekte
— DCC-übergreifende Fehlerbehebung
— Desktop-Einreichungs-Wrapper
— Landing-Page (Renderer-Matrix, Hardware, Preisbeispiele)

FAQ

Q: Welche Houdini-Versionen unterstützt die Farm? A: Houdini 19.5, 20.0 und 20.5 sind auf jedem Worker vorinstalliert. Wir verfolgen den Release-Zeitplan von SideFX und stellen neue Major-Builds innerhalb von vier Wochen nach öffentlicher Verfügbarkeit bereit. Sowohl Houdini FX (.hip) als auch Houdini Indie (.hipnc) werden unterstützt. Houdini-Apprentice-Dateien werden gerendert, erzeugen jedoch Wasserzeichen-Ausgaben gemäß den nicht-kommerziellen Lizenzbedingungen von SideFX — für bezahlte Produktionsarbeit speichern Sie aus einer Nicht-Apprentice-Lizenz vor der Einreichung.

Q: Muss ich meine Houdini-Lizenz übertragen, um auf der Farm zu rendern? A: Nein. Wir betreiben Houdini unter Render-only-Nutzung, die das Ausführen von Houdini auf Render-Workern für das Offline-Rendering ermöglicht, ohne einen SideFX-Seat aus dem Lizenz-Pool Ihres Studios zu belegen. Ihre lokale Houdini-Lizenz verbleibt bei Ihnen. Super Renders Farm ist kein SideFX-Partner — die Render-only-Nutzung ist der rechtliche Rahmen, der das Farm-Rendering von Houdini-Szenen ermöglicht.

Q: Soll ich für ein neues Projekt Karma XPU, Karma CPU oder Mantra verwenden? A: Karma XPU für neue Projekte in 2026 — es ist der von SideFX empfohlene Vorwärtspfad, läuft auf unserem RTX-5090-GPU-Tier und ist für die meisten Szenen deutlich schneller als Karma CPU oder Mantra. Verwenden Sie Karma CPU für Szenen, die 32 GB VRAM übersteigen, auf schwere Volumetrics angewiesen sind, die die GPU überlasten, oder OSL-Custom-Shader verwenden, die noch nicht in XPU unterstützt werden. Verwenden Sie Mantra nur, wenn Ihr Projekt an Mantra gebunden ist (eine laufende Produktion, die vor der Viabilität von Karma begann, oder ein Mantra-spezifisches Shader-Feature ohne Karma-Äquivalent). Für neue Projekte standardmäßig Karma verwenden.

Q: Kann die Farm Houdini-Simulationen (Pyro, FLIP, Vellum, RBD) ausführen? A: Nein — Simulationen sind Workstation-Arbeit. Baken Sie alle Simulations-Caches lokal in .bgeo.sc- oder .vdb-Dateien, bevor Sie einreichen. Die Farm rendert gegen vorab gebakte Caches; sie führt keine Live-Simulation als Teil des Render-Jobs aus. Dies ist dasselbe Muster wie Blender- oder Maya-Simulations-Workflows auf den meisten verwalteten Cloud-Farmen.

Q: Mein Projekt verwendet Houdinis Solaris/USD-Pipeline. Wird es korrekt gerendert? A: Ja, mit Karma (CPU oder XPU) als Renderer. Der für Solaris konzipierte Weg ist Karma — beide Renderer konsumieren die USD-Stage nativ und die Solaris/Karma-Integration ist die von SideFX empfohlene Forward-Pipeline. Für Cloud-Einreichungen flachen Sie entweder die USD-Stage zu einer einzelnen zusammengesetzten .usd-Datei über den USD-ROP ab, oder bündeln Sie den vollständigen $HIP/usd/-Verzeichnisbaum, damit jeder Layer auf dem Worker aufgelöst wird. Drittanbieter-Renderer (Redshift, Arnold) können auch USD-basierte Szenen rendern, wenn ihre Houdini-Integration dies unterstützt — überprüfen Sie lokal an einem einzelnen Frame, bevor Sie eine vollständige Sequenz einreichen.

Q: Meine Szene verwendet benutzerdefinierte HDAs aus der gemeinsam genutzten Bibliothek unseres Studios. Wird die Farm diese finden? A: Die Farm findet keine HDAs auf dem gemeinsam genutzten Netzlaufwerk Ihres Studios (\\studio-fs\hda\... oder ähnlich). Betten Sie die HDAs entweder in die .hip über Asset-Menü → Operator-Typ-Manager → „In Eingebettet speichern" ein, oder kopieren Sie die .hda/.otl-Dateien in $HIP/hda/ vor dem Archivieren des Projekts. Überprüfen Sie mit hou.hda.loadedFiles() aus der Python-Shell, dass jedes geladene HDA unter $HIP aufgelöst wird oder ein Stock-SideFX-Asset ist.

Q: Wie verpacke ich ein Houdini-Projekt mit Simulations-Caches? A: Baken Sie jede Simulation lokal in $HIP/cache/{solver_name}/$F4.bgeo.sc (oder .vdb für Volumes), bevor Sie einreichen. Überprüfen Sie, ob die Cache-Dateien an den erwarteten Pfaden vorhanden sind, über Datei → Alle aktualisieren. Archivieren Sie den gesamten $HIP-Ordner — einschließlich des cache/-Unterordners — als .tar.gz oder .7z. Bei Caches über einige hundert Gigabyte verwenden Sie SFTP statt des Web-Formulars. Die Farm rendert gegen die gebakten Caches; die Simulation selbst läuft auf Ihrer Workstation, nicht auf einem Worker-Node.

Q: Wie groß darf ein Houdini-Projekt-Upload sein? A: Es gibt kein hartes Upload-Größenlimit, aber wir empfehlen, einen einzelnen Browser-Upload unter ~50 GB zu halten. Darüber hinaus wechseln Sie zu SFTP für wiedereinsetzbare Übertragungen — siehe . Die Farm hat Multi-Terabyte-Houdini-Sim-Renderings abgewickelt, alle via SFTP mit beibehaltener korrekter Verzeichnisstruktur hochgeladen.

Q: Mein Mantra-Rendering ist auf der Farm viel langsamer als lokal. Ist das zu erwarten? A: Mantras Frame-Geschwindigkeit auf unserem CPU-Worker-Tier (Dual Xeon E5-2699 V4) ist vergleichbar mit einer High-End-Workstation. Wenn Sie deutlich langsamere Pro-Frame-Zeiten als lokal sehen, sind die wahrscheinlichsten Ursachen: eine andere Sampling-Konfiguration auf dem Worker (Mantra liest Samples aus dem ROP — bestätigen Sie, dass die ROP-Einstellungen übereinstimmen), oder lokale OpenCL-Beschleunigung, die auf dem reinen CPU-Tier des Workers nicht aktiv ist. Die strukturelle Lösung ist die Migration: Karma XPU auf unserem GPU-Tier ist für die meisten Szenen deutlich schneller als Mantra, und Karma ist der Weg, den SideFX empfiehlt.

Q: Unterstützt die Farm Houdinis PDG/TOPs für verteiltes Aufgaben-Management? A: PDG ist workstation-seitige Orchestrierung; die Farm verwendet ihr eigenes Queue- und Worker-Zuteilungssystem. Sie können PDG lokal zum Erstellen und Baken von Assets verwenden und dann die finalen ROP-Jobs über das Web-Dashboard oder die Client App bei der Farm einreichen. Direkte PDG-gesteuerte Einreichungen an externe Farmen stehen auf unserer Roadmap, sind aber noch kein erstklassiger Workflow.

Q: Wie werden die Kosten für Houdini-Cloud-Rendering berechnet? A: Die Kosten für Houdini auf der Farm richten sich nach dem Worker-Tier des Renderers — GPU-Tarife für Karma XPU, Redshift und Octane; CPU-Tarife für Karma CPU, Mantra, Arnold und V-Ray für Houdini. Die Pro-Frame-Komplexität (Sample-Anzahl, AOV-Anzahl, Ausgabeauflösung) bestimmt die Pro-Frame-Kosten; die Renderer-Wahl bestimmt den Pro-Node-Stunden-Tarif. Simulationen kosten nur extra, wenn Sie diese auf der Farm ausführen (wir empfehlen, lokal zu cachen und den Cache hochzuladen). Für Preisdetails siehe oder schätzen Sie mit unserem .

---