V-Ray 6 numa Render Farm na Nuvem: Um Guia Prático para 2026

Introdução

O V-Ray tem sido uma referência na renderização de produção há mais de duas décadas, e o V-Ray 6 continua a ser a versão que grande parte dos estúdios utiliza no dia a dia. As novas versões principais são lançadas, os pipelines validam-nas gradualmente, e um trabalho de visualização arquitetónica em 4K que tem de ser entregue na próxima semana não espera por uma migração de versão. Por isso, mesmo com o V-Ray 7 já disponível, muitas das cenas que chegam a uma render farm na nuvem com V-Ray 6 são construídas, iluminadas e aprovadas na versão 6 — e precisam de renderizar da mesma forma em mil núcleos que num único workstation.

É precisamente nesse último ponto que residem a maioria dos problemas. Uma cena de V-Ray 6 que renderiza perfeitamente no computador onde foi criada pode produzir flicker, perder recursos ou silenciosamente retroceder para o motor errado quando os seus frames são distribuídos por nós de trabalho que nunca viram a pasta do projeto. Na Super Renders Farm, passámos anos a observar exatamente quais os passos que sobrevivem a essa transição e quais os que falham. Este guia percorre o que mudou no V-Ray 6 para quem efetivamente prime o botão de render, como a versão se comporta nas aplicações que suportamos, quando o V-Ray GPU supera o V-Ray CPU (e quando não o faz), e como preparar uma cena para que os frames distribuídos regressem limpos. Nada do que aqui se descreve pressupõe que tenha adquirido as suas próprias licenças de renderização ou que queira aceder remotamente a uma máquina para supervisionar uma fila.

O que o V-Ray 6 mudou para quem realmente renderiza

Grande parte da discussão em torno do V-Ray 6 centra-se nas conveniências de modelação e de look development. O que importa numa render farm é mais restrito: quais as funcionalidades que alteram o trabalho realizado por um nó de renderização, o tamanho do ficheiro que tem de enviar, ou os plugins que precisam de estar instalados. Algumas do ciclo do V-Ray 6 são genuinamente relevantes para render farms.

Funcionalidades de renderização do V-Ray 6 — Enmesh, Chaos Scatter, V-Ray Decals e nuvens volumétricas

O Enmesh aplica uma malha de origem sobre uma superfície em tempo de renderização, em vez de incorporar essa geometria na cena. Pense em cota de malha, fachadas perfuradas, tecidos entrelaçados, grades. Como a geometria é gerada no nó durante a renderização em vez de ser guardada no ficheiro, o .vrscene que chega a cada nó de trabalho mantém-se pequeno e a geometria pesada só existe na memória de renderização. Isto é uma vantagem real numa render farm: menos transferência de rede e RAM que escala com a renderização em vez de com o ficheiro guardado.

O Chaos Scatter integrou a dispersão nativa no próprio V-Ray — vegetação, rochas, cobertura de solo — resolvida proceduralmente em tempo de renderização. A vantagem do lado da render farm é a redução de dependências: uma cena dispersa com Chaos Scatter não precisa de um plugin de dispersão de terceiros com licença instalada em cada nó, o que significa um elemento a menos que pode estar em falta quando um frame chega a um nó de trabalho.

Os V-Ray Decals projetam um material sobre uma superfície sem tocar nas suas UVs ou topologia — etiquetas, autocolantes, desgaste de superfície, sinalética. Resolvem-se inteiramente dentro do próprio pipeline do V-Ray, pelo que o único elemento de que um nó necessita é o acesso aos mapas de textura do decal.

O céu procedural e as nuvens volumétricas permitem construir um céu como parâmetros em vez de um HDRI fixo, com nuvens que se comportam como volumes reais na cena. Estas renderizações são mais pesadas por frame, mas são completamente paralelas ao nível de frame — cada nó calcula os seus próprios frames sem dependência dos vizinhos — pelo que se distribuem sem problemas. O ponto a ter em conta é a memória VRAM do V-Ray GPU: céus volumétricos densos consomem muita VRAM, e um céu complexo é frequentemente mais seguro em CPU.

O V-Ray Frame Buffer continua também a justificar o seu lugar num pipeline de render farm. O seu Light Mix permite separar e reequilibrar luzes ou grupos de luz individuais depois de a renderização estar concluída, diretamente a partir dos elementos de renderização guardados, sem necessidade de re-renderizar. Quando um realizador pede para "aquecer a luz principal e reduzir o enchimento" no dia seguinte a uma sequência ter terminado, esse ajuste acontece em compositing em vez de reentrar na fila — que é a alteração menos dispendiosa que se pode fazer. E o Chaos Cosmos, a biblioteca de recursos integrada, é conveniente no viewport mas introduz a falha mais comum de render farm que vemos; mais sobre isso na secção de fluxo de trabalho, porque vale a pena perceber bem.

V-Ray 6 nas DCCs que renderizamos

O V-Ray 6 é distribuído como integrações separadas para aplicações anfitrião separadas, e o facto relevante para a render farm é que todas convergem para o mesmo formato de despacho: um ficheiro .vrscene renderizado pelo V-Ray Standalone. A aplicação em que se modela importa para o fluxo de trabalho; importa muito menos para o nó, que simplesmente executa a cena exportada.

Na nossa render farm, as aplicações anfitrião através das quais executamos o V-Ray são o 3ds Max, Maya, Cinema 4D e Houdini. O 3ds Max com V-Ray é o motor de trabalho da visualização arquitetónica e o caminho mais comum que vemos — interiores, exteriores, visualização de produto. O Maya com V-Ray cobre o mesmo terreno para pipelines de VFX e animação. O Cinema 4D com V-Ray serve estúdios de motion e design. O Houdini com V-Ray para Houdini completa a lista para cenas construídas proceduralmente, onde a geometria orientada por VEX e por nós é resolvida na cena exportada no momento da exportação. Para os detalhes por aplicação, mantemos páginas de chegada para 3ds Max, Maya, Cinema 4D e Houdini, e uma visão geral específica do V-Ray na página da render farm na nuvem para V-Ray.

Vale a pena referir dois limites honestos. O SketchUp tem a sua própria integração de V-Ray, mas o SketchUp não é uma das aplicações anfitrião que executamos na render farm. Os utilizadores de SketchUp ainda têm um caminho direto: o V-Ray para SketchUp pode exportar um .vrscene diretamente, e esse ficheiro renderiza no V-Ray Standalone da mesma forma que um exportado do 3ds Max — pelo que a cena chega à render farm sem necessidade de ter o SketchUp instalado em qualquer lugar. A alternativa é importar o modelo para o 3ds Max, reconfigurar os materiais e exportar a partir daí, o que implica mais trabalho mas dá acesso ao conjunto completo de ferramentas do 3ds Max para limpeza. De qualquer forma, a renderização ocorre através da exportação de uma aplicação suportada, não dentro do SketchUp.

O outro limite é o Blender. Na nossa render farm, as cenas Blender renderizam em Cycles — o renderer de produção nativo do Blender — e não em V-Ray. Portanto, se o seu pipeline é V-Ray, as suas aplicações anfitrião são as quatro acima; se for Blender, está a trabalhar em Cycles, que é um fluxo de trabalho diferente.

V-Ray GPU vs V-Ray CPU numa render farm: a decisão real

O V-Ray 6 oferece dois motores de renderização que partilham materiais e iluminação, mas que se comportam de forma muito diferente quando escalados. Escolher o errado é um dos erros mais dispendiosos numa render farm, porque normalmente não se nota até os frames regressarem.

Comecemos pela verdade simples: a maior parte do trabalho de V-Ray continua a ser trabalho de CPU. Nos trabalhos que vemos, cerca de 70% da renderização é CPU — V-Ray (CPU), Corona, Arnold CPU — e a grande maioria é visualização arquitetónica. O V-Ray CPU escala de forma próxima do linear com núcleos físicos, o que explica por que os servidores com muitos núcleos se adequam tão bem a ele. A nossa frota de CPU é constituída por máquinas com processadores dual Intel Xeon E5-2699 V4 com 96–256 GB de RAM cada, totalizando mais de 20.000 núcleos de CPU, e um interior em 4K que demora horas num workstation é dividido por esse conjunto frame a frame. De forma crucial, a renderização em CPU utiliza RAM do sistema, não VRAM, pelo que um interior com muitas texturas PBR de 4K e 8K em todo o conjunto não atinge um limite de memória da mesma forma que uma GPU pode. Para visualização arquitetónica de qualidade final em grande escala, o CPU é geralmente a opção padrão mais segura.

O V-Ray GPU representa os outros 30%, e é genuinamente mais rápido — quando a cena cabe. Funciona em dois modos: um modo CUDA amplamente compatível, e um modo RTX que utiliza os núcleos de ray tracing por hardware nas GPUs NVIDIA de classe RTX para um aumento de velocidade dependente da cena. As nossas máquinas GPU têm placas RTX 5090 com 32 GB de VRAM cada, e esse número de VRAM é o cerne de tudo. A VRAM é a principal restrição na renderização em GPU: se a geometria e as texturas de uma cena couberem, o V-Ray GPU é excelente para iteração e para interiores de complexidade moderada. A diferença de 24 GB (uma placa de gama alta típica para workstation) para 32 GB é a diferença entre uma cena que fica inteiramente em memória e uma cena que tem de paginar dados dentro e fora através do modo out-of-core, o que penaliza o desempenho. Para cenas que estavam a paginar numa placa de 24 GB, simplesmente ter a margem disponível pode ser a parte mais significativa do ganho de velocidade. Fizemos benchmarks precisamente neste cenário em hardware RTX 5090 no nosso teste de velocidade de V-Ray GPU e na análise mais abrangente sobre desempenho de renderização RTX 5090; a página da render farm na nuvem para GPU explica como esses nós estão configurados.

A decisão, em resumo:

O V-Ray 6 também suporta um modo híbrido em que os núcleos de CPU e a GPU do mesmo nó contribuem para uma única renderização, o que é útil quando uma cena de GPU está mesmo no limite do seu orçamento de memória. O que se deve evitar é presumir que "GPU é sempre mais rápido." Para uma cena de visualização arquitetónica grande e com muitas texturas, o V-Ray CPU é frequentemente mais rápido no geral porque não está a lutar contra um limite de memória. Adapte o motor à cena, não ao entusiasmo.

Preparar uma cena de V-Ray 6 para renderizar corretamente numa render farm

Esta é a parte que decide se os frames regressam utilizáveis. As mecânicas não são complicadas, mas algumas falham silenciosamente, que é a pior forma de falhar.

O caminho de despacho. A forma canónica de renderizar V-Ray numa render farm é exportar a cena como .vrscene e deixar o V-Ray Standalone renderizá-la em cada nó. A consequência importante é o licenciamento: um nó a executar V-Ray Standalone não precisa de uma licença de 3ds Max, Maya ou Cinema 4D para renderizar — precisa de V-Ray. Na nossa render farm, essas licenças de renderização estão incluídas no que paga para renderizar; não traz a sua própria licença nem instala nada. Este é o significado prático de "totalmente gerido" — sem acesso remoto, sem servidor de licenças para supervisionar, sem configuração de software por nó da sua parte. É também a linha clara entre este modelo e um modelo de aluguer de infraestrutura, onde alugaria máquinas e forneceria as suas próprias licenças de software.

Distribuição de frames, não Distributed Rendering. Estes dois conceitos são constantemente confundidos. Uma render farm distribui frames inteiros por nós — o nó A renderiza o frame 1, o nó B renderiza o frame 2, e assim sucessivamente. O Distributed Rendering (DR) do V-Ray é outra coisa: múltiplas máquinas a colaborar num único frame, a dividir buckets pela rede em tempo real. O DR é uma ferramenta de estúdio para um único frame hero de grande dimensão; acrescenta latência de rede, exige versões idênticas de V-Ray em todo o lado, e é menos eficiente em grande escala. Para praticamente toda a animação e sequências de imagens, a distribuição de frames é o modelo correto, e é o que uma render farm faz por predefinição.

Distribuição de intervalos de frames versus Distributed Rendering do V-Ray numa render farm

GI sem flicker. Para animação, esta é a escolha que mais vezes apanha as pessoas. Brute Force GI com uma Light Cache por frame calcula a iluminação de forma independente para cada frame — mais lento por frame, mas sem flicker e sem dependência entre frames, pelo que qualquer nó pode renderizar qualquer frame em qualquer ordem. Este é o padrão seguro contra flicker que recomendamos para animação distribuída. A abordagem de Irradiance Map é mais rápida por frame porque pré-computa uma solução de GI e reutiliza-a, mas só funciona para animações de câmara com luzes e objetos estáticos, e todos os nós têm de ler o mesmo mapa pré-computado a partir de um caminho partilhado. A falha clássica: o mapa é guardado num caminho local como C:\Users\artista\cena.vrmap, os nós não o conseguem encontrar, e cada frame recalcula silenciosamente o GI — produzindo exatamente o flicker que se tentava evitar. Se utilizar Irradiance Map, processe-o uma vez, envie o ficheiro com o trabalho e reconfigure os caminhos. Se não tiver a certeza, utilize Brute Force.

Denoising. O V-Ray 6 oferece o V-Ray Denoiser (CPU), o NVIDIA AI Denoiser (necessita de uma GPU NVIDIA no nó) e o Intel Open Image Denoise (CPU, funciona em qualquer lugar). Os três funcionam por frame sem estado entre frames, pelo que são seguros para renderização totalmente paralela. O nosso conselho habitual: guarde sempre o passe de beleza bruto e sem denoising a par da saída com denoising. Se o denoiser borrar um detalhe, volte a aplicar o denoising em pós-produção em vez de re-renderizar a sequência.

Recursos Chaos Cosmos — o problema silencioso. Esta é a falha mais comum de render farm com V-Ray 6 para novos utilizadores, e falha silenciosamente. Os recursos Cosmos são descarregados para a sua cache local de Cosmos. Quando exporta o .vrscene, esses recursos são referenciados pelos seus caminhos locais. Os nós não têm a sua cache Cosmos, por isso recebem uma cena que aponta para ficheiros que não existem — e o resultado é vegetação em falta, adereços cinzentos ou um céu em branco, sem qualquer erro explícito. A solução é recolher os recursos antes de submeter: utilize as ferramentas de recolha de recursos / "pack project" do V-Ray para reunir todos os ficheiros Cosmos e de textura numa pasta ao lado da cena e reconfigurar tudo para caminhos relativos. Faça isso e o trabalho fica autocontido. Salte esse passo e terá de re-renderizar. A mesma disciplina se aplica a texturas simples — qualquer elemento referenciado por um caminho local absoluto é um recurso em falta à espera de acontecer.

Pipeline de despacho de render farm do V-Ray 6, desde a exportação DCC até aos nós de renderização V-Ray Standalone

Envio. Empacote o projeto como .tar.gz ou .7z — os ficheiros .zip não são suportados para envio, por isso volte a empacotar antes de enviar um projeto comprimido em zip. Para cenas muito grandes, SFTP ou o cliente de secretária é mais estável do que um envio via browser. Os resultados de renderização ficam disponíveis durante 45 dias, por isso transfira os frames concluídos atempadamente ou deixe o cliente transferi-los automaticamente.

Uma lista de verificação pré-envio

A maioria das renderizações falhadas de render farm tem origem em quatro ou cinco causas repetíveis. Executar um único frame de teste na render farm antes de confirmar uma sequência de 2.000 frames demora poucos minutos e deteta quase todos os problemas. Eis a versão resumida que entregamos às pessoas:

Os custos seguem a mesma lógica por unidade em ambos os motores, o que torna a estimativa direta: a renderização em CPU é faturada a $0,004 por GHz-hora, e a renderização em GPU a $0,003 por OctaneBench-hora, com todas as licenças do motor de renderização já incluídas nessas tarifas. As novas contas começam com $25 de crédito de renderização gratuito para realizar exatamente o tipo de teste de frame único acima descrito, e os créditos não expiram. A análise completa está na página de preços, e se estiver a comparar fornecedores em vez de motores, a nossa comparação de render farms para V-Ray explica o que procurar.

FAQ

Q: Posso renderizar V-Ray 6 numa render farm na nuvem sem migrar para o V-Ray 7? A: Sim. As cenas de V-Ray 6 renderizam através do V-Ray Standalone a partir de um .vrscene exportado, e não existe qualquer requisito de migração para uma versão principal mais recente primeiro. Muitos pipelines de produção permanecem deliberadamente no V-Ray 6, e uma render farm renderiza a versão em que a cena foi construída e aprovada.

Q: Preciso de comprar a minha própria licença de V-Ray para renderizar na nuvem? A: Não. Na nossa render farm, a licença de renderização V-Ray está incluída na tarifa de renderização por unidade, pelo que não traz nem paga uma licença separada para renderizar. Esta é a diferença entre uma render farm totalmente gerida e um modelo de aluguer de infraestrutura, em que alugaria máquinas e forneceria as suas próprias licenças de software.

Q: V-Ray GPU ou V-Ray CPU — qual devo utilizar numa render farm? A: Utilize V-Ray GPU quando a geometria e as texturas da sua cena couberem na VRAM e pretender velocidade para interiores ou iteração; utilize V-Ray CPU quando a cena for grande e tiver muitas texturas ou necessitar do conjunto de funcionalidades mais maduro para entrega final. O CPU utiliza RAM do sistema em vez de VRAM, pelo que lida com cenas de visualização arquitetónica de grande dimensão que forçariam uma GPU a recorrer à paginação out-of-core mais lenta.

Q: Como evito o flicker de GI numa animação de V-Ray 6 renderizada em muitos nós? A: Utilize Brute Force GI com uma Light Cache por frame como predefinição — calcula a iluminação de forma independente para cada frame, pelo que os nós distribuídos nunca divergem. Reserve o método de Irradiance Map para flythroughs apenas de câmara com luzes e objetos estáticos, e certifique-se de que o mapa pré-computado se encontra num caminho partilhado acessível a todos os nós.

Q: Por que razão os meus recursos Chaos Cosmos estão em falta quando os frames regressam da render farm? A: Os recursos Cosmos são referenciados por caminhos locais que existem apenas na sua própria cache, pelo que os nós de renderização não os conseguem encontrar e os objetos renderizam a cinzento, em falta ou em branco sem qualquer erro explícito. Recolha e reconfigure todos os recursos numa pasta de projeto autocontida antes de submeter — as ferramentas de recolha de recursos do V-Ray fazem isso — para que a cena transporte tudo o que necessita.

Q: Posso renderizar uma cena de V-Ray para SketchUp na render farm? A: Sim, através de uma exportação. O SketchUp não é uma aplicação anfitrião que executamos, mas o V-Ray para SketchUp pode exportar um .vrscene que renderiza diretamente no V-Ray Standalone, ou pode importar o modelo para o 3ds Max e exportar a partir daí. A renderização acontece através da cena exportada de uma aplicação suportada, não dentro do SketchUp.

Q: Qual é a diferença entre uma render farm e o Distributed Rendering do V-Ray? A: Uma render farm distribui frames inteiros por muitas máquinas, que é o modelo eficiente para animações e sequências de imagens. O Distributed Rendering (DR) do V-Ray divide em vez disso os buckets de um único frame por máquinas em tempo real — útil para um único frame hero de grande dimensão, mas mais lento e menos robusto em grande escala, e não é assim que as sequências são renderizadas numa render farm.