Renderização de Cenas Maya com USD numa Render Farm

O Universal Scene Description passou de um formato interno da Pixar para a espinha dorsal de muitas pipelines Maya. Se o estúdio compõe planos a partir de camadas de estágios USD, referencia ativos publicados entre departamentos e entrega o resultado ao motor de renderização através de um procedural, já sabe que o USD deixou de ser uma experiência marginal — é a estrutura central da cena. O que é menos óbvio, até que um prazo esteja em jogo, é que uma cena renderizada perfeitamente numa estação de trabalho não garante que seja renderizada na render farm de outra pessoa. A render farm tem de ter a compilação correta do MayaUSD, o suporte USD correto no motor de renderização e uma forma de resolver todos os caminhos de ativos para os quais o estágio aponta. Quando um desses elementos está em falta, não se obtém um erro claro — obtêm-se frames falhados, fallbacks silenciosos ou geometria que simplesmente não aparece.

Gerimos uma render farm gerida, e os trabalhos Maya com USD são um dos fluxos de trabalho que vemos os estúdios com mais dificuldade em mover das suas estações de trabalho. Este guia explica por que razão o USD é mais difícil de renderizar remotamente do que um ficheiro .ma autossuficiente, o que realmente tem de estar alinhado para funcionar, e como tratamos disso do nosso lado — incluindo as partes que é fácil errar.

Pipeline de renderização Maya USD: estágios USD em camadas para o plugin MayaUSD, para o Arnold USD procedural, para os frames renderizados, com resolução de ativos e correspondência de ambiente.

Por que razão o USD é mais difícil de renderizar remotamente do que uma cena autossuficiente

Uma cena Maya tradicional é amplamente autodescritiva: abre-se, as malhas e os materiais estão lá, aponta-se o motor de renderização para ela e os frames saem. Uma cena orientada por USD é mais uma receita do que um prato acabado. Os ficheiros .usd, .usda ou .usdc são um conjunto de instruções em camadas — sublayers, referências, payloads e variantes — que compõem num estágio final no momento do carregamento. Essa composição é poderosa, mas significa que três elementos distintos têm de estar presentes e compatíveis na máquina que os renderiza.

O primeiro é o próprio plugin MayaUSD. O MayaUSD é a ponte que permite ao Maya ler, compor e passar estágios USD para a renderização. Se o Maya da render farm não tiver o MayaUSD carregado, ou tiver uma versão que compõe o estágio de forma diferente daquela com que os artistas trabalharam, a cena falha ao abrir ou abre sem as partes que entraram através do USD.

O segundo é a resolução de caminhos de ativos. Um estágio USD referencia outros ficheiros — geometria, texturas, camadas USD aninhadas — por caminho. Na estação de trabalho, esses caminhos resolvem porque os dados estão onde o estágio os espera. Numa render farm, a menos que a mesma estrutura de diretórios e o mesmo comportamento de resolução sejam reproduzidos, metade dessas referências resolve para nada. Esta é a razão mais comum pela qual uma cena USD que "funciona em casa" volta vazia da render farm: os pixels renderizaram bem, as referências simplesmente não foram encontradas.

O terceiro é o suporte USD do motor de renderização. O motor de renderização tem de compreender os dados USD que o Maya lhe entrega. Para o Arnold, esse caminho passa pelo Arnold USD procedural, que lê o conteúdo USD no momento da renderização em vez de expandir todo o estágio no Maya primeiro. Se o procedural não estiver instalado, ou a sua versão não corresponder aos dados, o motor de renderização ignora o que não consegue ler — silenciosamente.

É também aqui que a lacuna bem documentada em alguns serviços de renderização na nuvem se manifesta. O próprio rastreador do Deadline Cloud da AWS para Maya tem um problema em aberto (aws-deadline/deadline-cloud-for-maya#409) relacionado com o suporte MayaUSD no submissor, que é exatamente o tipo de infraestrutura que tem de ser resolvida de ponta a ponta antes de as cenas USD serem renderizadas de forma fiável. É uma boa ilustração do problema: a renderização USD não é uma funcionalidade que se ativa, é uma cadeia de versões e caminhos que têm de estar todos de acordo.

Um estágio USD em camadas no Editor de Camadas USD do Maya — sublayers e referências visíveis — ao lado do output do Arnold RenderView.

Como renderizamos Maya + USD na nossa render farm

A nossa abordagem começa antes de um único frame ser colocado na fila: adaptamos o ambiente à cena em vez de pedir à cena que se adapte a uma imagem fixa da render farm. Quando um estúdio nos envia um trabalho Maya baseado em USD, confirmamos a versão do Maya, a compilação do MayaUSD, o motor de renderização e a versão USD em que os ativos foram criados, e depois configuramos os nós para corresponder. O objetivo é que o estágio componha nos nossos nós exatamente da mesma forma que compõe nas máquinas dos artistas — mesmo comportamento do plugin, mesma resolução, mesmo procedural.

Do lado da renderização, as duas peças mais importantes para Maya USD com Arnold têm de inicializar corretamente: o MayaUSD para compor o estágio dentro do Maya, e o Arnold USD procedural para ler o conteúdo USD no momento da renderização. Renderizámos trabalhos Maya de produção em que ambos carregam e funcionam corretamente em todo o conjunto de nós, que é o teste prático que importa — não "a render farm afirma suportar USD" mas "este estágio, com estas referências, produz os frames que o artista espera." O Arnold funciona nos nossos nós de CPU, o que se adequa à forma como muitos estúdios usam o Arnold para trabalho USD de qualidade final; as mesmas cenas podem ser executadas em GPU quando o projeto o requer.

Um detalhe que vale a pena referir, porque causa confusão: as cenas USD que passaram por várias pipelines frequentemente têm referências de plugins residuais e atributos de nós dispersos de motores de renderização que o projeto já não utiliza. Vemos cenas que ainda pedem um plugin que o estúdio abandonou há meses, ou que têm atributos de um motor que não está no caminho de renderização final. Nos nossos nós, esses elementos residuais são inofensivos — o Maya ignora-os e renderiza com o motor que está efetivamente a ser usado. Se quiser registos mais limpos, pode eliminar os pedidos de plugins desconhecidos e os nós residuais no Maya antes de enviar, mas é cosmético; não é o que impede uma renderização. Saber a diferença entre "elemento residual inofensivo" e "o que está realmente a falhar" é a maior parte do que faz uma renderização USD correr bem.

Uma limitação honesta para definir expetativas relativamente ao hardware: os nossos nós de GPU são construídos com placas RTX 5090 com 32 GB de memória por GPU, e essa memória é por placa — não é agrupada entre as duas placas de uma máquina. Para o trabalho CPU-Arnold USD que a maioria dos estúdios nos traz, esse limite raramente surge, mas se estiver a executar um caminho de GPU em cenas com texturas muito grandes ou volumetrias pesadas, vale a pena verificar de antemão a pegada de memória por GPU. Preferimos qualificar isso antes de um trabalho do que ter um frame que não encaixa a meio da execução.

Renderização a partir do espaço de ficheiros existente, sem necessidade de novo upload

O problema de resolução de ativos descrito anteriormente tem uma solução clara quando um estúdio já mantém o seu projeto num espaço de ficheiros montado. Se os ativos estiverem no LucidLink, podemos montar esse mesmo espaço de ficheiros nos nós de renderização, de modo a que o estágio USD resolva as suas referências com os dados exatos que os artistas veem — sem necessidade de novo upload de uma biblioteca de ativos de vários gigabytes, e sem reconstrução manual da estrutura de diretórios. O estágio compõe com os caminhos reais porque os caminhos reais estão montados.

Isto é mais relevante para o USD do que para uma cena de ficheiro único empacotada precisamente porque o USD depende dessas referências externas. Montar a fonte da verdade elimina toda uma classe de falhas "referência não encontrada", porque não há nada a copiar incorretamente — a render farm lê a mesma árvore que o estúdio lê. Para as equipas que já são nativas do LucidLink, isto tende a ser a diferença entre um ciclo complicado de upload-e-espera e uma renderização que simplesmente resolve.

Um espaço de ficheiros LucidLink do estúdio montado em direto nos nós de renderização, que leem os ativos no local — sem novo upload.

O que está incluído — licenças e DCC, não apenas máquinas

Quando se aluga capacidade dedicada da nossa render farm, as licenças do motor de renderização e as aplicações DCC vêm incluídas. Maya, o motor de renderização — Arnold, V-Ray, Redshift, Octane, Cycles — e os plugins de suporte fazem parte do que provisionamos, em vez de algo que se traz e licencia por nó. Para um trabalho USD, isso significa habitualmente que o licenciamento do Arnold é tratado do nosso lado como parte da execução, pelo que não é necessário obter licenças de renderização separadas para cada nó do bloco.

Vale a pena ponderar isto face a uma abordagem de bare-metal ou de construção própria, onde a taxa por máquina pode parecer mais baixa até adicionar as licenças do motor de renderização — que custam algumas centenas a bem mais de mil dólares por nó, por ano, por motor num host próprio. Incluí-las no serviço é a parte do modelo que faz o trabalho silencioso: a cena que renderiza é aquela em que o Maya, o MayaUSD, o procedural e a licença do motor estão todos presentes ao mesmo tempo, e provisioná-los em conjunto é a forma de manter essa cadeia intacta.

Uma migração real: USD no Maya, abandonando um scheduler na nuvem que não o conseguia executar

Para tornar isto concreto: trabalhámos recentemente com um estúdio britânico de efeitos visuais que nos contactou porque a sua configuração existente de scheduler na nuvem estava a falhar precisamente com este problema — o Maya não conseguia trabalhar com os seus ativos USD nesse ambiente. A pipeline deles era Maya com Arnold, num espaço de ficheiros LucidLink. Montámos o espaço de ficheiros nos nós, adaptámos o ambiente à cena e confirmámos nos registos que o MayaUSD e o Arnold USD procedural inicializaram e renderizaram corretamente em todas as máquinas. A cena tinha algumas referências residuais de fases anteriores; essas foram ignoradas, e os frames saíram. O estúdio passou de "as nossas renderizações USD continuam a falhar" para uma execução limpa, e escalou a partir daí. Mantemos o estúdio anónimo, mas o fluxo de trabalho — Maya, USD, Arnold, LucidLink — é cada vez mais a norma e não a exceção.

Lista de verificação antes de enviar um trabalho USD para qualquer render farm

Quer se renderize connosco ou em qualquer outro lugar, estes são os pontos que vale a pena confirmar previamente para que uma cena USD não crie surpresas numa render farm:

A maioria das renderizações USD falhadas remonta a uma das três primeiras linhas. A razão pela qual percorremos estes pontos antes de um trabalho e não depois é que, com o USD, a diferença entre uma execução limpa e um frame vazio é habitualmente uma única versão incompatível ou um caminho não resolvido — e é muito mais económico detetar isso num frame de teste do que no frame 480 de um prazo.

Por isso mesmo, a forma como normalmente iniciamos um trabalho Maya USD é com um frame representativo: executamos um antes do bloco completo para que o estúdio possa ver o estágio compor e os frames aterrar nos nossos nós, e confirmar a pipeline de ponta a ponta, antes de qualquer compromisso maior. Com o USD, provar a cadeia num frame vale mais do que qualquer lista de funcionalidades.

Para uma visão mais abrangente de como a renderização Maya funciona numa render farm para além do USD especificamente, o nosso guia de renderização Maya na nuvem abrange o fluxo de trabalho geral, e a nossa visão geral sobre como escolher uma render farm para Maya abrange a forma de avaliar uma. A locação de nós dedicados em que este trabalho USD é executado está descrita na nossa página de aluguer de render farm. Para o formato em si, a documentação OpenUSD da Pixar é a referência canónica sobre como os estágios compõem.

FAQ

Q: A vossa render farm suporta cenas Maya que utilizam USD? A: Sim. Renderizamos trabalhos Maya que utilizam USD, adaptando a compilação MayaUSD e o suporte USD do motor de renderização à cena. Em execuções de produção, confirmámos nos registos que o MayaUSD e o Arnold USD procedural inicializam e renderizam corretamente em todo o conjunto de nós. A chave está em reproduzir do lado da renderização a mesma compilação MayaUSD, versão USD e caminhos de ativos que os artistas utilizaram.

Q: Que versões de Maya e USD suportam? A: Em vez de fixar uma imagem única, adaptamos a versão do Maya, a compilação do MayaUSD e a versão USD em que os ativos foram criados. A composição USD é sensível a diferenças de versão na forma como as camadas, referências e variantes resolvem, pelo que adaptar o ambiente de criação é o que garante que o estágio compõe da mesma forma que nas estações de trabalho.

Q: Suportam o Arnold USD procedural? A: Sim — para Maya com Arnold, o Arnold USD procedural é o caminho que lê o conteúdo USD no momento da renderização, e provisionamo-lo juntamente com o Arnold. Tem de estar presente e ser compatível em versão com os dados, caso contrário o motor de renderização ignora o que não consegue ler. Confirmamos que inicializa antes de executar um bloco completo.

Q: É necessário trazer a própria licença Arnold? A: Não. As licenças do motor de renderização, incluindo o Arnold, fazem parte da capacidade dedicada que provisionamos — estão incluídas em vez de serem licenciadas por nó de forma independente. Numa configuração de host próprio, essas licenças seriam adicionadas por cima do custo das máquinas; incluí-las faz parte da forma como mantemos a cadeia de renderização intacta.

Q: É possível montar o nosso espaço de ficheiros LucidLink para não ser necessário fazer novo upload dos ativos? A: Sim. Se o projeto estiver no LucidLink, podemos montar esse espaço de ficheiros nos nós de renderização para que o estágio USD resolva as suas referências com os dados exatos que os artistas veem. Para o USD especificamente, isto elimina um modo de falha comum, porque a render farm lê a mesma árvore de ativos que o estúdio, em vez de uma cópia que pode ter uma estrutura diferente.

Q: Estamos num scheduler na nuvem que não consegue executar as nossas cenas Maya USD. É possível migrar? A: É uma razão comum pela qual os estúdios nos escolhem. Adaptamos o ambiente à cena, montamos o espaço de ficheiros se existir, e verificamos num frame representativo que o estágio USD compõe e renderiza antes de nos comprometermos com uma execução completa. A migração resume-se essencialmente a reproduzir fielmente o ambiente de criação do lado da renderização.

Q: A nossa cena tem referências residuais de um motor de renderização que já não utilizamos — isso é um problema? A: Normalmente não. As cenas USD que passaram por várias pipelines frequentemente têm pedidos de plugins dispersos e atributos de nós residuais. Nos nossos nós, o Maya ignora-os e renderiza com o motor que está efetivamente a ser utilizado. Podem ser eliminados no Maya para obter registos mais limpos, mas é cosmético — os elementos residuais raramente são o que impede uma renderização.

Q: Devemos renderizar Maya USD em CPU ou GPU? A: Ambas as opções estão disponíveis, e a resposta certa depende do motor de renderização e da cena. Muitos estúdios executam o Arnold para trabalho USD de qualidade final em CPU, para o qual os nossos nós de CPU estão preparados. A GPU está disponível quando o projeto o requer — note apenas que as nossas placas GPU têm 32 GB de memória cada, não agrupada, pelo que para cenas GPU muito pesadas vale a pena verificar de antemão a pegada de memória por GPU.