Nuke Cloud-render-farm: Compositing-Rendering im großen Maßstab 2026

Nuke-Comps auf einer Cloud-render-farm rendern

Compositing ist der letzte Schritt einer Visual-Effects-Einstellung. Wenn eine Sequenz Nuke erreicht, sind die 3D-Renders abgeschlossen, die Plates sind gradiert, und der Artist setzt das endgültige Bild zusammen — Merges, Keys, Deep Holdouts, Linsenarbeiten, Grain. Das Problem dabei: dieses „endgültige Bild" ist selten günstig zu schreiben. Eine 200-Frame-4K-Sequenz mit einem Stack aus Multi-Channel-EXR-Inputs und einigen GPU-fähigen Nodes kann eine einzelne Workstation stundenlang binden, und der Artist kann währenddessen nicht weiterarbeiten. Genau diese Art von Arbeit ist es, die eine Cloud-render-farm übernimmt.

Wir betreiben NukeX auf unserer gesamten Render-Flotte bei Super Renders Farm, und im Laufe der Jahre haben wir beobachtet, wie dieselben Details darüber entscheiden, ob ein Nuke-Comp auf einer Farm sauber rendert oder mitten in einer Sequenz stecken bleibt. Es ist fast nie die Compositing-Mathematik, die das Problem verursacht. Es ist ein fehlender Gizmo, eine OCIO-Konfiguration, die nicht übereinstimmt, ein absoluter Windows-Pfad, der auf einem Linux-Worker nichts bedeutet, oder ein Missverständnis darüber, welche Nuke-Edition überhaupt remote rendern kann. Dieser Leitfaden erläutert, wie sich Nuke-Comp-Rendering auf einer Farm verteilt, die Edition- und Lizenzierungslandschaft, die Sie vor der Einreichung verstehen müssen, wo GPU-Beschleunigung tatsächlich hilft (und wo nicht), und wie Sie einen Comp so vorbereiten, dass nichts verloren geht. Die gleichen betrieblichen Überlegungen gelten für breitere VFX- und Produkt-Visualisierungs-Workflows, aber Nuke hat seine eigenen spezifischen Tücken, und auf diese werden wir uns hier konzentrieren.

Warum ein Nuke-Comp parallel nach Frame, nicht nach Kachel ist

Um zu verstehen, wie sich Nuke auf einer Farm verteilt, ist es hilfreich, es mit einem 3D-Renderer zu vergleichen. Ein Pathtracer wie V-Ray oder Arnold kann einen einzelnen Frame in Buckets oder Kacheln aufteilen und jeden Bereich einem anderen Thread übertragen — oder bei verteiltem Rendering einer anderen Maschine. Die Pixel in der oberen linken Ecke hängen nicht von den Pixeln in der unteren rechten ab, sodass der Frame räumlich aufgeteilt werden kann.

Ein 2D-Comp funktioniert anders. Der Wert eines beliebigen Pixels an Frame N hängt nur von den Inputs dieses Frames ab, die durch den Node-Tree laufen. Jeder Frame ist vollständig eigenständig, was einen Nuke-Comp hochgradig parallelisierbar nach Frame macht: Sie können Frame 1 auf einer Maschine und Frame 200 auf einer anderen rendern, ohne dass eine Koordination zwischen ihnen erforderlich ist. Was Nuke nicht tut, ist, einen Frame in räumliche Kacheln aufzuteilen, die auf separate Maschinen verteilt werden — ein Write-Node rendert einen vollständigen Frame in einem einzigen Prozess. Innerhalb einer Maschine parallelisiert Nuke über CPU-Threads und verwendet eine Scanline/Regions-Engine, aber über Maschinen hinweg ist die Verteilungseinheit der Frame.

Diese einzelne Tatsache prägt alles beim Farm-Rendering für Nuke. Der Render-Manager unterteilt keine Bilder; er unterteilt den Frame-Range. Eine 1.000-Frame-Sequenz wird zu einem Satz kleinerer Frame-Range-„Chunks", jeder Chunk wird an einen Worker übergeben, und jeder Worker startet sein eigenes Headless-Nuke-Rendering für sein Segment. Das folgende Diagramm zeigt die Struktur.

Da Frames unabhängig sind, skaliert der Durchsatz nahezu linear mit der Anzahl der Worker, die Sie für den Job einsetzen können — und das ist der Hauptgrund, warum das Rendering einer langen Comp-Sequenz in der Cloud sinnvoll ist.

Das Headless-Rendering: wie Nuke auf einem Worker läuft

Auf einer Farm gibt es keine GUI. Jeder Worker führt Nuke im Terminal-(Batch-)Modus aus, der alle aktiven Write-Nodes für einen bestimmten Frame-Range rendert und dann beendet. Der Basisbefehl sieht so aus:

nuke -x -F 1-50 comp.nk

-x versetzt Nuke in den Execute-Modus. -F setzt den Frame-Range und akzeptiert einzelne Frames (-F 7), inklusive Ranges (-F 1-50) und schrittweise Ranges (-F 1-100x2 rendert jeden zweiten Frame). Sie können mehrere -F-Argumente in einem Befehl für nicht zusammenhängende Ranges übergeben. Einige weitere Flags sind wichtig, wenn Sie von einem einzelnen Comp zu Produktionssequenzen wechseln:

Ein so gestartetes Rendering fordert standardmäßig eine Render-Lizenz an statt eines interaktiven Platzes — mehr dazu im nächsten Abschnitt. Nuke gibt auch nützliche Exit-Codes zurück, die ein Render-Manager liest, um eine Aufgabe als erfolgreich, fehlgeschlagen oder wiederholungsbedürftig zu kennzeichnen: 0 ist Erfolg, 1 ist ein Render-Fehler, und 100 signalisiert einen Lizenzierungsfehler. Auf einer verwalteten Farm tippen Sie diese Befehle selten selbst; die Einreichungswerkzeuge erstellen sie. Das Wissen darüber, was im Hintergrund läuft, erklärt jedoch den Großteil des Verhaltens, das Sie in einem Render-Log sehen werden.

Es gibt noch einen weiteren Verteilungsmechanismus, der erwähnt werden sollte, damit er nicht mit Farm-Rendering verwechselt wird: Nukes interner Frame Server. Der Frame Server startet mehrere Hintergrund-Render-Prozesse, um ein einzelnes Rendering zu beschleunigen — nützlich auf einer ausgelasteten Workstation oder einer kleinen Gruppe von Hilfsmaschinen. Er ist ein anderes Werkzeug als die Farm-skalierte Frame-Range-Verteilung, die Sie benötigen, wenn eine vollständige Sequenz über Nacht statt über ein langes Wochenende zurückkommen soll.

Nuke-Editionen und Lizenzierung für Farm-Rendering

Dies ist der Teil, der die meisten Menschen überrascht, weil „Nuke" eine Familie ist, kein einzelnes Produkt, und die Editionen verhalten sich auf einer Farm nicht alle gleich.

Diese Tabelle beschreibt die Nuke-Familie im Allgemeinen gegenüber den Anforderungen jeder render farm — nicht speziell unserer Flotte; auf unserer eigenen Farm ist die render-seitige Anwendung NukeX, wie der Rest dieses Leitfadens beschreibt. Zwei Punkte aus dieser Tabelle sind besonders hervorzuheben.

Erstens kann Nuke Indie überhaupt nicht auf einer Farm rendern. Foundrys Indie-Edition ist für Solo-Artists mit einer Umsatzobergrenze konzipiert, und ihre Bedingungen schließen externe Drittanbieter-render-farms, Cloud Rendering-Dienste und Remote-Frame-Server-Rendering ausdrücklich aus. Indie speichert zudem in eigenen verschlüsselten Script-Formaten, die der kommerzielle Parser nicht lesen kann. Wenn Sie also Nuke Indie verwenden und sich wundern, warum die Farm-Einreichung nicht funktioniert, liegt das nicht an einem Konfigurationsproblem — es ist eine Lizenzierungsgrenze. Farm-Rendering erfordert die Commercial-, NukeX- oder Nuke-Studio-Editionen.

Zweitens rendern Sie auf einer Farm mit Render-Lizenzen, nicht mit interaktiven Plätzen. Eine Render-Lizenz ist ein Headless-, GUI-loses Nuke, das speziell zum Rendern existiert — wenn Sie ein Terminal-Rendering starten, fordert Nuke standardmäßig eine an. Render-Lizenzen sind unabhängig von den interaktiven Plätzen, die Ihre Artists verwenden, was es einem Studio erlaubt, einen Comp auf fünfzig Maschinen zu platzieren, ohne fünfzig vollständige interaktive Nuke-Plätze zu kaufen. Ein nützliches Detail für gemischte Pipelines: Eine Render-Lizenz kann jeden Node rendern, der in der NukeX-Edition oder darunter erstellt wurde, sodass ein NukeX-ausgestatteter Render-Node problemlos ein Script rendert, das ein Artist in der Basis-Nuke erstellt hat. NukeX ist eine Obermenge von Nuke — es fügt Nodes hinzu, ohne die Fähigkeit zu entfernen, Standard-Nodes zu lesen. Die Umkehrung ist die einzige echte Einschränkung: Basis-Nuke kann keine NukeX-exklusiven Nodes auswerten.

Was das Lizenzierungsmodell betrifft, hat Foundry die Nuke-Familie Anfang 2023 auf ein Jahresabonnement umgestellt, mit login-basierter Lizenzierung, die online oder offline betrieben werden kann; auch Perpetual- und Mietoptionen sind verfügbar. Die Mechanik unterscheidet sich von Studio zu Studio, was der Punkt des nächsten Abschnitts ist.

Wie Lizenzierung auf unserer Farm funktioniert

Super Renders Farm ist kein Foundry-Partner, und wir behaupten das nicht — unsere verifizierten Anbieter-Partnerschaften sind mit den Render-Engine-Herstellern, nicht mit Compositing-Software-Anbietern. Was unsere Farm betreibt, ist ein Render-Only-Utilization-Modell, denselben Ansatz, den wir für die anderen Anwendungen auf der Flotte verwenden, die nicht an eine Partnerschaft gebunden sind.

In der Praxis bedeutet das, dass Sie keinen Render-Lizenz-Platz pro Worker selbst bereitstellen oder verwalten. Die Worker-Flotte betreibt NukeX, versionsgebunden an einen unterstützten Build, und der Compositor startet Headless, um Ihr Script zu rendern. Da SuperRenders eine vollständig verwaltete render farm ist, stellen Sie keine Remote-Desktop-Verbindung zu Maschinen her, installieren Nuke nicht oder konfigurieren keine Lizenz-Server manuell — die render-seitige Umgebung ist bereits eingerichtet, wenn Ihr Job eintrifft. Das ist der betriebliche Unterschied zwischen einer verwalteten Farm und einem Do-it-yourself-IaaS-Setup, bei dem das Einrichten von Nuke und seiner Lizenzierung Ihr Problem ist, das auf jeder Instanz gelöst werden muss.

Bei den Kosten wird Comp-Rendering wie der Rest unserer CPU-Arbeit abgerechnet — pro GHz-Stunde genutzter Rechenleistung, ohne Mindestmietzeiten für Maschinen und mit Render-Credits, die nicht ablaufen. Neue Konten beginnen mit einem Guthaben von 25 $, was ausreicht, um eine kurze Testsequenz von Anfang bis Ende zu rendern und zu bestätigen, dass sich Ihr Comp auf der Farm genauso verhält wie auf Ihrer Workstation, bevor Sie einen vollständigen Job einreichen. Die aktuellen Preise und ein Kostenkalkulator befinden sich auf der Preisseite.

Frame-Range-Verteilung in der Praxis

Zu wissen, dass eine Farm den Frame-Range in Chunks aufteilt, ist eine Sache; saubere, vorhersehbare Renders daraus zu erhalten, eine andere. Auf unserer Support-Seite tauchen immer wieder dieselben Praktiken auf.

Chunk-Größe ist ein Kompromiss. Kleine Chunks (jeweils einige Frames) verteilen die Arbeit auf mehr Maschinen und erholen sich schneller von einer fehlgeschlagenen Aufgabe, zahlen aber Nukes Startaufwand — Script-Laden, Lizenz-Checkout, Plugin-Init — häufiger. Große Chunks amortisieren den Start, hinterlassen aber Nachzügler, wenn eine langsame Maschine das Ende einer Sequenz aufhält. Für die meisten Comps ist ein moderater Chunk, der jeden Worker für mehrere Minuten beschäftigt, ein vernünftiger Standard; sehr schwere Per-Frame-Comps (Deep, 4K-plus, viele GPU-Nodes) tendieren zu kleineren Chunks.

Achten Sie auf Write-Node-Abhängigkeiten. Wenn Ihr Script einen nachgelagerten Read enthält, der von einer Datei abhängt, die ein früherer Write produziert hat — ein auf Disk gebackener Precomp zum Beispiel — müssen diese Writes in der richtigen Reihenfolge ausgeführt werden. Dafür ist --sro da. Ohne es kann ein Worker versuchen, den abhängigen Write auszuführen, bevor sein Input existiert, und Sie erhalten sporadische Fehler mit fehlenden Frames, die zufällig wirken, weil sie vom Maschinen-Timing abhängen.

Planen Sie für den gelegentlichen fehlerhaften Frame. Ein einzelner unlesbarer Input oder ein vorübergehender Storage-Ausfall sollte keinen gesamten Chunk zum Absturz bringen. --cont lässt ein Rendering nach einem fehlgeschlagenen Frame fortsetzen, sodass Sie anschließend nur die Lücken neu in die Warteschlange stellen können, anstatt alles neu zu rendern. Die Kombination mit dem automatischen Task-Retry eines Render-Managers hält lange Sequenzen in Bewegung, ohne sie ständig überwachen zu müssen.

Der Gewinn aus dem richtigen Umgang damit ist klar: Eine Sequenz, die die Maschine eines Artists einen ganzen Tag lang binden würde, kommt zurück, sobald der langsamste einzelne Chunk gerendert hat, weil jeder andere Chunk parallel rendert.

GPU vs. CPU für Nuke auf der Farm

Hier ist ein Punkt, der Menschen überrascht, die vom GPU-first-3D-Rendering kommen: Nuke ist grundlegend eine CPU-Anwendung. Die überwiegende Mehrheit der Compositing-Operationen — Merges, Farbkorrekturen, Transforms, Keys, die meisten Filter — läuft auf der CPU. GPU-Beschleunigung in Nuke ist opt-in für einen spezifischen Subset von Nodes, die über eine „GPU verwenden, falls verfügbar"-Steuerung verfügen; Nodes ohne diese Steuerung sind CPU-only.

Konzeptueller Nuke-Node-Tree, der zeigt, wie die meisten Compositing-Nodes auf der CPU laufen und einige GPU-beschleunigte Nodes hervorgehoben sind

Was dies für Hardware bedeutet: Ein Comp, der von Grades, Merges und Transforms dominiert wird, profitiert kaum von einer GPU — er braucht CPU-Kerne und Arbeitsspeicher. Ein Comp, der stark auf einen schweren Kronos-Retime, ein großes ZDefocus, Denoise oder benutzerdefinierte BlinkScript-Arbeit setzt, kann auf einer GPU erheblich schneller werden. Die meisten Produktions-Comps liegen irgendwo dazwischen, weshalb wir mit CPU-Kapazität anfangen und die GPU als Beschleuniger für die Nodes behandeln, die sie tatsächlich nutzen.

Unsere Flotte spiegelt das wider. Der Großteil der Compositing-Arbeit läuft auf CPU-Maschinen, die auf dual Intel Xeon E5-2699 V4-Prozessoren mit jeweils 96–256 GB RAM aufgebaut sind — insgesamt mehr als 20.000 CPU-Kerne — und dieser Arbeitsspeicher-Spielraum ist das, was die Leute unterschätzen. Deep Compositing und hochauflösende Multi-Channel-EXR-Plates sind speicherhungrig; ein einzelner Deep Frame bei 4K kann viele Samples pro Pixel halten, und der Arbeitsspeicher läuft beim Farm-Rendering weit häufiger aus als die reine CPU-Geschwindigkeit. Für Comps, die wirklich von GPU-Nodes profitieren, betreiben wir auch eine dedizierte GPU-Cloud-render-farm auf NVIDIA RTX 5090-Karten mit jeweils 32 GB VRAM. Wenn Sie sehen möchten, wie diese GPU-Stufe bei schwereren Workloads abschneidet, behandeln unsere RTX 5090 Cloud Rendering-Benchmarks das im Detail. Die ehrliche Empfehlung für Nuke im Besonderen ist jedoch, die Größe dem Comp anzupassen: Zahlen Sie nicht für GPU-Zeit, die ein merge-lastiges Script nie nutzen wird.

Datei- und Asset-Handling: der Teil, der tatsächlich kaputt geht

Wenn ein Nuke-Rendering auf einer Farm fehlschlägt, ist die Wahrscheinlichkeit überwältigend, dass es sich um ein Abhängigkeitsproblem handelt, nicht um ein Compositing-Problem. Ein Comp-Script ist hauptsächlich ein Satz von Referenzen — auf Footage, auf Gizmos, auf eine Farbkonfiguration — und jede dieser Referenzen muss auf einem Worker, der nicht die Maschine des Artists ist, identisch aufgelöst werden.

Diagramm eines Nuke-Comp-Scripts und der Abhängigkeiten, die damit zu einer render farm reisen müssen: Footage, Gizmos, OCIO-Konfiguration, Fonts und LUTs

Einige dieser Punkte verdienen eine genauere Betrachtung. Pfade sind der klassische: Ein Artist unter Windows, der auf Z:\project\plates\ verweist, erstellt ein Script, das für einen Linux-Worker nichts bedeutet. Konsistente, netzwerkzugängliche Projektpfade — oder ein Render-Manager, der Pfade auf dem Weg zur Farm umschreibt — lösen dieses Problem. Gizmos und benutzerdefinierte OFX müssen auf dem Render-Node vorhanden sein; die sicherste Gewohnheit vor der Einreichung ist, alle benutzerdefinierten Gizmos in Groups zu konvertieren, sodass sie in das Script eingebacken sind und keine externe Abhängigkeit tragen.

OCIO-Config-Drift ist der subtilste Punkt und es lohnt sich, darauf zu verweilen, weil er einen Render erzeugt, der erfolgreich ist, aber falsch aussieht. Nukes Farbmanagement wird von einer OpenColorIO-Konfiguration gesteuert; wenn die Farm eine andere Konfiguration auflöst als die vom Artist verwendete — ein anderer Dateipfad, eine benutzerdefinierte Konfiguration, die nie bereitgestellt wurde, oder eine Umgebungsvariable, die woanders hinzeigt — weichen die Farbtransformationen ab und das Farm-Rendering stimmt nicht mit dem Viewer überein, den der Artist genehmigt hat. Die Lösung ist Disziplin: Binden Sie das Projekt an eine spezifische, bereitgestellte Konfiguration und stellen Sie sicher, dass die Render-Umgebung genau diese verwendet. Eine verwaltete Farm hält Nukes Standard-OCIO-Konfigurationen standardmäßig an Ort und Stelle, aber eine benutzerdefinierte OCIO-Konfiguration eines Studios muss trotzdem mit dem Job mitreisen.

Auf der Output-Seite lesen und schreiben Nuke-Comps typischerweise Multi-Channel-EXR. Eine einzelne OpenEXR-Datei kann viele Kanäle tragen — einen Beauty-Pass plus Diffuse, Specular, Lighting-AOVs, einen Z-Depth-Pass und Cryptomatte-Mattes — alle durch einen einzigen Read-Node gelesen und mit Shuffle-Nodes für die Pass-Arbeit im Comp aufgeteilt. Für Deep Compositing liest und schreibt Nuke Deep-EXR über DeepRead und DeepWrite, speichert mehrere Tiefen-Samples pro Pixel, um Holdout- und Kantenprobleme zu lösen, ohne 3D neu rendern zu müssen. Die meisten dieser Daten werden als 16-Bit-Half-Float gespeichert, dem Standard für HDR-lineare Plates, wobei 32-Bit-Full-Float für Datenpässe wie Weltposition oder Motion-Vectors reserviert ist, die volle Präzision benötigen. Nichts davon ist exotisch — aber jeder dieser Kanäle bedeutet mehr zu bewegende Daten und mehr zu haltenden Speicher, was direkt darauf zurückführt, warum RAM und Storage-Durchsatz für Comp-Rendering genauso wichtig sind wie die Kernanzahl.

Eine Voreinreichungs-Checkliste für Nuke-Comps

Bevor Sie einen Comp an eine Farm senden — unsere oder Ihre eigene interne Warteschlange — verhindert ein schneller Durchgang durch diese Punkte den Großteil fehlgeschlagener Renders:

• Pfade: Alle Read- und Write-Nodes verwenden netzwerkzugängliche, OS-unabhängige Pfade, keine lokalen Laufwerksbuchstaben.
• Gizmos: Benutzerdefinierte Gizmos sind in Groups konvertiert (eingebacken) oder auf den Render-Nodes bestätigt installiert.
• Farbe: Die OCIO-Konfiguration ist diejenige, die die Farm auflösen wird; eine benutzerdefinierte Konfiguration reist mit dem Job.
• Fonts und LUTs: Jeder Font, der von einem Text-Node verwendet wird, und jede referenzierte .cube/LUT-Datei ist vorhanden.
• Version: Der Render-Build stimmt mit dem Build überein, in dem der Comp erstellt wurde.
• Edition: Das Script stammt aus Commercial Nuke, NukeX oder Nuke Studio — nicht aus Nuke Indie, das nicht farm-rendert.
• Render-Reihenfolge: Wenn ein nachgelagerter Read von einem früheren Write abhängt, rendern Sie mit --sro.
• Kleiner Test zuerst: Rendern Sie zuerst einige Frames und vergleichen Sie mit dem lokalen Output des Artists, bevor Sie den vollständigen Range einreichen.

Dieser letzte Punkt ist kostengünstiger Versicherungsschutz. Ein Fünf-Frame-Test-Rendering erkennt einen Pfad-, Farb- oder Versions-Mismatch zum Preis einiger Minuten — weit besser, als ihn 800 Frames in einem Über-Nacht-Job zu entdecken.

Wo Nuke-Rendering in eine breitere Pipeline passt

Finales-Frame-EXR-Output ist der häufigste Endpunkt für einen Nuke-Comp, aber nicht der einzige. Wenn Ihr Shot in eine Real-Time-Engine geht statt in eine flache gerenderte Sequenz — Virtual Production oder In-Engine-Review — sind die Integrationsfragen andere, und wir behandeln diesen Weg separat in unserem Nuke-zu-Unreal-Engine-Pipeline-Leitfaden. Halten Sie die Unterscheidung klar: Dieser Artikel handelt vom Rendering von Comp-Frames im großen Maßstab auf einer Farm, während der Unreal-Weg davon handelt, Nuke-Arbeit in einen Real-Time-Kontext zu überführen. Wenn Sie noch dabei sind, wie verteiltes Rendering im Allgemeinen funktioniert, ist unser Leitfaden zu was eine render farm ist ein guter Ausgangspunkt.

Für eine maßgebliche Referenz zu den hier beschriebenen Mechaniken sind Foundrys eigene Dokumentation zu Command-Line-Operationen und render farms sowie die Nuke-Familien-Lizenzierungs-FAQs die kanonischen Quellen, und die OpenEXR- und OpenColorIO-Projektseiten dokumentieren die Datei- und Farbstandards, von denen ein Comp abhängt.

FAQ

Q: Kann ich Nuke auf einer Cloud-render-farm mit einer Nuke-Indie-Lizenz rendern? A: Nein. Foundrys Nuke-Indie-Edition unterstützt ausdrücklich keine externen Drittanbieter-render-farms, Cloud Rendering-Dienste oder Remote-Frame-Server-Rendering und speichert in verschlüsselten Script-Formaten, die der kommerzielle Parser nicht lesen kann. Farm-Rendering erfordert die Commercial-Nuke-, NukeX- oder Nuke-Studio-Editionen.

Q: Benötige ich eine separate Nuke-Render-Lizenz, um eine Cloud-render-farm zu nutzen? A: Auf einer Farm laufen Renders Headless mit Render-Lizenzen statt mit interaktiven Plätzen — so kann ein Studio auf vielen Maschinen rendern, ohne für jede einen vollständigen interaktiven Platz zu kaufen. Auf unserer Farm stellen Sie diese nicht selbst bereit; die Worker-Flotte betreibt NukeX unter einem Render-Only-Utilization-Modell, sodass die render-seitige Lizenzierung farm-seitig gehandhabt wird.

Q: Ist Nuke-Rendering auf GPU oder CPU schneller? A: Für die meisten Comps CPU. Nuke ist grundlegend eine CPU-Anwendung; nur ein spezifischer Subset von Nodes — Kronos, Denoise, ZDefocus, Convolve, BlinkScript und Machine-Learning-Werkzeuge wie CopyCat — sind GPU-beschleunigt. Ein Comp, der hauptsächlich aus Merges, Grades und Transforms besteht, braucht CPU-Kerne und RAM, während ein Comp, der sich auf diese schweren Nodes stützt, von einer GPU profitiert.

Q: Wie teilt eine render farm einen Nuke-Comp auf Maschinen auf? A: Nach Frame-Range, nicht nach Bildbereich. Da jeder Frame eines Comps unabhängig ist, teilt der Render-Manager den gesamten Frame-Range in Chunks auf und übergibt jeden Chunk an einen Worker, der sein Segment Headless rendert. Der Durchsatz skaliert nahezu linear mit der Anzahl der Worker für den Job.

Q: Warum rendert mein Nuke-Comp auf der Farm mit falschen Farben? A: Die häufigste Ursache ist OCIO-Config-Drift — die Farm hat eine andere OpenColorIO-Konfiguration aufgelöst als die vom Artist verwendete, sei es durch einen anderen Dateipfad, eine Umgebungsvariable oder eine benutzerdefinierte Konfiguration, die nie auf den Render-Nodes bereitgestellt wurde. Binden Sie das Projekt an eine spezifische Konfiguration und stellen Sie sicher, dass genau diese Konfiguration die Render-Umgebung verwendet.

Q: Welche Dateien muss ich mit einem Nuke-Script senden, um remote zu rendern? A: Das Script plus alles, worauf es verweist: Footage und Bildsequenzen, alle benutzerdefinierten Gizmos oder OFX-Plugins (oder backen Sie sie in Groups ein), die OCIO-Farbkonfiguration, von Text-Nodes verwendete Fonts und alle eigenständigen LUT-Dateien. Der Render-Build sollte auch mit der Version übereinstimmen, in der der Comp erstellt wurde.

Q: Rendert NukeX einen Standard-Nuke-Comp? A: Ja. NukeX ist eine Obermenge von Basis-Nuke — es fügt Nodes hinzu, ohne die Fähigkeit zu entfernen, Standard-Nodes zu lesen — sodass ein NukeX-Render-Node Scripts, die in Basis-Nuke erstellt wurden, ohne Probleme rendert. Eine Render-Lizenz kann jeden Node rendern, der in der NukeX-Edition oder darunter erstellt wurde. Die einzige Einschränkung ist die Umkehrung: Basis-Nuke kann keine NukeX-exklusiven Nodes auswerten.

Q: Was kostet das Rendering von Nuke-Comps auf Ihrer Farm? A: Comp-Rendering wird pro GHz-Stunde genutzter CPU-Rechenleistung abgerechnet, ohne Mindestmietzeiten für Maschinen und mit Render-Credits, die nicht ablaufen. Neue Konten erhalten ein Guthaben von 25 $, das eine kurze Testsequenz von Anfang bis Ende abdeckt. Aktuelle Preise und ein Kostenkalkulator befinden sich auf unserer Preisseite.