Automatização de render farm com Python: o que pode fazer por script hoje

A parte mais lenta de um render na nuvem é muitas vezes tudo o que acontece à volta do render: a cena que falha porque uma textura ainda aponta para uma unidade local, o upload que tem de ser reiniciado, os frames que voltaram sem que ninguém verificasse se voltaram todos. A pergunta útil é até onde um script Python consegue chegar de facto.

Operamos a Super Renders Farm, uma render farm totalmente gerida, e queremos ser exatos quanto a este limite, porque a automatização construída sobre um caminho que não existe falha na primeira noite sem supervisão. Por isso, aqui fica logo a versão simples. Enviar os ficheiros do projeto para a farm pode ser feito por script: o S3 access (Cloud Direct Connect na sua conta) dá-lhe uma chave de acesso que a AWS CLI usa para copiar ficheiros de e para o seu SRF Space. A submissão de trabalhos não: os trabalhos são submetidos a partir do painel de controlo web, da Client App ou do plugin de submissão dentro do 3ds Max, do Maya ou do Cinema 4D. Não oferecemos um serviço SFTP ou FTP, uma API ou SDK públicos, nem um endpoint de submissão de trabalhos que se possa chamar a partir de código. Uma API pública para submissão programática está no nosso roteiro; não está disponível agora, e nada do que se segue depende dela.

Uma nota para quem já viu esta página antes: uma versão anterior descrevia transferências por script através de SFTP. Esse caminho não é oferecido na nossa render farm; as transferências por script passam agora pelo S3 access, descrito mais abaixo.

Ainda assim, sobra muito para o Python. Tudo o que vem antes do upload, o próprio upload e tudo o que acontece depois de os frames chegarem ao seu disco pode ser feito por script. Para o mapa concetual da renderização headless e sem supervisão, consulte o nosso guia sobre fluxos de trabalho de render farm headless e sem supervisão; este fica ao nível do código.

Onde fica o limite numa render farm gerida

Na nossa farm, o pipeline divide-se em quatro etapas.

• Antes do upload: do seu lado, totalmente automatizável. Validação da cena dentro do DCC, correção de caminhos, empacotamento, verificações prévias, checksums.
• Upload: automatizável com S3 access, ou manual. A AWS CLI copia a pasta do projeto para o seu SRF Space a partir de um script. As opções manuais são o upload pela web e a SuperRenders Client App. O upload pela web não tem limite rígido de tamanho, mas não retoma se o separador for fechado, pelo que, para tudo acima de alguns gigabytes, ou numa ligação instável, deve usar-se a Client App (retomável, em blocos paralelos) ou o S3 access. Um único upload no navegador fica lento acima de cerca de 2 GB e pouco fiável acima de cerca de 5 GB em ligações residenciais.
• Submissão: manual. Submete-se a partir do painel de controlo web, da Client App ou do plugin de submissão, e a farm executa a Scene Analysis no projeto enviado antes de o trabalho ser cobrado.
• Depois do render: do seu lado outra vez. Com o download automático da Client App ativo, os frames chegam a uma pasta local à medida que cada um termina, ou um script vai buscá-los por S3. A partir do momento em que um frame está no seu disco, cada verificação, codificação, cópia e notificação é um script local.

Assim, a forma realista é automatização dos dois lados de um passo manual curto, e os scripts abaixo tornam esse passo rápido e difícil de errar. O nosso texto explicativo sobre o que é uma render farm totalmente gerida descreve o que o modelo gerido trata por si.

Três vias: verificações de cena e upload por S3 automatizáveis, submissão manual do trabalho, depois verificação de frames e codificação automatizáveis A automatização fica dos dois lados de um passo manual curto: validar, fazer a verificação prévia, gerar o manifesto e enviar do seu lado, submeter à mão e, depois, verificar e pós-processar o que volta.

Passo 1: valide a cena dentro do DCC

Na nossa experiência, a maioria dos trabalhos de render falhados não se deve a erros do renderizador. São falhas de empacotamento: uma textura numa unidade que a farm nunca vê, um ficheiro referenciado que não foi recolhido, uma cache uma pasta acima da raiz do projeto. Um nó só consegue abrir o que está dentro da pasta enviada, pelo que o primeiro script pertence ao interior do DCC, onde consegue ler a lista de dependências da própria cena.

Todos os principais DCC expõem isto através de Python: maya.cmds no Maya, pymxs no 3ds Max, o módulo c4d no Cinema 4D, hou no Houdini, bpy no Blender. Execute primeiro o passo de recolha do próprio DCC (Resource Collector no 3ds Max, ou Archive seguido da descompactação do ficheiro que este escreve; Save Project with Assets no Cinema 4D; no Blender, mantenha os assets na pasta do .blend e execute Make Paths Relative). O passo de recolha reúne os ficheiros; o seu script comprova o resultado. A versão para Blender corre no espaço de trabalho Scripting ou em headless com 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()

O padrão aplica-se a qualquer DCC: resolver todas as referências a ficheiros, sinalizar tudo o que estiver em falta e sinalizar tudo o que se resolva fora da raiz do projeto.

Alguns projetos não podem passar a caminhos relativos, porque bibliotecas de scatter, bibliotecas de pessoas e certas caches guardam caminhos absolutos internamente. Para esses, a opção Auto keep local path da Client App preserva a estrutura de pastas absoluta no upload e, quando o caminho do lado da farm tem de diferir do seu caminho local, o nosso utilitário Simulate Local Path recria o caminho que a cena espera. O seu script passa então a verificar «tudo o que está sob as raízes que preservou» em vez de «tudo o que está sob a raiz do projeto». Para o 3ds Max, o nosso guia sobre como empacotar um ficheiro 3ds Max percorre o passo de recolha.

Passo 2: verificação prévia da pasta do projeto

A verificação do DCC conhece a cena; a verificação da pasta conhece o upload. Apanha os problemas que vivem no disco: nenhum ficheiro de cena, um ficheiro compactado deixado ali por alguém, ficheiros de zero bytes de uma cópia interrompida, caminhos suficientemente longos para fazer tropeçar aplicações Windows mais antigas.

A verificação de ficheiros compactados importa mais do que parece. A farm não extrai ficheiros compactados (.zip, .rar, .7z, .tar, .tar.gz), pelo que nada dentro de um ficheiro compactado é renderizado. Envie a pasta do projeto descompactada, com o ficheiro de cena e todos os assets referenciados no lugar.

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

O código de saída diferente de zero é o essencial. Ligue o script ao que já corre no fim do dia de um artista (uma ferramenta de publicação, um hook de gravação, um botão «pronto para a farm»), para que um projeto com problemas nunca chegue ao upload. Os avisos são impressos; os problemas bloqueiam.

Passo 3: escreva um manifesto para saber exatamente o que enviou

Depois de um projeto passar a verificação prévia, registe-o. Um manifesto lista cada ficheiro com o seu tamanho e o seu hash SHA-256, escrito ao lado do projeto e não dentro dele, para nunca passar a fazer parte do upload. Responde a três perguntas que de outra forma custam uma tarde: que versão da cena foi renderizada, o que mudou desde a última submissão e se a pasta no disco ainda corresponde ao que foi enviado.

# 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 os manifestos por shot e versão (shot010_v003.manifest.json) e o diff passa a ser um resumo de uma linha: «duas texturas alteradas, uma cache adicionada, nada removido».

Automatizar transferências com a AWS CLI

O S3 access (Cloud Direct Connect na sua conta) permite gerar uma chave de acesso e depois ligar o Cyberduck (protocolo: Amazon S3) ou a AWS CLI ao seu SRF Space para enviar e descarregar ficheiros. O Cyberduck serve para quem quer um navegador de ficheiros; a AWS CLI é a que um script consegue conduzir. O S3 access apenas move ficheiros: não é um serviço SFTP ou FTP e não submete trabalhos.

A configuração faz-se uma vez por máquina. Na sua conta, abra Cloud Direct Connect, gere uma chave de acesso e copie o Access Key ID, a Secret Access Key e o Remote Directory. Depois guarde a chave num perfil AWS com 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

Envie a pasta do projeto descompactada, a mesma que passou a verificação prévia, para o seu Remote Directory:

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

O aws s3 sync recebe a mesma origem e o mesmo destino, sem --recursive, e copia apenas os ficheiros novos ou alterados por tamanho ou data e hora, pelo que voltar a executá-lo depois de uma transferência interrompida ignora o que já chegou. Os ficheiros grandes são divididos automaticamente em uploads multipart paralelos. Os ficheiros enviados desta forma aparecem no seu SRF Space e podem ser submetidos como qualquer outro upload. Uma ressalva para a verificação prévia: quando um projeto é sincronizado para os nós de render, os ficheiros que correspondam a *.ini, *.db, *.tmp, *.temp, *.lnk, *.swap e *.partial, e qualquer pasta rendertemp/, são ignorados, pelo que a cena não deve depender deles.

A parte em Python é um wrapper fino: executar a verificação prévia, recusar o upload se houver um problema e entregar a pasta à 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 preferir ficar dentro do Python, o upload_file do boto3 faz o mesmo trabalho sobre o bucket e o prefixo do seu Remote Directory, com o mesmo perfil e a mesma região.

A mesma chave funciona no sentido inverso. O output renderizado fica na pasta SuperRendersOutput/<jobId>/ do seu Space (aws s3 ls "s3://<your Remote Directory>/SuperRendersOutput/" lista as pastas dos trabalhos), e um só comando traz um trabalho para uma pasta local:

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

Trate a chave como uma palavra-passe:

• Quem tiver a chave consegue aceder ao seu SRF Space. Guarde-a num perfil AWS ou nas variáveis de ambiente AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY da máquina que executa o upload, nunca no próprio script.
• Nunca a inclua num commit de um repositório nem a cole numa configuração de pipeline partilhada. Guarde também o Remote Directory numa variável de ambiente, como acima.
• Cada conta tem uma única chave, e ela não expira. Se achar que foi divulgada, ou se for preciso alterá-la, contacte a nossa equipa de suporte.

O que continua manual é a submissão. Depois do upload, o trabalho continua a ser submetido a partir do painel de controlo web, da Client App ou de um plugin de DCC.

Passo 4: torne a entrega para submissão curta e repetível

A submissão é uma pessoa a percorrer um formulário, por isso faça do formulário a parte fácil. Faça o passo de validação escrever também uma pequena folha de entrega ao lado do manifesto: ficheiro de cena, câmara, intervalo de frames, resolução, formato de saída, motor de render e a pasta local onde os frames devem aterrar. Quem submete copia valores em vez de os tentar recordar, e o watcher do Passo 5 lê a mesma folha, pelo que os dois não podem discordar.

Três convenções tornam a cadeia mais fácil de automatizar:

• Uma pasta por shot e versão (shot010_v003/), com o ficheiro de cena na raiz. A verificação prévia, o manifesto, o destino do upload e a folha de entrega partem todos desse nome.
• Números de frame com zeros à esquerda nos nomes de saída (shot010.1001.exr). Um watcher não consegue verificar um intervalo que não consegue interpretar.
• Uma pasta de download previsível por trabalho. A Client App transfere para um caminho predefinido nas suas definições, e esse caminho pode ser substituído por trabalho na submissão. Aponte-o para a pasta de render do próprio shot.

No 3ds Max, no Maya e no Cinema 4D, o plugin de submissão lê o intervalo de frames, o caminho de saída e as definições de render da cena aberta, preenche previamente o formulário do trabalho e executa a sua própria verificação de assets. O Blender, o Houdini e o After Effects não têm plugin dentro do DCC, pelo que esses trabalhos passam pela Client App ou pelo painel de controlo web. De qualquer forma, a Scene Analysis corre antes de o trabalho ser cobrado; os seus scripts fazem com que essa barreira o trave com menos frequência.

Passo 5: verifique os frames que voltam

Com a Client App em execução e o download automático ativo (a predefinição), cada frame é transferido para a sua máquina assim que termina na farm; com S3 access, é a sua própria execução de aws s3 sync que preenche uma pasta local. Em ambos os casos a pergunta passa a ser «como sei que chegaram todos, intactos». Um watcher responde a partir apenas de ficheiros locais: um frame só conta como completo quando o seu tamanho deixou de mudar entre duas leituras e o cabeçalho do ficheiro é válido.

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

A pesquisa é recursiva, pelo que os frames são encontrados pelo nome, qualquer que seja a estrutura de subpastas do download. Quando o trabalho aparece como concluído mas o watcher continua a indicar lacunas, use Sync output nesse trabalho na Client App, que volta a transferir os frames em falta (ou volte a executar aws s3 sync), e deixe o watcher correr de novo; faça o mesmo se o tamanho de um frame parecer curto, porque um download parcial parado também pode parecer estável. Se preferir eventos a polling, o pacote watchdog envolve as notificações de alteração de ficheiros do sistema operativo; mantenha a verificação de estabilidade em ambos os casos. Se um trabalho escrever render elements ou AOVs como ficheiros separados, execute um watcher por passagem, ou uma passagem terminada pode mascarar um frame beauty em falta com o mesmo número.

Passo 6: passos locais pós-render

Quando o watcher devolve uma lista verificada, o resto é código de pipeline comum:

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)

Alguns hábitos que vale a pena copiar:

• Codifique a partir de frames referidos ao ecrã. PNG ou JPEG podem ir diretamente para um filme de revisão. O EXR linear precisa primeiro do seu pipeline de cor (normalmente uma transformação OCIO), ou o filme ficará escuro e plano.
• Arquive o manifesto com os frames. Seis meses depois, «que texturas produziram este render» está a um ficheiro de distância.
• Notifique com factos. Número de frames, frames que precisaram de sincronização, tamanho total, caminho do filme de revisão, publicados no chat do estúdio ou no tracker.
• Mantenha a sua própria cópia como arquivo de referência. Os ficheiros na nossa farm são mantidos durante o tempo necessário para executar os seus trabalhos e lhe permitir descarregar os resultados, sem prazo fixo de eliminação automática, e eliminamo-los sempre que o pedir. Isso não é um plano de cópias de segurança; o seu arquivo local é.

Agendar as peças locais

Nada disto precisa de um novo agendador. O cron no Linux, o launchd no macOS ou o Agendador de Tarefas no Windows podem executar a verificação prévia, o manifesto e o upload com a AWS CLI sobre os projetos marcados como «prontos» ao fim de cada dia, para que os ficheiros estejam no seu SRF Space antes de alguém se sentar para submeter. O watcher pode arrancar logo a seguir à submissão, ou correr como um scanner sobre uma lista de vigilância alimentada pelas folhas de entrega do Passo 4.

Uma dependência a planear: o download automático só acontece enquanto a Client App está em execução numa máquina que esteja ligada e online. No Windows, instala um serviço em segundo plano que mantém as transferências depois de a janela principal ser fechada. Execute-a, ou o seu aws s3 sync agendado, numa máquina que fique ligada durante a noite.

Resumo: o que automatizar e como

Automatize os dois extremos, mantenha o meio curto e deliberado e verifique tudo o que volta. Se a maioria dos seus projetos são cenas Blender, a nossa página de render farm na nuvem para Blender explica como esses trabalhos correm do nosso lado, e a documentação da Client App e a documentação do plugin de submissão cobrem os passos manuais em detalhe.

FAQ

Q: Posso enviar um projeto para a render farm a partir de um script Python? A: Sim, com S3 access. Gere uma chave de acesso em Cloud Direct Connect na sua conta, configure a AWS CLI com ela (região ap-southeast-1) e faça o seu script executar aws s3 cp --recursive ou aws s3 sync sobre a pasta do projeto descompactada, para o seu Remote Directory. Execute primeiro a verificação prévia, para que um projeto com problemas nunca seja enviado. Submeter o trabalho depois continua a ser manual.

Q: Devo usar o S3 access ou a Client App? A: Use o S3 access quando as transferências devem correr a partir de um script ou de um agendador, ou quando a sua equipa já trabalha com um cliente S3 como o Cyberduck. Use a Client App quando uma pessoa faz o upload à mão: retoma grandes transferências depois de uma ligação cair, submete trabalhos e transfere automaticamente os frames terminados à medida que ficam prontos. Os dois combinam bem: S3 access para transferências por script, Client App para a submissão.

Q: Existe uma API ou SDK para submeter trabalhos de render a partir do meu pipeline? A: Hoje não. Os trabalhos são submetidos a partir do painel de controlo web, da Client App ou do plugin de submissão no 3ds Max, Maya ou Cinema 4D. Uma API pública para submissão programática está no nosso roteiro, mas não está disponível, por isso construa a automatização em torno das etapas que controla. Se o seu pipeline estiver bloqueado por isso, indique o caso de utilização à nossa equipa de suporte.

Q: A farm oferece acesso SFTP ou FTP para transferências grandes? A: Não. Não operamos um serviço SFTP ou FTP para uploads, downloads ou máquinas de aluguer. Os projetos grandes passam pela Client App, que envia em blocos paralelos retomáveis, ou pelo S3 access com o Cyberduck ou a AWS CLI. Os frames terminados regressam pelo download automático da Client App, pelo download web ou pelo S3 access.

Q: Como sei se todos os meus frames voltaram? A: Execute um watcher na pasta onde a Client App transfere automaticamente o trabalho, ou onde o seu aws s3 sync escreve. Conte um frame como concluído apenas quando o seu tamanho for estável entre duas verificações e o cabeçalho for válido, e compare o conjunto verificado com o intervalo esperado. Se o trabalho estiver concluído e ainda faltarem frames, use Sync output na Client App ou volte a executar o sync.

Q: Devo compactar o projeto antes do upload para poupar tempo? A: Não. A farm não extrai ficheiros compactados (.zip, .rar, .7z, .tar, .tar.gz), pelo que nada dentro de um ficheiro compactado é renderizado. Envie a pasta do projeto descompactada, com o ficheiro de cena e todos os assets referenciados no lugar, seja qual for o caminho de upload usado.

Q: Durante quanto tempo os frames renderizados são mantidos na farm? A: Não há prazo fixo de eliminação automática. Os ficheiros são mantidos durante o tempo necessário para executar os seus trabalhos e lhe permitir descarregar os resultados, e eliminamo-los sempre que o pedir. Trate o seu próprio armazenamento como o arquivo de referência e use o download automático da Client App para que os frames cheguem ao seu disco à medida que terminam.