Automatisation d'une render farm avec Python : ce que vous pouvez scripter aujourd'hui

La partie la plus lente d'un rendu cloud est souvent tout ce qui entoure le rendu lui-même : la scène qui échoue parce qu'une texture pointe encore vers un disque local, le téléversement à relancer, les images revenues sans que personne ne vérifie si elles sont toutes revenues. La bonne question est de savoir jusqu'où un script Python peut réellement aller.

Nous exploitons Super Renders Farm, une render farm entièrement gérée, et nous voulons être précis sur cette frontière, car une automatisation construite sur un chemin qui n'existe pas échoue dès sa première nuit sans surveillance. Voici donc la version claire d'entrée de jeu. Le transfert des fichiers de projet vers la render farm peut être scripté : l'accès S3 (Cloud Direct Connect dans votre compte) vous donne une clé d'accès que l'AWS CLI utilise pour copier des fichiers vers et depuis votre SRF Space. La soumission des tâches, non : elles se soumettent depuis le tableau de bord web, le Client App ou le plugin de soumission intégré à 3ds Max, Maya ou Cinema 4D. Nous ne proposons ni service SFTP ou FTP, ni API ou SDK publics, ni point d'accès de soumission de tâches appelable depuis du code. Une API publique de soumission programmatique figure sur notre feuille de route ; elle n'est pas disponible aujourd'hui, et rien de ce qui suit n'en dépend.

Une remarque pour les lecteurs qui ont déjà vu cette page : une version antérieure décrivait des transferts scriptés via SFTP. Ce chemin n'est pas proposé sur notre render farm ; les transferts scriptés passent désormais par l'accès S3, détaillé plus bas.

Il reste donc beaucoup à faire pour Python. Tout ce qui précède le téléversement, le téléversement lui-même et tout ce qui suit l'arrivée des images sur votre disque peut être scripté. Pour la carte conceptuelle du rendu headless et sans surveillance, consultez notre guide sur le workflow de render farm headless sans surveillance ; celui-ci reste au niveau du code.

Où passe la frontière sur une render farm gérée

Sur notre render farm, le pipeline se découpe en quatre étapes.

• Avant le téléversement : à vous, entièrement scriptable. Validation de scène dans votre DCC, correction des chemins, empaquetage, contrôles de pré-vol, sommes de contrôle.
• Téléversement : scriptable avec l'accès S3, ou manuel. L'AWS CLI copie le dossier de projet vers votre SRF Space depuis un script. Les options manuelles sont le téléversement web et le SuperRenders Client App. Le téléversement web n'a pas de plafond de taille strict, mais il ne reprend pas si l'onglet se ferme ; au-delà de quelques gigaoctets, ou sur une connexion instable, utilisez donc le Client App (reprise possible, blocs en parallèle) ou l'accès S3. Un téléversement unique dans le navigateur devient lent au-dessus d'environ 2 Go et peu fiable au-dessus d'environ 5 Go sur une connexion résidentielle.
• Soumission : manuelle. Vous soumettez depuis le tableau de bord web, le Client App ou le plugin de soumission, et la render farm exécute Scene Analysis sur le projet téléversé avant la facturation de la tâche.
• Après le rendu : à vous de nouveau. Avec le téléchargement automatique du Client App activé, les images arrivent dans un dossier local au fur et à mesure qu'elles se terminent, ou un script les récupère via S3. Dès qu'une image est sur votre disque, tout contrôle, encodage, copie ou notification est un script local.

La forme réaliste est donc une automatisation de part et d'autre d'une courte étape manuelle, et les scripts ci-dessous rendent cette étape rapide et difficile à rater. Notre explication de ce qu'est une render farm entièrement gérée détaille ce que le modèle géré prend en charge à votre place.

Trois voies : contrôles de scène scriptables et téléversement S3, soumission manuelle des tâches, puis contrôles d'images et encodage scriptables L'automatisation se place de part et d'autre d'une courte étape manuelle : valider, contrôler en pré-vol, écrire le manifeste et téléverser de votre côté, soumettre à la main, puis vérifier et post-traiter ce qui revient.

Étape 1 : valider la scène dans votre DCC

D'après notre expérience, la plupart des tâches de rendu qui échouent ne viennent pas d'un bogue du moteur de rendu, mais de lacunes d'empaquetage : une texture sur un disque que la render farm ne voit jamais, un fichier référencé qui n'a pas été collecté, un cache situé un dossier au-dessus de la racine du projet. Un nœud de rendu ne peut ouvrir que ce qui se trouve dans le dossier téléversé ; le premier script a donc sa place dans le DCC, où il peut lire la liste de dépendances de la scène.

Tous les grands DCC exposent cela via Python : maya.cmds dans Maya, pymxs dans 3ds Max, le module c4d dans Cinema 4D, hou dans Houdini, bpy dans Blender. Lancez d'abord l'étape de collecte propre au DCC (Resource Collector dans 3ds Max, ou Archive suivi de la décompression de l'archive produite ; Save Project with Assets dans Cinema 4D ; dans Blender, gardez les assets sous le dossier du .blend et lancez Make Paths Relative). L'étape de collecte rassemble les fichiers ; votre script prouve le résultat. La version Blender s'exécute dans l'espace de travail Scripting ou en mode headless avec 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()

Le schéma se transpose à tous les DCC : résoudre chaque référence de fichier, signaler tout ce qui manque et tout ce qui se résout en dehors de la racine du projet.

Certains projets ne peuvent pas passer en chemins relatifs, car les bibliothèques de dispersion (scatter), les bibliothèques de personnages et certains caches contiennent des chemins absolus en interne. Pour ceux-là, l'option Auto keep local path du Client App conserve la structure de dossiers absolue au téléversement, et quand le chemin côté render farm doit différer du vôtre en local, notre utilitaire Simulate Local Path recrée le chemin attendu par la scène. Votre script vérifie alors « tout ce qui se trouve sous les racines que vous conservez » au lieu de « tout ce qui se trouve sous la racine du projet ». Pour 3ds Max, notre guide sur l'empaquetage d'un fichier 3ds Max détaille l'étape de collecte.

Étape 2 : contrôle de pré-vol du dossier de projet

Le contrôle DCC connaît la scène ; le contrôle du dossier connaît le téléversement. Il détecte les problèmes qui vivent sur le disque : aucun fichier de scène, une archive glissée là par quelqu'un, des fichiers de zéro octet issus d'une copie interrompue, des chemins assez longs pour faire trébucher d'anciennes applications Windows.

Le contrôle des archives compte plus qu'il n'y paraît. La render farm n'extrait pas les archives (.zip, .rar, .7z, .tar, .tar.gz) : rien de ce qu'elles contiennent n'est donc rendu. Téléversez votre dossier de projet non compressé, avec le fichier de scène et chaque asset référencé à sa place.

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

Le code de sortie non nul est tout l'intérêt. Branchez le script sur ce qui s'exécute déjà en fin de journée d'un artiste (un outil de publication, un hook de sauvegarde, un bouton « prêt pour la render farm ») afin qu'un projet à problèmes n'atteigne jamais le téléversement. Les avertissements s'affichent ; les problèmes bloquent.

Étape 3 : écrire un manifeste pour savoir exactement ce que vous avez envoyé

Une fois qu'un projet passe le pré-vol, enregistrez-le. Un manifeste liste chaque fichier avec sa taille et son empreinte SHA-256, écrit à côté du projet et non dedans, afin qu'il ne fasse jamais partie du téléversement. Il répond à trois questions qui coûtent sinon un après-midi : quelle version de la scène a été rendue, ce qui a changé depuis la dernière soumission, et si le dossier sur disque correspond encore à ce qui a été envoyé.

# 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

Rangez les manifestes par plan et par version (shot010_v003.manifest.json) et la comparaison devient un résumé d'une ligne : « deux textures modifiées, un cache ajouté, rien de supprimé ».

Scripter les transferts avec l'AWS CLI

L'accès S3 (Cloud Direct Connect dans votre compte) vous permet de générer une clé d'accès, puis de connecter Cyberduck (protocole : Amazon S3) ou l'AWS CLI à votre SRF Space pour téléverser et télécharger des fichiers. Cyberduck convient à ceux qui veulent un navigateur de fichiers ; l'AWS CLI est celui qu'un script peut piloter. L'accès S3 ne fait que déplacer des fichiers : ce n'est pas un service SFTP ou FTP, et il ne soumet pas de tâches.

La configuration se fait une fois par machine. Dans votre compte, ouvrez Cloud Direct Connect, générez une clé d'accès et copiez l'Access Key ID, la Secret Access Key et le Remote Directory. Stockez ensuite la clé dans un profil AWS nommé :

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

Téléversez le dossier de projet non compressé, celui qui a passé le pré-vol, dans votre Remote Directory :

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

aws s3 sync prend la même source et la même cible sans --recursive et ne copie que les fichiers nouveaux ou modifiés (taille ou horodatage) ; le relancer après un transfert interrompu ignore donc ce qui est déjà arrivé. Les gros fichiers sont automatiquement découpés en envois multipartites parallèles. Les fichiers téléversés de cette façon apparaissent dans votre SRF Space et peuvent être soumis comme n'importe quel autre téléversement. Une précaution pour le pré-vol : quand un projet est synchronisé vers les nœuds de rendu, les fichiers correspondant à *.ini, *.db, *.tmp, *.temp, *.lnk, *.swap et *.partial, ainsi que tout dossier rendertemp/, sont ignorés ; la scène ne doit donc pas en dépendre.

Côté Python, il suffit d'un fin wrapper : exécuter le pré-vol, refuser de téléverser en cas de problème, puis confier le dossier à l'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"])

Si vous préférez rester dans Python, upload_file de boto3 fait le même travail sur le bucket et le préfixe de votre Remote Directory, avec le même profil et la même région.

La même clé fonctionne dans l'autre sens. Le résultat du rendu arrive dans le dossier SuperRendersOutput/<jobId>/ de votre Space (aws s3 ls "s3://<your Remote Directory>/SuperRendersOutput/" liste les dossiers de tâches), et une seule commande rapatrie une tâche dans un dossier local :

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

Traitez la clé comme un mot de passe :

• Quiconque détient la clé peut accéder à votre SRF Space. Conservez-la dans un profil AWS ou dans les variables d'environnement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY de la machine qui exécute le téléversement, jamais dans le script lui-même.
• Ne la commitez jamais dans un dépôt et ne la collez pas dans une configuration de pipeline partagée. Conservez aussi le Remote Directory dans une variable d'environnement, comme ci-dessus.
• Chaque compte dispose d'une seule clé, qui n'expire pas. Si vous pensez qu'elle a fuité, ou si elle doit être changée, contactez notre équipe d'assistance.

Ce qui reste manuel, c'est la soumission. Après le téléversement, vous soumettez toujours la tâche depuis le tableau de bord web, le Client App ou un plugin DCC.

Étape 4 : rendre la transmission à la soumission courte et reproductible

La soumission, c'est une personne qui remplit un formulaire : faites donc du formulaire la partie facile. Faites écrire à l'étape de validation une petite fiche de transmission à côté du manifeste : fichier de scène, caméra, plage d'images, résolution, format de sortie, moteur de rendu et dossier local où les images doivent arriver. La personne qui soumet copie les valeurs au lieu de les retenir de mémoire, et le script de surveillance de l'étape 5 lit la même fiche ; les deux ne peuvent donc pas diverger.

Trois conventions facilitent l'automatisation de la chaîne :

• Un dossier par plan et par version (shot010_v003/), avec le fichier de scène à sa racine. Le pré-vol, le manifeste, la cible de téléversement et la fiche de transmission s'appuient tous sur ce nom.
• Des numéros d'image complétés par des zéros dans les noms de sortie (shot010.1001.exr). Un script de surveillance ne peut pas vérifier une plage qu'il ne sait pas analyser.
• Un dossier de téléchargement prévisible par tâche. Le Client App télécharge vers un chemin par défaut défini dans ses paramètres, et vous pouvez remplacer ce chemin tâche par tâche au moment de la soumission. Pointez-le vers le dossier de rendu propre au plan.

Dans 3ds Max, Maya et Cinema 4D, le plugin de soumission lit la plage d'images, le chemin de sortie et les réglages de rendu dans la scène ouverte, pré-remplit le formulaire de tâche et exécute son propre contrôle des assets. Blender, Houdini et After Effects n'ont pas de plugin intégré au DCC ; ces tâches passent donc par le Client App ou le tableau de bord web. Dans tous les cas, Scene Analysis s'exécute avant la facturation de la tâche ; vos scripts font que cette barrière vous arrête moins souvent.

Étape 5 : vérifier les images qui reviennent

Quand le Client App tourne avec le téléchargement automatique activé (par défaut), chaque image est téléchargée sur votre machine dès qu'elle est terminée sur la render farm ; avec l'accès S3, c'est votre propre exécution de aws s3 sync qui remplit un dossier local. Dans les deux cas, la question devient « comment savoir que toutes les images sont arrivées intactes ». Un script de surveillance y répond à partir des seuls fichiers locaux : une image n'est considérée comme complète que lorsque sa taille a cessé de changer entre deux relevés et que son en-tête de fichier est valide.

# 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 recherche est récursive : les images sont donc retrouvées par leur nom, quelle que soit l'organisation en sous-dossiers du téléchargement. Quand la tâche apparaît comme terminée mais que le script de surveillance signale encore des manques, utilisez Sync output sur cette tâche dans le Client App, qui retélécharge les images manquantes (ou relancez aws s3 sync), puis laissez le script tourner de nouveau ; faites de même si la taille d'une image paraît trop courte, car un téléchargement partiel bloqué peut lui aussi sembler stable. Si vous préférez les événements à l'interrogation périodique, le paquet watchdog encapsule les notifications de changement de fichier du système d'exploitation ; conservez dans tous les cas le contrôle de stabilité. Si une tâche écrit des éléments de rendu ou des AOV dans des fichiers séparés, lancez un script de surveillance par passe, sinon une passe terminée peut masquer une image beauty manquante portant le même numéro.

Étape 6 : étapes locales après le rendu

Une fois que le script de surveillance renvoie une liste vérifiée, le reste est du code de pipeline ordinaire :

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)

Quelques habitudes à reprendre :

• Encodez à partir d'images référencées à l'affichage. Des PNG ou JPEG peuvent aller directement vers une vidéo de revue. Un EXR linéaire a d'abord besoin de votre pipeline colorimétrique (généralement une transformation OCIO), faute de quoi la vidéo paraîtra sombre et terne.
• Archivez le manifeste avec les images. Six mois plus tard, « quelles textures ont produit ce rendu » se trouve à un fichier de distance.
• Notifiez avec des faits. Nombre d'images, images ayant nécessité une synchronisation, taille totale, chemin de la vidéo de revue, publiés sur la messagerie ou l'outil de suivi de votre studio.
• Gardez votre propre copie comme archive de référence. Les fichiers sur notre render farm sont conservés le temps nécessaire pour exécuter vos tâches et vous permettre de télécharger vos résultats, sans durée de suppression automatique fixe, et nous les supprimons dès que vous le demandez. Ce n'est pas un plan de sauvegarde ; votre archive locale, elle, en est un.

Planifier les éléments locaux

Rien de tout cela ne demande un nouvel ordonnanceur. Cron sous Linux, launchd sous macOS ou le Planificateur de tâches sous Windows peuvent exécuter chaque soir le pré-vol, le manifeste et le téléversement AWS CLI sur les projets marqués « prêts », de sorte que les fichiers soient dans votre SRF Space avant que quelqu'un s'assoie pour soumettre. Le script de surveillance peut démarrer juste après la soumission, ou tourner comme un scanner sur une liste de suivi alimentée par les fiches de transmission de l'étape 4.

Une dépendance à anticiper : le téléchargement automatique n'a lieu que tant que le Client App tourne sur une machine allumée et en ligne. Sous Windows, il installe un service en arrière-plan qui maintient les transferts après la fermeture de la fenêtre principale. Faites-le tourner, ou votre aws s3 sync planifié, sur une machine qui reste allumée toute la nuit.

Résumé : quoi automatiser, et comment

Automatisez les deux extrémités, gardez le milieu court et délibéré, et vérifiez tout ce qui revient. Si la plupart de vos projets sont des scènes Blender, notre page Blender cloud render farm explique comment ces tâches s'exécutent de notre côté, et la documentation du Client App ainsi que la documentation du plugin de soumission détaillent les étapes manuelles.

FAQ

Q: Puis-je téléverser un projet vers la render farm depuis un script Python ? A: Oui, avec l'accès S3. Générez une clé d'accès sous Cloud Direct Connect dans votre compte, configurez l'AWS CLI avec elle (région ap-southeast-1) et faites exécuter à votre script aws s3 cp --recursive ou aws s3 sync sur le dossier de projet non compressé, vers votre Remote Directory. Lancez d'abord votre contrôle de pré-vol pour qu'un projet défectueux ne parte jamais. La soumission de la tâche ensuite reste manuelle.

Q: Dois-je utiliser l'accès S3 ou le Client App ? A: Utilisez l'accès S3 quand les transferts doivent tourner depuis un script ou un ordonnanceur, ou quand votre équipe travaille déjà avec un client S3 comme Cyberduck. Utilisez le Client App quand une personne téléverse à la main : il reprend les gros transferts après une coupure de connexion, soumet les tâches et télécharge automatiquement les images terminées au fur et à mesure. Les deux se combinent bien : l'accès S3 pour les transferts scriptés, le Client App pour la soumission.

Q: Existe-t-il une API ou un SDK pour soumettre des tâches de rendu depuis mon pipeline ? A: Pas aujourd'hui. Les tâches sont soumises depuis le tableau de bord web, le Client App ou le plugin de soumission dans 3ds Max, Maya ou Cinema 4D. Une API publique de soumission programmatique figure sur notre feuille de route mais n'est pas disponible ; construisez donc l'automatisation autour des étapes qui vous appartiennent. Si votre pipeline est bloqué par ce manque, décrivez votre cas d'usage à notre équipe d'assistance.

Q: La render farm propose-t-elle un accès SFTP ou FTP pour les gros transferts ? A: Non. Nous n'exploitons pas de service SFTP ou FTP pour les téléversements, les téléchargements ou les machines en location. Les gros projets passent par le Client App, qui téléverse par blocs parallèles avec reprise, ou par l'accès S3 avec Cyberduck ou l'AWS CLI. Les images terminées reviennent via le téléchargement automatique du Client App, le téléchargement web ou l'accès S3.

Q: Comment savoir que toutes mes images sont bien revenues ? A: Faites tourner un script de surveillance sur le dossier où le Client App télécharge automatiquement la tâche, ou où votre aws s3 sync écrit. Ne comptez une image comme terminée que si sa taille est stable sur deux relevés et que son en-tête est valide, puis comparez l'ensemble vérifié à la plage attendue. Si la tâche est terminée et que des images manquent encore, utilisez Sync output dans le Client App ou relancez la synchronisation.

Q: Dois-je compresser le projet en zip avant le téléversement pour gagner du temps ? A: Non. La render farm n'extrait pas les archives (.zip, .rar, .7z, .tar, .tar.gz) : rien de ce qu'elles contiennent n'est donc rendu. Téléversez le dossier de projet non compressé, avec le fichier de scène et chaque asset référencé à sa place, quelle que soit la voie de téléversement.

Q: Combien de temps les images rendues sont-elles conservées sur la render farm ? A: Il n'y a pas de durée de suppression automatique fixe. Les fichiers sont conservés le temps nécessaire pour exécuter vos tâches et vous permettre de télécharger vos résultats, et nous les supprimons dès que vous le demandez. Considérez votre propre stockage comme l'archive de référence et utilisez le téléchargement automatique du Client App pour que les images arrivent sur votre disque au fur et à mesure.