Automatización de render farm con Python: qué programar

La parte más lenta de un render en la nube suele ser todo lo que rodea al render: la escena que falla porque una textura sigue apuntando a un disco local, la subida que hay que reiniciar, los fotogramas que volvieron sin que nadie comprobara si volvieron todos. La pregunta útil es hasta dónde puede llegar realmente un script de Python.

Operamos Super Renders Farm, una farm completamente gestionada, y queremos ser exactos sobre ese límite, porque una automatización construida sobre una vía que no existe falla en su primera noche desatendida. Así que aquí va la versión clara desde el principio. Mover los archivos del proyecto a la farm sí se puede automatizar con scripts: el acceso S3 (Cloud Direct Connect en su cuenta) le da una clave de acceso que la AWS CLI usa para copiar archivos desde y hacia su SRF Space. El envío de trabajos no: los trabajos se envían desde el panel web, la Client App o el plugin de envío dentro de 3ds Max, Maya o Cinema 4D. No ofrecemos un servicio SFTP ni FTP, ni una API o un SDK públicos, ni un endpoint de envío de trabajos que pueda llamar desde código. Una API pública para el envío programático está en nuestra hoja de ruta; no está disponible ahora, y nada de lo que sigue depende de ella.

Una nota para quienes vieron esta página antes: una versión anterior describía transferencias con scripts mediante SFTP. Esa vía no se ofrece en nuestra farm; las transferencias con scripts pasan ahora por el acceso S3, que se explica más abajo.

Aun así, queda mucho para Python. Todo lo que ocurre antes de la subida, la subida en sí y todo lo que ocurre cuando los fotogramas llegan a su disco puede automatizarse con scripts. Para el mapa conceptual del renderizado headless y desatendido, consulte nuestra guía sobre el flujo de trabajo headless y desatendido en una render farm; esta se queda en el nivel del código.

Dónde está el límite en una farm gestionada

En nuestra farm, el pipeline se divide en cuatro tramos.

Antes de la subida: suyo, totalmente automatizable. Validación de escena dentro de su DCC, correcciones de rutas, empaquetado, comprobaciones de pre-flight, checksums.
Subida: automatizable con el acceso S3, o manual. La AWS CLI copia la carpeta del proyecto a su SRF Space desde un script. Las opciones manuales son la subida web y la SuperRenders Client App. La subida web no tiene un límite de tamaño estricto, pero no se reanuda si se cierra la pestaña, así que para cualquier cosa que supere unos pocos gigabytes, o con una conexión inestable, use la Client App (reanudable, en fragmentos paralelos) o el acceso S3. Una única subida desde el navegador se vuelve lenta por encima de unos 2 GB y poco fiable por encima de unos 5 GB en conexiones domésticas.
Envío: manual. Usted envía el trabajo desde el panel web, la Client App o el plugin de envío, y la farm ejecuta Scene Analysis sobre el proyecto subido antes de que se cobre el trabajo.
Después del render: suyo de nuevo. Con la descarga automática de la Client App activada, los fotogramas llegan a una carpeta local a medida que cada uno termina, o bien un script los recoge por S3. Desde el momento en que un fotograma está en su disco, cada comprobación, codificación, copia y notificación es un script local.

Así que la forma realista es automatización a ambos lados de un breve paso manual, y los scripts de más abajo hacen que ese paso sea rápido y difícil de hacer mal. Nuestra explicación sobre qué es una render farm completamente gestionada cubre lo que el modelo gestionado hace por usted.

Tres carriles: comprobaciones de escena y subida por S3 automatizables, envío de trabajos manual, y después comprobación de fotogramas y codificación automatizables La automatización se sitúa a ambos lados de un breve paso manual: validar, hacer el pre-flight, crear el manifiesto y subir por su parte, enviar a mano, y después verificar y postprocesar lo que vuelve.

Paso 1: valide la escena dentro de su DCC

En nuestra experiencia, la mayoría de los trabajos de render fallidos no se deben a errores del motor de render. Son fallos de empaquetado: una textura en una unidad que la farm nunca ve, un archivo referenciado que no se recopiló, una caché una carpeta por encima de la raíz del proyecto. Un nodo de render solo puede abrir lo que está dentro de la carpeta subida, así que el primer script debe vivir dentro del DCC, donde puede leer la lista de dependencias de la propia escena.

Todos los DCC importantes lo exponen a través de Python: maya.cmds en Maya, pymxs en 3ds Max, el módulo c4d en Cinema 4D, hou en Houdini y bpy en Blender. Ejecute primero el paso de recopilación del propio DCC (Resource Collector en 3ds Max, o Archive seguido de descomprimir el archivo comprimido que genera; Save Project with Assets en Cinema 4D; en Blender, mantenga los assets bajo la carpeta del .blend y ejecute Make Paths Relative). El paso de recopilación reúne los archivos; su script comprueba el resultado. La versión para Blender se ejecuta en el espacio de trabajo Scripting o en modo 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()

El patrón se traslada a cualquier DCC: resuelva cada referencia a archivos, señale todo lo que falte y señale todo lo que se resuelva fuera de la raíz del proyecto.

Algunos proyectos no pueden pasar a rutas relativas, porque las bibliotecas de scatter, las bibliotecas de personas y ciertas cachés contienen rutas absolutas internamente. Para esos casos, la opción Auto keep local path de la Client App conserva la estructura de carpetas absoluta al subir, y cuando la ruta del lado de la farm tiene que ser distinta de su ruta local, nuestra utilidad Simulate Local Path recrea la ruta que la escena espera. Entonces su script comprueba "todo lo que esté bajo las raíces que conserva" en lugar de "todo lo que esté bajo la raíz del proyecto". Para 3ds Max, nuestra guía sobre cómo empaquetar un archivo de 3ds Max recorre el paso de recopilación.

Paso 2: compruebe la carpeta del proyecto (pre-flight)

La comprobación del DCC conoce la escena; la comprobación de la carpeta conoce la subida. Detecta los problemas que viven en el disco: ningún archivo de escena, un archivo comprimido que alguien metió, archivos de cero bytes por una copia interrumpida, rutas lo bastante largas como para hacer tropezar a aplicaciones antiguas de Windows.

La comprobación de archivos comprimidos importa más de lo que parece. La farm no extrae archivos comprimidos (.zip, .rar, .7z, .tar, .tar.gz), así que no se renderiza nada de lo que haya dentro de un archivo comprimido. Suba la carpeta de su proyecto sin comprimir, con el archivo de escena y todos los assets referenciados en su sitio.

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

El código de salida distinto de cero es lo esencial. Conecte el script a lo que ya se ejecute al final de la jornada de un artista (una herramienta de publicación, un hook de guardado, un botón "listo para la farm") para que un proyecto con problemas nunca llegue a la subida. Las advertencias se imprimen; los problemas bloquean.

Paso 3: escriba un manifiesto para saber exactamente qué envió

Cuando un proyecto supera el pre-flight, regístrelo. Un manifiesto enumera cada archivo con su tamaño y su hash SHA-256, y se escribe junto al proyecto y no dentro de él, para que nunca pase a formar parte de la subida. Responde tres preguntas que de otro modo cuestan una tarde: qué versión de la escena se renderizó, qué cambió desde el último envío y si la carpeta en disco sigue coincidiendo con lo que se subió.

# 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

Guarde los manifiestos por plano y versión (shot010_v003.manifest.json) y la diferencia se convierte en un resumen de una línea: "dos texturas cambiadas, una caché añadida, nada eliminado".

Transferencias con scripts mediante la AWS CLI

El acceso S3 (Cloud Direct Connect en su cuenta) le permite generar una clave de acceso y luego conectar Cyberduck (protocolo: Amazon S3) o la AWS CLI a su SRF Space para subir y descargar archivos. Cyberduck resulta adecuado para quien quiere un explorador de archivos; la AWS CLI es la que un script puede manejar. El acceso S3 solo mueve archivos: no es un servicio SFTP ni FTP, y no envía trabajos.

La configuración se hace una vez por equipo. En su cuenta, abra Cloud Direct Connect, genere una clave de acceso y copie el Access Key ID, la Secret Access Key y el Remote Directory. Después guarde la clave en un perfil con nombre de AWS:

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

Suba la carpeta del proyecto sin comprimir, la misma que superó el pre-flight, a su Remote Directory:

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

aws s3 sync toma el mismo origen y destino sin --recursive y copia solo los archivos nuevos o modificados según el tamaño o la marca de tiempo, de modo que volver a ejecutarlo tras una transferencia interrumpida omite lo que ya llegó. Los archivos grandes se dividen automáticamente en subidas multiparte en paralelo. Los archivos subidos de esta forma aparecen en su SRF Space y se pueden enviar como cualquier otra subida. Una advertencia para el pre-flight: cuando un proyecto se sincroniza con los nodos de render, se omiten los archivos que coincidan con *.ini, *.db, *.tmp, *.temp, *.lnk, *.swap y *.partial, y cualquier carpeta rendertemp/, así que la escena no debe depender de ellos.

La parte de Python es un envoltorio fino: ejecuta el pre-flight, se niega a subir si hay un problema y luego entrega la carpeta a la 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 prefiere no salir de Python, upload_file de boto3 hace el mismo trabajo contra el bucket y el prefijo de su Remote Directory, con el mismo perfil y la misma región.

La misma clave funciona en el otro sentido. La salida renderizada llega a la carpeta SuperRendersOutput/<jobId>/ de su Space (aws s3 ls "s3://<your Remote Directory>/SuperRendersOutput/" enumera las carpetas de trabajos), y un solo comando trae un trabajo a una carpeta local:

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

Trate la clave como una contraseña:

Cualquiera que tenga la clave puede acceder a su SRF Space. Guárdela en un perfil de AWS o en las variables de entorno AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY del equipo que ejecuta la subida, nunca en el propio script.
No la incluya nunca en un commit de un repositorio ni la pegue en la configuración compartida de un pipeline. Guarde también el Remote Directory en una variable de entorno, como arriba.
Cada cuenta tiene una sola clave, y no caduca. Si cree que se ha filtrado, o necesita cambiarla, contacte con nuestro equipo de soporte.

Lo que sigue siendo manual es el envío. Tras la subida, usted sigue enviando el trabajo desde el panel web, la Client App o un plugin de DCC.

Paso 4: haga que el traspaso al envío sea corto y repetible

El envío es una persona avanzando por un formulario, así que conviene que el formulario sea la parte fácil. Haga que el paso de validación escriba también una pequeña hoja de traspaso junto al manifiesto: archivo de escena, cámara, rango de fotogramas, resolución, formato de salida, motor de render y la carpeta local donde deben llegar los fotogramas. Quien envía copia valores en lugar de recordarlos, y el vigilante del paso 5 lee la misma hoja, así que ambos no pueden discrepar.

Tres convenciones facilitan la automatización de la cadena:

Una carpeta por plano y versión (shot010_v003/), con el archivo de escena en su raíz. El pre-flight, el manifiesto, el destino de la subida y la hoja de traspaso dependen de ese nombre.
Números de fotograma con relleno de ceros en los nombres de salida (shot010.1001.exr). Un vigilante no puede verificar un rango que no puede interpretar.
Una carpeta de descarga predecible por trabajo. La Client App descarga en una ruta predeterminada definida en sus ajustes, y usted puede cambiar la ruta por trabajo al enviarlo. Apúntela a la carpeta de render del propio plano.

En 3ds Max, Maya y Cinema 4D, el plugin de envío lee el rango de fotogramas, la ruta de salida y los ajustes de render de la escena abierta, rellena de antemano el formulario del trabajo y ejecuta su propia comprobación de assets. Blender, Houdini y After Effects no tienen plugin dentro del DCC, así que esos trabajos pasan por la Client App o el panel web. En cualquier caso, Scene Analysis se ejecuta antes de que se cobre el trabajo; sus scripts hacen que esa compuerta le detenga con menos frecuencia.

Paso 5: verifique los fotogramas que llegan

Con la Client App en ejecución y la descarga automática activada (el valor predeterminado), cada fotograma se descarga en su equipo en cuanto termina en la farm; con el acceso S3, es su propia ejecución de aws s3 sync la que rellena una carpeta local. En cualquier caso, la pregunta pasa a ser "cómo sé que todos llegaron intactos". Un vigilante responde a eso solo con archivos locales: un fotograma cuenta como completo únicamente cuando su tamaño ha dejado de cambiar entre dos consultas y la cabecera de su archivo es válida.

# 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 búsqueda es recursiva, así que los fotogramas se encuentran por nombre sea cual sea la estructura de subcarpetas que use la descarga. Cuando el trabajo figura como completado pero el vigilante sigue informando de huecos, use Sync output en ese trabajo dentro de la Client App, que vuelve a descargar los fotogramas que faltan (o vuelva a ejecutar aws s3 sync), y deje que el vigilante se ejecute de nuevo; haga lo mismo si el tamaño de un fotograma parece corto, porque una descarga parcial detenida también puede parecer estable. Si prefiere eventos a sondeo, el paquete watchdog envuelve las notificaciones de cambios de archivo del sistema operativo; mantenga la comprobación de estabilidad en cualquier caso. Si un trabajo escribe render elements o AOV como archivos separados, ejecute un vigilante por pase, o un pase terminado puede enmascarar un fotograma beauty que falta con el mismo número.

Paso 6: pasos locales posteriores al render

Cuando el vigilante devuelve una lista verificada, el resto es código de pipeline corriente:

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)

Unos hábitos que conviene copiar:

Codifique a partir de fotogramas referidos a la visualización. PNG o JPEG pueden ir directamente a un vídeo de revisión. El EXR lineal necesita antes su pipeline de color (normalmente una transformación OCIO), o el vídeo se verá oscuro y plano.
Archive el manifiesto junto con los fotogramas. Seis meses después, "qué texturas produjeron este render" queda a un solo archivo de distancia.
Notifique con datos. Número de fotogramas, fotogramas que necesitaron una sincronización, tamaño total y ruta del vídeo de revisión, publicados en el chat o el gestor de tareas de su estudio.
Conserve su propia copia como archivo de referencia. Los archivos en nuestra farm se conservan mientras haga falta para ejecutar sus trabajos y permitirle descargar sus resultados, sin un plazo fijo de eliminación automática, y los eliminamos cuando usted lo pida. Eso no es un plan de copias de seguridad; su archivo local sí lo es.

Programar las piezas locales

Nada de esto necesita un planificador nuevo. Cron en Linux, launchd en macOS o el Programador de tareas en Windows pueden ejecutar el pre-flight, el manifiesto y la subida con la AWS CLI sobre los proyectos marcados como "listos" cada tarde, de modo que los archivos estén en su SRF Space antes de que nadie se siente a enviar. El vigilante puede arrancar justo después del envío, o ejecutarse como un escáner sobre una lista de vigilancia alimentada por las hojas de traspaso del paso 4.

Una dependencia a tener en cuenta: la descarga automática solo ocurre mientras la Client App se ejecuta en un equipo encendido y conectado. En Windows instala un servicio en segundo plano que mantiene las transferencias activas después de cerrar la ventana principal. Ejecútela, o su aws s3 sync programado, en un equipo que permanezca encendido durante la noche.

Resumen: qué automatizar y cómo

Etapa	¿Se puede automatizar hoy en nuestra farm?	Cómo
Validación de escena (rutas ausentes y absolutas)	Sí	Python dentro del DCC (`bpy`, `maya.cmds`, `pymxs`, `c4d`, `hou`)
Comprobación de pre-flight de la carpeta del proyecto	Sí	Script local; bloquea ante archivos comprimidos, escena ausente y archivos de cero bytes
Manifiesto y diferencias de cambios	Sí	SHA-256 por archivo, JSON junto al proyecto
Subida a la farm	Sí, con el acceso S3	AWS CLI (`aws s3 cp --recursive` o `aws s3 sync`) con la clave de Cloud Direct Connect; las opciones manuales son la subida web (lenta por encima de unos 2 GB, poco fiable por encima de unos 5 GB) y la Client App (reanudable, fragmentos en paralelo)
Envío de trabajos	No	Panel web, Client App o plugin en 3ds Max, Maya y Cinema 4D; API pública en la hoja de ruta
Descarga de los fotogramas terminados	Sí, con el acceso S3, o se hace automáticamente por usted	`aws s3 sync` desde `SuperRendersOutput/<jobId>/`; o descarga automática de la Client App, fotograma a fotograma; o descarga web
Verificación de fotogramas	Sí	Vigilante local: tamaño estable, cabecera válida, rango completo presente
Codificación, archivo y notificación	Sí	ffmpeg, copia de archivos, su chat o su gestor de tareas

Automatice ambos extremos, mantenga breve y deliberado el tramo intermedio y verifique todo lo que vuelve. Si la mayoría de sus proyectos son escenas de Blender, nuestra página de render farm en la nube para Blender explica cómo se ejecutan esos trabajos de nuestro lado, y la documentación de la Client App y la documentación del plugin de envío cubren los pasos manuales en detalle.

FAQ

Q: ¿Puedo subir un proyecto a la render farm desde un script de Python? A: Sí, con el acceso S3. Genere una clave de acceso en Cloud Direct Connect dentro de su cuenta, configure la AWS CLI con ella (región ap-southeast-1) y haga que su script ejecute aws s3 cp --recursive o aws s3 sync sobre la carpeta del proyecto sin comprimir hacia su Remote Directory. Ejecute antes su comprobación de pre-flight para que un proyecto defectuoso nunca se suba. Enviar el trabajo después sigue siendo manual.

Q: ¿Debo usar el acceso S3 o la Client App? A: Use el acceso S3 cuando las transferencias deban ejecutarse desde un script o un planificador, o cuando su equipo ya trabaje con un cliente S3 como Cyberduck. Use la Client App cuando una persona sube los archivos a mano: reanuda las transferencias grandes tras una caída de la conexión, envía trabajos y descarga automáticamente los fotogramas terminados a medida que van terminando. Las dos se combinan bien: el acceso S3 para las transferencias con scripts y la Client App para el envío.

Q: ¿Hay una API o un SDK para enviar trabajos de render desde mi pipeline? A: Hoy no. Los trabajos se envían desde el panel web, la Client App o el plugin de envío de 3ds Max, Maya o Cinema 4D. Una API pública para el envío programático está en nuestra hoja de ruta pero no está disponible, así que construya la automatización en torno a las etapas que usted controla. Si su pipeline depende de ella, cuente el caso de uso a nuestro equipo de soporte.

Q: ¿Ofrece la farm acceso SFTP o FTP para transferencias grandes? A: No. No operamos un servicio SFTP ni FTP para subidas, descargas ni máquinas de alquiler. Los proyectos grandes pasan por la Client App, que sube en fragmentos reanudables y en paralelo, o por el acceso S3 con Cyberduck o la AWS CLI. Los fotogramas terminados regresan mediante la descarga automática de la Client App, la descarga web o el acceso S3.

Q: ¿Cómo sé que todos mis fotogramas han llegado? A: Ejecute un vigilante sobre la carpeta donde la Client App descarga automáticamente el trabajo, o donde escribe su aws s3 sync. Cuente un fotograma como terminado solo cuando su tamaño sea estable entre dos comprobaciones y su cabecera sea válida, y compare el conjunto verificado con el rango esperado. Si el trabajo está completo y aún faltan fotogramas, use Sync output en la Client App o vuelva a ejecutar la sincronización.

Q: ¿Debo comprimir el proyecto en un zip antes de subirlo para ahorrar tiempo? A: No. La farm no extrae archivos comprimidos (.zip, .rar, .7z, .tar, .tar.gz), así que no se renderiza nada de lo que haya dentro de un archivo comprimido. Suba la carpeta del proyecto sin comprimir, con el archivo de escena y todos los assets referenciados en su sitio, sea cual sea la vía de subida que utilice.

Q: ¿Cuánto tiempo se conservan en la farm los fotogramas renderizados? A: No hay un plazo fijo de eliminación automática. Los archivos se conservan mientras haga falta para ejecutar sus trabajos y permitirle descargar sus resultados, y los eliminamos cuando usted lo pida. Trate su propio almacenamiento como el archivo de referencia y use la descarga automática de la Client App para que los fotogramas lleguen a su disco a medida que terminan.