Automatisierung einer render farm mit Python: Was sich heute skripten lässt

Der langsamste Teil eines Cloud Renderings ist oft alles rund um das Rendering: die Szene, die scheitert, weil eine Textur noch auf ein lokales Laufwerk zeigt, der Upload, der neu gestartet werden muss, die Frames, die zurückkamen, während niemand prüfte, ob wirklich alle zurückkamen. Die nützliche Frage lautet, wie weit ein Python-Skript tatsächlich reicht.

Wir betreiben Super Renders Farm, eine vollständig verwaltete Farm, und wollen bei dieser Grenze genau sein, denn eine Automatisierung, die auf einem nicht vorhandenen Weg aufbaut, scheitert schon in ihrer ersten unbeaufsichtigten Nacht. Hier deshalb vorab die klare Fassung: Projektdateien zur Farm zu übertragen lässt sich skripten. Der S3-Zugriff (Cloud Direct Connect in Ihrem Konto) liefert Ihnen einen Access Key, mit dem die AWS CLI Dateien in Ihren SRF Space und aus ihm heraus kopiert. Die Einreichung von Jobs lässt sich nicht skripten: Jobs werden über das Web-Dashboard, die Client App oder das Einreichungs-Plugin in 3ds Max, Maya oder Cinema 4D eingereicht. Wir bieten keinen SFTP- oder FTP-Dienst, keine öffentliche API und kein SDK und keinen Endpunkt zur Job-Einreichung, den Sie aus Code aufrufen könnten. Eine öffentliche API für die programmatische Einreichung steht auf unserer Roadmap; sie ist derzeit nicht verfügbar, und nichts von dem Folgenden hängt von ihr ab.

Ein Hinweis für alle, die diese Seite schon früher gesehen haben: Eine frühere Fassung beschrieb skriptgesteuerte Übertragungen über SFTP. Dieser Weg wird auf unserer Farm nicht angeboten; skriptgesteuerte Übertragungen laufen jetzt über den S3-Zugriff, wie unten beschrieben.

Für Python bleibt dennoch viel. Alles vor dem Upload, der Upload selbst und alles, nachdem die Frames auf Ihrer Platte liegen, lässt sich skripten. Die konzeptionelle Übersicht über Headless-Rendering und unbeaufsichtigte Workflows finden Sie in unserem Leitfaden zu Headless-Rendering und unbeaufsichtigten Workflows auf einer render farm; dieser hier bleibt auf der Ebene des Codes.

Wo die Grenze auf einer verwalteten Farm verläuft

Auf unserer Farm gliedert sich die Pipeline in vier Abschnitte.

• Vor dem Upload: Ihre Seite, vollständig skriptbar. Szenenvalidierung in Ihrer DCC-Anwendung, Pfadkorrekturen, Paketierung, Pre-Flight-Prüfungen, Prüfsummen.
• Upload: skriptbar mit S3-Zugriff oder manuell. Die AWS CLI kopiert den Projektordner aus einem Skript in Ihren SRF Space. Die manuellen Wege sind der Web-Upload und die SuperRenders Client App. Der Web-Upload hat keine harte Größenbegrenzung, wird aber nicht fortgesetzt, wenn der Tab geschlossen wird; nutzen Sie daher für alles, was über wenige Gigabyte hinausgeht, oder bei instabiler Verbindung die Client App (fortsetzbar, parallele Chunks) oder den S3-Zugriff. Ein einzelner Browser-Upload wird auf privaten Internetanschlüssen ab etwa 2 GB langsam und ab etwa 5 GB unzuverlässig.
• Einreichung: manuell. Sie reichen im Web-Dashboard, in der Client App oder mit dem Einreichungs-Plugin ein, und die Farm führt Scene Analysis für das hochgeladene Projekt aus, bevor der Job abgerechnet wird.
• Nach dem Render: wieder Ihre Seite. Ist der Auto-Download der Client App aktiv, werden die Frames in einen lokalen Ordner geladen, sobald jedes einzelne fertig ist, oder ein Skript holt sie über S3. Sobald ein Frame auf Ihrer Platte liegt, ist jede Prüfung, jedes Encoding, jede Kopie und jede Benachrichtigung ein lokales Skript.

Die realistische Form ist also Automatisierung auf beiden Seiten eines kurzen manuellen Schritts, und die folgenden Skripte machen diesen Schritt schnell und schwer falsch zu machen. Unser Erklärstück dazu, was eine vollständig verwaltete render farm ist, zeigt, was das verwaltete Modell für Sie übernimmt.

Drei Spuren: skriptbare Szenenprüfungen und S3-Upload, manuelle Job-Einreichung, danach skriptbare Frame-Prüfungen und Encoding Die Automatisierung sitzt auf beiden Seiten eines kurzen manuellen Schritts: Validierung, Pre-Flight, Manifest und Upload auf Ihrer Seite, Einreichung von Hand, danach Prüfung und Nachbearbeitung dessen, was zurückkommt.

Schritt 1: Die Szene in Ihrer DCC-Anwendung validieren

Nach unserer Erfahrung sind die meisten fehlgeschlagenen Render-Jobs keine Renderer-Bugs. Es sind Lücken bei der Paketierung: eine Textur auf einem Laufwerk, das die Farm nie sieht, eine referenzierte Datei, die nicht eingesammelt wurde, ein Cache einen Ordner oberhalb des Projektstamms. Ein Worker kann nur öffnen, was im hochgeladenen Ordner liegt; das erste Skript gehört daher in die DCC-Anwendung, wo es die Abhängigkeitsliste der Szene selbst lesen kann.

Jede große DCC-Anwendung stellt das über Python bereit: maya.cmds in Maya, pymxs in 3ds Max, das Modul c4d in Cinema 4D, hou in Houdini, bpy in Blender. Führen Sie zuerst den eigenen Sammelschritt der DCC-Anwendung aus (Resource Collector in 3ds Max, oder Archive mit anschließendem Entpacken des geschriebenen Archivs; Save Project with Assets in Cinema 4D; in Blender die Assets im Ordner der .blend halten und Make Paths Relative ausführen). Der Sammelschritt trägt die Dateien zusammen; Ihr Skript belegt das Ergebnis. Die Blender-Variante läuft im Scripting-Workspace oder headless mit blender -b scene.blend --python check_paths.py:

# check_paths.py: runs inside Blender, reads the open .blend, touches nothing remote
import os
import sys
import bpy

def inside(path, root):
    try:
        a, b = os.path.normcase(path), os.path.normcase(root)
        return os.path.commonpath([a, b]) == b
    except ValueError:
        return False   # different drive on Windows

def main():
    if not bpy.data.filepath:
        if bpy.app.background:
            sys.exit("save the .blend first")
        print("save the .blend first")
        return

    bpy.ops.file.make_paths_relative()   # rewrite paths under the .blend's folder to // form
    blend_dir = os.path.dirname(bpy.data.filepath)

    refs = [("image", i) for i in bpy.data.images
            if i.source == "FILE" and not i.packed_file]   # skip generated, sequence, UDIM, packed
    refs += [("library", lib) for lib in bpy.data.libraries]
    refs += [("cache", c) for c in bpy.data.cache_files]     # Alembic and USD caches
    refs += [("volume", v) for v in bpy.data.volumes]        # OpenVDB volumes

    issues = []
    for kind, block in refs:
        full = os.path.abspath(bpy.path.abspath(block.filepath))
        if not os.path.exists(full):
            issues.append((f"missing {kind}", block.name, block.filepath))
        elif not inside(full, blend_dir):
            issues.append(("outside project", block.name, block.filepath))

    for kind, name, path in issues:
        print(f"{kind:16} {name:32} {path}")
    if not issues:
        bpy.ops.wm.save_mainfile()        # keep the relative paths only when the scene is clean
    if bpy.app.background:
        sys.exit(1 if issues else 0)

main()

Das Muster gilt für jede DCC-Anwendung: jede Dateireferenz auflösen, alles Fehlende markieren und alles markieren, was außerhalb des Projektstamms aufgelöst wird.

Manche Projekte lassen sich nicht auf relative Pfade umstellen, weil Scatter-Bibliotheken, Personenbibliotheken und bestimmte Caches intern absolute Pfade enthalten. Für sie bewahrt die Option Auto keep local path der Client App beim Upload die absolute Ordnerstruktur, und wenn der Pfad auf der Farm vom lokalen abweichen muss, legt unser Utility Simulate Local Path den Pfad an, den die Szene erwartet. Ihr Skript prüft dann „alles unterhalb der Wurzeln, die Sie erhalten“ statt „alles unterhalb des Projektstamms“. Für 3ds Max führt unsere Anleitung, wie man eine 3ds-Max-Datei paketiert, durch den Sammelschritt.

Schritt 2: Den Projektordner per Pre-Flight prüfen

Die Prüfung in der DCC-Anwendung kennt die Szene; die Ordnerprüfung kennt den Upload. Sie fängt Probleme ab, die auf der Platte liegen: keine Szenendatei, ein abgelegtes Archiv, Dateien mit null Byte von einer unterbrochenen Kopie, Pfade, die lang genug sind, um ältere Windows-Anwendungen zu überfordern.

Die Archivprüfung ist wichtiger, als sie aussieht. Die Farm entpackt keine Archive (.zip, .rar, .7z, .tar, .tar.gz); nichts in einem Archiv wird daher gerendert. Laden Sie Ihren Projektordner entpackt hoch, mit der Szenendatei und jedem referenzierten Asset an seinem Platz.

#!/usr/bin/env python3
"""preflight.py: check a project folder before upload. Reads local disk only."""
import json
import sys
from pathlib import Path

SCENE_SUFFIXES = {".max", ".ma", ".mb", ".c4d", ".blend", ".hip", ".hiplc", ".aep"}
ARCHIVE_SUFFIXES = {".zip", ".rar", ".7z", ".tar", ".tgz"}  # the farm does not extract these
SINGLE_BROWSER_UPLOAD_GB = 2     # above this, use the Client App or S3 access instead
LONG_PATH = 240                  # headroom under the classic 260-character Windows limit

def preflight(root: Path) -> dict:
    files = [p for p in root.rglob("*") if p.is_file()]
    scenes = [p for p in files if p.suffix.lower() in SCENE_SUFFIXES]
    total = sum(p.stat().st_size for p in files)
    problems, warnings = [], []

    if not scenes:
        problems.append("no scene file found in the folder")
    for p in files:
        rel = p.relative_to(root)
        if p.suffix.lower() in ARCHIVE_SUFFIXES or p.name.lower().endswith(".tar.gz"):
            problems.append(f"archive will not be unpacked: {rel}")
        if p.stat().st_size == 0:
            warnings.append(f"zero-byte file: {rel}")
        if len(str(p)) > LONG_PATH:
            warnings.append(f"long path ({len(str(p))} chars): {rel}")
    if total > SINGLE_BROWSER_UPLOAD_GB * 1024**3:
        warnings.append("over ~2 GB: use the Client App or S3 access, not one browser upload")

    return {"root": str(root), "files": len(files), "gigabytes": round(total / 1024**3, 2),
            "scenes": [str(p.relative_to(root)) for p in scenes],
            "problems": problems, "warnings": warnings}

if __name__ == "__main__":
    report = preflight(Path(sys.argv[1]).resolve())
    print(json.dumps(report, indent=2))
    sys.exit(1 if report["problems"] else 0)

Der Exit-Code ungleich null ist der springende Punkt. Binden Sie das Skript in alles ein, was am Ende eines Arbeitstags ohnehin läuft (ein Publish-Tool, ein Save-Hook, ein Button „bereit für die Farm“), damit ein Projekt mit Problemen nie in den Upload gelangt. Warnungen werden ausgegeben; Probleme blockieren.

Schritt 3: Ein Manifest schreiben, damit Sie genau wissen, was Sie gesendet haben

Besteht ein Projekt den Pre-Flight, halten Sie es fest. Ein Manifest listet jede Datei mit Größe und SHA-256-Hash und wird neben dem Projekt geschrieben, nicht darin, damit es nie Teil des Uploads wird. Es beantwortet drei Fragen, die sonst einen Nachmittag kosten: Welche Version der Szene wurde gerendert, was hat sich seit der letzten Einreichung geändert, und stimmt der Ordner auf der Platte noch mit dem überein, was hochgeladen wurde.

# manifest.py: hash a project folder and compare two snapshots. Local files only.
import hashlib
import json
import time
from pathlib import Path

def sha256(path: Path, chunk: int = 8 * 1024 * 1024) -> str:
    h = hashlib.sha256()
    with open(path, "rb") as f:
        while block := f.read(chunk):
            h.update(block)
    return h.hexdigest()

def write_manifest(root: Path, out: Path) -> dict:
    files = [{"path": p.relative_to(root).as_posix(), "bytes": p.stat().st_size, "sha256": sha256(p)}
             for p in sorted(root.rglob("*")) if p.is_file()]
    manifest = {"project": root.name, "created": time.strftime("%Y-%m-%dT%H:%M:%S"), "files": files}
    out.write_text(json.dumps(manifest, indent=2))
    return manifest

def diff_manifests(old: dict, new: dict):
    a = {f["path"]: f["sha256"] for f in old["files"]}
    b = {f["path"]: f["sha256"] for f in new["files"]}
    changed = sorted(k for k in a.keys() & b.keys() if a[k] != b[k])
    return sorted(b.keys() - a.keys()), sorted(a.keys() - b.keys()), changed

Speichern Sie Manifeste nach Shot und Version (shot010_v003.manifest.json), dann wird der Diff zu einer Einzeiler-Zusammenfassung: „zwei Texturen geändert, ein Cache hinzugefügt, nichts entfernt“.

Transfers mit der AWS CLI skripten

Der S3-Zugriff (Cloud Direct Connect in Ihrem Konto) erlaubt es Ihnen, einen Access Key zu generieren und dann Cyberduck (Protokoll: Amazon S3) oder die AWS CLI mit Ihrem SRF Space zu verbinden, um Dateien hoch- und herunterzuladen. Cyberduck eignet sich für alle, die einen Datei-Browser möchten; die AWS CLI ist diejenige, die ein Skript steuern kann. Der S3-Zugriff verschiebt nur Dateien: Er ist kein SFTP- oder FTP-Dienst und reicht keine Jobs ein.

Die Einrichtung ist einmal pro Rechner nötig. Öffnen Sie in Ihrem Konto Cloud Direct Connect, generieren Sie einen Access Key und kopieren Sie Access Key ID, Secret Access Key und Remote Directory. Speichern Sie den Key dann in einem benannten AWS-Profil:

aws configure --profile srf      # both keys; region ap-southeast-1; output format blank or json
export AWS_PROFILE=srf           # the AWS CLI and boto3 both read this

Laden Sie den Projektordner entpackt hoch, denselben Ordner, der den Pre-Flight bestanden hat, in Ihr Remote Directory:

aws s3 cp ./shot010_v003 "s3://<your Remote Directory>/shot010_v003/" --recursive

aws s3 sync nimmt dieselbe Quelle und dasselbe Ziel ohne --recursive und kopiert nur Dateien, die nach Größe oder Zeitstempel neu oder geändert sind; ein erneuter Lauf nach einer unterbrochenen Übertragung überspringt also, was bereits angekommen ist. Große Dateien werden automatisch in parallele Multipart-Uploads aufgeteilt. Auf diese Weise hochgeladene Dateien erscheinen in Ihrem SRF Space und lassen sich wie jeder andere Upload einreichen. Ein Hinweis für den Pre-Flight: Wird ein Projekt auf die Render-Nodes synchronisiert, werden Dateien, die auf *.ini, *.db, *.tmp, *.temp, *.lnk, *.swap und *.partial passen, sowie jeder Ordner rendertemp/ übersprungen; die Szene darf also nicht von ihnen abhängen.

Die Python-Seite ist ein dünner Wrapper: Pre-Flight ausführen, bei einem Problem den Upload verweigern, dann den Ordner an die AWS CLI übergeben.

# upload_project.py: pre-flight, then copy the folder to your SRF Space with the AWS CLI.
import os
import subprocess
import sys
from pathlib import Path

from preflight import preflight   # the Step 2 script

def upload(project: Path, remote_dir: str) -> None:
    report = preflight(project)
    if report["problems"]:
        sys.exit("pre-flight failed: " + "; ".join(report["problems"]))
    target = f"s3://{remote_dir.removeprefix('s3://').strip('/')}/{project.name}/"
    subprocess.run(["aws", "s3", "sync", str(project), target,
                    "--region", "ap-southeast-1"], check=True)

if __name__ == "__main__":
    upload(Path(sys.argv[1]).resolve(), os.environ["SRF_REMOTE_DIR"])

Wenn Sie lieber in Python bleiben möchten, erledigt upload_file von boto3 dieselbe Aufgabe gegen den Bucket und das Präfix in Ihrem Remote Directory, mit demselben Profil und derselben Region.

Derselbe Key funktioniert auch in der Gegenrichtung. Gerenderte Ausgabe landet im Ordner SuperRendersOutput/<jobId>/ Ihres Space (aws s3 ls "s3://<your Remote Directory>/SuperRendersOutput/" listet die Job-Ordner auf), und ein Befehl holt einen Job in einen lokalen Ordner:

aws s3 sync "s3://<your Remote Directory>/SuperRendersOutput/<jobId>/" ./renders/shot010_v003/

Behandeln Sie den Key wie ein Passwort:

• Jeder, der den Key besitzt, kann Ihren SRF Space erreichen. Halten Sie ihn in einem AWS-Profil oder in den Umgebungsvariablen AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY auf dem Rechner, der den Upload ausführt, niemals im Skript selbst.
• Committen Sie ihn nie in ein Repository und fügen Sie ihn nie in eine gemeinsam genutzte Pipeline-Konfiguration ein. Halten Sie auch das Remote Directory in einer Umgebungsvariablen, wie oben.
• Jedes Konto hat einen Key, und er läuft nicht ab. Wenn Sie vermuten, dass er offengelegt wurde, oder er geändert werden muss, wenden Sie sich an unser Support-Team.

Manuell bleibt die Einreichung. Nach dem Upload reichen Sie den Job weiterhin im Web-Dashboard, in der Client App oder mit einem DCC-Plugin ein.

Schritt 4: Die Übergabe zur Einreichung kurz und wiederholbar halten

Die Einreichung ist eine Person, die ein Formular durchklickt; machen Sie das Formular also zum einfachen Teil. Lassen Sie den Validierungsschritt neben dem Manifest auch ein kleines Übergabeblatt schreiben: Szenendatei, Kamera, Frame-Bereich, Auflösung, Ausgabeformat, Render-Engine und den lokalen Ordner, in dem die Frames landen sollen. Wer einreicht, kopiert Werte, statt sie aus dem Gedächtnis abzurufen, und der Watcher in Schritt 5 liest dasselbe Blatt, sodass beide nicht voneinander abweichen können.

Drei Konventionen erleichtern die Automatisierung der Kette:

• Ein Ordner pro Shot und Version (shot010_v003/), die Szenendatei in seiner Wurzel. Pre-Flight, Manifest, Upload-Ziel und Übergabeblatt richten sich alle nach diesem Namen.
• Aufgefüllte Frame-Nummern in Ausgabenamen (shot010.1001.exr). Ein Watcher kann keinen Bereich prüfen, den er nicht parsen kann.
• Ein vorhersehbarer Download-Ordner pro Job. Die Client App lädt in einen Standardpfad aus ihren Einstellungen herunter, und Sie können den Pfad beim Einreichen pro Job überschreiben. Legen Sie ihn auf den eigenen Render-Ordner des Shots.

In 3ds Max, Maya und Cinema 4D liest das Einreichungs-Plugin Frame-Bereich, Ausgabepfad und Render-Einstellungen aus der geöffneten Szene, füllt das Job-Formular vor und führt eine eigene Asset-Prüfung aus. Blender, Houdini und After Effects haben kein Plugin in der DCC-Anwendung, diese Jobs laufen daher über die Client App oder das Web-Dashboard. So oder so läuft Scene Analysis, bevor der Job abgerechnet wird; Ihre Skripte sorgen dafür, dass diese Hürde Sie seltener aufhält.

Schritt 5: Die zurückkommenden Frames verifizieren

Ist die Client App gestartet und der Auto-Download aktiv (Standard), wird jedes Frame auf Ihren Rechner geladen, sobald es auf der Farm fertig ist; mit S3-Zugriff füllt stattdessen Ihr eigener Lauf von aws s3 sync einen lokalen Ordner. So oder so lautet die Frage dann: „Woher weiß ich, dass alle vollständig angekommen sind?“ Ein Watcher beantwortet das allein aus lokalen Dateien: Ein Frame gilt erst als fertig, wenn sich seine Größe zwischen zwei Abfragen nicht mehr ändert und sein Datei-Header gültig ist.

# watch_frames.py: verify frames arriving in a local folder. Reads local disk only.
import re
import time
from pathlib import Path

MAGIC = {".exr": b"\x76\x2f\x31\x01", ".png": b"\x89PNG\r\n\x1a\n"}

def header_ok(path: Path) -> bool:
    magic = MAGIC.get(path.suffix.lower())
    with open(path, "rb") as f:
        head = f.read(8)
    return head.startswith(magic) if magic else len(head) > 0

def watch(job_dir: Path, first: int, last: int, poll: int = 60, give_up_hours: float = 24,
          name_re: str = r"\.(\d{4,})\.(exr|png)$") -> list:
    # name_re: default matches any frame-numbered file. Anchor it to one pass's file
    # prefix (e.g. r"^shot010_beauty\.(\d{4,})\.(exr)$") when the job writes render
    # elements or AOVs as separate files, so this watcher tracks a single pass.
    pattern = re.compile(name_re, re.IGNORECASE)
    expected = set(range(first, last + 1))
    last_size, done = {}, {}
    deadline = time.time() + give_up_hours * 3600

    while True:
        for p in job_dir.rglob("*"):
            m = pattern.search(p.name) if p.is_file() else None
            if not m or int(m.group(1)) not in expected or int(m.group(1)) in done:
                continue
            size = p.stat().st_size
            if size > 0 and last_size.get(p) == size and header_ok(p):
                done[int(m.group(1))] = p    # stable across two polls, valid header
            last_size[p] = size

        missing = sorted(expected - done.keys())
        print(f"{len(done)}/{len(expected)} frames verified, {len(missing)} outstanding")
        if not missing:
            return [done[f] for f in sorted(done)]
        if time.time() > deadline:
            raise TimeoutError(f"frames still missing: {missing[:20]}")
        time.sleep(poll)

Die Suche ist rekursiv, sodass Frames unabhängig von der Unterordnerstruktur des Downloads am Namen gefunden werden. Wird der Job als abgeschlossen angezeigt und der Watcher meldet trotzdem Lücken, nutzen Sie in der Client App Sync output für diesen Job, das fehlende Frames erneut herunterlädt (oder führen Sie aws s3 sync erneut aus), und lassen Sie den Watcher noch einmal laufen; tun Sie dasselbe, wenn die Größe eines Frames zu klein wirkt, denn auch ein stehen gebliebener Teil-Download kann stabil aussehen. Wenn Sie Ereignisse dem Polling vorziehen, kapselt das Paket watchdog die Benachrichtigungen des Betriebssystems über Dateiänderungen; behalten Sie die Stabilitätsprüfung in beiden Fällen bei. Schreibt ein Job Render-Elemente oder AOVs als separate Dateien, führen Sie einen Watcher pro Pass aus, sonst kann ein fertiger Pass ein fehlendes Beauty-Frame mit derselben Nummer verdecken.

Schritt 6: Lokale Schritte nach dem Render

Liefert der Watcher eine verifizierte Liste, ist der Rest gewöhnlicher Pipeline-Code:

import subprocess

def encode_review(frames_dir, pattern, start, out, fps=24):   # pattern e.g. "shot010.%04d.png"
    subprocess.run(["ffmpeg", "-y", "-framerate", str(fps), "-start_number", str(start),
                    "-i", f"{frames_dir}/{pattern}", "-vf", "scale=trunc(iw/2)*2:trunc(ih/2)*2",
                    "-c:v", "libx264", "-pix_fmt", "yuv420p", "-crf", "18", str(out)], check=True)

Ein paar Gewohnheiten, die sich zu übernehmen lohnen:

• Aus display-referred Frames encodieren. PNG oder JPEG können direkt in ein Review-Movie gehen. Lineares EXR braucht zuvor Ihre Farb-Pipeline (meist eine OCIO-Transformation), sonst wirkt das Movie dunkel und flach.
• Das Manifest zusammen mit den Frames archivieren. In sechs Monaten ist die Frage „Welche Texturen haben dieses Rendering erzeugt?“ nur eine Datei entfernt.
• Mit Fakten benachrichtigen. Frame-Anzahl, Frames, die eine Synchronisierung brauchten, Gesamtgröße, Pfad des Review-Movies, gepostet in Ihren Studio-Chat oder Tracker.
• Die eigene Kopie als maßgebliches Archiv behalten. Dateien auf unserer Farm werden so lange aufbewahrt, wie es nötig ist, um Ihre Jobs auszuführen und Ihnen den Download Ihrer Ergebnisse zu ermöglichen, ohne festen automatischen Löschzeitraum, und wir löschen sie jederzeit auf Ihren Wunsch. Das ist kein Backup-Konzept; Ihr lokales Archiv ist eines.

Die lokalen Teile zeitlich planen

Nichts davon braucht einen neuen Scheduler. Cron unter Linux, launchd unter macOS oder die Aufgabenplanung unter Windows können Pre-Flight, Manifest und den AWS-CLI-Upload jeden Abend für Projekte ausführen, die als „bereit“ markiert sind, sodass die Dateien in Ihrem SRF Space liegen, bevor sich jemand zum Einreichen hinsetzt. Der Watcher kann direkt nach der Einreichung starten oder als Scanner über eine Beobachtungsliste laufen, die aus den Übergabeblättern von Schritt 4 gespeist wird.

Eine Abhängigkeit, die Sie einplanen sollten: Der Auto-Download findet nur statt, solange die Client App auf einem Rechner läuft, der wach und online ist. Unter Windows installiert sie einen Hintergrunddienst, der Übertragungen auch nach dem Schließen des Hauptfensters fortsetzt. Betreiben Sie sie, oder Ihren geplanten aws s3 sync, auf einem Rechner, der über Nacht eingeschaltet bleibt.

Zusammenfassung: Was sich automatisieren lässt und wie

Automatisieren Sie beide Enden, halten Sie die Mitte kurz und bewusst, und verifizieren Sie alles, was zurückkommt. Wenn die meisten Ihrer Projekte Blender-Szenen sind, zeigt unsere Seite zur Blender-Cloud-render-farm, wie diese Jobs auf unserer Seite laufen; die Dokumentation der Client App und die Dokumentation des Einreichungs-Plugins beschreiben die manuellen Schritte im Detail.

FAQ

Q: Kann ich ein Projekt aus einem Python-Skript auf die render farm hochladen? A: Ja, mit S3-Zugriff. Generieren Sie unter Cloud Direct Connect in Ihrem Konto einen Access Key, konfigurieren Sie die AWS CLI damit (Region ap-southeast-1) und lassen Sie Ihr Skript aws s3 cp --recursive oder aws s3 sync auf den entpackten Projektordner in Ihr Remote Directory ausführen. Führen Sie zuvor Ihre Pre-Flight-Prüfung aus, damit ein defektes Projekt nie hochgeladen wird. Das anschließende Einreichen des Jobs bleibt manuell.

Q: Sollte ich den S3-Zugriff oder die Client App nutzen? A: Nutzen Sie den S3-Zugriff, wenn Übertragungen aus einem Skript oder von einem Scheduler laufen sollen oder wenn Ihr Team ohnehin mit einem S3-Client wie Cyberduck arbeitet. Nutzen Sie die Client App, wenn eine Person von Hand hochlädt: Sie setzt große Übertragungen nach einer abgebrochenen Verbindung fort, reicht Jobs ein und lädt fertige Frames automatisch herunter, sobald sie fertig sind. Beides lässt sich gut kombinieren: S3-Zugriff für skriptgesteuerte Übertragungen, die Client App für die Einreichung.

Q: Gibt es eine API oder ein SDK, um Render-Jobs aus meiner Pipeline einzureichen? A: Heute nicht. Jobs werden über das Web-Dashboard, die Client App oder das Einreichungs-Plugin in 3ds Max, Maya oder Cinema 4D eingereicht. Eine öffentliche API für die programmatische Einreichung steht auf unserer Roadmap, ist aber nicht verfügbar; bauen Sie Ihre Automatisierung daher um die Abschnitte, die Sie selbst verantworten. Wenn Ihre Pipeline daran hängt, schildern Sie unserem Support-Team den Anwendungsfall.

Q: Bietet die Farm SFTP- oder FTP-Zugang für große Übertragungen an? A: Nein. Wir betreiben keinen SFTP- oder FTP-Dienst für Uploads, Downloads oder Mietmaschinen. Große Projekte laufen über die Client App, die in fortsetzbaren, parallelen Chunks hochlädt, oder über den S3-Zugriff mit Cyberduck oder der AWS CLI. Fertige Frames kommen über den Auto-Download der Client App, den Web-Download oder den S3-Zugriff zurück.

Q: Woher weiß ich, dass alle meine Frames zurückgekommen sind? A: Lassen Sie einen Watcher auf dem Ordner laufen, in den die Client App den Job automatisch herunterlädt oder in den Ihr aws s3 sync schreibt. Zählen Sie ein Frame erst als fertig, wenn seine Größe über zwei Prüfungen stabil ist und sein Header gültig ist, und vergleichen Sie die verifizierte Menge mit dem erwarteten Bereich. Ist der Job abgeschlossen und fehlen weiterhin Frames, nutzen Sie Sync output in der Client App oder führen Sie die Synchronisierung erneut aus.

Q: Sollte ich das Projekt vor dem Upload zippen, um Zeit zu sparen? A: Nein. Die Farm entpackt keine Archive (.zip, .rar, .7z, .tar, .tar.gz); nichts in einem Archiv wird daher gerendert. Laden Sie den Projektordner entpackt hoch, mit der Szenendatei und jedem referenzierten Asset an seinem Platz, egal welchen Upload-Weg Sie nutzen.

Q: Wie lange werden gerenderte Frames auf der Farm aufbewahrt? A: Es gibt keinen festen automatischen Löschzeitraum. Dateien werden so lange aufbewahrt, wie es nötig ist, um Ihre Jobs auszuführen und Ihnen den Download Ihrer Ergebnisse zu ermöglichen, und wir löschen sie jederzeit auf Ihren Wunsch. Betrachten Sie Ihren eigenen Speicher als maßgebliches Archiv und nutzen Sie den Auto-Download der Client App, damit die Frames Ihre Platte erreichen, sobald sie fertig sind.