Configurar o Cinema 4D para cloud rendering

O Cinema 4D na nossa render farm corre em quatro motores — Redshift, V-Ray, Octane e Arnold — cada um com o seu modelo de licença, convenção de saída e perfil de bottleneck. Esta página abrange o fluxo de empacotamento e envio comum a todos eles, depois detalha as especificidades de cada motor, explica o fluxo de trabalho Tiled Camera para imagens fixas muito grandes, percorre o padrão de cache GI para animações de archviz e termina com indicações de envio e resolução de problemas transversais a motores.

Como parceiro oficial Maxon, executamos instalações Cinema 4D licenciadas em toda a frota de nós. Não é necessário partilhar a conta Maxon nem transferir licenças para renderizar connosco. Para o posicionamento de alto nível do C4D na nossa render farm — versões suportadas, adequação de hardware, exemplos de preços — consulte a página de destino . Para Redshift especificamente, a página dedicada é .

Versões suportadas

O Cinema 4D 2024 e 2025 estão pré-instalados em todos os nós de trabalho. R23, R25 e S22–S26 estão disponíveis a pedido para projetos legados, mas não estão ativados por predefinição — contacte o suporte antes de enviar se necessitar de uma versão legada. A render farm corresponde automaticamente à versão do ficheiro .c4d; não é necessário especificá-la.

Uma nota sobre o ritmo de lançamentos do Cinema 4D: a Maxon lança versões anuais mais atualizações de ponto. Disponibilizamos a versão GA mais recente no prazo de quatro semanas após a sua disponibilidade pública. Se um projeto necessitar de uma atualização de ponto específica (por exemplo, 2024.4.0 vs. 2024.5.0) por compatibilidade de plugins, mencione a atualização de ponto nas notas do trabalho — a maioria dos problemas de plugins resolve-se correspondendo à versão exata do ficheiro de projeto.

Empacotar o projeto Cinema 4D

Um projeto Cinema 4D é o ficheiro de cena .c4d mais quaisquer ativos externos — texturas, perfis IES, referências a outros ficheiros C4D, caches de simulação, ficheiros de som, volumes OpenVDB. Tal como com todos os DCCs, a render farm não consegue ler caminhos da unidade local, pelo que o empacotamento é obrigatório antes do upload.

A funcionalidade integrada do Cinema 4D "Guardar Projeto com Ativos" é a ferramenta de empacotamento recomendada. O fluxo de trabalho:

1. Ficheiro → Guardar Projeto com Ativos (ou Guardar Projeto para Cinema 4D Cloud se disponível; ambos produzem a mesma estrutura de pacote).
2. Escolha uma pasta de destino com o nome do projeto — por exemplo, meu-projeto/. O C4D cria a estrutura meu-projeto/meu-projeto.c4d mais uma subpasta tex/ para texturas e subpastas adicionais para perfis IES, ficheiros de som e outros tipos de ativos.
3. Para Team Render ou ativos externos que não são recolhidos automaticamente: arraste esses ativos para a pasta tex/ manualmente e re-ligue-os a partir do C4D antes de guardar.
4. Para cenas XRef e referências externas: abra cada XRef e execute Guardar Projeto com Ativos no projeto principal. O C4D irá puxar a geometria XRef para o pacote. Se mantiver XRefs como ficheiros .c4d separados para edição em direto, pode aplainê-los no projeto principal antes de enviar ou incluir todos os ficheiros .c4d referenciados no upload.
5. Para caches de simulação (Cloth, Dynamics, Particle, Volume caches): cozinhe o cache em disco primeiro, depois verifique que os ficheiros de cache estão dentro da pasta do projeto (tipicamente numa subpasta cache/ que cria) antes de arquivar.
6. Archive a pasta completa como .tar, .tar.gz ou .7z. Não aceitamos arquivos .zip.

Verifique antes de fazer o upload: abra a pasta empacotada na estação de trabalho, clique duas vezes no .c4d dentro e confirme que todas as texturas aparecem no Gestor de Materiais (sem pontos de interrogação a indicar ativos em falta). Se algo estiver em falta, localize manualmente e execute novamente Guardar Projeto com Ativos. Uma segunda verificação de sanidade é renderizar um único fotograma a partir da cópia empacotada na estação de trabalho — se renderizar corretamente aí, o pacote está completo.

Um atalho comum que não funciona: copiar apenas o ficheiro .c4d. As cenas Cinema 4D armazenam apenas referências a bitmaps e ativos externos, nunca os próprios ativos. Sem empacotamento, o nó de trabalho carregará a cena mas falhará na primeira pesquisa de textura em falta.

Plugin de envio

O plugin de envio para Cinema 4D trata da verificação de empacotamento de ativos, verificações de sanidade das definições de renderização e envio de trabalho diretamente a partir do C4D. É compatível com C4D 2024 e 2025. Funcionalidades do plugin:

• Envio com um clique a partir do C4D — recolhe a predefinição de definições de renderização ativas e envia o projeto sem sair do C4D.
• Verificação de caminhos de ativos — assinala texturas, perfis IES ou referências externas em falta antes do envio, para detetar ativos em falta localmente em vez de após o nó de trabalho falhar ao carregar a cena.
• Suporte a intervalo de fotogramas e Takes — respeita o sistema Take, para que diferentes takes possam ser enviados como trabalhos de renderização separados numa única passagem.
• Feedback de estado de envio — mostra o estado do trabalho a partir do C4D após o envio.

Para os passos de instalação do plugin por DCC e resolução de problemas de plugins, consulte .

Notas específicas por motor

Redshift para Cinema 4D

O Redshift é o motor GPU mais utilizado na nossa frota C4D, particularmente para interiores de archviz, motion design e visualização de produto. Corre na nossa camada de nós NVIDIA RTX 5090 (32 GB de VRAM por cartão), que se adequa à pegada de memória de cena típica do Redshift.

Notas de configuração:

• Licença: O Redshift na nossa render farm funciona sob a nossa licença de parceiro Maxon. Não é necessária uma licença Redshift separada para renderizar connosco.
• Memória out-of-core: O Redshift suporta streaming de texturas e geometria out-of-core, o que alarga a capacidade efetiva de cena para além dos 32 GB de VRAM por cartão. Ative nas Definições de Renderização → Redshift → Memória. Para a maioria das cenas de archviz (abaixo de 50 GB de ativos totais), o out-of-core trata o overflow sem abrandamento visível.
• AOVs e elementos de renderização: O sistema AOV do Redshift escreve juntamente com o pass beauty principal. A saída .exr multicanal predefinida funciona na render farm. Se necessitar de ficheiros separados por AOV, mude para a opção de saída "Ficheiros Separados".
• Denoiser: Os denoisers Altus e Optix do Redshift correm ambos na render farm. O Optix é mais rápido por fotograma; o Altus produz um resultado mais limpo para animação. Recomendamos o Optix para pré-visualizações e o Altus para finais.
• Definições de amostragem a verificar: As amostras Min/Max de Unified Sampling devem ser calibradas localmente antes do envio. Uma cena que necessita de 2.000 amostras máximas para limpar ruído localmente necessita do mesmo na render farm — a render farm não aplica denoise de forma mais agressiva do que a configuração local.
• Suporte a cabelo, volume e proxy: Hair e Volumes do Redshift renderizam ambos na render farm. Os Proxies Redshift (ficheiros .rs) são suportados; inclua-os na estrutura de pasta do projeto antes de arquivar.

V-Ray para Cinema 4D

O V-Ray no C4D corre na nossa camada de nós CPU (Dual Intel Xeon E5-2699 V4, até 256 GB de RAM por nó). É a escolha para estúdios que necessitam do look específico do V-Ray — particularmente estúdios de archviz com bibliotecas V-Ray estabelecidas partilhadas de pipelines 3ds Max ou Maya.

Notas de configuração:

• Licença: O V-Ray na nossa render farm funciona sob a nossa licença de parceiro Chaos. Como parceiro oficial Chaos, operamos instalações V-Ray licenciadas.
• Cache GI: Para renderizações de fotogramas fixos de archviz, pré-calcular o Irradiance Map e o Light Cache localmente e depois incluir os ficheiros de cache no upload é significativamente mais rápido do que deixar cada nó recalcular do zero. O fluxo de trabalho dedicado está documentado no ; um resumo resumido transversal a motores está na secção de cache GI abaixo.
• VRayProxy e VRayScene: Ambos funcionam na render farm. Inclua os ficheiros proxy .vrmesh na pasta do projeto empacotado. A resolução de caminhos é tratada no momento do envio.
• V-Ray Frame Buffer (VFB): A saída EXR via VFB é suportada. Se usar correções de cor específicas do VFB, guarde-as como um ficheiro de correções .vccglb e inclua-o no pacote; o nó de trabalho aplicará as correções durante a renderização.
• Elementos de Renderização V-Ray: Todos os elementos de renderização padrão (VRayDiffuseFilter, VRayReflection, VRayRefraction, VRayLightSelect, VRayZDepth, etc.) escrevem corretamente. Para um único EXR multicanal, configure a saída nas definições de renderização V-Ray; para ficheiros por elemento, defina o modo de saída para ficheiros separados.

Octane para Cinema 4D

O Octane corre na nossa camada de nós GPU RTX 5090. É a escolha para estúdios que produzem renders estilizados que beneficiam do comportamento específico de shader do Octane — particularmente motion design, visualização de produto e trabalho conceptual.

Notas de configuração:

• Licença: O Octane na nossa render farm funciona sob o licenciamento de nó de renderização da Otoy. Não é necessário transferir a licença local Octane Studio.
• Kernels específicos de GPU: Os kernels Pathtracing, PMC e Direct Lighting do Octane correm todos na render farm. O Octane Render Cloud (serviço próprio da Otoy) é um produto separado; este documento abrange o Octane a correr como plugin C4D nos nós de trabalho da Super Renders Farm.
• Limitações de VRAM: O Octane é mais exigente em VRAM do que o Redshift. Cenas que cabem nos 32 GB do Redshift à escala podem precisar de ser otimizadas para o Octane — particularmente texturas (reduza texturas grandes de 8K para 4K onde possível) e instâncias (prefira o Octane Scatter em vez de cópias de malha duplicadas).
• Passes de Renderização Octane: Os Passes de Renderização no Octane comportam-se como AOVs no Redshift; configure-os no Octane Live Viewer. O EXR multi-pass é a saída predefinida e renderiza corretamente na render farm.
• Octane Vectron e primitivos: Os primitivos procedurais gerados no momento da renderização são suportados no nó de trabalho; inclua qualquer grafo de shader personalizado ou referências LiveDB no arquivo do projeto.

Arnold para Cinema 4D

O Arnold para C4D corre na nossa camada de nós CPU. É a escolha para estúdios com um pipeline Arnold partilhado entre Maya e C4D, ou para projetos que necessitam do shader volumétrico e de cabelo específico do Arnold.

Notas de configuração:

• Licença: O Arnold na nossa render farm funciona sob licenciamento de nó de renderização Autodesk. Não é necessária uma licença Arnold separada para enviar trabalhos C4D.
• AOVs e definições de renderização: O sistema AOV do Arnold é configurado por-pass nas Definições de Renderização. A saída EXR multicanal predefinida funciona na render farm. Para ficheiros por AOV, defina "Modo de Saída" para "Ficheiros Separados" por AOV.
• Amostragem: As Amostras de Câmara do Arnold mais as amostras Difusa / Especular / Transmissão devem ser calibradas localmente antes do envio. A render farm usa os mesmos valores de amostragem especificados no projeto — sobre-amostrar localmente significa sobre-amostrar no nó de trabalho, sem limite automático.
• Volumétrico e OpenVDB: Os ficheiros VDB devem ser empacotados juntamente com o projeto. A resolução de caminhos é tratada no momento do envio, tal como com texturas.
• Arnold Denoiser: O Arnold Denoiser baseado em OptiX corre na render farm para uso em fotogramas únicos e animação. Calibre a intensidade do denoiser localmente; o nó de trabalho aplica as definições que o ficheiro de cena contém.

Comparação rápida de motores

| Motor | Camada de nós | Fonte de licença | Melhor para | |---|---|---|---| | Redshift | GPU (RTX 5090) | Parceiro Maxon | Motion design, interiores archviz, iteração rápida | | V-Ray | CPU | Parceiro Chaos | Archviz, estúdios com pipeline V-Ray, grandes animações de interiores | | Octane | GPU (RTX 5090) | Nó de renderização Otoy | Motion design, visualização de produto estilizada | | Arnold | CPU | Nó de renderização Autodesk | Pipelines Maya-C4D partilhados, VFX volumétrico |

Tiled Camera para imagens fixas grandes

Para renders fixos acima de cerca de 6K de resolução, o caminho de renderização padrão do Cinema 4D pode encontrar limitações de VRAM ou RAM num único nó de trabalho. O fluxo de trabalho Tiled Camera renderiza a imagem em tiles distribuídos por múltiplos nós, depois monta o resultado numa única imagem final.

O fluxo de trabalho:

1. No C4D, mude a câmara de renderização para o modo Tiled Camera (objeto Câmara → tag Tiled Camera).
2. Defina a contagem de tiles — um ponto de partida razoável é 4×4 para 8K, 8×8 para 16K e 16×16 para fotogramas fixos 32K.
3. Verifique a definição de sobreposição de tiles. O padrão é 0 pixéis, o que funciona para tiles limpos mas pode produzir costuras visíveis em bordas de alto contraste. Definir a sobreposição para 4–8 pixéis suaviza as costuras durante a montagem.
4. Envie o trabalho. A render farm divide os tiles pelos nós automaticamente, com cada nó a renderizar um tile.
5. Após todos os tiles estarem concluídos, monte a imagem final localmente com o Tile Assembler do C4D ou através da aplicação de composição (After Effects, Nuke, Fusion).

Notas por motor para Tiled Camera:

• Redshift e Octane (GPU): o tamanho de tile GPU é a limitação relevante — condicionada pela VRAM por nó. Para uma imagem 16K em cartões RTX 5090 de 32 GB, tiles 8×8 renderizam com margem de VRAM para a maioria das cenas; interiores muito pesados podem necessitar de 16×16.
• V-Ray e Arnold (CPU): a limitação é a RAM CPU por nó (256 GB). Os tiles CPU são mais tolerantes — 4×4 é normalmente suficiente mesmo a 16K para interiores de archviz.
• Montagem de tiles: Os tiles EXR montam-se de forma limpa sem desvio de cor se todos os tiles partilharem as mesmas definições de gestão de cor (configuração OCIO ou Linear sRGB). Confirme que a gestão de cor é idêntica entre o ficheiro de projeto e a saída de renderização do nó antes de dividir em muitos tiles — uma incompatibilidade é muito mais difícil de detetar depois dos tiles já estarem renderizados.

O tempo de renderização por tile escala aproximadamente de forma linear com a contagem de pixéis do tile, pelo que tiles 4×4 renderizam cerca de 16× mais rápido no total do que 1×1 uma vez distribuídos pela frota de nós, uma vez que cada nó renderiza apenas um dezasseis avos da área de imagem.

Fluxo de trabalho de cache GI para animações de archviz

Para animações de archviz V-Ray e Redshift no Cinema 4D, recalcular a Iluminação Global por fotograma em cada nó desperdiça processamento e pode produzir cintilação. O padrão padrão é pré-calcular o cache GI localmente como um pass de "flythrough", depois enviar o ficheiro de cache juntamente com a animação para a renderização final.

Fluxo de trabalho prepass de animação V-Ray:

1. Na estação de trabalho, nas definições de renderização V-Ray, defina o Irradiance Map para o modo "Animation (prepass)" e o Light Cache para o modo "Fly-through".
2. Defina o prepass para amostrar cada N fotogramas (tipicamente cada 5.º ou 10.º fotograma para uma animação suave).
3. Renderize o prepass localmente. O V-Ray escreve os ficheiros Irradiance Map (.vrmap) e Light Cache (.vrlmap) para o caminho especificado nas definições de renderização.
4. Mude as definições de renderização: Irradiance Map para o modo "Animation (rendering)" e Light Cache para "From File", apontando para os ficheiros de cache gerados pelo prepass.
5. Verifique que os caminhos de ficheiro de cache estão dentro da pasta do projeto antes de arquivar — os caminhos têm de ser relativos à raiz do projeto, não caminhos absolutos de estação de trabalho.
6. Envie a animação completa. Cada nó lê do mesmo ficheiro de cache em vez de recalcular.

O mesmo padrão geral aplica-se ao Irradiance Point Cloud e ao Irradiance Cache do Redshift para interiores de archviz, embora o formato de ficheiro e os nomes das definições de renderização difiram. Para o guia de otimização GI transversal a motores incluindo a comparação UHD Cache e Brute Force, consulte o .

Uma nota sobre higiene de cache: um cache desatualizado de uma versão de cena anterior pode produzir erros de renderização silenciosos que parecem saída normal mas referenciam iluminação desatualizada. Ao alterar geometria de cena, iluminação ou materiais, regenere o cache em vez de reutilizar o anterior.

Fluxo de envio

Três canais de envio funcionam para projetos Cinema 4D:

• Plugin de envio (recomendado para utilizadores C4D). Envio a partir do C4D após instalar o plugin. O ciclo de iteração mais curto, uma vez que o plugin trata da verificação de ativos e criação de trabalho num único passo. Consulte .
• Upload web + envio pelo painel. Faça upload do arquivo do projeto empacotado e depois envie através do website. Funciona sem o plugin instalado. Adequado para projetos pontuais ou para estúdios em máquinas onde a instalação de plugins não é prática.
• Client App. Upload + envio + auto-download num único wrapper. Ideal para estúdios com trabalhos C4D recorrentes que pretendem auto-download na conclusão. Consulte .

Para o fluxo upload-envio-download transversal a DCCs, consulte o . Para transferências baseadas em SFTP em pacotes muito grandes, consulte .

Ao configurar o trabalho de renderização, verifique estes campos antes de enviar:

• A predefinição de definições de renderização ativas corresponde ao motor pretendido (Redshift / V-Ray / Octane / Arnold). O sistema de predefinições do C4D pode ter uma predefinição diferente da visível no viewport.
• O intervalo de fotogramas está definido nas definições de renderização (Fotograma Único, Todos os Fotogramas, Intervalo de Pré-visualização, ou personalizado). O envio de fotograma único a renderizar acidentalmente como animação é um dos padrões mais comuns de consumo excessivo de créditos.
• O caminho de saída usa um padrão relativo dentro do projeto (por exemplo, ./render/$prj_$take_$frame.exr). Os caminhos absolutos de estação de trabalho causam deslocação da saída no nó de trabalho.
• O formato de saída é EXR salvo se a composição a jusante necessitar explicitamente de PNG ou TIFF — o EXR transporta dados de cor float completo e AOVs multicanal num único ficheiro.

Resolução de problemas

Para resolução de problemas gerais transversal a DCCs, consulte . Casos específicos do C4D que vale a pena mencionar aqui:

• "Missing assets" no carregamento de cena. Execute novamente Guardar Projeto com Ativos numa cópia limpa do projeto e faça upload novamente. A causa mais frequente é um caminho de textura que foi alterado após o último pass de Guardar Projeto, ou uma referência .c4d externa que não foi aplainada.
• A renderização começa mas o Redshift devolve preto. Verifique que a câmara de renderização tem uma tag Câmara Redshift válida e que a câmara não está definida para o modo "Bloqueada" no viewport. Uma segunda causa: o Redshift não é o motor de renderização ativo — verifique Definições de Renderização → menu pendente Motor.
• Erro "License not found". É raro na nossa render farm porque o licenciamento é tratado do lado do servidor, mas pode ocorrer se a frota de nós estiver em atualização. Reenviar o trabalho 5–10 minutos depois resolve-o na maioria dos casos. Se persistir, contacte o suporte.
• Artefactos de tile visíveis nas fronteiras de tiles (modo Tiled Camera). Aumente os pixéis de sobreposição de tiles nas definições da Tiled Camera — o padrão é 0; definir 4–8 pixéis normalmente produz costuras suaves.
• O prepass de animação renderiza vazio. Para fluxos de trabalho de animação V-Ray, o prepass e os passes finais têm de referenciar o mesmo cache Irradiance Map. Verifique que o caminho do ficheiro de cache está incluído no projeto empacotado e que tanto as definições de renderização do prepass como as finais apontam para ele.
• A cor da saída difere da estação de trabalho. Mais frequentemente uma incompatibilidade de gestão de cor. Verifique Definições do Projeto → OCIO e confirme que a mesma configuração OCIO é referenciada tanto na estação de trabalho como no nó de trabalho. O C4D 2024+ tem como padrão OCIO ACES 1.3; se a estação de trabalho usar o pipeline Linear sRGB legado, o nó de trabalho renderizará no espaço de cor guardado do projeto, que pode diferir da interpretação de viewport.
• Plugin não reconhecido no nó de trabalho. Se um plugin de renderização (por exemplo, X-Particles, add-on MoGraph, deformador de terceiros) é referenciado pela cena mas não está pré-instalado no nó de trabalho, a renderização falha no carregamento de cena. Contacte o suporte antes do envio para plugins fora do conjunto de motores principal; alguns plugins podem ser adicionados à imagem do nó de trabalho, outros podem requerer cozimento em cache (Alembic, OpenVDB) antes do upload.

Referências cruzadas

• — fluxo upload, envio, download
• — como são calculados os custos de trabalhos C4D
• — Irradiance Map, Light Cache, UHD Cache, fluxo prepass de animação
• — formatos de arquivo, guia SFTP
• — resolução de problemas transversal a DCCs
• — instalação do plugin de envio C4D
• — wrapper de auto-download para trabalhos recorrentes
• — para arquivos de projeto muito grandes
• — página de destino
• — página de destino específica Redshift
• — artigo de fluxo Redshift mais aprofundado

FAQ

Q: Quais as versões do Cinema 4D que a render farm suporta? A: C4D 2024 e 2025 estão pré-instalados em todos os nós de trabalho. R23, R25 e S22–S26 estão disponíveis a pedido para projetos legados, mas não estão ativados por predefinição. A render farm corresponde automaticamente à versão do ficheiro .c4d; não é necessário especificá-la manualmente no envio.

Q: É necessário transferir a licença Maxon para renderizar na render farm? A: Não. Como parceiro oficial Maxon, executamos instalações Cinema 4D licenciadas em toda a frota de nós. O utilizador faz o upload do projeto e nós renderizamos. A licença Maxon Cinema 4D local permanece na estação de trabalho.

Q: Que motor devo escolher para cloud rendering — Redshift, V-Ray, Octane ou Arnold? A: Depende do projeto. O Redshift adequa-se ao motion design e archviz com complexidade de cena moderada (iteração GPU rápida). O V-Ray adequa-se a pipelines de archviz com bibliotecas V-Ray estabelecidas e grandes animações de interiores com cache GI. O Octane adequa-se a renders GPU estilizados e visualização de produto. O Arnold adequa-se a projetos com um pipeline Maya-C4D partilhado ou trabalho intensivo de volumétrico e cabelo. Os quatro são suportados na nossa render farm com licenciamento verificado.

Q: A cena usa referências externas XRef. Resolverão na render farm? A: Sim, se estiverem incluídas no upload empacotado. Execute Guardar Projeto com Ativos no projeto principal; o C4D irá puxar a geometria XRef para o pacote. Se preferir manter os ficheiros XRef separados para edição em direto, inclua cada .c4d referenciado no upload também — o nó de trabalho resolve os caminhos no momento do envio desde que os ficheiros referenciados estejam presentes no arquivo.

Q: Pretendo renderizar uma imagem fixa de 8K. Caberá num único nó de trabalho? A: Depende da cena. Um fotograma fixo de 8K no Redshift com complexidade de cena moderada frequentemente cabe nos 32 GB de VRAM num único nó de trabalho. Para cenas muito complexas ou resoluções mais altas (12K, 16K, 32K), use o modo Tiled Camera — a render farm renderiza tiles por múltiplos nós e o utilizador monta o resultado. Contagens de tiles de 4×4 para 8K, 8×8 para 16K e 16×16 para 32K são pontos de partida razoáveis.

Q: O projeto C4D usa um plugin como X-Particles ou um deformador de terceiros. Vai renderizar? A: O plugin precisa de estar instalado no nó de trabalho. Pré-instalamos os principais plugins de renderização (Redshift, V-Ray, Octane, Arnold) e as suas ferramentas associadas. Para outros plugins (X-Particles, add-ons MoGraph, deformadores de terceiros), contacte o suporte antes do envio. Alguns plugins podem ser adicionados à imagem do nó de trabalho; outros podem requerer cozimento do resultado em cache (geometria Alembic, volumes OpenVDB) antes do upload.

Q: Como funciona o sistema Take do C4D com a renderização na render farm? A: O plugin de envio reconhece o take ativo quando se envia. Para renderizar múltiplos takes, envie cada take como um trabalho separado, ou use a funcionalidade Fila de Renderização no C4D 2024+ para colocar múltiplos takes na fila e enviar a fila como um lote. Cada take renderiza como o seu próprio trabalho na render farm e é cobrado pelo seu próprio tempo de renderização.

Q: Tenho uma animação de archviz de 30 segundos em V-Ray. Como evitar cintilação GI de fotograma para fotograma? A: Pré-calcule o cache GI localmente usando o fluxo prepass de animação do V-Ray — Irradiance Map no modo Animation (prepass) mais Light Cache no modo Fly-through, amostrado a cada 5.º ou 10.º fotograma. Depois envie a animação completa com Irradiance Map definido para Animation (rendering) e Light Cache definido para From File, apontando para o cache do prepass. Cada nó lê do mesmo cache em vez de recalcular, o que elimina a cintilação e reduz o tempo total de renderização. O fluxo completo está na secção de cache GI acima e no guia de otimização V-Ray.

Q: A renderização concluiu mas a cor da saída parece diferente da estação de trabalho. O que mudou? A: Mais frequentemente isto é uma incompatibilidade de gestão de cor. Verifique Definições do Projeto → OCIO e confirme que a mesma configuração OCIO é referenciada tanto na estação de trabalho como no nó de trabalho. O C4D 2024+ tem como padrão OCIO ACES 1.3; se a estação de trabalho usar o pipeline Linear sRGB legado, o nó de trabalho renderizará no espaço de cor guardado do projeto, que pode diferir da interpretação de viewport. Voltar a guardar o projeto a partir de uma estação de trabalho que usa o mesmo alvo OCIO que a render farm resolve o desvio.

---