Corona Renderer em Render Farms: Guia Completo de Configuração

Introdução

Corona Renderer destaca-se entre os principais processadores porque utiliza ray tracing baseado em CPU exclusivamente — sem percurso de processamento em GPU. Esta arquitetura tem implicações profundas para a implementação de farms de processamento. Em farms tradicionais construídas para V-Ray GPU, Corona requer provisionamento de hardware diferente, modelos de licenciamento e abordagens de otimização distintas.

Somos um parceiro oficial de processamento Chaos, apoiando Corona ao lado de V-Ray e Redshift na nossa farm. O foco em CPU do Corona significa que excele em cenários onde a largura de banda da farm GPU é limitada ou onde clientes preferem estabilidade de CPU. Durante os últimos três anos, processámos milhares de trabalhos Corona e refinamos fluxos de trabalho que maximizam a eficiência da farm enquanto minimizam problemas comuns de implementação.

Este guia cobre a arquitetura do Corona, configuração de processamento distribuído, licenciamento de nós, preparação de cenas, erros comuns e soluções, Corona vs. V-Ray em farms, e as técnicas de otimização que utilizamos para manter tempos de processamento Corona competitivos.

Compreender a Arquitetura de Processamento Baseada em CPU do Corona

Corona Renderer produz saída fotorrealista via ray tracing unidirecional — um raio único salta da câmara através da cena, recolhendo amostras de luz até atingir uma fonte de luz ou o limite de rejeição. Isto é diferente do ray tracing bidirecional (abordagem de V-Ray) ou processamento espectral (Arnold). O design unidirecional do Corona prioriza velocidade e consistência. Para documentação técnica, consulte o manual do Corona Renderer.

Por que apenas CPU? O ray tracing em CPU evita limitações de memória GPU, permitindo ficheiros de cenas massivas. Uma cena com 500 milhões de polígonos ou 10GB de texturas encaixa-se confortavelmente numa máquina CPU com 128GB de RAM. O processamento em GPU teria dificuldades. CPU também oferece precisão numérica superior (64 bits em ponto flutuante), crucial para visualização arquitetónica onde pequenos desalinhamentos de superfície importam.

Implicações para farm: Processamentos Corona são exigentes em CPU mas indulgentes em memória. Um servidor Xeon de 4 soquetes processa uma cena complexa 4-8x mais rápido que uma máquina com quatro GPUs, mas consome a mesma energia. A nossa farm aloca máquinas Xeon E5-2699 v4 de duplo soquete especificamente para Corona — 44 núcleos por máquina, funcionando a 100% durante processamentos.

Realidade de licenciamento: Corona utiliza licenças node-locked, significando que uma licença ativa um núcleo de CPU. Uma máquina com 44 núcleos requer 44 licenças Corona. Isto é dispendioso em escala mas oferece faturação de capacidade precisa e evita overhead de licenças flutuantes. Para modelos de licenciamento detalhados entre processadores, consulte o nosso guia de licenças de nó.

Configuração de Processamento Distribuído em Corona

O processamento distribuído do Corona divide um fotograma em múltiplas máquinas, cada uma processando um tile e devolvendo resultados à máquina de submissão para composição. A configuração requer:

1. Máquina de submissão (primária): Executa Corona, submete o trabalho e recebe resultados de tiles.

2. Trabalhadores de farm (secundários): Executam Corona em modo headless, recebem atribuições de tiles e devolvem tiles processados.

3. Rede: LAN rápida necessária (gigabit mínimo, 10-gigabit preferido). Corona transfere tiles pela rede, portanto latência e largura de banda importam.

4. Armazenamento partilhado: Texturas, ficheiros de cache e ativos de projeto devem estar acessíveis de todos os trabalhadores. Utilizamos um NAS de 10Gb montado via NFS em todos os nós da farm.

Passos de configuração:

Iniciar Corona → Processar → Definições de Processamento Distribuído → Ativar Modo Distribuído → Configurar Máquinas de Trabalho (endereços IP ou nomes de máquinas). Corona processa automaticamente divisão de tiles e composição de resultados na máquina primária.

Se utiliza 3ds Max ou Cinema 4D com Corona, o processo é semelhante mas encontra-se no diálogo de definições de processamento em vez da UI autónoma do Corona.

Requisitos de nó de trabalho: Cada trabalhador necessita exatamente da mesma versão de Corona que a máquina primária. Versões incompatíveis causam falhas silenciosas de tiles. Mantemos consistência de versão via provisionamento automatizado — novos nós de trabalho transferem Corona de um repositório central durante inicialização.

Licenciamento Corona para Render Farms

Licenças de Nó Corona são subscrições perpétuas, por-núcleo. Uma licença ativa um núcleo de CPU para processamento. Diferentemente do modelo de licença de nó de V-Ray (uma licença por máquina independentemente de contagem de núcleos), Corona é granular.

Implicações de custo: Uma máquina de 64 núcleos requer 64 licenças Corona — dispendioso mas transparente. Paga-se pelo que se utiliza. Calculámos o licenciamento Corona da nossa farm em aproximadamente $0,03-$0,05 por núcleo de processamento por mês (baseado no nosso contrato de parceiro de processamento Chaos), tornando farms de 1.000 núcleos economicamente viáveis para produção de alto volume.

Ativação de licença: Licenças Corona são node-locked via endereço MAC do sistema. Na nossa farm, mantemos uma base de dados de licenças mapeando endereços MAC para chaves de licença. Quando um trabalhador arranca, auto-ativa licenças durante inicialização — crítico para implementações cloud elásticas.

Flutuante vs. node-locked: Corona não suporta licenças flutuantes (diferentemente de V-Ray). Cada núcleo recebe a sua própria licença. Isto simplifica registos mas requer gestão cuidada de inventário. Para comparação entre modelos de licenciamento de processadores, consulte o nosso comparação de licenciamento Corona.

Percursos de atualização: Corona mantém compatibilidade retroativa entre versões principais (por exemplo, processadores 11 podem trabalhar com cenas Corona 10). No entanto, chaves de licença são version-locked. Atualizar de Corona 10 para Corona 11 requer novas chaves de licença para todos os núcleos.

Na nossa farm: Mantemos dois lotes de licença — um conjunto primário para processamento de produção, um conjunto secundário para desenvolvimento e teste. Isto isola produção de experimentação.

Preparação de Cenas e Erros Comuns de Submissão em Farm

Cenas Corona falham em farms por razões previsíveis. A nossa lista de verificação pré-submissão aborda todas:

1. Caminhos de textura: Garantir que todas as texturas utilizam caminhos UNC absolutos (ex: \\farm-nas\project\textures\wood.exr) ou caminhos relativos dentro da estrutura do projeto. Corona não incorpora texturas no ficheiro de cena como alguns processadores, portanto caminhos em falta = texturas em falta no momento do processamento.

Criámos um script "path checker" automatizado em MaxScript que reporta quaisquer caminhos de textura não-UNC antes da submissão. Isto eliminou ~95% das falhas de farm "textura em falta".

2. Ficheiros proxy: Corona suporta proxies V-Ray (.vrmesh) lindamente, mas caminhos de proxy devem ser absolutos. Convertemos caminhos relativos (ex: .\proxies\building.vrmesh) para caminhos UNC completos antes da submissão.

3. Mapas HDR: Mapas de ambiente (ficheiros .hdr) devem estar acessíveis de trabalhadores de farm. Mesma regra que texturas — caminhos UNC absolutos.

4. Plugins e extensões: O ecossistema de plugin Corona é pequeno. Se a cena utiliza um material de terceiros (ex: Substance Designer dentro de 3ds Max), esse plugin deve existir em trabalhadores de farm ou o material falhará em carregar silenciosamente, processando como preto.

5. Cenas animadas: Corona processa animação e motion blur eficientemente, mas verificar cache de fotograma em nós de trabalho. Algumas configurações fazem cache de fotogramas desnecessariamente, inchando utilização de NAS.

6. Disponibilidade de licença: Verificar que a contagem de licenças Corona corresponde ao número de núcleos que está a solicitar. Uma cena submetida a 100 núcleos mas com apenas 50 licenças processará a 50% de capacidade silenciosamente — sem mensagem de erro. Adicionámos verificações de quota ao dashboard da nossa farm para prevenir isto.

Resolução de Erros Comuns

Erro	Causa	Solução
Processamento devolve pixéis pretos ou totalmente preto	Plugin em falta ou material	Verificar definições de material em cena; verificar disponibilidade de plugin em farm
Tiles não compõem corretamente	Incompatibilidade de versão entre máquina primária e trabalhador	Atualizar todos os trabalhadores para versão Corona correspondente à máquina primária
Processamento extremamente lento (~100x mais lento que esperado)	Processamento em modo interativo em vez de distribuído	Verificar Definições de Processamento Distribuído ativadas e trabalhadores registados
Alguns tiles falham; outros têm sucesso	Timeout de rede ao obter texturas	Mover texturas para volume NAS local acessível via NFS; aumentar timeout de rede em definições Corona
Falha de ativação de licença em trabalhador	Incompatibilidade de endereço MAC ou chave de licença expirada	Verificar endereço MAC em base de dados de licença; renovar licença se expirada
Ruído/artefatos aparecem inconsistentemente	Corrupção de cache de trabalhador	Limpar C:\ProgramData\Corona\Cache em todos os trabalhadores; reenviar

Corona vs. V-Ray em Render Farms: Quando Usar Cada

Pontos fortes Corona:

• Suporte de cena massiva (500M+ polígonos, 10GB+ texturas)
• Saída consistente e limpa com menos artefatos para gerir
• Qualidade excelente para visualização arquitetónica e de produto
• Apenas CPU significa escalagem previsível (mais núcleos = mais rápido)

Para mais detalhes sobre configuração de Corona na nossa farm, consulte a nossa página de farm de processamento Corona.

Pontos fracos Corona:

• Apenas CPU (sem percurso GPU), portanto mais lento por núcleo que V-Ray GPU
• Licenciamento mais dispendioso (por-núcleo, não por-máquina)
• Ecossistema de plugin mais pequeno que V-Ray

Pontos fortes V-Ray:

• Processamento em GPU (cartões RTX) — rápido para cenas complexas
• Processamento de rede distribuído bem estabelecido
• Ecossistema maior e suporte de terceiros

Pontos fracos V-Ray:

• Limites de memória GPU cenas a ~50-100GB orçamentos de textura
• Competição de recursos GPU — uma cena pesada priva outros

Nosso marco de decisão:

• Corona para: Archviz (>200M polígonos), visualização de produto, trabalho de estúdio com bibliotecas de ativos massivas
• V-Ray para: Prazos mais curtos, GPU disponível, processamento de animação (farms de fotograma)
• Ambos: Cargas de trabalho mistas de alto volume — distribuir entre pools Corona e V-Ray

Técnicas de Otimização para Processamento Corona Distribuído

1. Sintonização de tamanho de tile: Corona divide fotogramas em tiles (padrão 32x32 pixels). Tiles mais pequenos = distribuição de granularidade fina mas mais overhead de rede. Tiles maiores = menos viagens de rede mas carga desequilibrada se um tile for mais difícil. Utilizamos tipicamente 64x64 para saída 4K, 128x128 para 8K.

2. Processamento de múltiplas passagens: Corona suporta dividir um fotograma em múltiplas passagens (luz direta, indireta, AO, etc.), processando cada uma independentemente. Isto é mais rápido que processamento de passagem única e permite flexibilidade de composição. A nossa farm processa todos os trabalhos Corona como múltiplas passagens por padrão.

3. Largura de banda de memória: Processamento em CPU de Corona é limitado por memória, não por CPU. Máquinas de duplo soquete com frequência de RAM maximizada (3200MHz+) processam ~20% mais rápido que RAM padrão. Especificamos memória de alta frequência em hardware dedicado Corona.

4. Localidade de cache: Corona beneficia de cache L3 de CPU. Máquinas com caches maiores (como E5-2699 v4 com 55MB L3) processam 10-15% mais rápido. Ao provisionar capacidade Corona, priorizar cache de CPU sobre velocidade de relógio.

5. Otimização de rede: 10Gb LAN vale o investimento para farms Corona. LANs de gigabit tornam-se estrangulamentos acima de 20 processamentos Corona concorrentes. Documentámos isto; farms com infraestrutura 10Gb vêem transferência de tile 25-30% mais rápida.

6. Pré-processamento de cena: Antes da submissão em farm, utilizar "Preprocess for distributed rendering" incorporado de Corona que faz cache de geometria, materiais e texturas localmente. Isto reduz tráfego de rede durante processamento real.

Implementação em Escala: Nossa Arquitetura de Farm

A nossa configuração Corona abrange 12 máquinas Xeon de duplo soquete (528 núcleos totais, ~480 utilizáveis após overhead). Esta configuração:

• Processa 100-200 trabalhos Corona concorrentes dependendo de complexidade de cena
• Processa fotogramas de 3-5 minutos (típico archviz 4K + GI pesado) em 20-30 minutos
• Custa ~$6-8K por mês em energia, manutenção e licenciamento
• Gera ~$15-20K de receita mensalmente, rendendo ROI de 2,5x dentro de 18 meses de implementação de hardware

Para estúdios considerando farms Corona no local, esta escala é o ponto de equilíbrio. Abaixo de 300 núcleos, processamento cloud (AWS, Google Cloud) é mais rentável. Acima de 500 núcleos, no local escala melhor.

Super Renders Farm é uma render farm na nuvem e parceiro oficial de renderização Chaos.

FAQ

Posso utilizar Corona com V-Ray na mesma cena?

Não. Uma cena processa com um motor. No entanto, pode processar duas passagens (uma Corona, uma V-Ray) e compor em pós-produção. Não recomendamos isto devido a complexidade, mas é tecnicamente possível.

Corona suporta processamento distribuído aninhado (farm → sub-farm)?

Não. O modo distribuído Corona espera uma máquina primária e máquinas de trabalho numa rede plana. Delegação aninhada não é suportada. Cenas complexas são processadas escalando uma farm única, não federando farms.

Qual é o overhead típico para processamento distribuído?

Overhead de rede e composição de tile é 5-15%, dependendo de tamanho de tile e latência de rede. Um processamento de máquina única de 1 minuto pode levar 65-75 segundos distribuído através de 8 máquinas (1 minuto ÷ 8 máquinas = 7,5 segundos, mais 5-15% overhead). Escalagem quebra-se acima de ~50 máquinas devido a overhead de composição.

Posso processar Corona pela internet para farms remotas?

Tecnicamente sim, mas latência de rede torna isto impraticável. Latência de 100ms → atrasos visíveis em transferência de tile. Recomendamos LANs locais de gigabit. Para processamento remoto, utilizar serviços cloud (Chaos Cloud, AWS, Google Cloud) com rede otimizada.

A licença Corona requer conectividade à internet?

Não. Licenças Corona são node-locked via endereço MAC. Uma vez ativadas, funcionam offline. Isto é ideal para estúdios seguros sem acesso à internet. Chaves de licença são perpétuas — sem renovação de subscrição.

Corona pode retomar processamento se um trabalhador falhar a meio de um tile?

Não. Processamento distribuído reinicia o trabalho inteiro se qualquer trabalhador falhar. Por isto robusto hardware e monitorização de rede são críticos. Um trabalhador que falha a meio de processamento desperdiça tempo de computação. Mantemos 99,5% disponibilidade de trabalhador via monitorização proativa de hardware e gestão térmica.

Como processo iterações de cena Corona numa farm?

Utilizar versionamento. Cada iteração é um ficheiro separado (scene_v01.max, scene_v02.max). Submissões de farm estão ligadas a versões de ficheiro, permitindo rastreamento e reprocessamento de iterações específicas. Mantemos uma base de dados de ficheiro mapeando IDs de trabalho para versões de cena.

O formato de saída Corona é flexível para composição de pós-produção?

Sim. Corona pode processar para OpenEXR com passagens arbitrárias (direta, indireta, especular, difusa, sombras, etc.), permitindo flexibilidade completa de composição. Processamos OpenEXR de múltiplas passagens por padrão, permitindo pós-produção ajustar iluminação, materiais e efeitos sem reprocessar.

Qual é o tamanho máximo de cena que Corona pode processar?

Teoricamente ilimitado, limitado apenas por RAM disponível. Processámos ficheiros de cena de 3GB (1B+ polígonos, biblioteca de textura de 50GB) sem problemas em máquinas de 256GB RAM. Além disto, dividiríamos a cena e composiríamos em pós-produção.

Como Corona processa motion blur e profundidade de campo em farms?

Ambos são computados durante amostragem — sem pós-processamento separado. Motion blur é ligeiramente mais lento devido a ray casts extras, mas profundidade de campo tem overhead mínimo. Ambos funcionam identicamente em farms que em máquinas locais.