Configurar o Blender para cloud rendering

O Blender na nossa render farm executa Cycles (CPU e GPU/Optix) — o motor de produção para trabalhos Blender na nossa render farm. O Eevee não está disponível: requer um contexto de visualização ativo e não pode ser executado em nós de renderização headless (consulte a nota sobre Eevee em Notas específicas por motor). Esta página aborda o empacotamento de projetos — que é mais simples no Blender do que na maioria dos DCCs, pela forma como o Blender gere os caminhos de assets — notas por motor, renderização de animações com múltiplas câmaras e resolução de problemas específicos do Blender.

Para informações gerais sobre o Blender na nossa render farm — exemplos de preços, escolha entre GPU e CPU, add-ons suportados — consulte o artigo (o artigo sobre V-Ray inclui contexto do Blender). Para benchmarks específicos de Cycles GPU no 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 workers. Recomendamos as versões LTS do Blender para trabalho de produção, uma vez que o Blender 4.2 LTS recebe correções de erros até 2026 e é o alvo estável para a maioria dos estúdios. A render farm seleciona automaticamente a versão correspondente ao ficheiro .blend.

Uma nota sobre o ritmo de lançamentos do Blender: o Blender lança uma versão principal a cada três ou quatro meses, mais uma versão LTS anualmente. Disponibilizamos novas versões no prazo de duas semanas após a disponibilização pública — o ritmo de lançamentos do Blender é mais rápido do que o dos DCCs proprietários, pelo que a render farm acompanha de perto.

Empacotar o projeto Blender

Um projeto Blender é o ficheiro .blend mais quaisquer assets externos — texturas, ficheiros de áudio, caches de simulação, ficheiros .blend de biblioteca ligada e HDRIs EXR para iluminação de ambiente. A resolução de caminhos do Blender é mais permissiva do que a de outros DCCs (utiliza tanto caminhos absolutos como relativos e pesquisa em várias localizações), mas para cloud rendering é recomendado reunir tudo numa pasta de projeto consistente.

O método de empacotamento mais simples é a funcionalidade integrada "Pack Into .blend" do Blender:

Abrir o projeto. File → External Data → Find Missing Files (para verificar que nada está em falta localmente).
Empacotar os assets no ficheiro .blend. File → External Data → Pack All Into .blend. O Blender incorpora todas as texturas, sons e imagens ligadas no próprio ficheiro .blend.
Guardar o projeto. O ficheiro .blend é agora autossuficiente — tipicamente 10 a 100 vezes maior do que o original, dependendo do número de texturas.
Carregar apenas o ficheiro .blend único (não é necessário arquivo se o .blend tiver menos de alguns GB; para ficheiros maiores, utilize .tar.gz ou .7z para um carregamento mais rápido).

Um segundo método de empacotamento que produz um carregamento mais pequeno é "Make Paths Relative" + estruturação manual de pastas:

File → External Data → Make All Paths Relative. Todos os caminhos de assets ficam relativos à pasta do ficheiro .blend.
Verificar que todos os assets se resolvem com File → External Data → Report Missing Files. O relatório não deve indicar ficheiros em falta.
Colocar todos os assets referenciados em subpastas relativas ao .blend. Estrutura padrão: project/scene.blend mais project/textures/, project/cache/, project/hdr/, etc.
Arquivar toda a pasta como .tar.gz ou .7z e carregar.

O método de caminhos relativos é preferível para bibliotecas de texturas muito grandes (nas quais Pack Into .blend geraria um ficheiro único excessivamente grande) e para projetos que reutilizam a mesma biblioteca de texturas em várias cenas.

O que verificar antes da submissão

Uma lista de verificação rápida antes do envio:

O motor de renderização ativo está definido como Cycles. Properties → Render Properties → Render Engine determina se o worker utiliza Cycles ou Workbench. Definir como Cycles para renderização de produção — o Eevee não é suportado na render farm (consulte Notas específicas por motor). Confirmar que corresponde à intenção do projeto.
O intervalo de frames está definido. Properties → Output Properties → Frame Start / Frame End. A render farm respeita exatamente este intervalo.
O caminho de saída utiliza tokens relativos. O padrão //tmp/####.png é adequado; o prefixo // significa "relativo ao ficheiro .blend." Evitar caminhos absolutos de saída como D:\renders\.
O formato de saída corresponde ao pipeline seguinte. Sequência PNG com transparência para composição, OpenEXR Multilayer para saída completa de passes, vídeo FFmpeg para entrega direta. Para renderização de animações, as sequências de imagens são fortemente preferíveis à saída de vídeo direta.
A gestão de cor está definida. Properties → Render Properties → Color Management. O padrão Filmic + sRGB é adequado para a maioria dos projetos. Se o projeto utilizar ACES ou uma configuração OCIO personalizada, incluir os ficheiros de configuração OCIO na pasta do projeto e verificar que o caminho se resolve no worker.
A câmara ativa está definida. A câmara ativa da cena (Properties → Scene Properties → Camera) determina qual a câmara que renderiza. Confirmar que corresponde ao resultado esperado.

Notas específicas por motor

Cycles (CPU)

O Cycles CPU é executado no nosso nível de workers Dual Intel Xeon E5-2699 V4 (até 256 GB de RAM por nó). É a escolha para cenas que excedem a VRAM da GPU, cenas com bibliotecas de texturas muito grandes ou projetos que necessitam da saída bit-a-bit exata que o Cycles CPU produz.

Notas de configuração:

Licença: O Blender é gratuito e de código aberto; não há preocupações com licenciamento na render farm.
Amostragem: Cycles Render Properties → Sampling → Render Samples. A Amostragem Adaptativa com um Limiar de Ruído de 0,01 produz resultados limpos para animação; limiares mais baixos (0,005; 0,002) para maior qualidade ao custo de tempo de renderização.
Eliminação de ruído: O Cycles suporta OpenImageDenoise (OIDN) e Optix (apenas GPU). O OIDN é executado em CPU e produz bons resultados para imagens estáticas e animação; configurar em Render Properties → Sampling → Denoise.
Árvore de luzes: O Blender 3.4+ inclui amostragem de árvore de luzes para cenas com muitas fontes de luz. Ativar em Render Properties → Sampling para cenas com centenas de fontes de luz.

Cycles (GPU / Optix)

O Cycles GPU é executado no nosso nível de workers NVIDIA RTX 5090 (32 GB de VRAM por placa). É significativamente mais rápido do que o Cycles CPU para a maioria das cenas (tipicamente 5–15× de aceleração), especialmente para projetos com ray tracing intenso.

Notas de configuração:

Dispositivo: Properties → Render Properties → Device → GPU Compute. O backend Optix (que utiliza núcleos RT nas GPUs NVIDIA) está ativado por padrão nos nossos workers.
Limitações de VRAM: 32 GB de VRAM por worker são suficientes para a maioria dos projetos de archviz e animação. Para projetos que se aproximam do limite de VRAM, a opção "Persistent Data" em Render Properties → Performance reduz os tempos de carregamento por frame, mas aumenta o pico de utilização de VRAM. Para projetos que excedam 32 GB, mudar para Cycles CPU ou dividir a cena em partes renderizáveis.
Denoiser Optix: Mais rápido do que o OIDN para animação. Configurar em Render Properties → Sampling → Denoise → Use OptiX. Requer GPU NVIDIA (disponível no nosso nível de workers).

Eevee (não suportado)

O Eevee não está disponível na render farm. O Eevee requer um contexto de visualização ativo (uma sessão interativa OpenGL/GPU) e não pode ser executado no modo de servidor headless em que os nossos nós de renderização operam, pelo que a renderização com Eevee não é suportada. Um projeto cujo motor ativo esteja definido como Eevee não será renderizado — alterar o Render Engine para Cycles antes de submeter.

Se necessitar do aspeto rápido e derivado de tempo real do Eevee, renderize localmente. Para cloud rendering, o Cycles GPU na nossa frota RTX 5090 (com o denoiser Optix) oferece iteração rápida com saída fisicamente precisa; é o motor de produção suportado para Blender na render farm.

Cycles CPU vs Cycles GPU — qual escolher

O Cycles GPU no nível RTX 5090 é o padrão: é tipicamente 5–15× mais rápido por frame do que o Cycles CPU e suporta a maioria das cenas de archviz, animação e ray tracing intenso dentro dos seus 32 GB de VRAM. Escolher Cycles CPU quando uma cena excede 32 GB de VRAM, depende de bibliotecas de texturas muito grandes ou necessita da saída bit-a-bit exata do caminho CPU (até 256 GB de RAM por nó). Ambos produzem o mesmo resultado Cycles fisicamente preciso — a GPU termina mais rápido por frame, a CPU tem o teto de memória mais elevado.

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

Para projetos que necessitem de renderizar a mesma cena a partir de múltiplos ângulos de câmara numa única submissão, o Blender suporta dois padrões:

Padrão 1: Múltiplas cenas com câmaras ativas diferentes

O Blender permite múltiplas cenas por ficheiro .blend. Cada cena pode ter a sua própria câmara ativa e definições de renderização:

No projeto, criar uma nova cena por ângulo de câmara (Scene → New Scene → Link Objects).
Definir a câmara ativa de cada cena para a câmara correspondente.
Ao submeter, a render farm renderiza a cena definida como "Active" no momento da submissão. Para renderizar várias cenas, submeter cada uma como um trabalho separado.

Padrão 2: View Layer por câmara (Blender 2.8+)

Um padrão mais eficiente para muitos ângulos de câmara é utilizar View Layers com câmaras ativas diferentes:

Em Properties → View Layer, criar um View Layer por ângulo de câmara.
Em Properties → Output Properties → Output → Use Multi-View, configurar estéreo ou multi-view se aplicável.
Configurar os caminhos de saída por View Layer utilizando o token {layer} no nome do ficheiro de saída.
Submeter; o worker renderiza todos os View Layers ativados numa única passagem.

Para turntables típicos de archviz (8–16 ângulos de câmara), o Padrão 2 é significativamente mais eficiente porque a cena é carregada uma vez por frame e renderiza todas as vistas a partir da mesma cena carregada.

Fluxo de submissão

Existem três canais de submissão para projetos Blender:

Carregamento web + submissão via dashboard. Carregar o .blend empacotado (ou a pasta de projeto arquivada) e submeter através do website. Este é o caminho de submissão mais comum para utilizadores de Blender.
Client App. Carregamento + submissão + transferência automática numa única aplicação.
Plugin de submissão. Está disponível um add-on para Blender que permite submeter com um clique a partir do interior do Blender; instalar a partir do dashboard da conta.

Para o fluxo transversal de carregamento-submissão-transferência, consulte o .

Resolução de problemas específicos do Blender

Para resolução de problemas gerais aplicáveis a todos os DCCs, consulte . Casos específicos do Blender:

Alguns objetos da cena não são renderizados. Causa mais comum: o botão "Render Visibility" do objeto está desativado. No outliner, passar o rato sobre a linha do objeto e verificar que o ícone de câmara (Disable in Renders) está ativado. Verificar também que o objeto não está num View Layer oculto.
Texturas em falta apesar de Pack Into .blend. Verificar que Pack All Into .blend foi executado após as últimas alterações às texturas. Se as texturas foram recarregadas após o empacotamento, podem ter revertido para referências externas. Empacotar e guardar novamente.
A renderização devolve preto ou cor incorreta. Verificar as definições de Color Management (Properties → Render Properties → Color Management). A causa mais comum é uma incompatibilidade de View Transform — garantir que tanto o posto de trabalho como o worker utilizam o mesmo View Transform (Filmic é o padrão e a escolha mais segura).
O trabalho Cycles GPU é executado em CPU. Verificar que Properties → Render Properties → Device está definido como GPU Compute, não CPU. Verificar também que o backend Optix está selecionado se a cena requerer aceleração de ray tracing por hardware.
O shader OSL personalizado falha na renderização. O Cycles suporta OSL (Open Shading Language), mas os shaders OSL personalizados precisam de ser incluídos no arquivo do projeto. Os ficheiros de shader OSL (.osl) devem estar numa localização que o worker consiga encontrar — a mais simples é colocá-los na mesma pasta do .blend e referenciá-los por caminho relativo.
Add-on em falta no worker. Add-ons comuns (Animation Nodes, BlenderKit, Sverchok, FLIP Fluids, etc.) podem não estar pré-instalados. Para Animation Nodes e add-ons procedurais semelhantes, a solução alternativa é transformar a geometria procedural em malhas antes da submissão. Para outros add-ons, contactar o suporte para discutir a adição à imagem do worker.

Referências cruzadas

— fluxo de carregamento, submissão e transferência
— como são calculados os custos dos trabalhos Blender
— guia SFTP, formatos de arquivo
— resolução de problemas transversal a todos os DCCs
— instalar o add-on para Blender
— artigo de benchmarks

FAQ

Q: Quais as versões do Blender suportadas pela render farm? A: O Blender 4.0, 4.1, 4.2 LTS, 4.3 e 4.4 estão pré-instalados em todos os workers. Acompanhamos o ritmo de lançamentos do Blender e disponibilizamos novas versões no prazo de duas semanas após a disponibilização pública. O Blender 4.2 LTS é a escolha recomendada para trabalho de produção por receber correções de erros até 2026. Q: Posso renderizar cenas Eevee na render farm? A: Não — o Eevee requer um contexto de visualização ativo e não pode ser executado nos nós de renderização headless que a render farm utiliza, pelo que a renderização com Eevee não é suportada. Definir o Render Engine como Cycles antes de submeter. Para iteração rápida, o Cycles GPU na nossa frota RTX 5090 (com o denoiser Optix) é tipicamente 5–15× mais rápido do que o Cycles CPU para a mesma cena, pelo que a GPU é a recomendação padrão, salvo se a cena exceder 32 GB de VRAM. Q: A minha cena utiliza BlenderKit / Sverchok / Animation Nodes — será renderizada? A: Os assets do BlenderKit que já foram transferidos e guardados no .blend serão renderizados sem problemas (tornam-se dados de malha padrão após serem colocados). O Sverchok e o Animation Nodes são procedurais — se a geometria procedural não tiver sido transformada numa malha estática, o worker pode produzir resultados inesperados. Transformar a geometria procedural em malhas (Sverchok: Set/Bake to Mesh; Animation Nodes: bake to action) antes da submissão. Q: É necessário empacotar as texturas no .blend, ou posso carregá-las como ficheiros separados? A: Ambas as opções funcionam. Pack Into .blend é a mais simples porque o resultado é um único ficheiro autossuficiente. Caminhos relativos + estrutura de pastas é preferível para bibliotecas de texturas muito grandes, nas quais Pack Into .blend geraria um ficheiro único excessivamente grande. Executar "Find Missing Files" antes de qualquer uma das abordagens para confirmar que nada está em falta localmente. Q: A renderização termina mas as cores parecem diferentes do viewport do posto de trabalho. A: Na maioria das vezes, trata-se de uma incompatibilidade de Color Management ou View Transform. Verificar Properties → Render Properties → Color Management no posto de trabalho e confirmar que as definições guardadas incluem View Transform: Filmic (o padrão). As transformações Look (high contrast, low contrast, etc.) e os valores de Exposure também estão incorporados no .blend e aplicam-se no worker. Q: Estou a renderizar uma animação. Devo guardar para ficheiro de vídeo ou sequência de imagens? A: Sequência de imagens, quase sempre. PNG com transparência (para composição) ou OpenEXR Multilayer (para passes completos) é o padrão. A saída de vídeo direta (FFmpeg) não paraleliza bem na render farm — o worker que recebe o trabalho renderiza todos os frames sequencialmente e codifica um único ficheiro de vídeo. As sequências de imagens permitem que a render farm distribua frames por múltiplos workers em paralelo, o que é significativamente mais rápido para qualquer animação com mais de ~100 frames. Q: O projeto utiliza shaders OSL personalizados. Funcionarão na render farm? A: Sim, se os ficheiros de shader .osl estiverem incluídos no arquivo do projeto e referenciados via caminhos relativos nos nós de shader. O padrão mais simples é colocar todos os ficheiros .osl na mesma pasta do ficheiro .blend. Q: Como se compara o custo de renderização GPU vs CPU na render farm? A: A renderização GPU é tipicamente mais rápida por frame (5–15× para Cycles), mas o custo por worker é mais elevado porque as máquinas GPU são mais caras. O custo total de uma renderização é aproximadamente comparável entre Cycles CPU e Cycles GPU para a maioria das cenas — a GPU termina mais rápido mas custa mais por minuto. Para estimativas de custo específicas com base na cena, a fornece uma comparação por frame e por trabalho. Q: Posso renderizar simulações Blender (fluidos, fumo, cabelo) na render farm? A: Para simulações, os ficheiros de cache precisam de ser processados localmente primeiro e depois incluídos no carregamento do projeto. A render farm renderiza frames contra o cache processado; não executa simulação em tempo real. Este é o padrão em todos os DCCs — o processamento de simulações é trabalho do posto de trabalho, a renderização de frames é trabalho da render farm.