Houdini Karma XPU auf einer Cloud-render-farm: Ein technischer Leitfaden 2026

Einführung

Karma XPU ist der Renderer, auf den eine wachsende Zahl von Houdini-Studios standardisiert, und das aus gutem Grund: Es ist SideFX' eigener Produktions-Renderer, er lebt nativ in Solaris und USD, und seine hybride CPU-plus-GPU-Ausführung lässt Look-Dev fast interaktiv wirken. Auf einer einzelnen Workstation ist er eine Freude. Die Schwierigkeiten beginnen, wenn Sie eine Karma XPU-Szene von Ihrer Workstation nehmen und versuchen, einige hundert Frames davon auf einer Farm zu rendern.

Auf Farm-Ebene hört Karma XPU auf, sich wie eine schnellere Version von Karma CPU zu verhalten, und beginnt, sich wie ein anderes Tier zu verhalten. VRAM wird zu einer harten Obergrenze statt zu einem Richtwert. Simulationen, die interaktiv problemlos liefen, können überhaupt nicht verteilt werden, bis sie gecacht sind. Der Renderer kann bei einem aufwändigen Frame leise auf CPU zurückfallen und Sie fragen lassen, warum ein bestimmter Shot sechsmal länger gedauert hat als der benachbarte. Das sind keine Bugs – das ist die Architektur, die sich unter Last zeigt.

Wir betreiben seit Jahren verteiltes Rendering für Houdini-Arbeiten, und Karma XPU ist einer der verfügbaren Engines auf unserer Houdini Cloud-render-farm neben Redshift, Mantra, Arnold, V-Ray for Houdini und Octane. Dieser Leitfaden ist der technische Deep-Dive: Was Karma XPU tatsächlich ist, wie er sich von Karma CPU und Mantra unterscheidet, was sich ändert, wenn Sie ihn headless auf einer Farm rendern, wie das Simulations-Caching zuerst funktionieren muss und wie Sie zwischen Karma XPU und Redshift für einen bestimmten Shot entscheiden. Wenn Sie stattdessen eine schrittweise Szenen-Vorbereitungs-Checkliste wünschen, deckt unser Houdini Setup-Leitfaden diesen Bereich ab; dieser Artikel setzt voraus, dass Sie sich bereits mit Solaris auskennen.

Warum Karma XPU schwieriger zu skalieren ist als es aussieht

Das Wichtigste zu verstehen bei Karma XPU ist, dass „XPU" kein Renderer ist – es ist ein Ausführungsmodus. Karma ist ein einzelner USD-Render-Delegate, und XPU ist der Pfad, der Arbeit gleichzeitig an Ihre CPU-Kerne und Ihre NVIDIA-GPU verteilt, wobei beide Geräte Samples zum selben Bild beitragen. Karma CPU ist derselbe Delegate mit deaktivierter GPU. Dieses Design ist auf einer Workstation elegant und auf einer Farm unhandlich, aus vier Gründen.

Erstens läuft der GPU-Pfad auf OptiX, was bedeutet, dass er Geometrie, Texturen und Beschleunigungsstrukturen in den GPU-VRAM lädt. Wenn eine Szene in den VRAM passt, erhalten Sie den vollen hybriden Geschwindigkeitsvorteil. Wenn nicht, neigt Karma XPU dazu, zur CPU-Ausführung zurückzufallen, anstatt Daten zu streamen, wie es manche GPU-Renderer tun. Das Rendering wird zwar abgeschlossen, aber mit einem Bruchteil der erwarteten Geschwindigkeit – und nichts in einem normalen Job-Log macht darauf aufmerksam.

Zweitens ist XPU jünger als die Engines, mit denen er konkurriert. Houdini 20.0 war sein erster Meilenstein für Produktionsstabilität, und 20.5 erweiterte die Feature-Abdeckung erheblich, aber einige Features bevorzugen noch immer Karma CPU. Wenn ein Shot einen davon verwendet, kann ein Teil des Renderings lautlos auf den CPU-Pfad fallen.

Drittens ist Version-Pinning wichtiger als die meisten Leute erwarten. Eine Szene, die in einem Houdini Point Release erstellt wurde, sollte auf Farm-Nodes rendern, die dieses Release ausführen; Karmas Oberfläche hat sich zwischen 20.0, 20.5 und der 21er-Linie genug verändert, dass Cross-Version-Renderings nicht als selbstverständlich angenommen werden sollten.

Viertens – und das stolpert beim ersten Mal jeden – Simulationen sind keine Frames. Sie können ein Pyro- oder FLIP-Setup nicht einfach an eine Farm übergeben und erwarten, dass es sich verteilt. Das verdient einen eigenen Abschnitt, und er folgt unten.

Karma XPU vs. Karma CPU vs. Mantra

Mit Houdini werden drei Renderer mitgeliefert, und die Wahl zwischen ihnen ist die erste echte Entscheidung für jeden Farm-Job. Sie sind nicht austauschbar.

Mantra ist die Legacy-Engine. Sie existiert schon vor USD, arbeitet auf Houdinis eigenem Scene-Description-Pipeline und verwendet VEX-basierte (CVEX) Shader anstelle von MaterialX. SideFX hat sie nicht entfernt und sie ist voll funktionsfähig, erhält aber keine neuen Features – die Richtung ist klar Karma. Mantra verdient seinen Platz an zwei Stellen: Pipelines mit umfangreichen Bibliotheken von VEX-Shadern, die teuer umzubauen wären, und gelegentliche Micropolygon- oder Displacement-Verhalten, die noch kein sauberes Karma-Äquivalent haben. Wenn Ihre Shader CVEX sind, werden sie nicht auf Karma übertragen, und allein das kann einen Shot auf Mantra halten.

Karma CPU ist der Referenz-Pfad. Er ist USD-nativ, implementiert den vollständigen Karma-Feature-Satz und ist der Ground Truth, wenn Sie wissen müssen, wie ein Frame „aussehen soll". Er läuft multi-threaded über CPU-Kerne ohne GPU-Beteiligung. Auf einer Farm mit einer großen CPU-Flotte ist er wirklich praktisch – er umgeht die VRAM-Obergrenze vollständig, was ihn zur vernünftigen Wahl für Szenen macht, die zu schwer sind, um bequem in den GPU-Speicher zu passen.

Karma XPU ist der hybride beschleunigte Pfad: CPU plus NVIDIA-GPU, beide berechnen Samples in denselben Frame, mit MaterialX-Shading und derselben USD-nativen Grundlage wie Karma CPU. Mit der GPU-CPU-Kombination rendert er interaktives Look-Dev und In-VRAM-Final-Frames schneller als jeder CPU-only-Pfad, und er ist der natürliche Standard für neue Solaris-Pipelines. Seine Einschränkung ist, dass er ein Feature-Subset von Karma CPU ist – die meisten verbleibenden Lücken betreffen exotische Volume-, Shading- oder AOV-Edge-Cases, und SideFX schließt sie Release für Release. Die ehrliche Produktionsregel ist, einen Vergleichs-Frame sowohl auf XPU als auch auf CPU zu rendern, bevor Sie eine Sequenz auf XPU festlegen, denn wenn XPU und CPU nicht übereinstimmen, ist CPU korrekt.

Aspekt	Mantra	Karma CPU	Karma XPU
Szenen-Grundlage	Vor-USD (native Pipeline)	USD / Solaris	USD / Solaris
Compute	CPU	CPU	CPU + NVIDIA GPU
Shading	VEX / CVEX	MaterialX	MaterialX
Feature-Vollständigkeit	Eingefroren (keine neuen Features)	Referenz (vollständig)	Subset von CPU, reift heran
VRAM-Obergrenze	Keine	Keine	Ja – GPU-Speicher-gebunden
Geeignet für	Legacy-VEX-Pipelines	Schwere Szenen, Ground-Truth	USD-natives Look-Dev + Final Frames im VRAM

Karma XPU Headless auf einer Cloud-render-farm ausführen

Interaktiv rendern Sie, indem Sie den Knopf im Solaris-Viewport drücken. Auf einer Farm ist dieser Knopf ein Kommandozeilenprogramm namens husk. Es ist SideFX' eigenständiger USD-Renderer – ein leichtgewichtiger Prozess, der eine komponierte USD-Stage lädt und rendert, ohne eine vollständige interaktive Houdini-Session zu starten. Er wird mit Houdini geliefert und ist die kanonische Art, Karma im großen Maßstab zu rendern. Eine Übergabe sieht im Wesentlichen so aus:

husk --renderer Karma \
     --frame 1001 --frame-count 50 \
     --output /project/render/shot_010.$F4.exr \
     /project/usd/shot_010.usd

Jeder Farm-Node führt husk gegen dieselbe USD-Stage aus, aber für einen anderen Frame-Bereich, was die Frame-Level-Distribution ermöglicht. Die Stage selbst ist eine vollständig komponierte .usd/.usdc-Datei, die alle Geometrien, Lichter, Kameras und Materialien referenziert. Ihre AOVs sind keine Kommandozeilen-Flags – sie sind USD Render Var Prims, die aus den Render Settings und Render Var LOPs in die Stage eingebacken sind, sodass husk sie ohne ein aktives Houdini-Netzwerk liest. Beauty, Alpha, Normals, Albedo und der Rest reisen innerhalb des USD.

Einige farm-spezifische Mechanismen sind es wert zu kennen. Karma unterstützt Checkpointing, das Zwischenrender-Zustände in Sample-Intervallen schreibt, damit ein langer Hero-Frame fortgesetzt werden kann, anstatt neu zu starten, wenn ein Node ins Stocken gerät – wertvoll für Tausend-Sample-Einzelframes, weniger relevant für moderate-Sample-Animationen, bei denen jeder Frame günstig neu zu machen ist. Denoising läuft entweder über den OptiX-Denoiser auf der GPU oder Intel OIDN auf der CPU; auf einer Farm bevorzugen wir OIDN, wenn die zeitliche Stabilität über viele Nodes hinweg wichtig ist, da es identische Ausgabe unabhängig davon produziert, welche Maschine den Frame verarbeitet hat.

Zum Thema Lizenzierung: Karma ist kein separat lizenziertes Plugin wie Redshift, Arnold, V-Ray und Octane – er wird mit Houdini selbst gebündelt. Wir betreiben Houdini und Karma unter render-only-Nutzung, um Ihre Jobs zu rendern; wir sind kein SideFX-Partner und verkaufen keine Houdini-Lizenzen weiter. Da unsere Farm vollständig verwaltet ist, loggen Sie sich nicht per Remote-Desktop in einen Node ein, installieren Houdini selbst oder übergeben uns eine Lizenz – Sie laden Ihre Szene und gecachten Daten hoch, und die render-seitige Lizenzierung auf unseren Nodes wird als Teil des Betriebs des Dienstes gehandhabt. Für die kommerziellen Engines im Houdini-Stack sind die Redshift-, Arnold-, V-Ray- und Octane-Lizenzen in der Render-Rate enthalten.

Der Super Renders Farm Houdini-Stack

Eine render farm, die nur eine Engine betreibt, zwingt jeden Shot durch einen Satz von Kompromissen. Houdini-Arbeit kooperiert selten damit, daher betreibt unsere Houdini Cloud-render-farm den vollständigen Satz: Karma (in beiden XPU- und CPU-Modi), Mantra, Redshift, Arnold, V-Ray for Houdini und Octane. Der Sinn der Breite ist, dass Sie die richtige Engine pro Shot statt pro Studio wählen – Karma XPU für den USD-nativen Look-Dev-Pass, Karma CPU für den volume-schweren Hero-Frame, der nicht in den VRAM passt, Redshift für die geschwindigkeitskritische Sequenz, Mantra für das Legacy-Shader-Setup.

Die Hardware darunter teilt sich entlang derselben CPU/GPU-Linie auf, die Houdini-Arbeit macht. Unsere CPU-Flotte trägt mehr als 20.000 CPU-Kerne bei, wo der Großteil der Produktions-Renderings tatsächlich stattfindet – branchenweit und auf unserer Farm ist CPU-Rendering immer noch der größere Anteil an Jobs. Diese CPU-Kapazität macht Karma CPU und Mantra im Sequenz-Maßstab praktisch und fängt Karma XPU auf, wenn ein Frame zu schwer für die GPU ist. Für GPU-Arbeit betreiben unsere dedizierten GPU-Maschinen NVIDIA RTX 5090-Karten mit je 32 GB VRAM. Für Karma XPU speziell ist diese 32-GB-Zahl die wichtigste: VRAM ist die effektive Obergrenze dafür, wie komplex eine Szene sein kann, bevor XPU aufhört, auf der GPU zu beschleunigen. Ein 4K-UDIM-Textur-Set, eine dichte instanziierte Umgebung oder ein hochauflösendes VDB können dieses Budget jeweils schnell aufbrauchen, und je größer die Karte, desto weiter kommen Sie, bevor das Rendering leise auf CPU wechselt. Wenn Sie GPU-gebundene Arbeit im Allgemeinen abwägen, gehen unsere RTX 5090 GPU-Rendering-Hinweise tiefer auf die Karte ein, und die übergreifende GPU render farm-Seite behandelt die Flotte.

Die Abrechnung folgt der Hardware: CPU-Rendering wird pro GHz-Stunde gemessen und GPU-Rendering pro OctaneBench-Stunde, sodass eine Karma CPU-Sequenz und eine Redshift-Sequenz nach den Einheiten berechnet werden, die die tatsächlich geleistete Arbeit beschreiben. Da Karma XPU beide Geräte nutzen kann, ist das klarste mentale Modell, dass es als GPU-Zeit abgerechnet wird, wenn es auf einem GPU-Node läuft und im VRAM bleibt, wobei der CPU-Beitrag mitläuft – ein weiterer Grund, die VRAM-Obergrenze zu respektieren.

Simulations-Caching: Der Schritt, den Sie nicht überspringen können

Hier ist das wichtigste Konzept für das Rendering von Houdini auf einer Farm und dasjenige, das am wahrscheinlichsten einen Tag verschwendet, wenn es missverstanden wird: Frames sind embarrassingly parallel, aber Simulationen sind es nicht.

Frame 1042 einer gerenderten Animation braucht Frame 1041 nicht zuerst – beide können gleichzeitig auf separaten Maschinen rendern. Diese Unabhängigkeit ist der einzige Grund, warum render farms funktionieren. Eine Simulation ist das Gegenteil. Frame 1042 einer Pyro-Sim wird aus dem Zustand des Rauchs bei Frame 1041 berechnet, der von 1040 kam, all den Weg zurück zum ersten Frame. Sie können die Mitte einer Sim nicht berechnen, ohne alles davor, der Reihe nach, auf einer Maschine zu berechnen. Geben Sie einer Farm eine rohe Simulation und es gibt nichts zu verteilen.

Die Lösung ist deterministisch und nicht verhandelbar: Zuerst simulieren, auf die Festplatte cachen, dann den Cache auf der Farm rendern. Die Simulation läuft sequenziell auf einer Maschine (oder einer dedizierten Sim-Box) und schreibt das Ergebnis jedes Frames auf die Festplatte. Diese Cache-Dateien – jetzt statische, frame-unabhängige Daten – sind das, was die Farm rendert. Die Render-Nodes simulieren nie neu; sie lesen vorberechnete Geometrie und Volumes und rendern Frames parallel wie jede andere Animation.

Was Sie cachen, hängt vom Solver ab:

Simulation	Solver	Cache-Format	Hinweise
Rauch / Feuer	Sparse Pyro	.vdb	Branchenstandard sparse Volumes; direkt in die Render-Stage einlesbar
Flüssigkeiten	FLIP	.bgeo.sc Partikel → vermaschte Oberfläche	Das Vermaschen aus gecachten Partikeln ist frame-unabhängig, also kann es separat auf der Farm ausgeführt werden
Stoff / Korn / Softbody	Vellum	.bgeo.sc	Hero-Stoff-Caches werden schnell groß – achten Sie auf Speicherdurchsatz
Starre Körper, Crowds, Instanzen	RBD / Agents	.bgeo.sc oder USD	USD (PointInstancer) ist die sauberste Übergabe an Karma

Ein Detail, das erwähnenswert ist: Es gibt einen echten Unterschied zwischen der Simulation selbst und der Arbeit stromabwärts davon. FLIP-Surfacing – das Umwandeln gecachter Partikel in ein Render-Mesh – hängt nur von den eigenen Partikeln jedes Frames ab, nicht vom vorherigen Frame, sodass dieser Schritt parallelisierbar ist und als eigener Pass auf die Farm geschickt werden kann, auch wenn die zugrunde liegende Sim es nicht konnte. Das zunehmend verbreitete Muster in Houdini 20-plus-Pipelines ist das direkte Cachen von Geometrie zu USD, sodass husk es nativ zur Render-Zeit liest ohne SOP-zu-USD-Übersetzungsschritt auf dem Node.

Hier verdient PDG/TOPs seinen Platz. PDG ist Houdinis abhängigkeitsbasierter Task-Graph, und er modelliert genau die Beziehung, die Farm-Rendering benötigt: „Cache diese Simulation, und erst wenn der Cache existiert, rendere diese Frames daraus." Ein File Cache TOP produziert den Sim-Cache als Output-Abhängigkeit; ein Render-Task stromabwärts wartet darauf und fächert dann pro Frame auf. PDG kann sowohl das Caching als auch das husk-Rendering über seine Scheduler-Nodes antreiben, weshalb er zum Rückgrat seriöser Houdini-Farm-Pipelines geworden ist.

Ein praktischer Hinweis aus der Erfahrung: Stoff- und hochauflösende Flüssigkeitscaches können auf Gigabytes pro Frame anwachsen, und wenn Dutzende von Nodes dieselbe Sequenz gleichzeitig aus dem gemeinsamen Speicher ziehen, wird der Lesedurchsatz – nicht das Compute – zum Engpass. Wir unterstützen Uploads ohne feste Größenbeschränkung (wir empfehlen, unter 300 GB pro Upload zu bleiben und SFTP oder die Client-App darüber zu verwenden) und akzeptieren .tar-, .tar.gz- und .7z-Archive – aber nicht .zip. Packen Sie schwere Cache-Sequenzen als .tar.gz um, bevor sie hochgeladen werden. Gerenderte Ausgabe bleibt 45 Tage nach Abschluss eines Jobs verfügbar, was komfortabel lang genug ist, um eine vollständige Sequenz herunterzuladen.

Einen Karma XPU-Job einreichen, von Anfang bis Ende

Die Teile zusammensetzend läuft ein sauberer Karma XPU-Farm-Job in einer vorhersehbaren Reihenfolge:

1. Jede Simulation cachen. Pyro zu VDB, FLIP und Vellum zu .bgeo.sc oder USD. Bestätigen Sie, dass die Caches vollständig und frame-zusammenhängend sind – ein fehlender mittlerer Frame zeigt sich als Loch im Rendering, nicht als Fehler.
2. Eine komponierte USD-Stage exportieren mit Ihren in die Stage eingebackenen Render Settings und Render Var Prims, alle Asset-Pfade aufgelöst, sodass sie von einem Render-Node aus erreichbar sind statt von den lokalen Laufwerken Ihrer Workstation.
3. Das Projekt packen – Szene, Caches, Texturen und jede OCIO-Konfiguration – und hochladen. Da die Farm vollständig verwaltet ist, gibt es keinen Node, in den Sie sich einloggen, und keine Houdini-Installation, die Sie beobachten müssen.
4. Die Engine wählen. Karma XPU für die In-VRAM-Look-Dev- und Final-Passes; wechseln Sie zu Karma CPU für Frames, von denen Sie wissen, dass sie für 32 GB zu schwer sind; greifen Sie auf Redshift zurück, wo Geschwindigkeit Priorität hat.
5. Die Frames verteilen. Die Farm verteilt den Frame-Bereich auf Nodes, wobei jeder husk für seinen Bereich ausführt. Sie beobachten den Fortschritt statt ihn zu verwalten.
6. Denoisen und herunterladen. Holen Sie die EXRs (mit angewandtem OIDN, wenn Sie es konfiguriert haben) innerhalb des 45-Tage-Fensters.

Das wiederkehrende Versagen-Muster bei all dem ist die Asset-Auflösung. USD löst Pfade relativ zur Layer auf, die sie referenziert, oder als absolute Pfade, und ein absoluter Pfad, der auf Ihr lokales Workstation-Laufwerk zeigt, wird auf einem Render-Node einfach fehlende Texturen oder fehlende Geometrie produzieren – oft ohne harten Fehler, nur Schwarz wo ein Asset sein sollte. Lösen Sie Pfade gegen einen gemeinsamen Projekt-Root auf, halten Sie Ihre OCIO-Konfiguration konsistent über den Job hinweg, sodass Farbe nicht driftet, und flatten Sie benutzerdefinierte HDA-Abhängigkeiten in das USD vor dem Export, sodass ein Node kein Plugin braucht, das ihm nie gegeben wurde. Für die breiteren Grundlagen, wie Cloud Rendering diese Art von Arbeit verteilt, setzt unser Cloud-render-farm-Überblick den Kontext.

Wann Sie Karma XPU vs. Redshift wählen

Sowohl Karma XPU als auch Redshift können Houdini auf einer GPU-Farm rendern, und die Wahl dreht sich nicht darum, welcher „besser" ist – es geht darum, was Shot und Pipeline brauchen. Sie kommen aus unterschiedlichen Philosophien. Karma XPU ist physisch basiert, USD-nativ, MaterialX-geshaded und vom gleichen Anbieter wie Houdini selbst. Redshift ist ein ausgereifter, überwiegend biased GPU-Renderer mit über einem Jahrzehnt Produktionsgeschichte, einem Houdini-Plugin und – das ist seine herausragende Farm-Eigenschaft – einem robusten Out-of-Core-System, das bei einer zu großen Szene anstandslos von VRAM zu System-RAM und NVMe überfließt. Wo Karma XPU bei VRAM-Überlauf dazu neigt, auf CPU zurückzufallen, rendert Redshift weiter auf der GPU mit einer vorhersehbaren Leistungseinbuße, weshalb eine 32-GB-Karte unter Redshift Szenen mit weit mehr als 32 GB Texturen bewältigen kann.

Dieser Unterschied treibt den Großteil der Entscheidung an:

Wählen Sie Karma XPU wenn…	Wählen Sie Redshift wenn…
Die Pipeline ist USD / Solaris-nativ	Rohe GPU-Geschwindigkeit Priorität hat
Shader sind MaterialX	Die Szene VRAM-schwer ist (große VDBs, riesige Textur-Sets)
Sie physisch basiertes Lichttransport wollen, keine GI-Cache-Flicker	Sie Out-of-Core-Stabilität über der VRAM-Obergrenze benötigen
Sie auf den vollständigen SideFX-Stack standardisieren	Das Team bereits Redshift-Shader und Look-Dev hat
Der Renderer-Kosten-Hebel wichtig ist (Karma wird mit Houdini geliefert)	Sie über C4D / Maya / Houdini hinweg arbeiten und ein einheitliches Aussehen wollen

Die anderen Engines füllen die Ränder aus. Arnold ist die Wahl für schweres VFX mit komplexem Subsurface, Haaren und Volumes, oder wenn eine Pipeline bereits von Arnold-spezifischen Shadern abhängt – pinnen Sie einfach die HtoA-Version auf die Farm-Nodes und konvertieren Sie Texturen vorab in .tx. V-Ray for Houdini eignet sich für Studios, die bereits auf V-Ray über 3ds Max und Maya standardisiert sind und ein einheitliches Aussehen über DCCs hinweg wünschen; mehr zur GPU-Seite dieses Vergleichs finden Sie auf unserer Redshift-Seite. Octane eignet sich für Teams, die bereits in seinem spektralen, node-basierten Ökosystem sind, und wird sauber pro OctaneBench-Stunde abgerechnet. Wenn Sie stattdessen einen breiter gefassten Anbieter-für-Anbieter-Vergleich wünschen statt einen Engine-Vergleich, deckt unser Houdini render farm-Vergleich diese Entscheidung ab.

Ein Vorsicht-Hinweis speziell für Karma XPU auf einer Farm: Da eine Sequenz sowohl leichte Frames (GPU-beschleunigt) als auch schwere Frames (lautlos CPU-gebunden) enthalten kann, können die Renderzeiten stark variieren über das, was wie ein einheitlicher Job aussieht. Die Lösung ist ein Pre-Flight-Speicher-Check am schwersten Frame, bevor Sie den gesamten Bereich festlegen – wenn er über 32 GB VRAM hinausgeht, entscheiden Sie bewusst zwischen Karma CPU auf der CPU-Flotte und Redshifts Out-of-Core-Pfad, anstatt den Renderer mid-Sequenz für Sie entscheiden zu lassen. Jenseits der Engine selbst gelten noch die Standard-Farm-Fallstricke: Pinnen Sie die Houdini-Version, halten Sie die Denoiser-Konfiguration explizit statt auf Node-Standardwerte zu vertrauen, und verifizieren Sie, dass jeder Asset-Pfad von einem Node aus auflösbar ist und nicht nur von Ihrer Maschine.

Für offizielle Renderer-Details pflegt SideFX ausführliche Dokumentation sowohl für Karma als auch für den husk-Kommandozeilen-Renderer – lesenswert vor Ihrer ersten großen Einreichung.

FAQ

Q: Was ist der Unterschied zwischen Karma XPU und Karma CPU? A: Sie sind derselbe USD-native Karma-Renderer in zwei Ausführungsmodi. Karma CPU läuft nur auf CPU-Kernen und implementiert den vollständigen, referenzqualitativen Feature-Satz. Karma XPU fügt Ihre NVIDIA-GPU hinzu und rendert gleichzeitig auf CPU und GPU für Geschwindigkeit, unterstützt aber derzeit ein Subset der Features von Karma CPU und ist durch GPU-VRAM begrenzt. Die praktische Gewohnheit ist, einen Frame auf Karma CPU zu bestätigen, wenn die XPU-Ausgabe seltsam aussieht, da CPU der Ground Truth ist.

Q: Brauche ich eine SideFX- oder Houdini-Lizenz, um Karma auf einer Cloud-render-farm zu rendern? A: Nicht von Ihrer Seite, auf einer vollständig verwalteten Farm. Karma ist mit Houdini gebündelt statt separat lizenziert wie Redshift oder Octane, und wir betreiben Houdini unter render-only-Nutzung, um Ihre Jobs zu rendern – wir sind kein SideFX-Partner und verkaufen keine Houdini-Lizenzen weiter. Sie laden Ihre Szene und Caches hoch; die render-seitige Lizenzierung auf unseren Nodes wird als Teil des verwalteten Dienstes gehandhabt.

Q: Warum müssen Simulationen vor dem Rendern auf einer Farm gecacht werden? A: Weil Simulationen sequenziell sind und Frames es nicht sind. Jeder Simulations-Frame hängt vom Zustand des Frames davor ab, sodass eine Sim der Reihe nach auf einer Maschine gelöst werden muss. Render-Frames hingegen sind unabhängig und können auf Hunderten von Nodes gleichzeitig laufen. Das Cachen der fertigen Simulation auf die Festplatte (VDB für Pyro, .bgeo.sc oder USD für FLIP und Vellum) verwandelt sie in statische Daten, die die Farm parallel rendern kann ohne erneut zu simulieren.

Q: Wie geht Karma XPU mit einer Szene um, die den GPU-VRAM überschreitet? A: Im Gegensatz zu Redshift, das Out-of-Core aus dem System-Speicher streamt, neigt Karma XPU dazu, zur CPU-Ausführung zurückzufallen, wenn eine Szene nicht in den VRAM passt. Das Rendering wird zwar abgeschlossen, aber die GPU-Beschleunigung geht verloren und der Frame kann dramatisch länger dauern – ohne offensichtliche Hinweise im Log. Für Szenen, von denen Sie wissen, dass sie schwer sind, ist es besser, bewusst zwischen Karma CPU auf der CPU-Flotte und Redshifts Out-of-Core-Pfad zu wählen, als den Fallback mid-Sequenz passieren zu lassen.

Q: Ist Karma XPU schneller als Redshift? A: Das hängt vom Shot ab. Redshift ist ein hochoptimierter, meist biased GPU-Renderer und oft schneller bei typischen Produktionsszenen, besonders VRAM-schweren, wo sein Out-of-Core-System die Arbeit auf der GPU hält. Karma XPU ist physisch basiert und vollständig USD-nativ, was für Solaris-Pipelines und MaterialX-Shading besser passt, auch wenn es mehr Samples für äquivalentes Rauschen benötigt. Geschwindigkeit allein entscheidet es nicht – Pipeline-Passung und VRAM-Headroom tun es normalerweise.

Q: Was ist husk und muss ich es direkt verwenden? A: husk ist SideFX' eigenständiger Kommandozeilen-USD-Renderer, und es ist das, was tatsächlich Karma auf einem Farm-Node rendert – ein leichtgewichtiger Prozess, der eine komponierte USD-Stage ohne eine vollständige Houdini-Session lädt. Auf einer verwalteten Farm rufen Sie es nicht von Hand auf; Sie übergeben Ihre Szene und die Farm führt husk pro Frame auf Nodes für Sie aus. Das Wissen um seine Existenz hilft Ihnen zu verstehen, warum ein sauberer, vollständig aufgelöster USD-Export so wichtig ist.

Q: Kann PDG/TOPs ein Karma-Rendering auf der Farm steuern? A: Ja. PDG modelliert die Abhängigkeit zwischen dem Cachen einer Simulation und dem Rendern daraus, und seine Scheduler-Nodes können sowohl den File-Cache-Schritt als auch das nachgelagerte husk-Rendering auf einer Farm verteilen. Es ist die Standardmethode, mit der ernsthafte Houdini-Pipelines „zuerst cachen, dann das Rendering pro Frame auffächern" ausdrücken, und es hält die sequenziellen und parallelen Teile des Jobs automatisch in der richtigen Reihenfolge.

Q: Welche Houdini-Renderer kann ich neben Karma XPU verwenden? A: Unser Houdini-Stack betreibt Karma in beiden XPU- und CPU-Modi, plus Mantra, Redshift, Arnold, V-Ray for Houdini und Octane. Diese Bandbreite ermöglicht es Ihnen, die Engine dem Shot anzupassen – Karma XPU für USD-natives Look-Dev, Karma CPU für VRAM-schwere Hero-Frames, Redshift für Geschwindigkeit und Out-of-Core, Mantra für Legacy-VEX-Shader, und Arnold, V-Ray oder Octane, wo eine Pipeline bereits von ihnen abhängt.