Headless-Rendering und unbeaufsichtigte Workflows auf einer render farm: Was sich 2026 automatisieren lässt

Einleitung

Das Ziel einer automatisierten Render-Pipeline lässt sich am einfachsten damit beschreiben, was niemand tun möchte: um 2 Uhr nachts an einer Workstation sitzen und eine Frame-Warteschlange beaufsichtigen. Ein Technical Director stellt vor Feierabend eine Sequenz mit 500 Frames in die Warteschlange und möchte am Morgen die fertigen Frames auf dem lokalen Speicher haben. Dieser Wunsch hat zwei Hälften, die sich leicht vermischen: Headless-Rendering und unbeaufsichtigte Workflows.

Headless-Rendering bedeutet, ein Rendering von der Kommandozeile aus zu steuern, ohne dass eine grafische Oberfläche geöffnet ist. Unbeaufsichtigt bedeutet, dass die Schleife (die Szene zur Farm bringen, rendern, die Ausgabe zurückholen) läuft, ohne dass jemand sie überwacht. Das eine gibt es auch ohne das andere. Dieser Leitfaden trennt beides und zeigt anschließend, wie viel von einer unbeaufsichtigten Schleife sich heute rund um eine vollständig verwaltete Cloud-render-farm aufbauen lässt.

Wir betreiben verteiltes Rendering seit 2010, und viele Pipeline-Fragen, die uns erreichen, setzen eine öffentliche API zum Einreichen von Jobs voraus. Unsere Farm hat keine, und wir sind dabei bewusst genau, denn ein Workflow, der auf einer nicht vorhandenen Funktion aufbaut, scheitert schon beim ersten Nachtlauf. Was es gibt, reicht weiter, als viele erwarten: Die Vorbereitung liegt auf Ihrer Seite der Verbindung, und der Upload lässt sich mit der AWS CLI über den S3-Zugriff (Cloud Direct Connect) auf Ihren SRF Space skripten.

Was Headless-Rendering tatsächlich bedeutet

Headless-Rendering ist eine Eigenschaft eines einzelnen Render-Aufrufs: Der Renderer läuft, ohne die Benutzeroberfläche der Anwendung zu öffnen. Jede große 3D- und Compositing-Anwendung bringt dafür einen Kommandozeilen-Einstiegspunkt mit, und jeder Node einer render farm nutzt ihn, weil an einer Maschine im Rack kein Monitor hängt.

Hier sind die gängigen Aufrufformen für die Anwendungen, die wir unterstützen. Sie laufen auf Ihrer Maschine für lokale Vorbereitung und Validierung; auf einer verwalteten Farm ruft die Farm das Äquivalent auf ihren Nodes für Sie auf.

Anwendung	Kommandozeilen-Tool	Typischer Aufruf	Hinweise
Blender	blender -b	blender -b scene.blend -E CYCLES -o //out/fr_ -s 1 -e 250 -a	-b = Hintergrund, keine GUI; -a rendert den Bereich, -f N ein einzelnes Frame. -E wählt die Engine; unsere Farm rendert sowohl Cycles als auch EEVEE.
Maya	Render	Render -r arnold -s 1 -e 100 -rd /out/ -of exr scene.ma	-r wählt den Renderer (arnold, vray usw.); übergeben Sie -cam, damit die vorgesehene Kamera gerendert wird.
3ds Max	3dsmaxcmd.exe	3dsmaxcmd.exe -frames:1-100 -outputName:"D:\out\fr_.exr" scene.max	Syntax mit Doppelpunkt (key:value); für einen stillen Lauf ergänzen Sie -showRFW:0.
Cinema 4D	Commandline.exe	Commandline.exe -render scene.c4d -frame 1 100 -oimage D:\out\fr_	-frame erwartet Start und Ende, durch ein Leerzeichen getrennt; Frame-Nummern werden an den -oimage-Namen angehängt.
Houdini	hbatch / husk	husk --engine cpu --frame 1 --frame-count 100 -o '/out/fr_$F4.exr' scene.usd	hbatch steuert die ROPs von HIP-Dateien; husk rendert USD-Stages mit Karma (--engine wählt CPU oder XPU). $F4 füllt die Frame-Nummer auf vier Stellen auf.
After Effects	aerender	aerender -project x.aep -comp "Main" -s 1 -e 100 -OMtemplate "EXR Sequence" -output /out/fr_[####].exr	-comp muss exakt dem Namen der Composition entsprechen; -OMtemplate benennt eine gespeicherte Output-Module-Vorlage (der Name hier ist ein Beispiel); [####] nummeriert die Sequenz.
NukeX	nuke -x	nuke -x -F 1-100 script.nk	-x führt das Skript headless aus (es steht nicht für NukeX); -F akzeptiert 1-100 oder mit Schrittweite 1-100x2. Prüfen Sie, ob Ihre Lizenzvariante das Rendern über die Kommandozeile erlaubt.

Die Referenzen der Hersteller dokumentieren die genauen Flags je Version und lohnen sich als Lesezeichen: Blenders Handbuch zum Rendern über die Kommandozeile und die husk-Referenz von SideFX sind die beiden, auf die wir am häufigsten verweisen.

Headless und unbeaufsichtigt sind zwei verschiedene Probleme

Es hilft, die Unterscheidung klar zu halten. Headless beschreibt, wie ein Render gestartet wird: ohne GUI. Unbeaufsichtigt beschreibt, ob über den gesamten Workflow hinweg eine Person anwesend sein muss. Beide überschneiden sich, sind aber nicht dieselbe Achse.

Quadrantendiagramm, das Headless- und unbeaufsichtigtes Rendering nach Art der Oberfläche und menschlicher Beteiligung vergleicht Headless (wie ein Render gestartet wird) und unbeaufsichtigt (ob eine Person anwesend ist) sind unabhängige Achsen; die Automatisierung zielt auf die obere rechte Ecke; der Rest dieses Leitfadens behandelt, wie nah ein Workflow auf einer verwalteten Farm heute herankommt.

Ein Render kann headless und trotzdem beaufsichtigt sein: Sie führen nuke -x in einem Terminal aus und sehen den Frames beim Durchlaufen zu, bereit, den Prozess abzubrechen, falls Frame 12 einen Fehler wirft. Ein Workflow kann auch GUI-Tools nutzen und trotzdem weitgehend unbeaufsichtigt sein, wenn die langsamen Teile im Hintergrund laufen. Das Ziel der Pipeline-Automatisierung ist die unbeaufsichtigte Hälfte.

Auf einer render farm verschiebt sich das Bild, denn die Farm übernimmt bereits den Teil des Problems, für den Headless-Rendering erfunden wurde: Renders auf Maschinen ohne angeschlossenen Bildschirm zu starten.

Warum eine verwaltete Farm die Headless-Frage verändert

Es gibt zwei grundsätzliche Formen des Cloud-Renderings. Im Modell der Infrastruktur-Miete mieten Sie Maschinen und sind selbst der Render-Wrangler. Im vollständig verwalteten Modell betreibt die Farm die Maschinen, und Sie übergeben ihr Szenen. Das Wort „headless“ bedeutet in beiden etwas anderes.

Verantwortung	Infrastruktur-Miete (selbst verwaltet)	Vollständig verwaltete render farm
Maschinen bereitstellen	Sie, Node für Node	Die Farm
DCC und Plugins pro Node installieren	Sie, auf jedem Node	Die Farm
Lizenzen der Render-Engines verwalten	Sie: Lizenzserver, Checkout	Die Farm (im Preis enthalten)
Headless-Render pro Node starten	Sie: Render, blender -b usw. per Skript über die Nodes	Die Farm
Frames verteilen und fehlgeschlagene wiederholen	Sie: Die Orchestrierung ist Ihr Code	Die Farm
Vorbereiten, hochladen, einreichen, Ausgabe einsammeln	Sie	Sie: Dateien über das Web, die Client App oder den S3-Zugriff; Jobs über das Web-Dashboard, die Client App oder ein DCC-Plugin

Eine Studio-Workstation, verbunden mit einer verwalteten Cloud-render-farm, die die Render-Nodes auf der Seite der Farm betreibt Auf einer verwalteten Farm sind die Nodes Sache der Farm; die Studioseite sorgt dafür, dass ein sauberes Projekt hineinkommt und die Frames wieder herauskommen.

Im selbst verwalteten Modell bedeutet „headless“ Node-Orchestrierung, und die Automatisierung, die Sie schreiben, ist die gesamte Render-Management-Schicht. Auf einer vollständig verwalteten Farm entfällt diese Schicht für Sie: Unsere CPU-Seite betreibt Engines wie V-Ray, Corona und Arnold auf mehr als 20.000 CPU-Kernen, und eine GPU-Seite nutzt Karten des Typs NVIDIA RTX 5090 (32 GB VRAM) für Redshift, Octane und V-Ray GPU, alles intern orchestriert. Sie steuern die Nodes also überhaupt nicht. Was bleibt, ist die Schleife um die Farm, und der größte Teil davon läuft auf Ihren eigenen Maschinen.

Wenn eine durchgängig skriptgesteuerte Einreichung heute eine harte Anforderung ist, passt das Mieten von Maschinen mit eigener Automatisierung ehrlicherweise besser: Eine gemietete Maschine, auch unsere dedizierten Render-Server, wird mit installiertem DCC-Stack bereitgestellt, und Sie führen darauf Ihre eigene Automatisierung und Ihre eigenen Transfer-Tools aus.

Die Schleife auf einer verwalteten Farm, Stufe für Stufe

Hier ist die vollständige Schleife, jede Stufe ehrlich gekennzeichnet.

Sechsstufige Render-Schleife: Vorbereitung, Paketierung und Upload skriptbar; Einreichung manuell; Render auf der Farm; Abruf skriptbar Die Schleife auf einer verwalteten Farm: Vorbereitung, Paketierung und Upload lassen sich skripten (der Upload per S3-Zugriff), die Einreichung bleibt manuell, die Farm rendert, und der Abruf lässt sich wieder skripten.

1. Headless-Vorbereitung und Pre-Flight (Ihre Seite, vollständig skriptbar). Rendern Sie ein Test-Frame lokal im Headless-Modus (blender -b scene.blend -f 1, nuke -x -F 1 script.nk); scheitert Frame 1 lokal, scheitert es bei jedem Frame eines Farm-Jobs. Prüfen Sie dann jeden externen Verweis: Report Missing Files in Blender, Asset Tracking in 3ds Max, den File Path Editor in Maya, hou.fileReferences() in Houdini. Pfade relativ zur Szenendatei (// in Blender, $HIP/ in Houdini, sourceimages/ eines Maya-Projekts) überstehen den Weg zu jedem Node. Hängt ein Projekt von absoluten Pfaden ab (manche Scatter-, Crowd- und Cache-Plugins speichern sie intern), legt die Option Auto keep local path der Client App Ihre lokale Ordnerstruktur im Cloud-Speicher neu an, sodass diese Pfade weiterhin aufgelöst werden.

2. Projekt paketieren (Ihre Seite, vollständig skriptbar). Sammeln Sie die Szene und ihre Abhängigkeiten in einem Projektordner und lassen Sie ihn entpackt. Die Farm entpackt keine Archive (.zip, .rar, .7z, .tar, .tar.gz), daher wird nichts gerendert, was in einem Archiv liegt. Wer mit 3ds Max arbeitet, kann unserer Anleitung zum Paketieren einer 3ds-Max-Datei für die Farm folgen.

3. Upload (skriptbar mit S3-Zugriff). Es gibt drei Wege hinein. Der Web-Upload hat keine harte Größenbegrenzung, aber ein einzelner Browser-Upload wird auf privaten Internetanschlüssen ab etwa 2 GB langsam und ab etwa 5 GB unzuverlässig, und er stoppt, wenn der Tab geschlossen wird. Die SuperRenders Client App lädt in parallelen Chunks hoch, setzt nach einer unterbrochenen Verbindung beim letzten abgeschlossenen Chunk fort, und unter Windows überträgt ein Hintergrunddienst weiter, nachdem Sie das Hauptfenster geschlossen haben. Der S3-Zugriff (Cloud Direct Connect in Ihrem Konto) ist der skriptbare Weg: Generieren Sie dort einen Access Key, und die AWS CLI oder Cyberduck (Protokoll: Amazon S3) überträgt Dateien zu und von Ihrem SRF Space, sodass ein Upload aus einem geplanten Job laufen kann, ohne dass jemand am Schreibtisch sitzt.

4. Scene Analysis und Einreichung (manuell). Sobald die Dateien hochgeladen sind, prüft Scene Analysis, ob das Projekt rendern wird, bevor Credits abgebucht werden. Den Job starten Sie anschließend im Web-Dashboard, in der Client App (Start Render Job: Frame-Bereich, Ausgabeformat, Priorität Normal oder Express) oder mit dem Einreichungs-Plugin in 3ds Max, Maya oder Cinema 4D, das vor dem Einreichen eine Asset-Prüfung ausführt und die geöffnete Szene paketiert. Der S3-Zugriff überträgt nur Dateien: Es gibt keine öffentliche API, kein SDK und keinen Kommandozeilen-Submitter, den ein Build-Skript aufrufen könnte. Wenn Ihre Pipeline von einem davon ausgegangen ist, ist das die Stelle, um die Sie herum planen sollten.

5. Rendern und überwachen (Aufgabe der Farm; Sie sehen zu). Verfolgen Sie den Fortschritt im Render-Jobs-Panel der Client App oder im Web-Dashboard; die Client App kann Sie bei Einreichung, Abschluss, Meilensteinen und Fehlern benachrichtigen. Das ist eine Ansicht für Menschen, kein Statusfeed, den ein Skript abfragen könnte.

6. Abrufen (freihändig mit der Client App). Standardmäßig lädt die Client App jedes Frame herunter, sobald es fertig gerendert ist, in einen Standardordner oder in einen Ordner pro Job, den Sie beim Einreichen festlegen, sodass die Frames bei Jobende bereits auf der Platte liegen. Verschwindet der Download-Pfad mitten im Job (ein abgezogenes externes Laufwerk ist eine häufige Ursache), verweisen Sie auf einen beschreibbaren Ordner und nutzen Sync output. Auch der Web-Download funktioniert. Dateien bleiben zum Download verfügbar, ohne feste automatische Löschfrist, und werden auf Anfrage gelöscht; dennoch sollten Sie die Farm als Render-Dienst behandeln, nicht als Ihr Archiv.

In den Schritten 1 bis 3 und in allem nach Schritt 6 kommen Ihre Skripte zum Einsatz.

Die Studioseite automatisieren: Pre-Flight, Paketierung und Upload

Die meisten gescheiterten Nachtläufe lassen sich auf die Eingaben zurückführen. Deshalb ist die Automatisierung mit dem höchsten Nutzen ein Gate, das vor dem Start des Uploads läuft: bestätigen, dass eine Szenendatei vorhanden ist, Archive und Junk-Dateien markieren und ein Prüfsummen-Manifest schreiben. Unser Begleitleitfaden zum Automatisieren der Studioseite beim Upload zur render farm führt durch ein abhängigkeitsfreies Python-Skript, das genau das leistet.

Kombinieren Sie es mit einer DCC-seitigen Prüfung, die headless läuft. Für Blender melden ein paar Zeilen bpy jeden externen Pfad, der absolut ist oder fehlt, und --python-exit-code macht aus einem Fehler einen Exit-Code ungleich null, auf den Ihr Wrapper-Skript reagieren kann:

# check_paths.py
# run: blender -b scene.blend --python-exit-code 2 --python check_paths.py
import os
import bpy

absolute = [p for p in bpy.utils.blend_paths(absolute=False) if not p.startswith("//")]
missing = [p for p in bpy.utils.blend_paths(absolute=True) if not os.path.exists(p)]
for p in absolute:
    print("ABSOLUTE:", p)
for p in missing:
    print("MISSING:", p)
if absolute or missing:
    raise RuntimeError(f"{len(absolute)} absolute, {len(missing)} missing paths")

Dasselbe Muster funktioniert auch anderswo: hou.fileReferences() in hython, Abfragen von filePathEditor in mayapy, ein MAXScript-Durchlauf über das Asset Tracking in 3ds Max. Verketten Sie die DCC-Prüfung und die Ordnerprüfung in einem Shell-Skript, und Sie haben ein Gate, das ein Projekt als bereit durchlässt oder genau sagt, warum nicht.

Sobald das Gate bestanden ist, kann dasselbe Skript den Upload starten. Führen Sie einmal aws configure aus, mit der Access Key ID und dem Secret Access Key aus Cloud Direct Connect und der Region ap-southeast-1, und lassen Sie das Skript den entpackten Projektordner mit aws s3 cp und --recursive in Ihr Remote Directory kopieren. Laden Sie nur hoch, wenn das Gate sauber beendet wird, damit ein defektes Projekt Ihr Netzwerk nie verlässt. Der gleiche Begleitleitfaden behandelt die Skript-Details.

Den Rückweg automatisieren: den Download-Ordner beobachten

Übernimmt der Auto-Download der Client App die Übertragung, landen die Frames in einem lokalen Ordner, den Sie beim Einreichen gewählt haben. Ab dort ist es gewöhnliche lokale Automatisierung: Beobachten Sie den Ordner, bis der erwartete Frame-Bereich vorhanden ist und sich die Größe jeder Datei nicht mehr ändert, und lösen Sie dann Ihr Encoding, den Review-Upload oder die Archivkopie aus. Der Begleitleitfaden enthält ein Watcher-Skript für genau diesen Schritt.

Schreibt Ihr Job mehrere Passes pro Frame, zählen Sie einen einzigen Pass-Namen, damit jedes Frame nur einmal gezählt wird. Auch die Prüfung „Größen stabil“ ist wichtig: Ein Frame, das noch geschrieben wird, hat den richtigen Namen, bevor es die richtigen Bytes hat.

Planen, was sich planen lässt

Der Nachtlauf auf einer verwalteten Farm besteht aus lokalen Jobs und einem skriptgesteuerten Upload, eingebettet in Scheduler, mit einem manuellen Schritt in der Mitte.

• Vor der Übergabe: Führen Sie zeitgesteuert, mit cron (macOS, Linux) oder der Aufgabenplanung (Windows), das Pre-Flight-Gate über einen Ordner „bereit zum Einreichen“ aus und laden Sie jedes Projekt, das besteht, mit der AWS CLI in Ihren SRF Space hoch.
• Die Übergabe: Eine Person reicht das hochgeladene Projekt ein. Das dauert eine Minute und ist der eine Schritt, den Sie heute nicht skripten können.
• Nach der Übergabe: Lassen Sie die Client App laufen (unter Windows aktivieren Sie Run on Windows startup, damit ihr Hintergrunddienst einen Neustart übersteht) und starten Sie den Watcher auf dem Download-Ordner dieses Jobs.

# minute hour day month weekday  command
0 1 * * 1-5 /studio/bin/preflight-and-upload.sh >> "$HOME/render-preflight.log" 2>&1

Hier ist preflight-and-upload.sh Ihr eigener Wrapper: Er führt das Gate aus und ruft aws s3 cp nur für Projekte auf, die bestehen. Die Umleitung 2>&1 ist bei unbeaufsichtigter Arbeit nicht optional. Sie schreibt Fehler ins Log, und ohne sie schlägt eine fehlgeschlagene Prüfung oder ein fehlgeschlagener Upload still fehl, während niemand zusieht.

Was sich heute automatisieren lässt und was nicht

Klar gesagt, damit Sie darauf aufbauen können: Super Renders Farm veröffentlicht derzeit keine öffentliche REST-API, kein SDK und kein Kommandozeilen-Tool zur Job-Einreichung. Es gibt keinen Status-Endpunkt zum Abfragen und keinen Webhook, der nach Abschluss eines Renders zurückruft. Wir bieten weder SFTP noch FTP an, weder auf der verwalteten Farm noch für gemietete Maschinen; eine frühere Version dieses Artikels beschrieb einen skriptbaren SFTP-Weg, den es nicht gibt.

Der skriptbare Übertragungsweg ist der S3-Zugriff: ein Access Key aus Cloud Direct Connect, den Sie mit der AWS CLI oder Cyberduck verwenden, um Dateien zu und von Ihrem SRF Space zu verschieben.

Stufe	Heute automatisierbar?	Wie
Lokaler Testrender und Pfadprüfungen	Ja	Headless-DCC-Läufe auf Ihrer Maschine (blender -b, hython, mayapy, nuke -x)
Paketierung und Prüfsummen-Manifest	Ja	Lokale Skripte; der Projektordner bleibt entpackt
Upload	Ja, mit S3-Zugriff	AWS CLI aus einem Skript oder geplanten Job; Client App (fortsetzbar, Hintergrunddienst) und Web-Upload für manuelle Starts
Scene Analysis und Einreichung	Nein, manuell	Web-Dashboard, Client App oder Plugin für 3ds Max, Maya und Cinema 4D
Fortschritt	Beobachtet, nicht abgefragt	Render-Jobs-Panel der Client App, Web-Dashboard, Benachrichtigungen der Client App
Download	Ja, freihändig	Auto-Download der Client App in einen Ordner pro Job
Schritte nach dem Render	Ja	Lokaler Watcher auf dem Download-Ordner, dann Ihre Skripte für Encoding, Review und Archiv

Die programmatische Einreichung steht auf unserer Roadmap, ist aber heute nicht verfügbar. Ist sie für Ihre Pipeline eine harte Anforderung, sagen Sie unserem Support-Team, was Sie aufrufen würden und wann; diese Rückmeldung fließt in die Roadmap ein.

Wenn Sie das gegen den Betrieb eigener Nodes abwägen, lesen Sie unsere Beiträge zum vollständig verwalteten Modell und zur Abwägung zwischen vollständig verwaltet und Do-it-yourself. Die Einstiegsanleitung behandelt Upload, Einreichung und Download mit Screenshots, Anwendungshinweise finden Sie auf unseren Seiten zur Blender-Cloud-render-farm und zur Houdini-Cloud-render-farm, und die Preisseite erklärt das Credit-Modell.

Häufige Stolperfallen bei unbeaufsichtigten Render-Workflows

Das sind die Ursachen, die unser Support-Team am häufigsten sieht.

Symptom	Ursache	Lösung
Texturen rendern auf der Farm rosa oder schwarz, lokal aber korrekt	Absolute Asset-Pfade (D:\...), die auf einem Node nicht existieren	Szenenrelative Pfade verwenden (//, $HIP/, sourceimages/ des Projekts) oder mit Auto keep local path der Client App hochladen
Der Job findet keine Szene, oder es wird nichts gerendert	Projekt als Archiv hochgeladen oder nur ein Unterordner hochgeladen	Den gesamten Projektordner entpackt hochladen, mit allen referenzierten Assets an ihrem Platz
Der Upload stand morgens bei 60 %	Browser-Tab geschlossen oder Rechner während eines Web-Uploads in den Ruhezustand gegangen	Die Client App verwenden, die ab dem letzten Chunk fortsetzt, oder einen protokollierten AWS-CLI-Upload über den S3-Zugriff
Falsche Kamera in der Ausgabe	In einer Szene mit mehreren Kameras wurde keine Kamera festgelegt	Vor dem Einreichen die Render-Kamera in der Szene festlegen (Maya -cam für lokale Tests)
Nach Jobende fehlen lokal Frames	Der Auto-Download-Pfad war ein abgezogenes oder verschobenes Laufwerk	Den Download-Ordner auf einen beschreibbaren Pfad legen, dann Sync output nutzen
Das Nachtskript „hat nichts getan“, kein Fehler	Kein 2>&1-Logging; ein stiller Fehlschlag	stdout und stderr in ein Log umleiten; zuerst ein lokales Test-Frame rendern

Der rote Faden ist Determinismus: Ein unbeaufsichtigter Workflow funktioniert nur, wenn jede Eingabe festgelegt ist, bevor der Lauf beginnt. Ein Render, der von etwas abhängt, das nur auf Ihrer Workstation vorhanden ist, funktioniert einmal, vor Ihren Augen, und nie wieder um 2 Uhr nachts.

FAQ

Q: Was ist Headless-Rendering? A: Headless-Rendering bedeutet, ein Rendering von der Kommandozeile zu starten, ohne dass eine grafische Oberfläche geöffnet ist, zum Beispiel blender -b scene.blend -a oder nuke -x script.nk. Jeder Node einer render farm arbeitet so, und Artists nutzen dieselben Einstiegspunkte lokal, um eine Szene vor dem Upload zu testen.

Q: Was ist der Unterschied zwischen Headless- und unbeaufsichtigtem Rendering? A: Headless betrifft, wie ein einzelner Render gestartet wird: ohne GUI. Unbeaufsichtigt betrifft, ob über den gesamten Workflow hinweg eine Person anwesend sein muss. Auf einer verwalteten Farm übernimmt die Farm den Headless-Teil, sodass Ihre Automatisierung in die Schleife um sie herum gehört.

Q: Kann ich Jobs per Skript oder API bei Super Renders Farm einreichen? A: Heute nicht. Unsere Farm stellt keine öffentliche REST-API, kein SDK und keinen Kommandozeilen-Submitter bereit; die programmatische Einreichung steht auf der Roadmap. Jobs werden über das Web-Dashboard, die Client App oder das Plugin in 3ds Max, Maya oder Cinema 4D eingereicht. Skripten lassen sich die Vorbereitung davor, der Upload über den S3-Zugriff und die Verarbeitung danach.

Q: Kann ich Dateiübertragungen zur Farm skripten? A: Ja, über den S3-Zugriff; SFTP und FTP werden nicht angeboten. Generieren Sie unter Cloud Direct Connect in Ihrem Konto einen Access Key und nutzen Sie dann die AWS CLI (Region ap-southeast-1) oder Cyberduck mit dem Protokoll Amazon S3, um Dateien zu und von Ihrem SRF Space zu übertragen. Web-Upload und die SuperRenders Client App decken manuelle Übertragungen ab, und fertige Frames kommen über den Auto-Download der Client App oder den Web-Download zurück.

Q: Wie bekomme ich fertige Renders zurück, ohne am Rechner zu sitzen? A: Nutzen Sie den Auto-Download der Client App, der standardmäßig aktiv ist: Jedes Frame wird heruntergeladen, sobald es fertig ist, in einen Standardordner oder einen Ordner pro Job. Unter Windows überträgt ihr Hintergrunddienst weiter, nachdem Sie das Hauptfenster geschlossen haben, und ein lokales Watcher-Skript auf diesem Ordner kann Ihren Encoding- oder Review-Schritt starten.

Q: Wie rendere ich Blender über die Kommandozeile, um eine Szene vor dem Upload zu testen? A: Nutzen Sie den Hintergrundmodus, zum Beispiel blender -b scene.blend -E CYCLES -f 1 für ein Test-Frame. Das Flag -b läuft ohne GUI, und -E wählt die Engine; unsere Farm rendert sowohl Cycles als auch EEVEE. Ein kleines bpy-Skript, mit --python-exit-code ausgeführt, kann im selben Durchlauf absolute oder fehlende Pfade melden.

Q: Kann ich unbeaufsichtigte Nacht-Renders planen? A: Sie können Ihre Seite planen: eine Pre-Flight-Prüfung mit cron oder der Aufgabenplanung, einen AWS-CLI-Upload jedes bestandenen Projekts in Ihren SRF Space und einen Watcher, der Frames verarbeitet, sobald die Client App sie herunterlädt. Die Einreichung erfolgt im Web-Dashboard, in der Client App oder in einem DCC-Plugin, sodass eine Person eine kurze Übergabe macht.

Q: Muss ich für Headless-Rendering auf der Farm Lizenzen der Render-Engines verwalten? A: Nein. Auf einer vollständig verwalteten Farm werden die Lizenzen der Render-Engines als Teil des Dienstes auf Seiten der Farm gehandhabt. In einem selbst verwalteten Setup würden Sie eigene Lizenzserver betreiben und die Headless-Renders auf jedem Node selbst starten.