Cloud Rendering für VFX-Compositing: Comp vs. 3D

Einführung

Die meisten Inhalte zum Cloud Rendering sind für einen einzigen Workload geschrieben: eine 3D-Szene, die Bucket für Bucket durch einen Path Tracer läuft, bis das Rauschen verschwindet und ein Frame fertig ist. Diese Einordnung trifft für einen Redshift- oder V-Ray-Job zu, ist aber für ein Compositing-Rendering fast nutzlos. Ein Comp sampelt keine Lichtpfade. Es wertet einen Node-Graph gegen Footage und bereits vorhandene Passes aus, und das, was über Dauer und Kosten entscheidet, ist fast nie die Anzahl der GPU-Samples.

Diese Unterscheidung ist wichtiger, als es an der Oberfläche wirkt, denn beide Workloads werden in generischen Ratgebern zu „Cloud Rendering" ständig in einen Topf geworfen. Ein Compositor, der zum ersten Mal ein Nuke-Skript oder ein After-Effects-Projekt auf eine Farm überträgt und dasselbe GPU-gebundene Verhalten wie bei einem 3D-Render erwartet, wundert sich am Ende, warum ein Comp ohne Simulationen und ohne Raytracing trotzdem langsam ist, oder warum es auf eine Art schnell ist, die nichts mit der gewählten GPU-Stufe zu tun hat. In diesem Leitfaden geht es genau um diese Lücke: was ein Comp-Rendering auf einer Farm tatsächlich tut, wie es sich mechanisch von einem 3D-Render unterscheidet und wann es sich lohnt, Compositing-Arbeit in die Cloud zu verlagern, statt eine Workstation über Nacht laufen zu lassen.

Auf unserer render farm bei Super Renders Farm arbeiten wir täglich mit beiden Seiten dieser Pipeline: vom 3D-Rendering, das den Beauty Pass und die AOVs erzeugt, bis zum Compositing-Rendering, das diese zu einem finalen Shot zusammensetzt. Beide teilen sich die Hardware, aber beim Render-Verhalten haben sie sonst wenig gemeinsam, und dieses Verständnis macht einen Comp-Render-Job vorhersehbar statt rätselhaft.

Pipeline-Diagramm des mehrschichtigen EXR-Compositing-Workflows: 3D-Render-Passes fließen in einer mehrschichtigen EXR-Datei zusammen und wandern anschließend in die Compositing-Software und ins finale Grading

Compositing ist ein anderer Render-Workload als 3D-Rendering

Ein 3D-Renderer wie V-Ray, Redshift oder Arnold betreibt Lichttransport: Er verfolgt Strahlen, sampelt Materialien und baut über die Zeit Rauschreduzierung auf, bis ein Bild konvergiert. Diese Arbeit ist pro Pixel tatsächlich rechenintensiv. Deshalb ist 3D-Rendering je nach Engine CPU- oder GPU-lastig, und deshalb hat GPU-Beschleunigung einen so großen Effekt auf 3D-Renderzeiten.

Ein Compositing-Rendering tut nichts davon. Nuke, After Effects, Fusion und ähnliche Tools werten einen Node-Graph aus: ein Bild einlesen, eine Farbkorrektur anwenden, zwei Layer zusammenführen, eine Transformation anwenden, das Ergebnis schreiben. Es gibt kein Sampling und keine Konvergenz. Jede Operation ist ein deterministischer, meist linear-algebraischer Durchlauf über Pixeldaten, und die Mehrzahl dieser Operationen (Merges, Grades, Keyer, Transformationen, die meisten Filter) läuft auf der CPU statt auf der GPU. Eine Handvoll bestimmter Node-Typen (aufwendige Retimes, manche Denoise-Operationen, bestimmte Machine-Learning-Tools) ist GPU-beschleunigt, aber das ist in einem typischen Comp die Ausnahme, nicht die Regel.

Was tatsächlich bestimmt, wie lange ein Comp-Rendering dauert, ist eher ein Datenbewegungsproblem als ein Rechenproblem:

Lesedurchsatz. Ein Comp-Skript liest für jeden Frame Footage und Render-Passes, oft mehrere mehrschichtige EXR-Sequenzen gleichzeitig.
CPU-Threading. Compositing-Operationen parallelisieren innerhalb eines einzelnen Frames über CPU-Kerne, und der Render-Manager parallelisiert über Frames hinweg, indem er Abschnitte des Frame-Bereichs an verschiedene Worker verteilt.
Arbeitsspeicher. Mehrere Frames in voller Auflösung mit mehreren Kanälen gleichzeitig im Speicher zu halten (ein Beauty Pass, eine Handvoll AOVs, eine Cryptomatte-Matte, eventuell ein Deep Pass) ist viel speicherhungriger, als es aussieht, und ausgehender RAM mitten im Frame ist eine häufigere Ursache für ein gescheitertes Comp-Rendering als reine CPU-Geschwindigkeit.
Schreibdurchsatz. Der finale zusammengesetzte Frame oder ein Zwischen-Precomp muss zurückgeschrieben werden, und bei VFX-Pipeline-Deliverables ist dieser Output meist wieder eine EXR-Sequenz statt einer einzelnen Videodatei.

Das alles ist keine Kritik an Compositing-Software. Es handelt sich um eine andere Art von Workload, die darauf ausgelegt ist, vorhandene Bilddaten zu bewegen und zu kombinieren, statt sie von Grund auf zu erzeugen. Eine render farm, die einen Comp-Job wie ein 3D-Rendering behandelt, also viel GPU-Kapazität bereitstellt und bei RAM und Storage-Durchsatz spart, wird ausgerechnet auf den Maschinen unterdurchschnittlich abschneiden, die den Job eigentlich gut bewältigen sollten.

Was ein Comp-Rendering tatsächlich liest und schreibt

An der Form der Ein- und Ausgaben eines Compositing-Jobs zeigt sich der Unterschied zum 3D-Rendering am konkretesten.

Mehrschichtige EXR mit mehreren Passes als Eingabe. Ein Comp öffnet pro Frame typischerweise eine oder mehrere OpenEXR-Dateien, die bereits viele Kanäle enthalten: ein Beauty-Rendering, separate Diffuse- und Specular-Passes, Lighting-AOVs, einen Z-Depth-Pass, Motion Vectors und Cryptomatte-Mattes zur Isolation von Objekt-, Material- und Asset-ID, alles in einer einzigen Datei, die über einen Read-Node eingelesen und mit Shuffle-Nodes für die passweise Arbeit aufgeteilt wird. Diese Datei zu lesen ist kein kleiner Dateizugriff, sondern zieht jeden Kanal, den ein Frame enthält, selbst wenn ein bestimmtes Comp nur wenige davon nutzt. Deshalb ist die Lesebandbreite des Storage auf comp-lastigen Farm-Nodes ein echter Engpass, was bei einem 3D-Rendering, das die meisten seiner EXR-Daten schreibt statt liest, selten der Fall ist.

Cryptomatte als Eingabe, nicht als Ausgabe. Cryptomatte-Daten (prozedural erzeugte ID-Mattes, mit denen ein Compositor nachträglich einzelne Objekte, Materialien oder Asset-Instanzen isolieren kann, ohne neu zu rendern) werden vom 3D-Rendering geschrieben und vom Comp konsumiert. Das bedeutet, ein Job auf einer Compositing-render-farm erbt alle Cryptomatte-Kanäle, die das vorgelagerte 3D-Rendering erzeugt hat, und ein Comp, das stark auf Cryptomatte-Isolation setzt, liest pro Frame mehr Kanäle als eines, das dies nicht tut. Unser Leitfaden zu EXR-IO und Cryptomatte beschreibt, wie diese Daten strukturiert sind und wie man effizient damit arbeitet, was sich zu lesen lohnt, bevor Sie ein cryptomatte-lastiges Comp an eine render farm senden.

Wenige Ausgaben in hoher Bittiefe. Während ein 3D-Rendering oft mehrere Passes pro Frame schreibt, reduziert ein Comp-Rendering diese Passes typischerweise auf einen oder eine kleine Handvoll finaler zusammengesetzter Ausgaben, meist 16-Bit-Half-Float-EXR für HDR-lineare Deliverables, die weiter unten in der VFX-Pipeline benötigt werden, gelegentlich 32-Bit für Datenpasses, die volle Präzision brauchen. Der Schreibvorgang hat weniger Kanäle als der Lesevorgang, ist aber trotzdem ein Frame in voller Auflösung, und bei einem Deep-Compositing-Job (mehrere Tiefen-Samples pro Pixel, um Holdouts zu lösen, ohne die 3D-Szene neu zu rendern) werden sowohl Lese- als auch Schreibvorgang deutlich schwerer.

Video-Encoding ist ein separater Schritt, nicht das Rendering selbst. Wenn das finale Deliverable H.264 oder HEVC statt einer Bildsequenz ist, läuft dieses Encoding in der Regel als eigener Durchlauf nach dem Frame-für-Frame-Comp-Rendering, nicht als Teil davon, weil sich Video-Codecs nicht so sauber auf Worker aufteilen lassen wie eine unabhängige Bildsequenz. Unser Leitfaden H.264 vs. H.265 Encoding beschreibt die Abwägungen bei diesem letzten Schritt ausführlicher.

Sechs Render-Passes (Beauty, Diffuse, Specular, Cryptomatte, Depth, Ambient Occlusion) fließen in einer einzigen mehrschichtigen EXR-Datei zusammen

Wie sich Comp-Renderings auf einer Cloud-render-farm verteilen

Das Verteilungsmodell für Compositing-Arbeit ähnelt eher dem von Nuke als dem eines 3D-Renderers, und es lohnt sich, genau zu erklären, warum.

Ein 3D-Renderer kann einen einzelnen Frame räumlich aufteilen: Buckets oder Tiles werden an verschiedene Threads oder Maschinen verteilt, weil die Pixel in einer Region tatsächlich nicht von Pixeln in einer anderen Region abhängen. Ein Comp lässt sich in der Regel nicht so aufteilen. Der Wert eines Pixels bei Frame N hängt von den Eingaben dieses Frames ab, die durch den kompletten Node-Tree laufen, weshalb die meiste Compositing-Arbeit pro Frame embarrassingly parallel ist, nicht nach Bildregion. Ein Render-Manager unterteilt keinen Comp-Frame; er unterteilt den Frame-Bereich, verteilt Abschnitte von Frames an verschiedene Worker, von denen jeder für seinen Abschnitt eine eigene Instanz der Compositing-Anwendung im Headless-Modus (ohne GUI) ausführt.

Genau dieses Modell erklärt unser Nuke-Cloud-render-farm-Leitfaden im Detail speziell für Nuke, einschließlich der genauen Kommandozeilen-Flags und der Lizenzmechanik. After Effects verhält sich bei den meisten Produktions-Comps (Titelsequenzen, Motion Graphics, Archviz-Reveals) ähnlich, mit einer Einschränkung, die hier erwähnt werden sollte: AE-Kompositionen, die von zeitlichem Zustand über Frames hinweg abhängen (Motion Blur mit frameübergreifendem Sampling, akkumulierende Partikelsimulationen, manche Tracking-Operationen), sind nicht sauber frame-parallel, und ein naives Aufteilen über Worker kann an den Abschnittsgrenzen sichtbare Nähte erzeugen. Unser Leitfaden zum After-Effects-Cloud-Rendering-Setup beschreibt, welche AE-Workflows sauber parallelisieren und welche stattdessen einen Single-Worker-Durchlauf benötigen.

Die praktische Form eines Comp-Render-Jobs auf einer render farm sieht so aus: Das Skript oder Projekt wird zusammen mit allem, worauf es verweist, als eigenständiges Bundle hochgeladen; der Render-Manager teilt den gesamten Frame-Bereich in Abschnitte auf; jeder Worker holt sich seinen Abschnitt, löst dieselben Footage-Pfade, die Farbkonfiguration, Schriftarten und Plugin-Abhängigkeiten auf, die auch auf der Maschine des Artists vorhanden waren, und rendert headless; fertige Frames landen im Shared- oder Cloud-Storage, sobald jeder Abschnitt fertig ist, sodass eine lange Sequenz schon nutzbaren Output liefern kann, lange bevor der letzte Worker fertig ist.

Häufige Probleme beim Cloud Compositing

Die überwältigende Mehrheit der Comp-Renderings, die auf einer render farm fehlschlagen oder falsch zurückkommen, sind keine Compositing-Rechenprobleme. Es sind Abhängigkeits- und Umgebungsprobleme, die eine lokale Workstation stillschweigend überdeckt hat.

Problem	Ursache	Lösung
Falsche Farben, Rendering „gelingt", sieht aber falsch aus	Auf der render farm wird eine andere OCIO-/Farbkonfiguration aufgelöst als die, die der Artist lokal verwendet hat	Projekt auf eine fest hinterlegte Farbkonfiguration festlegen; sicherstellen, dass die Render-Umgebung genau diese Konfiguration nutzt, nicht eine Standardeinstellung
Fehlendes Footage oder Platzhalterblöcke	Absolute lokale Pfade (ein Windows-Laufwerksbuchstabe, ein gemapptes Netzlaufwerk), die auf einem entfernten Worker keine Bedeutung haben	Alle referenzierten Medien vor der Übermittlung in ein eigenständiges, netzwerkerreichbares Bundle sammeln
Out-of-Memory-Fehler mitten im Frame	Mehrere EXR-Passes in voller Auflösung mit mehreren Kanälen sowie eine Cryptomatte-Matte gleichzeitig im Speicher	Comp-Render-Nodes mit RAM-Reserve statt nur nach CPU-Kernanzahl bereitstellen; das ist eine häufigere Fehlerursache als reine Rechenleistung
Sichtbare Nähte an Abschnittsgrenzen	Eine zeitabhängige Operation (Motion Blur, Partikelsimulation, manches Tracking) wird über Worker verteilt, als wäre sie frame-unabhängig	Zeitabhängige Comps identifizieren und statt über Frame-Range-Verteilung per Single-Worker-Rendering laufen lassen
Fehlendes Plugin, Gizmo oder Schriftart	Ein benutzerdefiniertes Gizmo, ein Drittanbieter-Plugin oder eine Schriftart ist lokal installiert, aber nicht auf dem Render-Worker	Benutzerdefinierte Nodes/Gizmos wo möglich fest ins Skript einbacken; Plugin- und Schriftarten-Matrix vor der Übermittlung mit der render farm abstimmen
Langsamer als erwartet auf einem GPU-Tier-Node	Das Comp wird von Merges, Grades und Transformationen dominiert, also CPU-Operationen, nicht der GPU-beschleunigten Node-Teilmenge	Job passend zur CPU-Kapazität dimensionieren; GPU-Nodes für Comps reservieren, die tatsächlich auf GPU-beschleunigte Retimes, Denoise oder ML-Nodes setzen

Nichts davon ist auf eine bestimmte Anwendung beschränkt. Es ist das allgemeine Muster dessen, was kaputtgeht, wenn ein Compositing-Skript die Maschine verlässt, auf der es erstellt wurde, und deshalb lohnt sich „erst klein testen, bevor die volle Sequenz übermittelt wird" (zuerst eine Handvoll Frames rendern und mit dem lokalen Ergebnis vergleichen) als kostengünstige Absicherung bei jedem Comp-Rendering, auf jeder render farm.

Wann Cloud Rendering einer Compositing-Pipeline tatsächlich hilft

Nicht jedes Comp braucht eine render farm. Eine kurze Sequenz, die lokal in wenigen Minuten rendert, gewinnt wenig durch den Upload- und Warteschlangen-Aufwand des Umzugs in die Cloud. Cloud Compositing rechnet sich in einer bestimmten Reihe von Situationen:

Deadline-getriebene Spitzen. Ein Deliverable, das in Stunden statt Tagen fällig ist, bei dem Frame-Anzahl und Komplexität eine Workstation länger blockieren würden, als die Deadline erlaubt. Das Verteilen einer 1.000-Frame-Sequenz über Dutzende Worker macht aus einem Übernacht-Rendering etwas, das in ein bis zwei Stunden zurückkommen kann, weil der Durchsatz nahezu linear mit der Anzahl verfügbarer Worker skaliert.

Übernacht-Batch-Arbeit, die sonst einen Artist blockieren würde. Auch ohne akuten Deadline-Druck ist ein Comp, das die eigene Maschine eines Artists für mehrere Stunden belegt, Zeit, in der dieser Artist nicht iterieren, reviewen oder am nächsten Shot arbeiten kann. Das Senden an eine render farm gibt die Workstation sofort frei, statt darauf zu warten, dass ein lokales Rendering durchläuft.

Große Sequenzen mit datenintensiven Frames. Deep Compositing, 4K-plus-Multi-Channel-EXR und cryptomatte-lastige Comps sind genau die Workloads, bei denen sich die Renderzeit pro Frame am stärksten summiert und bei denen sich die Verteilung über viele CPU-lastige Worker mehr lohnt als bei einem leichten Comp mit wenigen Kanälen.

Gemischte 3D-und-Comp-Pipelines, die bereits eine render farm nutzen. Wenn das 3D-Rendering für einen Shot bereits auf einer Cloud-render-farm läuft, vermeidet es, die Compositing-Stufe auf derselben Infrastruktur zu belassen, einen Umweg über eine lokale Maschine zwischen den beiden Stufen und hält die Passes (Beauty, AOVs, Cryptomatte) dort, wo das Comp sie lesen wird.

Am wenigsten lohnt sich Cloud Compositing bei einer Handvoll kurzer, einfacher Comps ohne Deadline-Druck, bei denen die lokale Renderzeit ohnehin deutlich unter der Zeit liegt, die zum Vorbereiten und Hochladen eines eigenständigen Projekt-Bundles nötig ist. Der Aufwand für Upload und Abhängigkeitsprüfung ist real und kann bei einem kleinen Job die eingesparte Zeit übersteigen.

Kosten: Was ein Comp-Render-Job tatsächlich kostet

Da Compositing für die große Mehrheit der Nodes in einem typischen Comp ein CPU- und speichergebundener Workload ist, bestimmt meist der CPU-Preis die Kosten, während der GPU-Preis nur für die bestimmten Nodes gilt (aufwendige Retimes, manches Denoise, Machine-Learning-Tools), die tatsächlich GPU-Beschleunigung nutzen.

Auf unserer render farm wird CPU-Rechenleistung pro GHz-Stunde abgerechnet, mit einem Grundtarif von $0,004/GHz-Stunde (Prioritätsstufen liegen je nach Warteschlangenpriorität zwischen $0,004 und $0,016/GHz-Stunde), und GPU-Rechenleistung wird pro OctaneBench-Stunde (OBh) abgerechnet, mit einem Grundtarif von $0,003/OBh, wobei eine RTX-5090-Karte (32 GB VRAM) bei voller Auslastung mit rund $5,2/Karten-Stunde zu Buche schlägt. Render Credits verfallen nicht, und es gibt kein Mindestmaß an Maschinenmiete, sodass ein Comp-Job für die tatsächlich verbrauchte Rechenleistung abgerechnet wird statt für einen reservierten Zeitblock.

Um das an einem illustrativen Rechenbeispiel konkret zu machen (keine Benchmark-Zahl, da die tatsächliche Renderzeit pro Frame stark mit Auflösung, Kanalanzahl und Node-Komplexität variiert): Ein Compositing-Batch, der insgesamt 5.000 GHz-Stunden CPU-Rechenleistung verbraucht, eine plausible Größenordnung für eine mehrere tausend Frames umfassende 4K-Sequenz, die über Nacht auf Dutzende Worker verteilt wird, kostet beim Grundtarif vor jedem Prioritätsstufen-Multiplikator etwa $20 an Rechenleistung. Nutzt ein Teil desselben Jobs GPU-beschleunigte Nodes, wird dieser Anteil separat zum OBh-Tarif statt zum GHz-Stunden-Tarif abgerechnet. Der für die Budgetierung relevante Mechanismus ist einfach, auch wenn die genauen Zahlen von Job zu Job variieren: Die Kosten richten sich nach der insgesamt verbrauchten Rechenleistung, nicht nach der Wanduhr-Renderzeit, sodass das Verteilen eines Jobs auf mehr Worker, um schneller fertig zu werden, für sich genommen die Kosten nicht ändert.

Comp-Rendering vs. 3D-Rendering im Vergleich

Kategorie	3D-Rendering	Compositing-Rendering
Kernoperation	Lichttransport: Sampling, Raytracing, Rauschkonvergenz	Node-Graph-Auswertung: lesen, kombinieren, transformieren, schreiben
Primärer Engpass	GPU- oder CPU-Rechenleistung (enginenabhängig)	CPU-Threading, Speicherkapazität, Storage-I/O
Parallelisierungseinheit	Oft räumlich (Tiles/Buckets) plus Frame	Fast immer pro Frame, nicht nach Bildregion
GPU-Relevanz	Zentral für das Rendering bei GPU-Engines (Redshift, Octane)	Optional für eine bestimmte Node-Teilmenge; die meisten Operationen sind reine CPU-Operationen
Typische Eingabe	Szenengeometrie, Materialien, Texturen	Mehrschichtige EXR-Sequenzen mit mehreren Passes (Beauty, AOVs, Cryptomatte)
Typische Ausgabe	Beauty Pass plus AOVs, oft mehrere Dateien pro Frame	Wenige zusammengesetzte Ausgaben, meist eine finale EXR-Sequenz
Fehlermuster	Konvergenz/Rauschen, Speicher bei komplexen Szenen, Lizenz-Engpässe	Pfad-/Asset-Abhängigkeiten, Abweichungen bei der Farbkonfiguration, Out-of-Memory bei Multi-Channel-Reads

Wo Compositing in eine größere Cloud-Rendering-Pipeline passt

Compositing ist meist die letzte Stufe einer Kette, die mit einem 3D-Rendering beginnt, und beide Stufen mit denselben Annahmen zu Hardware und Engpässen zu behandeln, ist der häufigste Fehler, den wir in Support-Tickets von Teams sehen, die neu im Cloud Compositing sind. Wenn Ihre Pipeline vollständig auf der 3D-Seite liegt und Sie das breitere Servicemodell noch nicht durchdacht haben, behandeln unser Leitfaden dazu, was eine Cloud-render-farm ist und unser Leitfaden zu Cloud Rendering für VFX und Produktvisualisierung dieses Thema. Speziell für die Compositing-Stufe behandeln der Leitfaden zum Nuke Cloud Rendering und der Leitfaden zum After-Effects-Cloud-Rendering-Setup die anwendungsspezifische Mechanik (Lizenzierung, Submission-Flags, Plugin-Matrizen), die dieser Artikel bewusst allgemein gehalten hat. Auf der After-Effects-Seite behandelt unsere Seite After Effects Cloud Render Farm den unterstützten Workflow und die Preisgestaltung direkt.

Als kanonische Referenz zum Dateiformat, das den meisten VFX-Compositing-Pipelines zugrunde liegt, dokumentiert das OpenEXR-Projekt das Multi-Channel-, Multi-Part-Format, das die meisten Comp-Renderings lesen und schreiben, und die Cryptomatte-Spezifikation dokumentiert, wie ID-Matte-Daten in diese Dateien codiert werden.

FAQ

Q: Ist Compositing-Rendering auf einer Cloud-render-farm dasselbe wie 3D-Rendering? A: Nein. Ein 3D-Rendering betreibt Lichttransport, sampelt und verfolgt Strahlen, bis ein Bild konvergiert, und diese Arbeit ist pro Pixel tatsächlich rechenintensiv. Ein Compositing-Rendering wertet einen Node-Graph über bereits vorhandene Bilddaten aus (Footage, Render-Passes) und wird eher von CPU-Threading, Speicherkapazität und Storage-I/O dominiert als von Sampling. Beide Workloads teilen sich die Farm-Hardware, haben aber unterschiedliche Engpässe und unterschiedliche Fehlerbilder.

Q: Warum ist Compositing stärker I/O-gebunden als 3D-Rendering? A: Ein Comp liest pro Frame typischerweise eine oder mehrere mehrschichtige EXR-Dateien mit mehreren Passes und zieht dabei jeden Kanal, den eine Datei enthält (Beauty, AOVs, Cryptomatte-Mattes, Depth), und hält mehrere dieser Frames in voller Auflösung gleichzeitig im Speicher, während der Node-Graph ausgewertet wird. Dieses Lesevolumen macht zusammen mit dem Zurückschreiben des zusammengesetzten Frames Storage-Durchsatz und RAM-Kapazität für die Mehrzahl der Nodes in einem typischen Comp zu einem größeren Faktor für die Renderzeit als reine Rechengeschwindigkeit.

Q: Braucht eine Compositing-render-farm GPU-Nodes? A: Bei den meisten Comps nein. Die Mehrzahl der Compositing-Operationen (Merges, Grades, Keyer, Transformationen, die meisten Filter) läuft auf der CPU. Eine bestimmte, kleinere Gruppe von Node-Typen (aufwendige Retimes, manche Denoise-Operationen, Machine-Learning-Tools) ist GPU-beschleunigt, und Comps, die stark auf diese Nodes setzen, profitieren von GPU-Kapazität. Bei einem typischen Comp mit vielen Merges und Grades zählen CPU-Kerne und RAM mehr als die GPU-Stufe.

Q: Was ist Cryptomatte, und warum ist es für Cloud Compositing wichtig? A: Cryptomatte sind prozedural erzeugte ID-Matte-Daten, die von einem 3D-Rendering geschrieben werden und es einem Compositor erlauben, nachträglich einzelne Objekte, Materialien oder Asset-Instanzen zu isolieren, ohne die 3D-Szene neu zu rendern. Bei einem Cloud-Compositing-Job sind Cryptomatte-Daten eine Eingabe, die das Comp liest, nicht etwas, das das Comp-Rendering erzeugt, und cryptomatte-lastige Comps lesen pro Frame mehr Kanäle, was die I/O- und Speicherlast auf dem Render-Node erhöht.

Q: Können Nuke- und After-Effects-Comps auf derselben Cloud-render-farm rendern? A: Ja, auf einer render farm, die beide Anwendungen unterstützt, wobei sich das Verteilungsmodell leicht unterscheidet. Nuke-Comps sind konstruktionsbedingt fast immer frame-parallel (jeder Frame ist vollständig eigenständig). After-Effects-Comps sind in den meisten Produktionsfällen frame-parallel, aber Kompositionen, die von zeitlichem Zustand über Frames hinweg abhängen, etwa bestimmte Motion-Blur- oder Partikelsimulations-Setups, benötigen statt Frame-Range-Verteilung ein Single-Worker-Rendering, um Nähte zu vermeiden. Unsere Leitfäden zu Nuke und After Effects beschreiben die anwendungsspezifische Mechanik.

Q: Wann ist es sinnvoll, einen Compositing-Job an eine Cloud-render-farm zu senden, statt lokal zu rendern? A: Cloud Compositing lohnt sich am meisten bei Deadline-getriebenen Spitzen, bei Übernacht-Batch-Arbeit, die sonst die Workstation eines Artists blockieren würde, und bei großen oder datenintensiven Sequenzen (Deep Compositing, 4K-plus-Multi-Channel-EXR, cryptomatte-lastige Comps). Am wenigsten lohnt es sich bei einer Handvoll kurzer, einfacher Comps ohne Deadline-Druck, bei denen die lokale Renderzeit bereits kürzer ist als die Zeit, die zum Vorbereiten eines eigenständigen Projekt-Bundles für den Upload nötig ist.

Q: Wie wird Compositing-Rendering auf einer Cloud-render-farm abgerechnet? A: Auf unserer render farm wird CPU-Rechenleistung (die für die meisten Compositing-Arbeiten die Kosten bestimmt) pro GHz-Stunde mit einem Grundtarif von $0,004/GHz-Stunde abgerechnet, mit Prioritätsstufen bis zu $0,016/GHz-Stunde. GPU-beschleunigte Nodes werden separat pro OctaneBench-Stunde mit einem Grundtarif von $0,003/OBh abgerechnet. Die Kosten richten sich nach der insgesamt verbrauchten Rechenleistung statt nach der Wanduhr-Zeit, sodass das Verteilen eines Jobs auf mehr Worker, um schneller fertig zu werden, die Gesamtkosten für sich genommen nicht ändert.

Q: Welche Dateiformate verarbeitet eine Compositing-render-farm typischerweise? A: Mehrschichtiges, Multi-Part-OpenEXR ist der Standard für Ein- und Ausgaben in der VFX-Pipeline und enthält Beauty-Passes, AOVs, Cryptomatte-Mattes und Depth-Daten in 16-Bit-Half-Float (oder 32-Bit für Datenpasses, die volle Präzision brauchen). Wenn das finale Deliverable eine Videodatei (H.264, HEVC, ProRes) statt einer Bildsequenz ist, läuft dieses Encoding typischerweise als separater Durchlauf nach dem Frame-für-Frame-Comp-Rendering, da sich Video-Codecs im Allgemeinen nicht so über Worker aufteilen lassen wie eine unabhängige Bildsequenz. Unser Leitfaden H.264 vs. H.265 beschreibt diesen letzten Encoding-Schritt.