Redshift Render Farm: Guia de Rendering na Cloud

O Redshift é um motor de rendering biased, acelerado por GPU — na nossa render farm, e em todas as render farms que conhecemos, funciona exclusivamente em hardware GPU, sem qualquer caminho de rendering em CPU. Os artistas recorrem a ele no Cinema 4D, Maya, 3ds Max e Houdini pelos mesmos três motivos: está construído em torno da placa gráfica, mantém-se previsível sob prazos apertados e vem integrado nas aplicações que a maioria dos pipelines de produção já utiliza. O Redshift também é um motor comum para planos de veículos e produtos; o nosso guia sobre render farm para rendering automóvel aborda esse tipo de trabalho numa render farm GPU.

Este guia é uma referência única para correr o Redshift numa render farm na cloud, seja qual for a aplicação, de entre as quatro mencionadas, em que constrói as suas cenas. Uma render farm não muda a forma como ilumina ou texturiza um frame; muda o que acontece quando avança para o rendering. Em vez de uma estação de trabalho a processar uma sequência durante toda a noite, várias máquinas GPU recebem os frames em paralelo e devolvem-nos numa fração do tempo real. As opções que realmente importam — VRAM, licenciamento, transferência de ficheiros e custo — são as mesmas quer a sua cena Redshift tenha começado no Cinema 4D quer no Houdini, e é exatamente por isso que ajuda tratar "Redshift numa farm" como um único tópico, em vez de quatro separados.

Fluxo de rendering na cloud com Redshift — Cinema 4D, Maya, 3ds Max e Houdini alimentam um único motor Redshift, depois as cenas são carregadas para uma frota de GPU que renderiza frames em paralelo para download

Por que razão o Redshift renderiza na GPU — e o que isso significa numa farm

O Redshift é, antes de mais, um renderizador GPU. Utiliza os caminhos CUDA e OptiX da placa gráfica para traçar raios, o que lhe confere a sensação interativa que os artistas lhe associam. Na nossa render farm, cada trabalho Redshift corre numa frota GPU dedicada, construída sobre placas NVIDIA RTX 5090 com 32 GB de VRAM cada. Correm o Redshift em modo GPU — é esse o caminho para o qual o nosso hardware está preparado, e vale a pena ser preciso quanto a isto, porque o Redshift, enquanto produto, também ganhou um modo de rendering em CPU na versão 3.5. Na nossa render farm, o Redshift funciona apenas em GPU; não existe aqui qualquer caminho de rendering em CPU para ele. Se ajustou uma cena para o backend de CPU, deve validá-la face ao resultado em GPU antes de avançar com uma sequência longa.

Esse desenho GPU-first é o que torna o Redshift naturalmente adequado ao rendering distribuído. Os frames são unidades de trabalho independentes, pelo que uma sequência que demora oito horas numa placa pode ser distribuída por várias placas e devolvida muito mais depressa. O papel de uma farm é manter essas placas ocupadas, resolver o licenciamento e entregar os frames — nada disto deve exigir que pense nas máquinas subjacentes.

Uma render farm também elimina o obstáculo GPU mais comum para artistas a solo: o número de placas. Localmente, renderiza com uma ou duas GPUs na sua torre. Numa render farm, a limitação passa de "quantas placas tenho" para "como empacoto a cena para que as placas a consigam ler" — um problema muito mais fácil de resolver, e que abordamos na secção de fluxo de trabalho abaixo. Se tem curiosidade sobre o que uma segunda (ou vigésima) placa realmente traz na prática, o nosso benchmark de escalabilidade multi-GPU mede diretamente os tempos de rendering com 1 GPU face a 2 GPUs, em vez de presumir uma escala linear.

Redshift em quatro aplicações: Cinema 4D, Maya, 3ds Max e Houdini

O Redshift comporta-se de forma consistente entre aplicações anfitriãs porque o motor é o mesmo; o que difere é o plugin de ligação e a forma como cada aplicação exporta os dados da cena. Suportamos o Redshift nas quatro DCCs onde os nossos clientes mais o utilizam:

• Cinema 4D. O Redshift está profundamente integrado aqui — é um produto Maxon, e o Cinema 4D é uma aplicação Maxon, pelo que o sistema de materiais, a vista de rendering e o sistema de takes parecem nativos. Este é o emparelhamento Redshift mais maduro que vemos, e é aquele com o maior histórico de cenas prontas para farm. Para uma análise específica ao Cinema 4D — incluindo especificidades do fluxo de trabalho de motion design que vão além do que este guia multi-DCC cobre — consulte o nosso guia de render farm Redshift para Cinema 4D.
• Maya. O Redshift para Maya é uma integração de longa data e comprovada em produção, com suporte total para as camadas de rendering do Maya, AOVs e o habitual fluxo de trabalho de materiais baseado em nós. As cenas referenciam texturas e caches através da estrutura de projeto do Maya, pelo que a principal consideração na farm é garantir que esses caminhos se resolvem depois de os ficheiros saírem da sua máquina.
• 3ds Max. A integração com o 3ds Max cobre as definições do renderizador, o editor de materiais e os render elements esperados. O Redshift é aqui frequentemente utilizado juntamente com plugins de scatter e de proxy, pelo que os proxies e as referências externas são o que deve ser empacotado com cuidado.
• Houdini. O Redshift no Houdini é a opção GPU que muitos artistas associam a trabalho pesado de simulação e instancing, ao lado do Karma e do Mantra. Se o seu pipeline é centrado no Houdini, a nossa página render farm na cloud para Houdini cobre o panorama mais amplo do motor para essa aplicação.

Nas quatro, a licença do motor de rendering está incluída no que paga para renderizar — não lhe é pedido que traga a sua própria licença de Redshift. Como parceiro oficial Maxon, licenciamos o Redshift (e o resto da linha Maxon) para uso em rendering na farm, o que permite que o motor esteja disponível em todas as aplicações suportadas sem qualquer configuração da sua parte. Pode confirmar esse estatuto de parceiro diretamente no diretório de parceiros da Maxon.

Cinema 4D, Maya, 3ds Max e Houdini a alimentar um único motor Redshift numa render farm GPU, com a licença Redshift incluída na tarifa de rendering

VRAM, out-of-core e cenas grandes

Para o rendering em GPU, a VRAM é o número que decide se uma cena renderiza sem problemas ou bloqueia. O Redshift carrega geometria, texturas e outros dados da cena para a memória da placa; quando a cena cabe, a placa trabalha a ritmo máximo. A nossa frota GPU dá a cada trabalho Redshift 32 GB de VRAM para trabalhar numa NVIDIA RTX 5090, o que cobre uma vasta gama de cenas de produção sem tratamento especial.

Quando os dados de uma cena excedem a VRAM disponível, o Redshift não falha simplesmente — recorre à sua tecnologia out-of-core, transferindo texturas e geometria da memória do sistema à medida que a placa precisa delas. Esta é a resposta honesta a "e a minha cena pesada": o Redshift consegue renderizar cenas maiores do que a VRAM através do out-of-core, com algum custo de desempenho, porque a placa tem de aceder a memória mais lenta. É uma técnica GPU, não uma transferência para um renderizador de CPU — o frame continua a ser calculado na RTX 5090, apenas com acesso à memória mais lento para a parte que não cabe nos 32 GB da placa. Na prática, a forma de manter uma cena Redshift pesada rápida é reduzir primeiro a pressão desnecessária sobre a VRAM — tamanhos de textura sensatos, proxies para geometria repetida e cortar o que não está realmente em plano — e deixar que o out-of-core absorva o resto.

Se está a ponderar se os 32 GB da RTX 5090 são margem suficiente para o seu trabalho específico, o nosso artigo sobre desempenho de rendering na cloud com RTX 5090 percorre o comportamento da placa em cenas reais, e o nosso benchmark de escalabilidade multi-GPU mostra o que adicionar uma segunda placa realmente faz ao tempo real numa cena comparável.

Gráfico do uso de VRAM a subir com a complexidade da cena, cruzando a linha dos 32 GB da RTX 5090 onde o out-of-core do Redshift entra em ação e continua a renderizar na GPU com algum custo de desempenho

Totalmente gerida vs. alugar uma máquina GPU por conta própria

Existem duas formas amplas de renderizar Redshift na cloud, e a diferença importa mais do que a especificação de hardware.

A primeira é o aluguer de infraestrutura, em que se aluga uma máquina GPU remota, se liga a ela por ambiente de trabalho remoto, se instala o Redshift e a aplicação anfitriã, se trata do licenciamento, se copiam os ficheiros e se gere o rendering. Obtém uma máquina nua e controlo total, juntamente com toda a configuração e manutenção que isso implica.

A segunda é uma render farm totalmente gerida, que é como operamos. Carrega a sua cena, o motor e as licenças já estão em vigor, os frames são distribuídos pela frota GPU — placas RTX 5090, 32 GB de VRAM cada — por conta da farm, e recolhe o resultado. Não há ambiente de trabalho remoto onde iniciar sessão, nada para instalar e nenhuma licença para ativar. Para um artista Redshift, isto remove as partes do rendering na cloud que nada têm a ver com criar imagens — e é a principal diferença entre uma render farm gerida e os aluguéis de GPU em infraestrutura-como-serviço que possa já ter utilizado. A nossa página render farm Redshift na cloud é o local certo para indicar a um colega que queira a versão curta.

O modelo mais indicado depende do controlo que precisa sobre o ambiente. Se tem uma cadeia de plugins pouco comum ou uma configuração personalizada, uma máquina em bruto pode ser a ferramenta certa. Para a maioria do trabalho com Redshift — uma aplicação anfitriã padrão, o motor e a cena — uma render farm gerida devolve os frames com muito menos sobrecarga.

Quanto custa renderizar Redshift numa farm

O rendering em GPU na nossa render farm é faturado por utilização, e não por um plano mensal. A unidade é a OctaneBench-hour (OBh) — uma medida do trabalho de GPU realizado — cobrada a uma tarifa base de 0,003 $ por OBh. Na prática, uma placa RTX 5090 traduz-se em cerca de 5,20 $ por hora-placa de rendering. Paga apenas pelo tempo de GPU que os seus frames realmente consomem, não por um lugar ou por um nível de subscrição.

A mesma faturação por hora de GPU aplica-se aos trabalhos Octane; o nosso guia Octane render farm na cloud cobre a forma como as cenas Octane correm na frota.

Alguns pontos específicos que costumam surgir:

• O licenciamento está incluído. A licença Redshift faz parte da tarifa de rendering. O mesmo se aplica aos restantes motores que disponibilizamos — não há linha de licença separada a orçamentar.
• Os créditos não expiram. Carrega um saldo de créditos e gasta-o em trabalhos; os créditos pagos mantêm-se válidos para quando forem necessários. As novas contas também começam com 25 $ em crédito de avaliação, para dimensionar um trabalho real antes de se comprometerem com uma sequência.
• Sem níveis. Todas as contas renderizam à mesma tarifa baseada em utilização. Não há plano a escolher nem funcionalidade bloqueada atrás de um nível superior.

Para estimar um trabalho, considere o tempo que um frame precisa numa placa comparável, multiplique pelo número de frames e aplique o valor de hora-placa — distribuído pela frota, o tempo real diminui, mas as horas de GPU faturadas mantêm-se aproximadamente iguais ao trabalho total realizado. Renderizar um plano de 10 segundos a 24 fps são 240 frames; se cada frame demorar quatro minutos numa placa, são cerca de 16 horas-placa de trabalho, ou na ordem dos 83 $ à tarifa prática — devolvido numa pequena fração desse tempo real, porque os frames correm em paralelo em várias placas RTX 5090, em vez de aguardarem numa só.

Exemplo de custo calculado para um plano de 240 frames: as horas-placa faturadas são as mesmas numa única placa GPU e numa render farm de 24 placas, mas o tempo real da farm é muito mais curto

Escolher o Redshift, ou outro motor, para o trabalho

O Redshift é uma boa escolha quando se quer velocidade de GPU com a controlabilidade de um renderizador biased, e quando a sua aplicação anfitriã é uma das quatro acima. Não é a única opção, e parte de escolher bem é saber onde se posiciona face às alternativas.

• Face ao Arnold, a troca é a velocidade e interatividade biased-GPU do Redshift face à reputação do Arnold por um resultado unbiased e fisicamente fundamentado, tanto em CPU como em GPU. Comparamos os dois para trabalho em farm em Arnold vs. Redshift numa render farm.
• Face ao Octane, ambos são motores GPU com filosofias de shading e suporte de aplicações anfitriãs diferentes. A nossa comparação Octane vs. Redshift detalha as diferenças na prática.
• Face ao Cycles, o motor integrado do Blender, a comparação tem menos a ver com GPU-apenas vs. CPU-apenas e mais com o ecossistema — o Cycles corre tanto em CPU como em GPU, consoante as necessidades da cena, enquanto o Redshift na nossa render farm funciona apenas em GPU nas quatro DCCs suportadas.

Uma render farm não o prende a um único motor — o mesmo modelo de carregar e renderizar aplica-se aos restantes motores que disponibilizamos — pelo que a escolha do motor pode manter-se uma decisão criativa e de pipeline, e não de alojamento.

O fluxo de trabalho de upload, rendering e download

Colocar uma cena Redshift na farm segue os mesmos três passos, seja qual for a aplicação anfitriã.

Upload. Empacote a sua cena com os respetivos recursos — texturas, proxies, caches e referências. O upload pela web não tem limite de tamanho rígido, embora sugiramos manter cada upload abaixo de cerca de 300 GB; para algo maior, o SFTP ou a nossa aplicação cliente oferece uma transferência retomável e paralela. Os formatos de ficheiro suportados são tar, tar.gz e 7z; o .zip não é suportado, pelo que deve reempacotar ou transferir os ficheiros sem compressão, caso seja essa a única opção. A causa mais comum de um trabalho GPU bloqueado é um caminho de recurso que se resolvia na sua estação de trabalho mas não depois de os ficheiros serem movidos, por isso reúna ou volte a associar as referências externas antes de fazer o upload.

Rendering. Submeta o trabalho e os frames são distribuídos pela frota GPU. Como os trabalhos Redshift são apenas GPU aqui, cada frame é processado numa RTX 5090 com os seus 32 GB de VRAM, e o out-of-core cobre as cenas que precisam de mais.

Download. Os frames concluídos ficam disponíveis para recolha pela web, por SFTP ou automaticamente através da aplicação cliente. O resultado é mantido durante 45 dias após a conclusão de um trabalho, findos os quais é eliminado — por isso faça o download prontamente ou deixe a aplicação cliente fazer o download automático para o seu armazenamento local.

Uma lista de verificação curta antes de enviar um trabalho Redshift

Percorrer esta lista demora poucos minutos e elimina quase todas as razões evitáveis para um trabalho voltar mal.

FAQ

Q: O Redshift é apenas GPU numa render farm? A: Na nossa render farm, sim — todos os trabalhos Redshift correm na GPU, especificamente em placas NVIDIA RTX 5090 com 32 GB de VRAM cada, sem qualquer caminho de rendering em CPU. O Redshift, enquanto produto, adicionou um modo de CPU a partir da versão 3.5, mas esse modo não é o que corre aqui; o nosso hardware e pipeline estão preparados para rendering Redshift apenas em GPU. Se ajustou uma cena face ao backend de CPU noutro local, valide-a face ao resultado em GPU antes de se comprometer com uma sequência completa.

Q: Quanto custa uma render farm Redshift? A: Na nossa render farm, o rendering em GPU é faturado por utilização a 0,003 $ por OctaneBench-hour, o que se traduz em cerca de 5,20 $ por hora-placa RTX 5090. A licença Redshift está incluída nessa tarifa — não há taxa de licença separada — e os créditos nunca expiram. As novas contas começam com 25 $ em crédito de avaliação, suficiente para dimensionar um trabalho real antes de se comprometerem com um rendering completo.

Q: A farm renderiza o Redshift na GPU ou na CPU? A: Apenas na GPU. Os nossos trabalhos Redshift correm numa frota dedicada de NVIDIA RTX 5090 com 32 GB de VRAM por placa. O Redshift, enquanto produto, adicionou um modo de CPU na versão 3.5, mas na nossa render farm não existe qualquer caminho de rendering em CPU para o Redshift — se ajustou uma cena para o backend de CPU, valide-a primeiro face ao resultado em GPU.

Q: A partir de que aplicações posso renderizar Redshift? A: Cinema 4D, Maya, 3ds Max e Houdini. O motor é o mesmo nas quatro, apenas o plugin de ligação e a exportação da cena da aplicação anfitriã diferem. A licença Redshift está incluída na tarifa de rendering em todos os casos.

Q: O que acontece se a minha cena for maior do que 32 GB de VRAM? A: O Redshift utiliza a tecnologia out-of-core para transferir texturas e geometria da memória do sistema quando uma cena excede a VRAM disponível. A cena continua a renderizar na GPU, com algum custo de desempenho. Reduzir os tamanhos de textura e utilizar proxies mantém mais da cena residente na VRAM e rápida.

Q: Preciso da minha própria licença de Redshift? A: Não. A licença Redshift está incluída no que paga para renderizar. Como parceiro oficial Maxon, licenciamos o Redshift para uso em rendering na farm, pelo que está disponível em todas as aplicações suportadas, sem nada a ativar da sua parte.

Q: Como é o preço do rendering Redshift no dia a dia, e existem níveis? A: Não há níveis de plano — todas as contas renderizam à mesma tarifa baseada em utilização descrita acima. O licenciamento está incluído nessa tarifa para todos os motores que disponibilizamos, não apenas para o Redshift, pelo que não há linha separada a orçamentar, seja qual for a aplicação, de entre as quatro suportadas, a partir da qual renderize.

Q: Como coloco a minha cena na farm, e durante quanto tempo os meus frames ficam guardados depois? A: Faça o upload da cena empacotada pela web (sem limite de tamanho rígido; sugerimos abaixo de cerca de 300 GB por upload), ou utilize o SFTP ou a aplicação cliente para transferências maiores ou retomáveis. Utilize ficheiros tar, tar.gz ou 7z — o .zip não é suportado — e reúna ou reassocie os recursos externos antes do upload, para que os caminhos se resolvam na farm. Após os frames serem renderizados, o resultado é mantido durante 45 dias após a conclusão do trabalho, sendo depois eliminado automaticamente — faça o download pela web, por SFTP ou através do download automático da aplicação cliente antes disso, ou configure o download automático para manter uma cópia local.