VFX Compositing e Renderização na Nuvem: Porque os Renders de Compositing São uma Carga de Trabalho Diferente do 3D

Introdução

A maior parte do conteúdo sobre renderização na nuvem é escrita para um único tipo de carga de trabalho: uma cena 3D a passar por um path tracer, bucket a bucket, até o ruído desaparecer e o frame ficar pronto. Esse enquadramento é preciso para um job de Redshift ou V-Ray, e é praticamente inútil para um render de compositing. Um comp não está a fazer sampling de percursos de luz. Está a avaliar um node graph em relação a footage e passes que já existem, e aquilo que determina quanto tempo demora e quanto custa quase nunca é a contagem de samples da GPU.

Essa distinção importa mais do que parece à superfície, porque as duas cargas de trabalho são constantemente misturadas em conselhos genéricos sobre "renderização na nuvem". Um compositor que move um script de Nuke ou um projeto de After Effects para uma farm pela primeira vez, esperando o mesmo comportamento dependente de GPU de um render 3D, acaba confuso quanto ao motivo pelo qual um comp sem simulações e sem ray tracing continua lento, ou porque é rápido de uma forma que nada tem a ver com o tier de GPU escolhido. Este guia é sobre essa lacuna: o que um render de compositing realmente faz numa farm, em que difere mecanicamente de um render 3D, e quando é que vale a pena mover trabalho de compositing para a nuvem em vez de deixar uma workstation a correr durante a noite.

Trabalhamos diariamente com os dois lados deste pipeline na nossa farm, na Super Renders Farm, desde o render 3D que produz o beauty pass e os AOVs até ao render de compositing que os monta num shot final. As duas fases partilham hardware, mas pouco mais em termos de comportamento de render, e perceber essa diferença é o que torna um job de render de compositing previsível em vez de um mistério.

Diagrama de pipeline que mostra o fluxo de compositing com EXR multi-pass: os passes de render 3D combinam-se num ficheiro EXR multicamada, que depois passa para o software de compositing e para a grade final

O Compositing É uma Carga de Trabalho de Renderização Diferente da Renderização 3D

Um motor de renderização 3D como o V-Ray, o Redshift ou o Arnold faz transporte de luz: traça raios, faz sampling de materiais e acumula redução de ruído ao longo do tempo até a imagem convergir. Esse trabalho é genuinamente intensivo em computação por pixel, razão pela qual a renderização 3D é intensiva em CPU ou em GPU consoante o motor, e razão pela qual a aceleração por GPU tem um efeito tão grande nos tempos de renderização 3D.

Um render de compositing não faz nada disso. O Nuke, o After Effects, o Fusion e ferramentas semelhantes avaliam um node graph: leem uma imagem, aplicam uma correção de cor, fazem merge de duas layers, aplicam uma transformação, escrevem o resultado. Não há sampling nem convergência. Cada operação é uma passagem determinística, na maior parte álgebra linear, sobre dados de pixel, e a maioria dessas operações (merges, grades, keyers, transforms, a maioria dos filtros) corre na CPU em vez de na GPU. Um pequeno número de tipos de node específicos (retimes pesados, algumas operações de denoise, certas ferramentas de machine learning) é acelerado por GPU, mas são a exceção num comp típico, não a regra.

Aquilo que realmente determina quanto tempo um render de compositing demora está mais próximo de um problema de movimentação de dados do que de um problema de computação:

• Throughput de leitura. Um script de comp lê footage e passes de render, muitas vezes várias sequências EXR multicamada em simultâneo, para cada frame.
• Threading de CPU. As operações de compositing paralelizam entre núcleos de CPU dentro de um único frame, e o render manager paraleliza entre frames, distribuindo blocos do frame range por diferentes workers.
• Memória. Manter vários frames multi-channel em resolução total na memória ao mesmo tempo (um beauty pass, um punhado de AOVs, uma matte de cryptomatte, talvez um deep pass) consome muito mais memória do que parece, e ficar sem RAM a meio de um frame é uma causa de falha de render de compositing mais comum do que a velocidade pura da CPU.
• Throughput de escrita. O frame final composto, ou um precomp intermédio, tem de ser escrito de volta, e para deliverables de pipeline de VFX esse output é normalmente outra sequência EXR, e não um único ficheiro de vídeo.

Nada disto é uma crítica ao software de compositing. É um tipo diferente de carga de trabalho, construído à volta de mover e combinar dados de imagem já existentes em vez de os gerar do zero, e uma render farm que trata um job de comp como um render 3D, alocando capacidade pesada de GPU e poupando em RAM e throughput de storage, vai ter um desempenho fraco exatamente nas máquinas que deveriam lidar bem com o job.

O Que um Render de Compositing Realmente Lê e Escreve

É na forma dos inputs e outputs de um job de compositing que a diferença em relação à renderização 3D se torna mais concreta.

EXR multicamada e multi-pass à entrada. Um comp normalmente abre um ou mais ficheiros OpenEXR por frame que já transportam muitos channels: um beauty render, passes separados de diffuse e specular, AOVs de iluminação, um pass de Z-depth, motion vectors, e mattes de cryptomatte para isolamento de object, material e asset ID, tudo num único ficheiro lido através de um Read node e separado com Shuffle nodes para trabalho por pass. Ler esse ficheiro não é um acesso pequeno a um ficheiro; é puxar todos os channels que um frame transporta, mesmo que um dado comp só use alguns deles, razão pela qual a largura de banda de leitura de storage é um gargalo real em nós de farm intensivos em comp, de uma forma que raramente acontece num render 3D, que está a escrever, não a ler, a maior parte dos seus dados EXR.

Cryptomatte como input, não como output. Os dados de cryptomatte (mattes de ID geradas proceduralmente que permitem a um compositor isolar objetos, materiais ou instâncias de asset individuais a posteriori, sem voltar a renderizar) são escritos pelo render 3D e consumidos pelo comp. Isto significa que um job de compositing numa farm herda quaisquer channels de cryptomatte que o render 3D a montante tenha produzido, e um comp que depende de isolamento por cryptomatte está a ler mais channels por frame do que um que não depende. O nosso guia sobre EXR-IO e cryptomatte explica como esses dados estão estruturados e como trabalhar com eles de forma eficiente, o que vale a pena ler antes de enviar um comp pesado em cryptomatte para qualquer farm.

Um pequeno número de outputs, em alta profundidade de bits. Onde um render 3D escreve frequentemente vários passes por frame, um render de compositing normalmente reduz esses passes a um, ou a um pequeno número, de outputs finais compostos, geralmente EXR 16-bit half-float para deliverables HDR lineares que seguem mais à frente no pipeline de VFX, ocasionalmente 32-bit para data passes que precisam de precisão total. O output é menor em número de channels do que o input, mas continua a ser um frame em resolução total, e para um job de deep compositing (que mantém múltiplas amostras de profundidade por pixel para resolver holdouts sem voltar a renderizar a cena 3D) tanto a leitura como a escrita ficam consideravelmente mais pesadas.

Os encodes de vídeo são um passo separado, não o próprio render. Quando o deliverable final é H.264 ou HEVC em vez de uma sequência de imagens, esse encode acontece geralmente como um passe distinto após o render de compositing frame a frame, e não como parte dele, porque os codecs de vídeo não são facilmente divisíveis entre workers da mesma forma que uma sequência de imagens independente. O nosso guia de encoding H.264 vs H.265 explora esses trade-offs desse passo final com mais detalhe.

Seis passes de render (beauty, diffuse, specular, cryptomatte, depth, ambient occlusion) a convergir para um único ficheiro EXR multicamada

Como os Renders de Compositing se Distribuem numa Render Farm na Nuvem

O modelo de distribuição para trabalho de compositing está mais próximo do do Nuke do que do de um motor de renderização 3D, e vale a pena ser preciso sobre o porquê.

Um motor de renderização 3D pode dividir um único frame espacialmente: buckets ou tiles distribuídos por diferentes threads ou máquinas, porque os pixels numa região genuinamente não dependem dos pixels noutra. Um comp geralmente não pode ser dividido dessa forma. O valor de um pixel no frame N depende dos inputs desse frame a passar por toda a node tree, o que torna a maior parte do trabalho de compositing embaraçosamente paralelo por frame, não por região da imagem. Um render manager não subdivide um frame de comp; subdivide o frame range, distribuindo blocos de frames por diferentes workers, cada um a correr a sua própria instância da aplicação de compositing em modo headless (sem GUI) para a sua fatia.

É esse o modelo que o nosso guia de render farm na nuvem para Nuke explica em detalhe especificamente para o Nuke, incluindo as flags exatas de linha de comandos e a mecânica de licenciamento. O After Effects comporta-se de forma semelhante na maioria dos comps de produção (title sequences, motion graphics, reveals de archviz), mas com uma ressalva que vale a pena assinalar aqui: composições de AE que dependem de estado temporal entre frames (motion blur com sampling entre frames, simulações de partículas que acumulam, algumas operações de tracking) não são limpamente paralelas por frame, e dividi-las ingenuamente entre workers pode produzir seams visíveis nas fronteiras dos blocos. O nosso guia de configuração de renderização na nuvem para After Effects explica quais os workflows de AE que paralelizam de forma limpa e quais precisam, em vez disso, de um passe num único worker.

A forma prática de um job de render de compositing numa farm é a seguinte: o script ou projeto, mais tudo o que referencia, sobe como um bundle autocontido; o render manager divide o frame range total em blocos; cada worker recebe o seu bloco, resolve os mesmos caminhos de footage, color config, fontes e dependências de plugins que a máquina do artista tinha, e renderiza em modo headless; os frames terminados chegam a storage partilhado ou na nuvem à medida que cada bloco termina, pelo que uma sequência longa pode começar a devolver output utilizável bem antes de o último worker terminar.

Problemas Comuns no Compositing na Nuvem

A grande maioria dos renders de compositing que falham ou voltam errados numa farm não são problemas de matemática de compositing. São problemas de dependências e de ambiente que uma workstation local mascarava silenciosamente.

Nada disto é exclusivo de uma aplicação. É a forma geral do que se parte quando um script de compositing sai da máquina onde foi criado, e é por isso que "testar em pequeno antes de submeter a sequência completa" (renderizar primeiro um punhado de frames, comparar com o resultado local) é um passo de segurança de baixo custo que vale a pena dar em qualquer render de compositing, em qualquer farm.

Quando a Renderização na Nuvem Realmente Ajuda um Pipeline de Compositing

Nem todos os comps precisam de uma farm. Uma sequência curta que renderiza localmente em poucos minutos ganha pouco com o overhead de upload e fila de espera de passar para a nuvem. O compositing na nuvem justifica-se num conjunto específico de situações:

Picos orientados por deadline. Um deliverable com prazo em horas, não em dias, em que o número de frames e a complexidade ocupariam uma workstation durante mais tempo do que o deadline permite. Distribuir uma sequência de 1.000 frames por dezenas de workers transforma um render noturno em algo que pode voltar em uma ou duas horas, porque o throughput escala quase linearmente com o número de workers disponíveis.

Trabalho em lote noturno que de outra forma bloquearia um artista. Mesmo sem uma pressão de deadline rígida, um comp que ocuparia a máquina do próprio artista durante várias horas é tempo em que esse artista não pode iterar, rever ou trabalhar no shot seguinte. Enviá-lo para uma farm liberta a workstation de imediato, em vez de esperar que um render local termine.

Sequências grandes com muitos dados por frame. Deep compositing, EXR multi-channel em 4K ou superior, e comps pesados em cryptomatte são exatamente as cargas de trabalho onde o tempo de render por frame mais se acumula, e onde distribuir por muitos workers intensivos em CPU compensa mais do que compensaria para um comp leve, com poucos channels.

Pipelines mistos de 3D e comp que já usam uma farm. Se o render 3D de um shot já corre numa render farm na nuvem, manter a fase de compositing na mesma infraestrutura evita uma viagem de ida e volta a uma máquina local entre as duas fases, e mantém os passes (beauty, AOVs, cryptomatte) perto de onde o comp os vai ler.

Onde o compositing na nuvem menos se justifica: um punhado de comps curtos e simples, sem pressão de deadline, em que o tempo de render local já está bem abaixo do tempo que demora a preparar e a fazer upload de um bundle de projeto autocontido. O overhead de upload e de auditoria de dependências é real, e para um job pequeno pode exceder o tempo poupado.

Custo: Quanto Custa Realmente um Job de Render de Compositing

Como o compositing é uma carga de trabalho limitada por CPU e memória na grande maioria dos nodes de um comp típico, é geralmente a tarifa de CPU que determina o custo, aplicando-se a tarifa de GPU apenas aos nodes específicos (retimes pesados, algum denoise, ferramentas de machine learning) que realmente usam aceleração por GPU.

Na nossa farm, a computação de CPU é faturada por GHz-hour, com uma tarifa base de $0,004/GHz-hr (os tiers de prioridade variam entre $0,004 e $0,016/GHz-hr consoante a prioridade na fila), e a computação de GPU é faturada por OctaneBench-hour (OBh) com uma tarifa base de $0,003/OBh, sendo que uma placa RTX 5090 (32 GB VRAM) ronda os $5,2/card-hour em utilização total. Os render credits não expiram, e não existe um mínimo de aluguer de máquina, pelo que um job de compositing é faturado pela computação que realmente consome, e não por um bloco de tempo reservado.

Para tornar isto concreto com um exemplo ilustrativo (não uma referência de benchmark, já que o tempo de render real por frame varia imenso consoante a resolução, o número de channels e a complexidade dos nodes): um lote de compositing que consome 5.000 GHz-hours de computação de CPU agregada, uma ordem de grandeza plausível para uma sequência 4K de vários milhares de frames distribuída por dezenas de workers durante a noite, custa aproximadamente $20 em computação à tarifa base, antes de qualquer multiplicador de tier de prioridade. Se parte desse mesmo job depender de nodes acelerados por GPU, essa fatia é faturada separadamente à tarifa OBh, e não à tarifa GHz-hour. O mecanismo que importa para orçamentação é simples, mesmo quando os números exatos variam de job para job: o custo acompanha a computação total consumida, não o tempo de relógio do render, pelo que distribuir um job por mais workers para terminar mais depressa não muda, por si só, quanto custa.

Renderização de Compositing vs Renderização 3D: Lado a Lado

Onde o Compositing se Encaixa num Pipeline de Renderização na Nuvem Mais Amplo

O compositing é normalmente a última fase de uma cadeia que começa com um render 3D, e tratar as duas fases com os mesmos pressupostos sobre hardware e gargalos é o erro mais comum que vemos em tickets de suporte de equipas novas em compositing na nuvem. Se o seu pipeline é inteiramente do lado 3D e ainda não percebeu o modelo de serviço mais amplo, o nosso guia sobre o que é uma render farm na nuvem e o nosso guia de renderização na nuvem para VFX e visualização de produto cobrem esse terreno. Para a fase de compositing especificamente, o guia de renderização na nuvem para Nuke e o guia de configuração de renderização na nuvem para After Effects cobrem a mecânica específica de cada aplicação (licenciamento, flags de submissão, matrizes de plugins) que este artigo deliberadamente manteve geral. Do lado do After Effects, a nossa página After Effects cloud render farm cobre diretamente o workflow suportado e os preços.

Como referência canónica sobre o formato de ficheiro subjacente à maioria dos pipelines de VFX compositing, o projeto OpenEXR documenta o formato multi-channel e multi-part que a maioria dos renders de compositing lê e escreve, e a especificação Cryptomatte documenta como os dados de ID matte são codificados nesses ficheiros.

FAQ

Q: A renderização de compositing é a mesma coisa que a renderização 3D numa render farm na nuvem? A: Não. Um render 3D faz transporte de luz, fazendo sampling e traçando raios até a imagem convergir, e esse trabalho é genuinamente intensivo em computação por pixel. Um render de compositing avalia um node graph sobre dados de imagem que já existem (footage, passes de render) e é dominado por threading de CPU, capacidade de memória e I/O de storage, em vez de sampling. As duas cargas de trabalho partilham o hardware da farm, mas têm gargalos e modos de falha diferentes.

Q: Porque é que o compositing é mais limitado por I/O do que a renderização 3D? A: Um comp normalmente lê um ou mais ficheiros EXR multicamada e multi-pass por frame, puxando todos os channels que um ficheiro transporta (beauty, AOVs, mattes de cryptomatte, depth), e mantém vários desses frames em resolução total em memória ao mesmo tempo enquanto avalia o node graph. Esse volume de leitura, combinado com a escrita de volta do frame composto, torna o throughput de storage e a capacidade de RAM um fator mais importante no tempo de render do comp do que a velocidade de computação pura, para a maioria dos nodes de um comp típico.

Q: Uma render farm de compositing precisa de nodes de GPU? A: Para a maioria dos comps, não. A maioria das operações de compositing (merges, grades, keyers, transforms, a maioria dos filtros) corre na CPU. Um conjunto mais pequeno e específico de tipos de node (retimes pesados, algumas operações de denoise, ferramentas de machine learning) é acelerado por GPU, e os comps que dependem fortemente desses nodes beneficiam de capacidade de GPU. Para um comp típico, dominado por merges e grades, os núcleos de CPU e a RAM importam mais do que o tier de GPU.

Q: O que é o cryptomatte e porque é que importa para o compositing na nuvem? A: O cryptomatte é dados de ID matte gerados proceduralmente, escritos por um render 3D, que permitem a um compositor isolar objetos, materiais ou instâncias de asset individuais a posteriori, sem voltar a renderizar a cena 3D. Num job de compositing na nuvem, os dados de cryptomatte são um input que o comp lê, e não algo que o render de compositing gera, e os comps pesados em cryptomatte leem mais channels por frame, o que aumenta a carga de I/O e de memória no nó de render.

Q: Os comps de Nuke e de After Effects podem renderizar ambos na mesma render farm na nuvem? A: Sim, numa farm que suporte ambas as aplicações, embora o modelo de distribuição varie ligeiramente. Os comps de Nuke são quase sempre paralelos por frame por design (cada frame é totalmente autocontido). Os comps de After Effects são paralelos por frame na maioria dos casos de produção, mas composições que dependem de estado temporal entre frames, como certas configurações de motion blur ou de simulação de partículas, precisam de renderização num único worker em vez de distribuição por frame range, para evitar seams. Os nossos guias de Nuke e After Effects cobrem a mecânica específica de cada aplicação.

Q: Quando é que faz sentido enviar um job de compositing para uma render farm na nuvem em vez de renderizar localmente? A: O compositing na nuvem compensa mais em picos orientados por deadline, trabalho em lote noturno que de outra forma ocuparia a workstation de um artista, e sequências grandes ou pesadas por frame (deep compositing, EXR multi-channel em 4K ou superior, comps pesados em cryptomatte). Compensa menos num punhado de comps curtos e simples, sem pressão de deadline, em que o tempo de render local já é mais curto do que o tempo necessário para preparar um bundle de projeto autocontido para upload.

Q: Como é faturada a renderização de compositing numa render farm na nuvem? A: Na nossa farm, a computação de CPU (que determina o custo para a maioria do trabalho de compositing) é faturada por GHz-hour, com uma tarifa base de $0,004/GHz-hr, com tiers de prioridade até $0,016/GHz-hr. Os nodes acelerados por GPU são faturados separadamente por OctaneBench-hour, com uma tarifa base de $0,003/OBh. O custo acompanha a computação total consumida, não o tempo de relógio, pelo que distribuir um job por mais workers para terminar mais depressa não muda, por si só, o custo total.

Q: Que formatos de ficheiro uma render farm de compositing normalmente processa? A: O OpenEXR multicamada e multi-part é o padrão para input e output no pipeline de VFX, transportando beauty passes, AOVs, mattes de cryptomatte e dados de depth em 16-bit half-float (ou 32-bit para data passes que precisam de precisão total). Quando o deliverable final é um ficheiro de vídeo (H.264, HEVC, ProRes) em vez de uma sequência de imagens, esse encode normalmente corre como um passe separado após o render de compositing frame a frame, já que os codecs de vídeo geralmente não são divisíveis entre workers da mesma forma que uma sequência de imagens independente. O nosso guia H.264 vs H.265 cobre esse passo final de encoding.