Configurar o Blender para cloud rendering

O Blender na nossa render farm executa Cycles (CPU e GPU com Optix) e Eevee Next — os dois motores de renderização de produção fornecidos com o Blender 4.x. Comparado com os DCCs proprietários, o Blender é incomum de uma forma útil: um ficheiro .blend pode ser tornado completamente autossuficiente a partir da aplicação, pelo que o empacotamento para uma render farm é frequentemente uma única ação de menu em vez de uma procura manual de ativos. Esta página percorre esse fluxo do início ao fim: empacotamento, verificação pré-envio, notas por motor para Cycles CPU / Cycles GPU / Eevee Next, renderização de animação multi-câmara, os três canais de envio e resolução de problemas específicos do Blender. As falhas transversais a DCCs estão documentadas em .

Para exemplos de preços e a escolha GPU vs CPU na nossa render farm, consulte . Para benchmarks Cycles GPU na frota RTX 5090, consulte .

Versões suportadas

O Blender 4.0, 4.1, 4.2 LTS, 4.3 e 4.4 estão pré-instalados em todos os nós de trabalho. A render farm corresponde automaticamente à versão guardada do ficheiro .blend — não há seletor de versão para gerir; o nó de trabalho lê o cabeçalho do ficheiro e inicia o binário correspondente.

O Blender lança uma versão principal a cada três a quatro meses mais uma versão LTS anualmente. As novas versões são disponibilizadas no prazo de cerca de duas semanas após a disponibilidade pública. Recomendamos o Blender 4.2 LTS para trabalho de produção uma vez que recebe correções de bugs até 2026 e é o alvo estável para a maioria dos estúdios.

Os ficheiros guardados no Blender 3.x abrirão nos nós de trabalho 4.x, mas dois casos requerem atenção: as renderizações Eevee Legacy podem não corresponder à saída Eevee Next (consulte a secção Eevee Next), e ficheiros muito antigos 2.7x / 2.8x devem ser abertos localmente, guardados novamente em 4.x e retestados antes do envio. Se for necessário renderizar um projeto antigo, guarde primeiro uma cópia com versão fixada; a render farm não pode retroceder um guardado 4.x.

Empacotar o projeto Blender

Um projeto Blender é o ficheiro .blend mais quaisquer ativos externos — texturas, ficheiros de som, caches de simulação, ficheiros .blend de biblioteca ligada, perfis de luz IES, ficheiros de configuração OCIO, HDRIs EXR e quaisquer ficheiros de shader .osl. A resolução de caminhos do Blender é mais permissiva do que a de outros DCCs, mas para cloud rendering essa permissividade tem consequências: um caminho que resolve na estação de trabalho através da lógica de fallback do Blender pode não resolver da mesma forma num nó de trabalho, e o resultado são marcadores cor-de-rosa de textura em falta.

São suportados três padrões de empacotamento. Escolha o que corresponde ao tamanho do projeto e à frequência com que reutiliza ativos entre cenas.

Padrão 1 — Pack Resources (recomendado para a maioria dos projetos)

O "Pack Resources" integrado do Blender incorpora todos os dados externos no próprio .blend, produzindo um único ficheiro autossuficiente.

1. Ficheiro → Dados Externos → Encontrar Ficheiros em Falta. Percorre o projeto e reporta referências não resolvidas; corrija localmente qualquer problema primeiro.
2. Ficheiro → Dados Externos → Pack Resources. O Blender incorpora todas as texturas, sons, perfis IES e imagens ligadas no .blend.
3. Guarde o projeto. O .blend empacotado é agora autossuficiente — espere que cresça 10×–100× dependendo da contagem e resolução de texturas.
4. Faça upload do único .blend. Não é necessário arquivo salvo se o ficheiro for suficientemente grande para que a compressão (.tar.gz ou .7z) acelere o upload — tipicamente acima de alguns GB.

Padrão 2 — Tornar Caminhos Relativos + estrutura de pastas (para grandes bibliotecas de texturas)

Para projetos onde o Pack Resources produziria um único ficheiro impraticável, o padrão de caminhos relativos mantém o .blend pequeno e envia os ativos como pastas ao lado.

1. Ficheiro → Dados Externos → Tornar Todos os Caminhos Relativos. Todos os caminhos de ativos ficam relativos ao diretório do .blend (prefixo de caminho //).
2. Ficheiro → Dados Externos → Reportar Ficheiros em Falta. Não deve mostrar nenhum. Corrija qualquer problema reportado antes de continuar.
3. Coloque todos os ativos referenciados em subpastas relativas ao .blend. Estrutura padrão: projeto/cena.blend mais projeto/textures/, projeto/cache/, projeto/hdr/, projeto/osl/, projeto/lib/. Evite espaços nos nomes de pastas.
4. Archive toda a pasta do projeto como .tar.gz ou .7z e faça upload do arquivo.

Padrão 3 — Bibliotecas ligadas (avançado; estúdios com bibliotecas de ativos partilhadas)

O Blender suporta ligação de bibliotecas, onde um ficheiro .blend referencia objetos, materiais ou cenas de outro .blend. Isto é comum em estúdios com bibliotecas de ativos partilhadas (adereços, personagens, materiais):

1. Torne os caminhos relativos primeiro (Padrão 2 passo 1).
2. Verifique que cada ligação de biblioteca resolve localmente via Ficheiro → Dados Externos → Encontrar Ficheiros em Falta.
3. Inclua cada ficheiro .blend de biblioteca ligada no arquivo. Uma referência como //../partilhado/aderecos/cadeira.blend só resolve se o ficheiro existir nesse caminho no nó de trabalho. Teste localmente movendo toda a pasta do projeto para uma nova localização e abrindo a cena principal — se abrir de forma limpa, os mesmos caminhos resolverão no nó de trabalho.
4. Considere tornar as bibliotecas locais para trabalhos de longa duração. Ficheiro → Dados Externos → Criar Substituição de Biblioteca converte referências em cópias editáveis dentro do .blend, trocando tamanho de ficheiro por autossuficiência.

O que verificar antes do envio

Uma breve lista de verificação pré-envio aplica-se antes de qualquer envio:

• O motor de renderização ativo está definido. Propriedades → Propriedades de Renderização → Motor de Renderização — Cycles, Eevee Next ou Workbench. O nó de trabalho respeita o que guardar.
• O intervalo de fotogramas está definido. Propriedades → Propriedades de Saída → Fotograma Inicial / Fotograma Final. A render farm respeita este intervalo exatamente.
• O caminho de saída usa tokens relativos. O padrão //tmp/####.png está correto; o prefixo // significa "relativo ao ficheiro .blend." Evite caminhos absolutos como D:\renders\ — estes não podem resolver nos nós de trabalho Linux.
• O formato de saída corresponde ao pipeline a jusante. Sequência PNG com alfa para composição, OpenEXR Multilayer para saída de pass completo. Para animação, as sequências de imagens são fortemente preferidas à saída direta de vídeo (consulte as FAQ Multi-câmara).
• A gestão de cor está definida. Propriedades → Propriedades de Renderização → Gestão de Cor. O Filmic + sRGB predefinido funciona para a maioria dos projetos. Para ACES ou uma configuração OCIO personalizada, inclua os ficheiros de configuração OCIO na pasta do projeto.
• A câmara ativa está definida. A câmara ativa da cena (Propriedades → Propriedades de Cena → Câmara) determina qual a câmara que renderiza. "Câmara errada renderizada" está entre os tickets de suporte Blender mais comuns e é um dos mais simples de prevenir.
• Os caches de simulação estão cozidos. As simulações de fluido, fumo, tecido, cabelo e corpo mole precisam de ser cozidas localmente primeiro; a render farm renderiza contra o cache cozido e não executa simulação em direto. Inclua a pasta de cache no upload.
• Os light probes estão cozidos. Os probes Eevee Next — Irradiance Volume, Reflection Plane, Reflection Cube — precisam de ser cozidos localmente e os dados cozidos guardados com o .blend (Propriedades de Renderização → Light Probes → Cozinhar Iluminação Indireta). Os probes não cozidos produzem iluminação indireta plana ou ausente.

Notas específicas por motor

Cycles (CPU)

O Cycles CPU corre na nossa camada de nós Dual Intel Xeon E5-2699 V4 (até 256 GB de RAM por nó). É a escolha para cenas que excedem a VRAM GPU, projetos com grandes bibliotecas de texturas, ou cenas que usam funcionalidades ainda não suportadas no backend GPU.

• Licença: O Blender é gratuito e de código aberto; nada para autorizar, sem licença a consumir.
• Amostragem: Propriedades de Renderização → Amostragem → Amostras de Renderização. A Amostragem Adaptativa com Limiar de Ruído 0.01 é uma boa predefinição para animação; limiares mais baixos (0.005, 0.002) para maior qualidade ao custo de tempo de renderização. O Limite de Tempo (por fotograma) é uma proteção útil para trabalho de animação.
• Denoising: O Cycles suporta OpenImageDenoise (OIDN) e Optix (apenas GPU). O OIDN corre em CPU e produz bons resultados para fotogramas fixos e animação; configure nas Propriedades de Renderização → Amostragem → Denoise. Para animação, ative o denoising temporal (OIDN 2.x no Blender 4.2+) para reduzir a cintilação de fotograma para fotograma.
• Light tree: O Blender 3.4+ inclui amostragem light tree para cenas com muitas luzes. Ative nas Propriedades de Renderização → Amostragem → Light Tree para interiores de archviz ou iluminação de palco com centenas de fontes de luz.

Cycles (GPU / Optix)

O Cycles GPU corre na nossa camada de nós NVIDIA RTX 5090 (32 GB de VRAM por cartão). É tipicamente 5–15× mais rápido por fotograma do que o Cycles CPU para archviz e animação, e mais para planos VFX com percurso de traçado intensivo em volumétrico e SSS.

• Dispositivo: Propriedades → Propriedades de Renderização → Dispositivo → GPU Compute. O backend Optix (RT cores em GPUs NVIDIA) está ativo por predefinição nos nossos nós de trabalho.
• VRAM: 32 GB por nó de trabalho é suficiente para a maioria dos projetos de archviz, motion design e animação com várias texturas de 4K. Para projetos a aproximar-se do limite, "Dados Persistentes" nas Propriedades de Renderização → Desempenho reduz o tempo de carregamento por fotograma ao custo de um pico de VRAM ligeiramente mais alto. Para projetos que excedem 32 GB, mude para Cycles CPU na camada Xeon ou divida a cena.
• Denoiser Optix: Mais rápido do que OIDN para animação e a escolha padrão na GPU. Configure nas Propriedades de Renderização → Amostragem → Denoise → Usar OptiX. Para fotogramas fixos estáticos, o OIDN produz frequentemente uma saída ligeiramente mais limpa; para animação, o modo temporal do Optix é geralmente a melhor troca.
• Paridade de funcionalidades: Hair, volumes, SSS, OSL (4.0+, com requisitos de hardware), Subdivisão Adaptativa — tudo suportado no Cycles GPU em 4.x. A lacuna de funcionalidades CPU/GPU está essencialmente fechada.

Eevee Next

O Eevee Next corre na nossa camada de nós GPU. É a escolha para motion design, renders estilizados, iteração rápida e previz onde o orçamento por fotograma importa mais do que a fidelidade absoluta.

• Amostragem e reflexos: As Propriedades de Renderização → Amostragem controlam a contagem de amostras por pixel. Para finais, 64–128 amostras produz tipicamente uma saída limpa. Os light probes, reflexos de espaço de ecrã e refrações de espaço de ecrã têm de ser cozidos ou configurados por plano.
• Eevee Next vs Eevee Legacy: O Blender 4.2+ inclui o Eevee Next como a nova arquitetura (nome interno BLENDER_EEVEE_NEXT vs o legado BLENDER_EEVEE). Os projetos 3.x mais antigos que usam Eevee Legacy podem necessitar de ajuste quando migrados; teste um único fotograma localmente antes de enviar uma animação.
• Volumétrico: O pipeline volumétrico do Eevee Next difere significativamente da versão legada. Os volumes que renderizavam corretamente no Eevee Legacy podem mostrar diferenças de densidade ou dispersão. Verifique localmente antes de enviar.
• Cozimento de light probes: Crítico e a fonte do ticket de suporte Eevee mais comum. Propriedades de Renderização → Light Probes → Cozinhar Iluminação Indireta. Cozinhe localmente, guarde, e os dados de cozimento viajam com o ficheiro. Os probes não cozidos produzem iluminação indireta plana ou ausente.

Workbench

O Workbench é o motor de renderização de viewport do Blender, útil para fotogramas de pré-visualização técnica (passes de ID de matte, turntables de argila, pré-visualização AO). Corre em nós de trabalho CPU ou GPU; envie da mesma forma que Cycles ou Eevee, com Motor de Renderização definido para Workbench antes de guardar.

Comparação rápida Cycles GPU vs Eevee Next

| Aspeto | Cycles GPU | Eevee Next | |---|---|---| | Velocidade de renderização (cena típica) | Mais lento por fotograma, fisicamente preciso | Mais rápido por fotograma, derivado de tempo real | | Fotorrealismo | Maior | Menor (mas a melhorar a cada versão) | | Cintilação na animação | Baixa (com modo temporal do denoiser Optix) | Pode ser maior; precisa de cozimento de probes | | Limitação de VRAM | Limite rígido de 32 GB; fallback para CPU | 32 GB mas tipicamente menor utilização | | Qualidade volumétrica | Traçado de percurso, preciso | Aproximado; verifique localmente antes de enviar | | Melhor para | Archviz, VFX, animação fotorrealista | Motion design, estilizado, iteração rápida |

Renderização de múltiplos ângulos de câmara

Para projetos que necessitem de renderizar a mesma cena de múltiplos ângulos de câmara num único envio, o Blender suporta vários padrões. Escolha com base em como os ângulos se relacionam entre si.

Padrão A — Múltiplas cenas com diferentes câmaras ativas

O Blender permite múltiplas cenas por .blend, cada uma com a sua câmara ativa e definições de renderização:

1. Crie uma nova cena por ângulo de câmara (Cena → Nova Cena → Ligar Objetos partilha dados para que as edições se propaguem).
2. Defina a câmara ativa de cada cena.
3. No envio, a render farm renderiza a cena marcada como Ativa no momento do registo. Para renderizar múltiplas cenas, envie cada uma como um trabalho separado.

O Padrão A é a escolha certa quando os ângulos necessitam de amostragem, formatos de saída ou resoluções diferentes.

Padrão B — Camada de Vista por câmara (Blender 2.8+)

Para muitos ângulos de câmara que partilham definições de renderização, use Camadas de Vista cada uma com uma câmara ativa diferente:

1. Nas Propriedades → Camada de Vista, crie uma Camada de Vista por ângulo de câmara.
2. Vincule a câmara de cada Camada de Vista através de uma propriedade Câmara na camada (ou conduza a câmara ativa no Compositor).
3. Configure caminhos de saída por Camada de Vista usando o token {layer} no nome de ficheiro de saída.
4. Envie; o nó de trabalho renderiza todas as Camadas de Vista ativas numa única passagem.

Para turntables de archviz típicos (8–16 ângulos de câmara), o Padrão B é mais eficiente porque a cena carrega uma vez e todas as vistas renderizam a partir do mesmo estado carregado. Um único trabalho multi-câmara que produz N sequências de saída custa menos do que N trabalhos de câmara única.

Padrão C — Saída múltipla do Compositor (avançado)

Para pós-processamento complexo por câmara, o Compositor pode encaminhar a renderização de cada câmara para um nó File Output diferente. Mesmo padrão que as exportações AOV multi-camada. Use o Padrão B salvo se tiver uma razão real de pós-processamento para recorrer ao Compositor.

Fluxo de envio

Três canais de envio funcionam para projetos Blender. Escolher o que melhor corresponde ao fluxo de trabalho do projeto.

• Upload web + envio pelo painel. Faça upload do .blend empacotado (ou pasta do projeto arquivada) para a conta e depois envie através do painel. O painel lê o cabeçalho do .blend para detetar a versão Blender, motor de renderização, intervalo de fotogramas e câmara ativa, e pré-preenche o formulário de envio. Confirme ou substitua, envie, monitorize.
• Client App. A Client App (Windows / macOS) envolve upload + envio + auto-download. Após a instalação, arraste o .blend ou arquivo para a aplicação, confirme o formulário de envio, e a aplicação trata do upload, monitorização de progresso e download de fotogramas à medida que ficam prontos.
• Plugin de envio (add-on Blender). Um add-on Blender para envio na aplicação está disponível; instale a partir do painel da conta. O plugin lê as definições de renderização da cena atual, solicita substituições (intervalo de fotogramas, caminho de saída, resolução) e envia sem sair do Blender.

Para o fluxo upload-envio-download transversal a DCCs, consulte o . Para os passos de instalação do plugin, consulte .

Resolução de falhas específicas do Blender

Para resolução de problemas gerais que se aplica a todos os DCCs (ativo em falta, incompatibilidade de intervalo de fotogramas, erros de caminho de saída), consulte . Os casos abaixo são específicos do Blender.

• Alguns objetos da cena não estão a renderizar. Causa mais comum: a "Visibilidade de Renderização" do objeto (ícone de câmara no outliner) está desativada. Verifique também que o objeto não está numa Camada de Vista oculta, e verifique os flags de Propriedades do Objeto → Visibilidade → Visibilidade de Ray (câmara, difuso, brilhante, transmissão, volume, sombra).
• Texturas em falta apesar do Pack Resources. Verifique que o Pack Resources foi executado após as últimas alterações de textura. Se recarregou texturas após o empacotamento, podem ter revertido para referências externas. Reempacote e volte a guardar.
• A renderização devolve preto ou cor errada. Geralmente uma incompatibilidade de View Transform. Confirme que Propriedades → Propriedades de Renderização → Gestão de Cor usa View Transform: Filmic (o padrão) tanto na estação de trabalho como no ficheiro guardado. Os Look Transforms e os valores de Exposição estão incorporados no .blend e aplicam-se no nó de trabalho.
• Os light probes Eevee Next não cozem no nó de trabalho. O nó de trabalho não coze; os probes têm de ser cozidos localmente e guardados com o .blend. Propriedades de Renderização → Light Probes → Cozinhar Iluminação Indireta, guarde, faça upload.
• O trabalho Cycles GPU corre em CPU. Verifique que Propriedades → Propriedades de Renderização → Dispositivo está definido para GPU Compute. Se o ficheiro foi criado numa estação de trabalho sem GPU NVIDIA, o valor de Dispositivo guardado pode ter ficado como CPU por predefinição.
• O shader OSL personalizado falha na renderização. O Cycles suporta OSL, mas os ficheiros .osl têm de estar incluídos no arquivo e referenciados por caminho relativo. Coloque-os na mesma pasta que o .blend. O OSL na GPU tem requisitos de hardware que podem não corresponder a todos os shaders; se um shader funciona em CPU mas não em GPU, renderize essa cena na camada CPU.
• Referência de biblioteca ligada danificada. Uma biblioteca ligada resolve apenas se o .blend ligado estiver presente no caminho esperado no nó de trabalho. Use o empacotamento Padrão 2 e inclua cada biblioteca ligada no arquivo. Execute Ficheiro → Dados Externos → Encontrar Ficheiros em Falta localmente antes do upload.
• Add-on em falta no nó de trabalho. Os add-ons comuns (Animation Nodes, BlenderKit, Sverchok, FLIP Fluids) podem não estar todos pré-instalados. Para add-ons procedurais, cozinhe a geometria para malhas estáticas antes do envio (Sverchok: Set/Bake to Mesh; Animation Nodes: cozinhar para action; Geometry Nodes: Aplicar modificador). Para outros add-ons, contacte o suporte sobre adicioná-los à imagem do nó de trabalho.
• Cintilação na animação (Cycles). Geralmente variação de ruído de fotograma para fotograma. Aumente as amostras, baixe o Limiar de Ruído de Amostragem Adaptativa, ative o denoising temporal (OIDN 2.x ou Optix). Confirme que o modo de semente aleatória (Propriedades de Renderização → Amostragem → Avançado → Semente) corresponde à intenção do projeto — Animada para variação natural, fixada para saída bit-estável.
• Cintilação na animação (Eevee Next). Quase sempre light probes não cozidos ou desatualizados. Recozinhe a Iluminação Indireta, guarde, faça upload novamente. Os reflexos de espaço de ecrã que dependem do estado de viewport também podem cintilar — prefira Reflection Probes para reflexos limpos.

Referências cruzadas

• — fluxo upload, envio, download que se aplica a todos os DCCs
• — como são calculados os custos de trabalhos Blender, modelo de preços GHz-hour
• — guia SFTP, formatos de arquivo, transferência de ficheiros grandes
• — resolução de problemas transversal a DCCs (ativo em falta, intervalo de fotogramas, caminho de saída, desvio de gestão de cor)
• — instalação do add-on Blender para envio na aplicação
• — wrapper de secretária para upload + envio + download
• — fluxo de envio pelo painel
• — artigo de benchmark incluindo números Cycles GPU
• — artigo de comparação com secção de contexto Blender

FAQ

Q: Quais as versões do Blender que a render farm suporta? A: O Blender 4.0, 4.1, 4.2 LTS, 4.3 e 4.4 estão pré-instalados em todos os nós de trabalho. Seguimos o ritmo de lançamentos do Blender e disponibilizamos novas versões no prazo de cerca de duas semanas após a disponibilidade pública. O Blender 4.2 LTS é a escolha recomendada para trabalho de produção porque recebe correções de bugs até 2026. A render farm corresponde automaticamente à versão guardada do ficheiro .blend — não é necessário selecionar uma versão no momento do envio.

Q: Devo renderizar com Cycles ou Eevee Next? A: Cycles para archviz fotorrealista, VFX e animação onde o transporte de luz fisicamente preciso é importante. Eevee Next para motion design, trabalho estilizado, iteração rápida e previz onde o custo por fotograma importa mais do que a fidelidade absoluta. O Cycles GPU na nossa frota RTX 5090 é tipicamente 5–15× mais rápido por fotograma do que o Cycles CPU para a mesma cena, pelo que o GPU é a recomendação padrão para Cycles salvo se a cena exceder 32 GB de VRAM ou usar funcionalidades que requerem o backend CPU.

Q: A cena usa ativos BlenderKit / Sverchok / Animation Nodes / Geometry Nodes — vai renderizar? A: Os ativos BlenderKit já descarregados e guardados no .blend renderizam bem — uma vez colocados tornam-se dados de malha padrão. O Sverchok e Animation Nodes são procedurais; se a geometria procedural não tiver sido cozida para uma malha estática, o nó de trabalho pode produzir saída inesperada. Cozinhe a geometria procedural para malhas (Sverchok: Set/Bake to Mesh; Animation Nodes: cozinhar para action; Geometry Nodes: Aplicar modificador na árvore de nós resultante) antes do envio. Os Geometry Nodes que resolvem no momento da renderização sem cozimento geralmente funcionam, mas teste um único fotograma localmente primeiro.

Q: É necessário empacotar texturas no .blend, ou podem ser carregadas como ficheiros separados? A: Qualquer padrão funciona. O Pack Resources é o mais simples porque o resultado é um único ficheiro autossuficiente. Caminhos relativos + estrutura de pastas é preferível para grandes bibliotecas de texturas e projetos que partilham uma biblioteca de texturas entre cenas. Execute Encontrar Ficheiros em Falta antes de qualquer abordagem para confirmar que nada está danificado localmente.

Q: A renderização termina mas as cores parecem diferentes do viewport da estação de trabalho. A: Mais frequentemente isto é uma incompatibilidade de View Transform. Confirme que Propriedades → Propriedades de Renderização → Gestão de Cor usa View Transform: Filmic (o padrão) tanto na estação de trabalho como no ficheiro guardado. Os Look Transforms e os valores de Exposição também estão incorporados no .blend e aplicam-se no nó de trabalho.

Q: Estou a renderizar uma animação. Devo fazer saída para ficheiro de vídeo ou sequência de imagens? A: Sequência de imagens, quase sempre. PNG com alfa (para composição) ou OpenEXR Multilayer (para passes completos) é o padrão. A saída direta de vídeo (FFmpeg) não paraleliza — um nó de trabalho renderiza todos os fotogramas sequencialmente e codifica um único ficheiro. As sequências de imagens permitem que a render farm distribua fotogramas por múltiplos nós em paralelo, o que é mais rápido para qualquer animação acima de cerca de 100 fotogramas.

Q: Como se compara o custo de renderização GPU vs CPU na render farm? A: A GPU é tipicamente mais rápida por fotograma (5–15× para Cycles) mas a taxa por nó de trabalho é mais alta. O custo total é aproximadamente comparável para a maioria das cenas — a GPU termina em menos tempo de relógio mas cobra mais por minuto. A fornece uma comparação por fotograma e por trabalho para a cena específica.

Q: Posso renderizar simulações Blender (fluido, fumo, cabelo, tecido) na render farm? A: Cozinhe o cache de simulação localmente primeiro e depois inclua a pasta de cache no upload do projeto. A render farm renderiza os fotogramas contra o cache cozido; não executa simulação em direto. Cozinhe em disco (Tipo de Cache → Todos os Fotogramas + Guardar Cache em Disco), confirme que a pasta de cache está na pasta do projeto, empacote e faça upload.

---