Skip to main content

Upload e Download de Ficheiros na Super Renders Farm


Upload e Download de Ficheiros na Super Renders Farm
Upload e Download de Ficheiros na Super Renders Farm

Introdução

Mover ficheiros de projeto de e para uma render farm é a parte do fluxo de trabalho que mais frequentemente corre mal. Uma renderização falha não porque o motor se comporte mal, mas porque um caminho de textura não resolveu no nó remoto, um projeto foi enviado como ZIP que a farm nunca descompacta, ou uma ligação doméstica lenta bloqueou a meio do upload após vinte minutos.

A Super Renders Farm suporta três formas de mover ficheiros de projeto (a interface web, o SuperRenders Client App, e o acesso S3 com o Cyberduck ou a AWS CLI) e três formas de recuperar a saída renderizada. Nenhuma delas é "a correta" em abstrato; cada uma tem um ponto forte definido pelo tamanho do ficheiro, velocidade de rede e frequência de re-submissão do mesmo projeto.

Este guia apresenta uma árvore de decisão para escolher o método que se adequa ao trabalho, instruções passo a passo para cada um, e uma referência para os erros de upload que vemos mais frequentemente no suporte.

Árvore de Decisão: Que Método de Upload Usar?

Os três métodos não são intercambiáveis. Usar esta curta árvore de decisão na primeira submissão de um projeto e depois mudar à medida que o fluxo de trabalho se estabiliza.

Usar a Interface Web se:

  • O tamanho total do projeto for inferior a ~2 GB
  • Os trabalhos são enviados ocasionalmente (algumas vezes por mês) em vez de continuamente
  • Se quiser zero instalação — apenas um browser

Usar o Client App se:

  • Os trabalhos são enviados pelo menos semanalmente e se quiserem menos passos manuais
  • O tamanho total do projeto for superior a ~2 GB
  • Se quiser que o upload recomece automaticamente em caso de quedas de ligação
  • Se quiser que os fotogramas concluídos sejam descarregados automaticamente para uma pasta local à medida que terminam

Usar o acesso S3 (Cyberduck ou a AWS CLI) se:

  • Já trabalha com um cliente S3 e prefere-o a um browser ou à Client App
  • Quiser programar em script os uploads para o seu SRF Space, ou os downloads a partir dele; a AWS CLI corre a partir de um terminal ou de um script agendado
  • Se se sentir confortável a lidar com uma chave de acesso (trate-a como uma palavra-passe)

Aplica-se uma pequena ressalva a todos os caminhos: a farm não descompacta ficheiros compactados (.zip, .rar, .7z, .tar, .tar.gz). A farm precisa de uma pasta de projeto não comprimida (o ficheiro de cena mais todos os recursos referenciados na estrutura de diretórios correta) para que o gestor de renderização possa resolver os caminhos de recursos. Explicamos isto na secção Erros de Upload Comuns abaixo.

Método 1: Upload pela Interface Web

O upload web é o caminho mais simples e o que recomendamos para primeiras submissões e projetos pequenos.

Passo a passo:

  1. Iniciar sessão na conta em superrendersfarm.com e abrir o dashboard de renderização.
  2. Clicar em Novo Trabalho (ou Submeter Projeto, dependendo da landing do motor de onde se chegou).
  3. Arrastar a pasta do projeto para a área de upload, ou clicar em Escolher Pasta e selecioná-la.
  4. Aguardar a conclusão da barra de progresso do upload. O browser mostra o progresso individual dos ficheiros para projetos com muitos recursos.
  5. Após o upload terminar, configurar as definições de renderização (intervalo de fotogramas, formato de saída, prioridade) e submeter o trabalho.

Limites práticos. Os browsers limitam as sessões de upload individuais, por isso o caminho web torna-se lento acima de ~2 GB e não fiável acima de ~5 GB em ligações residenciais. Se o separador do browser for fechado a meio do upload, a transferência é abortada — não há retomada do lado do browser. Para projetos nessa gama, mudar para o Client App.

O que é carregado. O arrastar e largar preserva exatamente a estrutura de pastas. Se a cena referenciar texturas em \texturas\ e \proxies\, essas subpastas precisam de estar dentro da pasta do projeto de nível superior arrastada, com os mesmos nomes. As referências em falta na render farm quase sempre rastreiam a uma destas subpastas estar fora da raiz do upload.

Método 2: SuperRenders Client App

O Client App é o caminho para o qual a maioria dos estúdios de produção eventualmente converge. Trata de retomada após desconexão, verificações de integridade e descarregamento automático de fotogramas concluídos — nenhum dos quais o caminho do browser suporta.

Passo a passo:

  1. Descarregar o Client App da página de Download e instalá-lo na estação de trabalho.
  2. Iniciar sessão com as credenciais da conta Super Renders Farm.
  3. Clicar em Novo Projeto e selecionar a pasta do projeto. A aplicação procura o ficheiro de cena e os recursos referenciados.
  4. Rever a lista de ficheiros — a aplicação mostra referências em falta antes do upload iniciar, para que possam ser corrigidas localmente em vez de após uma renderização falhada.
  5. Clicar em Upload. O progresso é mostrado por ficheiro, e o upload retoma automaticamente se a ligação cair.
  6. Após o upload completar, configurar as definições de renderização dentro da aplicação e submeter.

Descarregamento automático. O Client App também trata da viagem de volta. Após ativar uma pasta de saída local, os fotogramas concluídos chegam à estação de trabalho à medida que cada fotograma termina — não é necessário esperar que o trabalho todo complete antes de recuperar qualquer coisa.

Nota sobre plugin v1 vs v2. Os estúdios a usar versões mais antigas do Client App devem verificar a referência de ferramentas e Client App para os caminhos de instalação atuais, compatibilidade de versão de plugin e o plano de migração quando Spaces (a nossa camada de transferência de próxima geração) substituir o Client App. Esse documento cobre a integração de plugin por DCC, submissão de ponta a ponta e passos de resolução de problemas em profundidade — esta página apenas cobre a superfície de upload e download.

Método 3: Acesso S3 (Cyberduck ou a AWS CLI)

O acesso S3 permite mover ficheiros entre a sua estação de trabalho e o seu SRF Space com um cliente S3 padrão, sem o browser ou a Client App. Os ficheiros que carrega desta forma aparecem no seu SRF Space e podem ser usados num trabalho como qualquer outro upload. O acesso S3 apenas move ficheiros: continua a submeter o trabalho a partir do painel web, da Client App, ou de um plugin DCC.

Passo a passo:

  1. Na sua conta, abra Cloud Direct Connect e gere a sua chave de acesso (o portal chama-lhe a sua conta FTP). Copie o Access Key ID, o Secret Access Key e o Remote Directory.
  2. Cyberduck: escolha Open Connection, selecione o protocolo Amazon S3 e introduza o Access Key ID e o Secret Access Key. Expanda More Options e introduza o seu Remote Directory em Path, depois ligue-se.
  3. AWS CLI: execute aws configure, introduza o Access Key ID e o Secret Access Key, defina a região como ap-southeast-1 e deixe o formato de saída em branco. Depois copie a pasta de projeto descompactada para o seu Remote Directory, por exemplo aws s3 cp ./my-project s3://<Remote Directory>/my-project --recursive.
  4. Submeta o trabalho a partir do painel web, da Client App, ou de um plugin DCC, escolhendo os ficheiros que carregou.

Recuperar a saída através do S3. Os frames concluídos são escritos na pasta SuperRendersOutput/<job ID>/ dentro do seu SRF Space, para que os possa obter com o mesmo cliente, por exemplo aws s3 sync s3://<Remote Directory>/SuperRendersOutput/<job ID>/ ./frames/.

Bom saber. A sua conta tem uma única chave de acesso, e ela não expira. Trate-a como uma palavra-passe: mantenha-a fora de scripts e repositórios partilhados. Se precisar de a alterar, contacte o suporte. Ficheiros temporários e de sistema (*.tmp, *.temp, *.partial, *.swap, *.lnk, *.ini, *.db) e qualquer pasta rendertemp/ não são passados aos nós de renderização, por isso mantenha os dados de cena fora de ficheiros com esses nomes.

Utilize o Cyberduck com o protocolo Amazon S3 ou a AWS CLI; o FileZilla e os clientes FTP/SFTP não conseguirão ligar-se.

Comparação: Métodos em Resumo

MétodoIdeal paraGama de tamanho práticaRetoma após desconexão?Descarregamento automático de saída?
Interface WebProjetos ocasionais e pequenosMenos de ~2 GBNãoNão (download manual)
Client AppEstúdios com submissões regulares e projetos grandes2 GB e acimaSimSim
Acesso S3 (Cyberduck / AWS CLI)Equipas que já utilizam um cliente S3, ou transferências programadas em scriptSem limite definido por nósGerido pelo clienteSim, se programar o download a partir de SuperRendersOutput/

Corresponder o método à forma do projeto. Um still de 200 MB está bem pelo browser; uma animação de 60 GB com fluidos cacheados deve passar pelo Client App, ou pelo acesso S3, se o seu pipeline já programa as suas transferências em script.

Erros de Upload Comuns

Estes são os erros que vemos mais frequentemente no suporte, e o que verificar primeiro.

"Fiz upload de um .zip, .rar ou .7z e o trabalho não encontra a cena."

Pode fazer upload de ficheiros .zip, .rar ou .7z, mas a farm não os descompacta, por isso nada dentro de um ficheiro compactado é renderizado (o carregador do website avisa que o ficheiro não vai ser descompactado automaticamente). O mesmo se aplica a .tar e .tar.gz. Descompactar a pasta da sua cena e fazer upload dos ficheiros descompactados. Se estiver a trabalhar a partir de uma entrega ZIP de um colega, descompactá-la localmente primeiro e depois fazer upload da pasta resultante.

"Textura em falta: D:\projetos\..."

A cena referencia um caminho absoluto na máquina local que não existe nos nós worker da farm. Esta é a causa mais comum de trabalhos falhados, e aparece quer o upload seja feito via Interface Web ou Client App. Corrigir localmente usando caminhos relativos (a maioria dos DCCs tem um comando "tornar caminhos relativos" ou "consolidar recursos" — Ficheiro → Editor de Referências → Tornar Relativo no Maya, Ficheiro → Arquivar no 3ds Max, Ficheiro → Empacotar Dados Externos no Blender). O Client App pré-verifica caminhos absolutos e assinala-os antes do upload iniciar, o que poupa uma viagem de ida e volta.

"Upload expirou."

Comum em ligações residenciais, especialmente por Wi-Fi com ficheiros acima de 1 GB. O caminho do browser não retoma — mudar para o Client App, que recupera de quedas de ligação transitórias. Verificar também a velocidade de upload local (a maioria dos ISP limita o upload residencial a 10–50 Mbps); um projeto de 20 GB numa linha de 10 Mbps demora cerca de cinco horas de transferência contínua.

"Estrutura de projeto inválida."

A pasta carregada não contém um ficheiro de cena que a render farm reconhece (.max, .ma/.mb, .c4d, .blend, .hip/.hiplc, .aep). Causa comum: arrastar apenas a pasta de texturas em vez da raiz completa do projeto. Re-carregar a partir de um nível acima para que o ficheiro de cena esteja incluído.

"Os caminhos dos recursos apontam fora da pasta do projeto."

A cena referencia recursos que estão acima da raiz do projeto (por exemplo, uma pasta \Biblioteca do Estúdio\ partilhada um nível acima de \Projeto_X\). Os nós worker só conseguem ver o que está dentro da pasta carregada. Consolidar esses recursos na pasta do projeto localmente antes do upload (a maioria dos DCCs tem um comando "recolher todos os recursos"), ou carregar a pasta principal para que todos os caminhos referenciados resolvam.

Descarregar Saída Renderizada

Existem três caminhos para recuperar fotogramas concluídos: download manual a partir do dashboard, streaming automático via Client App, ou uma obtenção por S3 a partir da pasta SuperRendersOutput/<job ID>/ no seu SRF Space.

Download manual via dashboard. Quando um trabalho completa, o dashboard lista cada fotograma de saída e oferece download por fotograma e do trabalho completo. Para trabalhos de animação, o dashboard comprime a saída (isto é uma conveniência de download — não um formato de submissão) para que toda a sequência possa ser descarregada numa transferência. Para stills ou sequências curtas, o download por fotograma mantém a contagem de ficheiros gerível.

Descarregamento automático via Client App. Com o Client App instalado e uma pasta de saída local configurada, os fotogramas concluídos chegam à estação de trabalho à medida que cada fotograma termina. Não é necessário esperar que o trabalho completo termine — é possível rever o fotograma 1 enquanto os fotogramas 240 a 480 ainda estão a renderizar. Isto é especialmente útil para trabalhos de animação longos em que os ciclos de revisão se sobrepõem com a própria renderização.

Obtenção por S3 com o Cyberduck ou a AWS CLI. Se utiliza o acesso S3 (Cloud Direct Connect), os fotogramas concluídos são escritos na pasta SuperRendersOutput/<job ID>/ dentro do seu SRF Space. Obtenha-os com o mesmo cliente que utiliza para o upload, por exemplo aws s3 sync s3://<Remote Directory>/SuperRendersOutput/<job ID>/ ./frames/. A configuração está descrita acima, no Método 3.

Retenção. Os ficheiros de saída ficam disponíveis para download depois de o trabalho terminar; não existe um período de eliminação automática fixo, e eliminamos o projeto quando o pedir. Para arquivamento a longo prazo, descarregar para o armazenamento do estúdio em vez de depender da render farm como uma camada de backup.

FAQ

Q: Porque é que a Super Renders Farm não descompacta ficheiros ZIP? A: O gestor de renderização precisa de percorrer a pasta do projeto para resolver os caminhos de recursos: os ficheiros de cena referenciam texturas, proxies, caches e plugins por caminhos relativos ou absolutos. A farm não descompacta ficheiros compactados de nenhum formato, por isso faça upload do projeto como uma pasta não comprimida, que é o que o comando "recolher todos os recursos" de cada DCC produz.

Q: Qual é o maior projeto que posso carregar? A: Não há limite superior aplicado. Já foram tratados projetos de animação de centenas de gigabytes com simulações cacheadas. Para projetos grandes, usar o Client App: os uploads pelo browser bloqueiam em transferências longas, e o Client App retoma a partir de onde ficou.

Q: Como faço upload se a minha ligação for pouco fiável? A: Usar o SuperRenders Client App. Retoma após desconexão, por isso uma queda de Wi-Fi não reinicia a transferência do zero. O caminho de upload pelo browser não retoma: se o separador fechar a meio do upload, a transferência é abortada.

Q: Quanto tempo ficam os fotogramas renderizados na render farm? A: Os ficheiros de saída ficam disponíveis para download depois de o trabalho terminar; não existe um período de eliminação automática fixo, e eliminamos o projeto quando o pedir. Para arquivamento, descarregar os trabalhos concluídos para o armazenamento do estúdio em vez de tratar a render farm como backup de longo prazo.

Q: Como obter automaticamente os fotogramas concluídos de volta para a estação de trabalho? A: Usar o SuperRenders Client App com uma pasta de saída configurada. Os fotogramas chegam à estação de trabalho à medida que cada um termina, para que seja possível rever os fotogramas iniciais enquanto os fotogramas posteriores ainda estão a renderizar. O caminho de download manual do dashboard é adequado para trabalhos pontuais, mas para trabalho de animação o descarregamento automático do Client App elimina muita espera.

Q: A cena referencia texturas numa unidade de rede. Essas serão carregadas? A: Apenas se os caminhos da unidade de rede estiverem dentro da pasta do projeto carregada. Os nós worker não conseguem aceder às partilhas de rede do estúdio diretamente. Executar primeiro o comando "recolher todos os recursos" ou "consolidar referências" do DCC localmente — isso copia todos os ficheiros referenciados para a pasta do projeto e reescreve os caminhos para relativos — e depois carregar a pasta consolidada. A maioria dos tickets de trabalhos falhados que vemos rastreia a este passo ser ignorado.

Formatos e limites de tamanho, em detalhe: porque é que a farm precisa do seu projeto descompactado e qual o caminho de upload a usar quando um projeto ultrapassa ~2 GB estão cobertos no guia dedicado: Formatos de upload e limites de tamanho.

Last updated: 29 de setembro de 2026