Automazione della render farm con Python: cosa puoi scriptare oggi

La parte più lenta di un render nel cloud è spesso tutto ciò che sta intorno al render: la scena che fallisce perché una texture punta ancora a un disco locale, l'upload che va rifatto da capo, i frame tornati indietro mentre nessuno ha controllato se fossero tornati tutti. La domanda utile è fin dove possa arrivare davvero uno script Python.

Gestiamo Super Renders Farm, una render farm completamente gestita, e vogliamo essere precisi su questo confine, perché un'automazione costruita su un percorso che non esiste fallisce alla prima notte senza supervisione. Ecco quindi subito la versione chiara. Il trasferimento dei file di progetto verso la farm si può scriptare: S3 access (Cloud Direct Connect nel tuo account) ti dà una chiave di accesso che l'AWS CLI usa per copiare i file da e verso il tuo SRF Space. L'invio dei job no: i job si inviano dalla dashboard web, dalla Client App o dal plugin di invio dentro 3ds Max, Maya o Cinema 4D. Non offriamo un servizio SFTP o FTP, né un'API o un SDK pubblici, né un endpoint di invio dei job richiamabile da codice. Un'API pubblica per l'invio programmatico è nella nostra roadmap; non è disponibile ora e nulla di quanto segue ne dipende.

Una nota per chi ha già visto questa pagina: una versione precedente descriveva trasferimenti scriptati via SFTP. Quel percorso non è offerto sulla nostra farm; oggi i trasferimenti scriptati passano da S3 access, come spieghiamo più avanti.

Resta comunque molto spazio per Python. Tutto ciò che precede l'upload, l'upload stesso e tutto ciò che accade dopo l'arrivo dei frame sul tuo disco si può scriptare. Per la mappa concettuale del rendering headless e non presidiato, vedi la nostra guida al flusso di lavoro non presidiato con una render farm headless; questa resta a livello di codice.

Dove passa il confine su una farm gestita

Sulla nostra farm la pipeline si divide in quattro tratti.

• Prima dell'upload: tuo, interamente scriptabile. Validazione della scena nel DCC, correzione dei percorsi, packaging, controlli pre-flight, checksum.
• Upload: scriptabile con S3 access, oppure manuale. L'AWS CLI copia la cartella del progetto nel tuo SRF Space da uno script. Le opzioni manuali sono l'upload web e la SuperRenders Client App. L'upload web non ha un limite rigido di dimensione, ma non riprende se la scheda del browser si chiude: per qualsiasi cosa oltre qualche gigabyte, o su una connessione instabile, usa la Client App (con ripresa e chunk paralleli) oppure S3 access. Un singolo upload da browser diventa lento sopra circa 2 GB e inaffidabile sopra circa 5 GB su connessioni domestiche.
• Invio: manuale. Invii dalla dashboard web, dalla Client App o dal plugin di invio, e la farm esegue Scene Analysis sul progetto caricato prima che il job venga addebitato.
• Dopo il render: di nuovo tuo. Con il download automatico della Client App attivo, i frame arrivano in una cartella locale man mano che ciascuno termina, oppure uno script li recupera via S3. Dal momento in cui un frame è sul tuo disco, ogni controllo, codifica, copia e notifica è uno script locale.

Quindi la forma realistica è un'automazione su entrambi i lati di un breve passaggio manuale, e gli script che seguono rendono quel passaggio rapido e difficile da sbagliare. Il nostro approfondimento su cos'è una render farm completamente gestita spiega cosa il modello gestito fa al posto tuo.

Tre corsie: controlli di scena e upload S3 scriptabili, invio manuale del job, poi controlli dei frame e encoding scriptabili L'automazione sta ai due lati di un breve passaggio manuale: valida, esegui il pre-flight, crea il manifest e carica dal tuo lato, invia a mano, poi verifica e post-elabora ciò che torna indietro.

Passo 1: valida la scena dentro il tuo DCC

Secondo la nostra esperienza, la maggior parte dei job di render falliti non dipende da bug del renderer. Sono lacune di packaging: una texture su un disco che la farm non vede mai, un file referenziato che non è stato raccolto, una cache una cartella sopra la radice del progetto. Un worker può aprire solo ciò che sta dentro la cartella caricata, quindi il primo script va dentro il DCC, dove può leggere l'elenco di dipendenze della scena stessa.

Ogni DCC importante lo espone tramite Python: maya.cmds in Maya, pymxs in 3ds Max, il modulo c4d in Cinema 4D, hou in Houdini, bpy in Blender. Esegui prima il passaggio di raccolta del DCC stesso (Resource Collector in 3ds Max, oppure Archive seguito dalla decompressione dell'archivio che produce; Save Project with Assets in Cinema 4D; in Blender, tieni gli asset sotto la cartella del .blend ed esegui Make Paths Relative). Il passaggio di raccolta riunisce i file; il tuo script ne verifica il risultato. La versione per Blender gira nello spazio di lavoro Scripting oppure in modalità headless con 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()

Lo schema vale per ogni DCC: risolvi ogni riferimento a un file, segnala tutto ciò che manca e tutto ciò che si risolve fuori dalla radice del progetto.

Alcuni progetti non possono passare ai percorsi relativi, perché le librerie di scatter, le librerie di persone e certe cache contengono percorsi assoluti al loro interno. Per questi, l'opzione Auto keep local path della Client App conserva in upload la struttura assoluta delle cartelle e, quando il percorso lato farm deve differire da quello locale, la nostra utility Simulate Local Path ricrea il percorso che la scena si aspetta. Il tuo script allora verifica «tutto ciò che sta sotto le radici che conservi» invece di «tutto ciò che sta sotto la radice del progetto». Per 3ds Max, la nostra guida su come impacchettare un file 3ds Max illustra il passaggio di raccolta.

Passo 2: controllo pre-flight della cartella del progetto

Il controllo nel DCC conosce la scena; il controllo sulla cartella conosce l'upload. Intercetta i problemi che vivono su disco: nessun file di scena, un archivio lasciato lì da qualcuno, file da zero byte dovuti a una copia interrotta, percorsi abbastanza lunghi da mettere in crisi le vecchie applicazioni Windows.

Il controllo sugli archivi conta più di quanto sembri. La farm non estrae gli archivi (.zip, .rar, .7z, .tar, .tar.gz), quindi nulla di ciò che sta dentro un archivio viene renderizzato. Carica la cartella del progetto non compressa, con il file di scena e ogni asset referenziato al proprio posto.

#!/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)

Il codice di uscita diverso da zero è il punto. Collega lo script a ciò che già gira a fine giornata dell'artista (uno strumento di publish, un hook di salvataggio, un pulsante «pronto per la farm»), così un progetto con problemi non arriva mai all'upload. I warning vengono stampati; i problemi bloccano.

Passo 3: scrivi un manifest per sapere esattamente cosa hai inviato

Quando un progetto supera il pre-flight, registralo. Un manifest elenca ogni file con dimensione e hash SHA-256, scritto accanto al progetto e non al suo interno, così non diventa mai parte dell'upload. Risponde a tre domande che altrimenti costano un pomeriggio: quale versione della scena è stata renderizzata, cosa è cambiato dall'ultimo invio e se la cartella su disco corrisponde ancora a ciò che è stato caricato.

# 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

Salva i manifest per shot e versione (shot010_v003.manifest.json) e il diff diventa un riepilogo di una riga: «due texture cambiate, una cache aggiunta, niente rimosso».

Scriptare i trasferimenti con l'AWS CLI

S3 access (Cloud Direct Connect nel tuo account) ti permette di generare una chiave di accesso e poi di collegare Cyberduck (protocollo: Amazon S3) o l'AWS CLI al tuo SRF Space per caricare e scaricare file. Cyberduck va bene per chi vuole un file browser; l'AWS CLI è lo strumento che uno script può pilotare. S3 access sposta solo file: non è un servizio SFTP o FTP e non invia job.

La configurazione si fa una sola volta per macchina. Nel tuo account apri Cloud Direct Connect, genera una chiave di accesso e copia Access Key ID, Secret Access Key e Remote Directory. Poi salva la chiave in un profilo AWS con nome:

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

Carica la cartella del progetto non compressa, la stessa che ha superato il pre-flight, nella tua Remote Directory:

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

aws s3 sync accetta la stessa origine e la stessa destinazione senza --recursive e copia solo i file nuovi o modificati per dimensione o timestamp, quindi rieseguirlo dopo un trasferimento interrotto salta ciò che è già arrivato. I file di grandi dimensioni vengono suddivisi automaticamente in upload multipart paralleli. I file caricati in questo modo compaiono nel tuo SRF Space e possono essere inviati come qualsiasi altro upload. Un'avvertenza per il pre-flight: quando un progetto si sincronizza sui nodi di render, i file che corrispondono a *.ini, *.db, *.tmp, *.temp, *.lnk, *.swap e *.partial, e qualsiasi cartella rendertemp/, vengono saltati, quindi la scena non deve dipendere da essi.

Il lato Python è un wrapper sottile: esegue il pre-flight, rifiuta l'upload se c'è un problema, poi passa la cartella all'AWS CLI.

# 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"])

Se preferisci restare dentro Python, upload_file di boto3 fa lo stesso lavoro sul bucket e sul prefisso della tua Remote Directory, con lo stesso profilo e la stessa regione.

La stessa chiave funziona nella direzione opposta. L'output renderizzato finisce nella cartella SuperRendersOutput/<jobId>/ del tuo Space (aws s3 ls "s3://<your Remote Directory>/SuperRendersOutput/" elenca le cartelle dei job) e un solo comando porta un job in una cartella locale:

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

Tratta la chiave come una password:

• Chiunque possieda la chiave può accedere al tuo SRF Space. Tienila in un profilo AWS o nelle variabili d'ambiente AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY sulla macchina che esegue l'upload, mai nello script stesso.
• Non committarla mai in un repository e non incollarla in una configurazione di pipeline condivisa. Tieni in una variabile d'ambiente anche la Remote Directory, come sopra.
• Ogni account ha una sola chiave e non scade. Se pensi che sia trapelata, o se deve cambiare, contatta il nostro team di supporto.

Ciò che resta manuale è l'invio. Dopo l'upload, invii comunque il job dalla dashboard web, dalla Client App o da un plugin DCC.

Passo 4: rendi l'handoff dell'invio breve e ripetibile

L'invio è una persona che compila un modulo, quindi fai in modo che il modulo sia la parte facile. Fai scrivere al passaggio di validazione anche una piccola scheda di handoff accanto al manifest: file di scena, camera, intervallo di frame, risoluzione, formato di output, motore di render e cartella locale in cui devono arrivare i frame. Chi invia copia i valori invece di ricordarli, e il watcher del Passo 5 legge la stessa scheda, quindi i due non possono divergere.

Tre convenzioni rendono la catena più facile da automatizzare:

• Una cartella per shot e versione (shot010_v003/), con il file di scena alla radice. Pre-flight, manifest, destinazione dell'upload e scheda di handoff dipendono tutti da quel nome.
• Numeri di frame con padding nei nomi di output (shot010.1001.exr). Un watcher non può verificare un intervallo che non riesce a leggere.
• Una cartella di download prevedibile per ogni job. La Client App scarica in un percorso predefinito impostato nelle sue impostazioni, e puoi sovrascriverlo per singolo job al momento dell'invio. Puntalo alla cartella di render dello shot.

In 3ds Max, Maya e Cinema 4D il plugin di invio legge intervallo di frame, percorso di output e impostazioni di render dalla scena aperta, precompila il modulo del job ed esegue un proprio controllo degli asset. Blender, Houdini e After Effects non hanno un plugin dentro il DCC, quindi questi job passano dalla Client App o dalla dashboard web. In entrambi i casi Scene Analysis gira prima che il job venga addebitato; i tuoi script fanno sì che questo passaggio ti fermi meno spesso.

Passo 5: verifica i frame che tornano

Con la Client App in esecuzione e il download automatico attivo (l'impostazione predefinita), ogni frame viene scaricato sulla tua macchina non appena termina sulla farm; con S3 access, è invece la tua esecuzione di aws s3 sync a riempire una cartella locale. In entrambi i casi la domanda diventa: «come faccio a sapere che sono arrivati tutti e integri?». Un watcher risponde usando solo file locali: un frame conta come completo solo quando la sua dimensione ha smesso di cambiare tra due polling e il suo header di file è valido.

# 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)

La ricerca è ricorsiva, quindi i frame vengono trovati per nome qualunque sia la struttura di sottocartelle usata dal download. Quando il job risulta completato ma il watcher segnala ancora dei buchi, usa Sync output su quel job nella Client App, che riscarica i frame mancanti (oppure riesegui aws s3 sync), e lascia girare di nuovo il watcher; fai lo stesso se la dimensione di un frame sembra troppo piccola, perché anche un download parziale bloccato può sembrare stabile. Se preferisci gli eventi al polling, il pacchetto watchdog incapsula le notifiche di modifica dei file del sistema operativo; mantieni comunque il controllo di stabilità. Se un job scrive render element o AOV come file separati, esegui un watcher per ogni passaggio, altrimenti un passaggio già finito può mascherare un frame beauty mancante con lo stesso numero.

Passo 6: operazioni locali dopo il render

Quando il watcher restituisce un elenco verificato, il resto è normale codice di pipeline:

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)

Alcune abitudini che vale la pena copiare:

• Codifica partendo da frame display-referred. PNG o JPEG possono andare direttamente in un filmato di review. Gli EXR lineari richiedono prima la tua pipeline colore (di solito una trasformazione OCIO), altrimenti il filmato risulterà scuro e piatto.
• Archivia il manifest insieme ai frame. Sei mesi dopo, «quali texture hanno prodotto questo render» è a un solo file di distanza.
• Notifica con i fatti. Numero di frame, frame che hanno richiesto una sincronizzazione, dimensione totale e percorso del filmato di review, pubblicati nella chat dello studio o nel tracker.
• Tieni la tua copia come archivio di riferimento. I file sulla nostra farm vengono conservati per il tempo necessario a eseguire i tuoi job e a permetterti di scaricare i risultati, senza un periodo di eliminazione automatica fisso, e li eliminiamo ogni volta che ce lo chiedi. Questo non è un piano di backup; il tuo archivio locale lo è.

Pianificare le parti locali

Nulla di tutto questo richiede un nuovo scheduler. Cron su Linux, launchd su macOS o Task Scheduler su Windows possono eseguire ogni sera pre-flight, manifest e upload con l'AWS CLI sui progetti contrassegnati come «pronti», così i file sono nel tuo SRF Space prima che qualcuno si sieda a inviare. Il watcher può partire subito dopo l'invio, oppure girare come scanner su un elenco di controllo alimentato dalle schede di handoff del Passo 4.

Una dipendenza di cui tenere conto: il download automatico avviene solo mentre la Client App è in esecuzione su una macchina accesa e online. Su Windows installa un servizio in background che mantiene attivi i trasferimenti anche dopo la chiusura della finestra principale. Esegui la Client App, o il tuo aws s3 sync pianificato, su una macchina che resta accesa di notte.

Riepilogo: cosa automatizzare e come

Automatizza entrambe le estremità, mantieni breve e deliberato il passaggio centrale e verifica tutto ciò che torna. Se la maggior parte dei tuoi progetti sono scene Blender, la nostra pagina sulla cloud render farm per Blender spiega come girano quei job da parte nostra, mentre la documentazione della Client App e la documentazione del plugin di invio descrivono nel dettaglio i passaggi manuali.

FAQ

Q: Posso caricare un progetto sulla render farm da uno script Python? A: Sì, con S3 access. Genera una chiave di accesso in Cloud Direct Connect nel tuo account, configura l'AWS CLI con quella chiave (regione ap-southeast-1) e fai eseguire al tuo script aws s3 cp --recursive oppure aws s3 sync sulla cartella del progetto non compressa, verso la tua Remote Directory. Esegui prima il controllo pre-flight, così un progetto difettoso non parte mai. L'invio del job, dopo, resta manuale.

Q: Devo usare S3 access o la Client App? A: Usa S3 access quando i trasferimenti devono girare da uno script o da uno scheduler, oppure quando il tuo team lavora già con un client S3 come Cyberduck. Usa la Client App quando è una persona a caricare a mano: riprende i trasferimenti grandi dopo una connessione interrotta, invia i job e scarica automaticamente i frame finiti man mano che terminano. I due strumenti si combinano bene: S3 access per i trasferimenti scriptati, la Client App per l'invio.

Q: Esiste un'API o un SDK per inviare job di render dalla mia pipeline? A: Oggi no. I job si inviano dalla dashboard web, dalla Client App o dal plugin di invio in 3ds Max, Maya o Cinema 4D. Un'API pubblica per l'invio programmatico è nella nostra roadmap ma non è disponibile, quindi costruisci l'automazione attorno alle fasi che controlli tu. Se la tua pipeline è bloccata da questo, racconta il caso d'uso al nostro team di supporto.

Q: La farm offre accesso SFTP o FTP per i trasferimenti di grandi dimensioni? A: No. Non gestiamo un servizio SFTP o FTP per upload, download o macchine a noleggio. I progetti grandi passano dalla Client App, che carica in chunk paralleli e ripristinabili, oppure da S3 access con Cyberduck o l'AWS CLI. I frame finiti tornano tramite il download automatico della Client App, il download web o S3 access.

Q: Come faccio a sapere che tutti i miei frame sono tornati? A: Fai girare un watcher sulla cartella in cui la Client App scarica automaticamente il job, oppure in cui scrive il tuo aws s3 sync. Conta un frame come completato solo quando la sua dimensione è stabile tra due controlli e il suo header è valido, e confronta l'insieme verificato con l'intervallo atteso. Se il job è completato ma mancano ancora dei frame, usa Sync output nella Client App oppure riesegui la sincronizzazione.

Q: Devo comprimere il progetto in uno zip prima dell'upload per risparmiare tempo? A: No. La farm non estrae gli archivi (.zip, .rar, .7z, .tar, .tar.gz), quindi nulla di ciò che sta dentro un archivio viene renderizzato. Carica la cartella del progetto non compressa, con il file di scena e ogni asset referenziato al proprio posto, qualunque percorso di upload tu usi.

Q: Per quanto tempo restano sulla farm i frame renderizzati? A: Non esiste un periodo di eliminazione automatica fisso. I file vengono conservati per il tempo necessario a eseguire i tuoi job e a permetterti di scaricare i risultati, e li eliminiamo ogni volta che ce lo chiedi. Considera il tuo storage l'archivio di riferimento e usa il download automatico della Client App, così i frame arrivano sul tuo disco man mano che terminano.