Corrigir erros de XGen e .tx numa render farm Maya

Introdução

Uma cena que é renderizada perfeitamente numa workstation e regressa errada de uma render farm é uma das falhas mais desorientadoras num pipeline Maya - nada no log aponta para «si», e nada na própria cena está corrompido. Dois dos culpados mais comuns são o XGen e as caches de texturas .tx. Ambos funcionam, por conceção, fora do ficheiro de cena principal: o XGen guarda os dados de groom e de description em pastas separadas de collection e archive, e o plugin MtoA do Arnold pode gerar silenciosamente a sua própria cache de texturas .tx em mosaico (tiled) junto das texturas de origem. Nenhum dos dois problemas aparece quando abre o ficheiro .ma ou .mb localmente, porque, localmente, esses ficheiros externos já estão onde o Maya os espera encontrar.

Vemos este padrão com frequência suficiente em trabalhos Maya freelance e de estúdios pequenos para valer a pena documentá-lo devidamente: o cabelo ou pelo que «desaparece» numa renderização na render farm, e a textura que gera um erro OpenImageIO inexplicado a meio de um frame, quase nunca são bugs de software. São problemas de recolha de assets e de caches desatualizadas, e ambos são evitáveis com uma breve passagem de preflight antes de submeter o trabalho.

Diagrama que mostra os dados de groom e de cache a serem resolvidos corretamente numa workstation local, mas a estarem em falta num nó da render farm, fazendo com que o cabelo ou pelo desapareça da renderização.

Porque é que o XGen falha numa render farm (mesmo quando a cena «parece» estar bem)

O XGen não guarda um groom ou uma description como geometria embutida (baked) no ficheiro .ma/.mb. Guarda-a como uma referência: um ficheiro de palette .xgen mais, consoante a forma como a description está configurada, uma pasta collections (dados de groom por description) e uma pasta archives (dados de point-cache ou Alembic já cozinhados, caso a description esteja definida para renderizar a partir de um archive em vez de gerar em tempo real). Quando abre a cena localmente, o Maya resolve essas referências em relação a caminhos que já existem na sua máquina ou na sua partilha de rede local. Quando a mesma cena chega a um nó da render farm, esses mesmos caminhos frequentemente não existem - porque eram absolutos, porque apontavam para uma partilha UNC à qual o nó da farm não está mapeado, ou porque apenas o ficheiro .ma/.mb foi carregado e a pasta xgen/ ao seu lado nunca fez a viagem.

O resultado raramente é um erro definitivo (hard error). Normalmente, o XGen falha a resolver a description de forma silenciosa, e a renderização termina - simplesmente sem o cabelo, o pelo ou as penas que deveriam lá estar. É este modo de falha específico que torna a depuração tão frustrante: tudo o resto no frame é renderizado corretamente, as drives são reportadas como mapeadas, e a versão do Maya e do XGen na farm corresponde exatamente à da workstation - o groom simplesmente desaparece, porque os ficheiros que o geram nunca chegaram.

Uma segunda causa, relacionada: mesmo quando a pasta xgen/ é recolhida, a definição da description - «gerar no momento da renderização» versus «cached/archived» - também importa. Se uma description estiver definida para ler a partir de um archive e esse caminho do archive for relativo a uma estrutura de projeto que o nó da farm não partilha, a description não resolve nada, em vez de recorrer a um groom gerado em tempo real.

Painel genérico ao estilo do editor de descriptions, a destacar os campos de caminho de collection e archive, ilustrando onde vivem, fora do ficheiro de cena principal, as referências aos dados de groom do XGen.

Porque é que os ficheiros de textura .tx falham numa render farm

.tx é um formato de textura em mosaico (tiled) e com mipmaps, produzido pela ferramenta maketx do OpenImageIO. O Arnold lê texturas .tx mais depressa e com um consumo de memória mais baixo do que os formatos de origem em bruto, razão pela qual o MtoA (o plugin do Arnold para o Maya) oferece a opção «Auto-Convert Textures to TX Files» - ao gravar ou ao renderizar, gera silenciosamente uma cache .tx junto das texturas de origem.

Este comportamento de auto-conversão é conveniente numa única workstation com um disco local e uma build do OpenImageIO consistente. É um comportamento muito menos fiável numa render farm distribuída, por três razões distintas:

Cache desatualizada. Se uma textura de origem for editada depois de o ficheiro .tx ter sido gerado, e a verificação de timestamp que normalmente desencadeia uma reconversão não disparar (ou se a localização com permissão de escrita de que o nó da farm precisa não for a mesma a partir da qual a cache foi gerada), o Arnold pode carregar um ficheiro .tx desatualizado sem qualquer aviso de que está obsoleto.
Incompatibilidade de versões. As versões do maketx/OpenImageIO diferem entre versões do Arnold e do MtoA. Uma cache .tx gerada por uma versão do OIIO pode produzir erros de leitura - normalmente manifestando-se como um erro OIIO não especificado que aborta o frame - quando é lida por uma versão diferente do lado da farm.
Contenção de escrita em caminhos partilhados ou só de leitura. A auto-conversão assume que pode escrever um ficheiro .tx junto da textura de origem. Numa render farm, essa localização pode ser só de leitura, partilhada entre trabalhos concorrentes, ou simplesmente não ser o mesmo caminho físico que a workstation utilizava, pelo que a conversão ou falha silenciosamente, ou dois nós entram em disputa (race) para escrever o mesmo ficheiro de cache.

Isto é suficientemente comum para que a documentação de render farms em toda a indústria - não só a nossa - recomende habitualmente aos utilizadores de Maya/Arnold que desativem a opção «Auto-Convert Textures to TX Files» especificamente para evitar o problema, em vez de tentar corrigir o próprio comportamento de auto-conversão. O padrão mais fiável é fazer uma escolha deliberada: ou pré-converter as texturas para .tx com uma versão fixa e conhecida do maketx e enviar esses ficheiros .tx como parte da recolha de assets, ou desativar por completo a auto-conversão, submeter as texturas de origem em bruto e deixar que o renderizador da farm trate a conversão de forma consistente do seu próprio lado.

Diagrama de pipeline a mostrar uma textura de origem convertida pelo maketx numa cache .tx, com um segundo ramo a mostrar uma cache desatualizada ou com incompatibilidade de versões a originar um erro de leitura de textura.

O que o Scene Archive do Maya não recolhe por si

O sistema de arquivo de cena nativo do Maya (Send To / archive project) é construído em torno do modelo de referência standard: texturas de ficheiro ligadas através dos próprios file nodes do Maya, e geometria que vive dentro do scene graph. O XGen não se encaixa totalmente nesse modelo, razão pela qual os seus dados são uma das peças mais comummente esquecidas numa recolha de assets, de resto, «completa». Antes de submeter uma cena com XGen a qualquer render farm, planeie empacotar explicitamente:

O próprio ficheiro de palette .xgen
A pasta xgen/collections/<description>/ para cada description referenciada na cena
A pasta xgen/archives/, caso alguma description esteja definida para renderizar a partir de um archive já cozinhado
Quaisquer guide curves externas, density maps ou length maps que um modifier do XGen referencie fora dos file nodes de textura standard do Maya - estas por vezes contornam as ferramentas de arquivo que apanham as texturas normais
A versão exata do Maya e do MtoA (Arnold para Maya) em que a cena foi construída, para que a render farm carregue a description com uma build do plugin correspondente, e não uma parecida mas diferente

Nada disto exige software especial - exige tratar os dados do XGen como uma parte de primeira classe da recolha de assets, e não como um efeito colateral implícito de gravar a cena.

Checklist de preflight Maya + Arnold para trabalhos com XGen e .tx

Passo	O que verificar	Porque é que importa
1. Correspondência de versões	Confirme que o intervalo de versões de Maya e Arnold/MtoA suportado pela render farm cobre a versão exata da sua cena	Uma incompatibilidade de versões pode quebrar a compatibilidade da description do XGen mesmo quando os caminhos de ficheiro estão corretos
2. Recolher as pastas do XGen	Empacote explicitamente `xgen/collections/`, `xgen/archives/` e o ficheiro `.xgen` - não confie apenas numa ferramenta genérica de arquivo de cena	São os ficheiros mais frequentemente esquecidos, fazendo com que o cabelo/pelo desapareça silenciosamente
3. Verificar a definição generate-vs-archive	Confirme se cada description gera em tempo real ou lê a partir de um archive já cozinhado, e que o caminho do archive viaja junto com o trabalho	Um caminho de archive que não resolve não renderiza nada, sem qualquer erro
4. Escolher uma estratégia de texturas	Desative «Auto-Convert Textures to TX Files» e submeta as texturas em bruto, ou pré-converta com uma versão fixa do `maketx` e inclua os ficheiros `.tx`	Manter a auto-conversão ativa assume acesso de escrita do lado da farm e uma versão de OIIO correspondente - pressupostos que nem sempre se verificam
5. Corrigir referências UNC e de letra de drive	Substitua quaisquer caminhos `\\server\share\...` ou de letra de drive local nos nós de XGen e de textura por caminhos relativos acessíveis à farm	Caminhos que resolvem localmente frequentemente não existem num nó de render
6. Executar um teste de um frame	Submeta um único frame de teste antes da sequência completa, e verifique o log de render especificamente quanto a avisos de carregamento de texturas e de resolução do XGen, não apenas a conclusão da renderização	Deteta cabelo em falta, texturas em falta e erros de OIIO antes de custarem uma sequência completa
7. Decidir entre CPU e GPU para o shot	Para grooms com uso intensivo de XGen, cobertura densa de cabelo/pelo e redes de shading personalizadas, planeie usar o caminho de renderização por CPU do Arnold para os frames finais - cenas com procedurais pesados e shaders personalizados são a classe de trabalho para a qual as próprias orientações do Arnold apontam a CPU no output final	Tomar a decisão de encaminhamento CPU/GPU antes da submissão evita descobrir uma limitação de dispositivo a meio da renderização

Problemas comuns e correções

Sintoma	Causa provável	Correção
Cabelo ou pelo em falta na renderização da farm, presente localmente	Pasta `collections`/`archives` do XGen não recolhida, ou caminho não acessível à farm	Empacote explicitamente as pastas do XGen e corrija quaisquer referências UNC/letra de drive
A renderização aborta com um erro OpenImageIO não especificado a meio do frame	Cache `.tx` desatualizada ou com incompatibilidade de versões	Regenere o `.tx` com uma versão fixa do `maketx`, ou desative a auto-conversão e submeta as texturas em bruto
A textura ou bitmap falha a resolver no nó de render (também visto em pipelines de Arnold no 3ds Max, uma classe de falha relacionada mas distinta - consulte o nosso guia de bitmaps em falta do Arnold no 3ds Max)	Caminho de textura não resolúvel a partir do nó de render	Confirme caminhos relativos e acessíveis à farm antes da submissão
O trabalho é renderizado corretamente ao ser reenviado, mas falhou na primeira vez	A auto-conversão escreveu a cache `.tx` a meio da renderização na primeira passagem; a segunda passagem leu a cache já completa	Pré-converta os ficheiros `.tx` antes da submissão, ou desative por completo a auto-conversão
Erros do plugin Arnold ou MtoA ao carregar	A versão do MtoA na farm não corresponde à versão em que a cena foi criada	Confirme o intervalo de versões alvo de Maya/Arnold antes da submissão

Simulação de consola de log de render a mostrar um erro de leitura de textura ao nível de aviso, ilustrando o tipo de mensagem que uma cache .tx desatualizada ou incompatível produz num nó de render.

Checklist resumo

Versões de Maya e Arnold/MtoA confirmadas em relação ao intervalo suportado pela render farm
xgen/collections/ e xgen/archives/ incluídas explicitamente na recolha de assets
A definição generate-vs-archive de cada description do XGen verificada, e o respetivo caminho confirmado como acessível à farm
Uma estratégia de texturas escolhida: .tx pré-convertido (versão fixa do maketx) ou texturas em bruto com a auto-conversão desativada - não ambas
Todos os caminhos UNC e de letra de drive substituídos por caminhos relativos acessíveis à farm
Um frame de teste submetido e o respetivo log de render verificado quanto a avisos de XGen e de texturas antes da sequência completa
Caminho de renderização CPU vs GPU decidido para shots com uso intensivo de XGen ou com shaders personalizados

Na nossa farm, as versões recentes do Maya (2022 e posteriores) passam automaticamente a correspondência de versões no momento da submissão; as versões mais antigas, dentro do intervalo suportado 2014-2027, são encaminhadas através de uma verificação de provisionamento e compatibilidade antes de a renderização começar, pelo que uma incompatibilidade é detetada antes de os frames serem gastos, e não a meio do trabalho. Os itens relativos a caminhos, caches e definições de archive são específicos de cada cena e vale a pena verificá-los independentemente da farm para a qual um trabalho é enviado.

Para uma configuração geral de renderização em cloud com Maya, para além do XGen e das texturas especificamente, consulte o nosso guia de renderização em cloud para Maya e o nosso guia completo do renderizador Arnold. Para os intervalos de suporte de software por trás da correspondência de versões da farm, consulte as nossas páginas render farm para Maya e render farm para Arnold. Do lado das texturas, a própria documentação do maketx do OpenImageIO é a referência técnica mais clara sobre o que a conversão .tx está realmente a fazer e quais as flags que controlam o comportamento de mipmap e tiling.

FAQ

Q: Porque é que o cabelo ou pelo XGen desaparece quando renderizo numa render farm na cloud, mas funciona bem localmente? A: Isto normalmente significa que as pastas collections e archives do XGen não foram recolhidas junto com o resto da cena. O XGen lê os dados de groom e de description a partir destes ficheiros externos no momento da renderização - se apenas o ficheiro .ma ou .mb for carregado, o nó de render não tem a partir de que gerar o cabelo ou o pelo, pelo que a renderização é concluída sem cabelo, em vez de apresentar um erro óbvio.

Q: O que é um ficheiro .tx e porque é que o Arnold precisa dele? A: Um ficheiro .tx é uma textura em mosaico (tiled) e com mipmaps, criada pela ferramenta maketx do OpenImageIO. O Arnold e o MtoA usam texturas .tx em vez dos formatos de origem em bruto porque os mipmaps em mosaico carregam mais depressa e usam menos memória durante a renderização, o que importa ainda mais à escala de uma farm do que numa única workstation.

Q: Devo deixar «Auto-Convert Textures to TX Files» ativado ao submeter para uma render farm? A: Deixá-lo ativado é uma fonte comum de erros de textura do lado da farm. Funciona bem numa workstation com um único disco, mas numa farm distribuída pode produzir uma cache .tx desatualizada ou com incompatibilidade de versões, ou esbarrar numa diferença de permissões de escrita no nó de render. Pré-converter com uma versão conhecida do maketx e enviar os ficheiros .tx, ou desativar a auto-conversão e submeter as texturas em bruto, evita ambos os modos de falha.

Q: As minhas versões de Maya e Arnold já correspondem às da farm - porque é que a renderização continua sem texturas? A: A correspondência de versões evita falhas ao nível do plugin, mas a maioria dos erros de XGen e .tx numa farm vem dos caminhos de ficheiro, não das versões. Se o XGen referenciar um caminho UNC ou uma letra de drive local que não existe no nó de render, ou se a cache .tx tiver sido gerada em relação a uma localização de textura que a farm não consegue alcançar, a renderização falha mesmo com versões de software correspondentes.

Q: Como sei quais as versões de Maya e Arnold que uma render farm suporta? A: Verifique o intervalo de versões de Maya e Arnold/MtoA suportado pela farm antes de submeter - fazer corresponder as versões elimina uma classe inteira de erros de renderização. A nossa farm suporta Maya 2014-2027: as versões 2022 e posteriores passam automaticamente a correspondência de versões no momento da submissão, e as versões mais antigas são encaminhadas através de uma verificação de compatibilidade antes da renderização.

Q: Os shots com XGen devem ser renderizados pelo caminho CPU ou GPU do Arnold? A: Os shots com uso intensivo de XGen, cobertura densa de cabelo ou pelo, e redes de shading personalizadas pertencem ao caminho CPU do Arnold para o output final - essa é a classe de trabalho para a qual as próprias orientações do Arnold apontam a CPU. Independentemente do caminho que um shot utilize, tome a decisão de dispositivo no momento da submissão, como parte do preflight, em vez de descobrir uma limitação a meio da renderização.

Q: O que devo verificar antes de submeter uma cena Maya com XGen a uma render farm? A: Execute um breve preflight: confirme a correspondência de versões Maya/MtoA, empacote explicitamente as pastas xgen/collections e xgen/archives, escolha uma estratégia de texturas (.tx pré-convertido ou em bruto com a auto-conversão desativada), corrija quaisquer referências UNC ou de drive local, e submeta um teste de um frame antes da sequência completa.

Q: Este é um problema exclusivo do XGen, ou também aparece com outros DCCs? A: O mesmo padrão subjacente - dados que vivem fora do ficheiro de cena principal, mais dados de textura em cache que ficam desatualizados - também aparece noutros locais. Os utilizadores de 3ds Max deparam-se com um problema relacionado, mas distinto, com nós de bitmap em falta no Arnold quando os caminhos de textura não resolvem no nó de render; consulte o nosso guia de bitmaps em falta do Arnold no 3ds Max para essa versão do problema.