Configurar o Maya para cloud rendering

O Maya na nossa render farm executa três motores principais — Arnold (o predefinido do Maya), V-Ray e Redshift — juntamente com suporte para XGen interactive grooming, pipelines Alembic e USD, e os principais plugins de terceiros em que as equipas de VFX e animação se baseiam. Esta página abrange o empacotamento de projetos, notas por motor, o fluxo de trabalho XGen, a configuração do Arnold Denoiser, Render Setup versus Render Layers legados, o fluxo de envio e resolução de problemas específicos do Maya.

Para o posicionamento de alto nível do Maya na nossa render farm — versões suportadas, camadas de hardware, exemplos de preços — a página de destino dedicada está em . Para a cobertura de funcionalidades da versão 2027, o artigo está em .

Versões suportadas

O Maya 2024, 2025 e 2026 estão pré-instalados em todos os nós de trabalho. O Maya 2023 está disponível a pedido para projetos legados; o Maya LT não é suportado porque não tem a capacidade de exportação de renderização necessária para renderização distribuída. A render farm corresponde automaticamente à versão do ficheiro .ma (ASCII) ou .mb (binário) — não é necessário especificá-la manualmente na interface de envio.

Uma nota sobre o ritmo de lançamentos do Maya: a Autodesk lança versões anuais mais atualizações de ponto (por exemplo, 2025.1, 2025.2, 2025.3). Disponibilizamos a versão GA mais recente no prazo de quatro a seis semanas após a disponibilidade pública. Se o projeto necessitar de uma atualização de ponto específica devido a compatibilidade de plugins — Yeti, Bifrost, ou uma compilação de motor de terceiros associada a uma versão menor do Maya — mencione-o nas notas do trabalho e podemos encaminhar o trabalho para um nó associado a essa versão.

A compatibilidade futura entre versões dentro de uma versão principal é geralmente segura (uma cena 2024.0 abre corretamente em 2024.3), mas a migração entre versões principais (2023 → 2025) por vezes expõe nós deprecados ou remapeamentos de atributos. Se for necessário enviar uma cena 2023, guarde uma cópia com a versão mais recente instalada na estação de trabalho e verifique que o fotograma de teste corresponde antes de fazer o upload.

Empacotar o projeto Maya

Um projeto Maya é o ficheiro de cena .ma ou .mb mais a estrutura de pastas do projeto que o Maya espera resolver no momento de abertura da cena:

sourceimages/ — texturas, HDRIs, entradas de cor geridas ACEScg
scenes/ — a cena principal mais quaisquer cenas de referência (.ma / .mb)
cache/ — caches Alembic (.abc), partículas, fluidos, nCloth
xgen/ — dados de patch XGen (collections/, descriptions/, patches/)
assets/ — standins Arnold (.ass), proxies V-Ray (.vrmesh), camadas USD (.usd / .usda / .usdc)
data/ — dados de cena auxiliares (mapas de deformador, ficheiros de simulação cozidos)

A funcionalidade integrada do Maya Ficheiro → Arquivar Cena é a ferramenta de empacotamento recomendada. O fluxo de trabalho:

Defina a raiz do projeto. Ficheiro → Definir Projeto. A resolução de caminhos do Maya depende de a raiz do projeto estar corretamente definida; se não estiver, a função Archive escreverá um arquivo estruturalmente válido mas com referências de caminho absoluto que falham num nó de trabalho.
Ficheiro → Arquivar Cena. O Maya reúne a cena ativa, todos os ficheiros referenciados (sourceimages, referências, caches, patches XGen, standins Arnold) e escreve-os num único arquivo.
Resolva primeiro os caminhos absolutos. O Arquivo de Cena preserva os caminhos absolutos se existirem (por exemplo, D:\Projetos\plano_010\sourceimages\madeira.exr). Antes de arquivar, abra o Reference Editor (Ficheiro → Reference Editor) e qualquer gestor de caminhos e reaponte os caminhos absolutos para forma relativa (./sourceimages/madeira.exr).
Rearquive como .tar, .tar.gz ou .7z se o Arquivo de Cena tiver produzido um .zip. Não aceitamos uploads .zip, pelo que o ficheiro tem de ser reempacotado antes do envio. O 7-Zip no Windows e tar -czf no macOS / Linux produzem ambos arquivos compatíveis com a render farm.
Verifique o arquivo. Abra a cena arquivada na estação de trabalho numa sessão Maya nova e renderize um único fotograma de teste. Se algo estiver em falta — bitmaps, referências, patches XGen — localize, re-ligue e rearquive.

Um atalho comum que não funciona: copiar apenas o ficheiro .ma. As cenas Maya armazenam apenas referências a ativos, nunca os próprios ativos.

O que verificar antes do envio

Uma breve lista de verificação pré-envio que deteta cerca de 80% dos casos de falha antes de chegarem a um nó de trabalho:

O motor ativo está corretamente definido. Definições de Renderização → Renderizar Usando é o menu pendente que determina qual o motor que o nó de trabalho utiliza. Definições de motor incompatíveis são uma causa comum de saída inesperada (uma cena criada para Arnold enviada com V-Ray ativo renderizará com predefinições V-Ray).
Render Setup vs Render Layers legados. O Maya 2017+ usa Render Setup por predefinição; projetos legados podem ainda usar Render Layers legados. Converta para Render Setup antes do envio (Janelas → Editores de Renderização → Render Setup → Importar de Render Layers Legados) para evitar o padrão de falha "Error: Legacy Render Layers" nos nós de trabalho.
O intervalo de fotogramas está definido nas Definições de Renderização, não apenas na linha de tempo. A render farm lê o Intervalo de Fotogramas nas Definições de Renderização → Geral, não na linha de tempo. Verifique que ambos correspondem; as incompatibilidades geralmente apresentam-se como "a render farm renderizou menos fotogramas do que esperado."
A câmara renderizável está verificada. Definições de Renderização → Geral → Câmaras Renderizáveis determina qual a câmara que renderiza. A persp predefinida é frequentemente deixada marcada por acidente; desmarque as câmaras que não pretende e marque a que pretende.
Os caminhos de saída usam tokens Maya. <RenderLayer>/<Scene>.<#>.<ext> é uma predefinição segura e produz uma estrutura de saída previsível na render farm. Evite caminhos de saída absolutos.
Scripts MEL ou Python pré-renderização e pós-renderização desativados se referenciarem caminhos específicos da estação de trabalho (servidores de licenças, pastas de rede, unidades mapeadas). Os hooks pré/pós-renderização que chamam system() para caminhos de rede falharão silenciosamente nos nós de trabalho.
A gestão de cor está explicitamente definida. As configurações OCIO (ACES, configurações de estúdio personalizadas) têm de ser incluídas no projeto ou depender da predefinição do nó de trabalho. Se usar uma configuração OCIO personalizada, inclua o ficheiro .ocio no arquivo e defina o caminho relativo à raiz do projeto.

Notas específicas por motor

Arnold para Maya

O Arnold é o motor predefinido do Maya e é a escolha mais comum para projetos Maya na nossa render farm — particularmente para VFX, animação de personagens e trabalho de longa-metragem. O Arnold corre na nossa camada de nós CPU (Dual Intel Xeon E5-2699 V4, até 256 GB de RAM por nó).

Notas de configuração:

Licença: O Arnold é fornecido como parte do Maya sob o licenciamento de nó de renderização da Autodesk. Não é necessária uma licença Arnold separada para renderizar connosco; operamos sob o modelo de utilização render-only da Autodesk para Arnold.
Definições de amostragem. As amostras de Câmara (AA), Difusa, Especular, Transmissão, SSS e Volume devem ser calibradas localmente antes do envio. A render farm usa os valores de amostragem especificados no projeto; as cenas sub-amostradas renderizam com ruído na render farm exatamente como o fazem localmente. A Amostragem Adaptativa, quando ativa, ajuda em planos com regiões de alta variância (interiores com luz de janela intensa) mas não recupera uma cena globalmente sub-amostrada.
AOVs. O Arnold escreve como EXR multicanal ou ficheiros por AOV consoante as definições do Output Driver. O EXR multicanal predefinido é suportado na render farm. Para saída de ficheiro por AOV (para compositores que preferem ficheiros separados), mude o driver para modo por-pass no navegador AOV.
Standins e procedurais. Os standins Arnold (ficheiros .ass) e procedurais funcionam na render farm. Inclua os ficheiros standin no arquivo do projeto; a resolução de caminhos é tratada no momento do envio. Para standins muito grandes (acima de 5 GB), o caminho de upload SFTP é mais fiável do que o upload pelo browser.
Shaders OSL. Os shaders OSL personalizados incluídos na cena funcionam na render farm. Os shaders que dependem de caminhos específicos da estação de trabalho (ficheiros .oso compilados numa localização não padrão) têm de ser movidos para a pasta shaders/ do projeto antes de arquivar.
Operadores (Imagers, Filtros de Luz). O grafo de operadores Arnold para substituições de cena em fase tardia (filtros de luz, imagers, drivers AOV personalizados) é suportado. Verifique que o grafo de operadores está ligado a defaultArnoldRenderOptions antes do envio.

Arnold Denoiser (Optix e Noice)

O Arnold Denoiser tem duas versões e ambas correm na render farm:

Denoiser Optix. Denoise pós-renderização acelerado por GPU, rápido. Configure-o nas Definições de Renderização → Arnold Renderer → Denoising. O Optix beneficia de amostras AA de entrada na gama 6–10; abaixo de 6 AA o denoiser começa a esbater detalhes finos.
Noice (CPU, temporal). O fluxo de trabalho recomendado para animação. O Noice opera em sequências EXR com os AOVs N (variância) e Z (profundidade) incorporados. Para denoise temporal — que remove a variância de ruído de fotograma para fotograma — defina o intervalo de fotogramas temporal (por exemplo, -3 +3 para uma janela de sete fotogramas). A render farm executa o Noice como passo pós-renderização; inclua os AOVs (N, Z, beauty) na lista AOV antes do envio.

Uma saída de denoiser com grão normalmente tem origem numa de três causas: amostras AA insuficientes (aumente para mínimo de 6–10), AOV de variância em falta (o Optix necessita do sinal de variância), ou intervalo de fotogramas temporal mal configurado no Noice. Para animações com grooming consistente ou motion blur, o modo temporal do Noice é significativamente mais limpo do que o Optix por fotograma.

V-Ray para Maya

O V-Ray para Maya corre na nossa camada de nós CPU. É a escolha para estúdios com pipelines V-Ray estabelecidos de fluxos de trabalho 3ds Max ou Cinema 4D que passaram para o Maya.

Notas de configuração:

Licença. O V-Ray na nossa render farm funciona sob a nossa licença de parceiro Chaos. Como parceiro oficial Chaos, operamos instalações V-Ray licenciadas.
Cache GI (Irradiance Map + Light Cache). Para renderizações de fotogramas fixos de archviz, pré-calcular o Irradiance Map e o Light Cache localmente é significativamente mais rápido do que recalcular por nó. O fluxo de trabalho de dois passes — prepass em disco, depois pass final reutilizando o mapa guardado — está documentado no .
Prepass de animação V-Ray. Para animação, o fluxo de trabalho recomendado usa o modo "Animation (prepass)" do Irradiance Map em toda a gama de fotogramas para construir um mapa parcial por fotograma, depois o modo "Animation (rendering)" para o pass final. Isto elimina a cintilação GI por fotograma e é significativamente mais rápido do que recalcular o GI em cada fotograma do nó de trabalho. O mesmo padrão documentado para o 3ds Max aplica-se aqui — os nomes dos parâmetros correspondem entre os dois bindings DCC.
VRayProxy. Suportado. Inclua os ficheiros proxy .vrmesh no arquivo do projeto em assets/ ou proxies/. Verifique que os caminhos de proxy na cena são relativos.
V-Ray Frame Buffer (VFB). A saída EXR com correções de cor VFB é suportada; guarde as correções como um ficheiro .vccglb usando VFB → menu "..." → Guardar Correções, e inclua o ficheiro no arquivo. O nó de trabalho aplica as correções guardadas durante a renderização.
Ficheiros VRayScene. Suportados como referências de cena externa. Inclua quaisquer ficheiros .vrscene no arquivo ao lado do .ma / .mb principal.

Redshift para Maya

O Redshift para Maya corre na nossa camada de nós GPU NVIDIA RTX 5090 (32 GB de VRAM por cartão). É a escolha para estúdios com pipelines Maya que necessitam de velocidade de iteração GPU — particularmente equipas de motion design, estúdios de animação independentes e trabalho de gráficos de transmissão.

Notas de configuração:

Licença. O Redshift na nossa render farm funciona sob a nossa licença de parceiro Maxon.
Memória out-of-core. Ativa por predefinição. Permite que cenas que excedam os 32 GB de VRAM renderizem através de streaming de texturas e geometria a partir da RAM do sistema. A penalização out-of-core é real em cenas pesadas — uma cena a correr puramente em VRAM é significativamente mais rápida do que uma que faz streaming de metade do seu conjunto de trabalho — pelo que, para sequências de produção, calibre os tamanhos de textura e a densidade de proxies para caber se possível.
Unified Sampling. Os valores de Unified Sampling controlam a qualidade de renderização por fotograma. Calibre localmente antes do envio; a saída Redshift sub-amostrada parece semelhante ao Arnold sub-amostrado (ruído em sombras e reflexos), mas os caminhos de otimização diferem.
AOVs. O mesmo padrão EXR multicanal ou ficheiro por AOV que o fluxo de trabalho Redshift para C4D. O navegador AOV do Redshift está em Definições de Renderização → AOVs.
Redshift Proxy. Suportado. Use ficheiros proxy .rs para geometria instanciada ou ativos principais exportados de outro DCC.
Redshift IPR vs renderização final. As definições que parecem aceitáveis no IPR (a pré-visualização interativa) por vezes subrrenderizam na qualidade do pass final. Renderize sempre um fotograma de teste no sampling do pass final localmente antes de enviar um lote de animação.

Maya XGen

O XGen interactive grooming para trabalho de personagens, objetos dispersos e trabalho de ornamento é suportado na render farm. O XGen carrega dados de patch fora do ficheiro de cena, pelo que o empacotamento requer atenção especial.

O fluxo de trabalho para projetos XGen:

Verifique que os patches XGen estão guardados. Abra o projeto localmente, atualize cada descrição XGen (Gerar → Atualizar) e guarde a cena. O XGen por vezes mantém dados de patch apenas na sessão de trabalho até serem explicitamente guardados.
Inclua a pasta xgen/ no arquivo. O Arquivo de Cena do Maya geralmente captura esta pasta, mas verifique antes de fazer o upload. A pasta contém as subpastas collections/, descriptions/ e patches/.
Verifique o Caminho de Coleção XGen na cena. Se o caminho referenciar uma unidade de estação de trabalho absoluta (por exemplo, D:\Projetos\plano\xgen\), o Maya não encontrará a coleção no nó de trabalho. Defina-o como relativo (./xgen/) antes de arquivar.
XGen procedural (geometria instanciada, arquivos). Certifique-se de que os arquivos referenciados estão na pasta do projeto, não num diretório separado da estação de trabalho. Para arquivos XGen baseados em Alembic, inclua os ficheiros .abc em cache/ ou assets/.
Pré-cache de splines grooming. Para cenas de cabelo denso, cozinhar o grooming para um estado em cache (Cache → Criar Ficheiro Cache) antes do envio reduz o tempo de configuração por nó de trabalho.

O tempo de renderização por fotograma para cenas com XGen intenso é significativamente maior do que para geometria estática — a avaliação XGen corre por fotograma, e as cenas de cabelo denso podem demorar 10–30 minutos por fotograma mesmo em nós de camada superior. Para trabalho de animação onde o grooming é estático (sem simulação por fotograma), pré-cozinhar o XGen para geometria Alembic antes de renderizar é uma otimização comum: converta a descrição XGen para polígonos ou curvas, coloque em cache para Alembic e referencie o Alembic na cena de renderização. A render farm renderiza o Alembic em cache com custo por fotograma previsível.

Suporte a plugins Maya

O plugin de envio da Super Renders Farm para Maya trata da verificação de ativos, verificações de definições de renderização e envio com um clique diretamente a partir do Maya. Instale a partir da secção de downloads do painel da conta. Após a instalação, o plugin aparece como um botão de prateleira com o rótulo SuperRenders e como um item de menu em SuperRenders na barra de menus principal do Maya.

Funcionalidades do plugin:

Envio com um clique a partir do Maya — recolhe as definições de renderização ativas (motor, intervalo de fotogramas, caminho de saída, AOVs, render layers) e envia sem sair do Maya.
Verificação de caminhos de ativos — assinala texturas, referências, patches XGen, standins e proxies em falta antes do envio. Deteta o modo de falha "ativo em falta no nó de trabalho" ao nível da estação de trabalho em vez do nível do nó de trabalho.
Reconhecimento de Render Layer / Render Setup — envia a configuração correta de camada, incluindo substituições de camada e flags visível-na-renderização.
Verificação de token de licença — confirma que o motor escolhido nas Definições de Renderização é suportado na render farm antes do envio, para que as configurações não suportadas surjam localmente em vez de no momento da renderização.
Pass-through de notas do trabalho — tudo o que for escrito no campo de notas do plugin chega à fila de envio e é visível para a equipa de suporte se abrir um ticket sobre o trabalho.

Para os passos de instalação do plugin e resolução de problemas (incluindo o padrão "plugin não na prateleira"), consulte .

Fluxo de envio

Três canais de envio funcionam para projetos Maya:

Plugin de envio (recomendado para trabalho iterativo). Envio a partir do Maya após instalar o plugin. Ciclo de iteração mais curto porque o plugin lê as definições de renderização em direto — sem risco de enviar com estado de interface desatualizado.
Upload web + envio pelo painel. Faça upload do projeto arquivado e depois envie através do website. Funciona sem o plugin instalado e é a escolha certa para trabalhos pontuais ou para utilizadores em estações de trabalho bloqueadas onde a instalação de plugins está impedida.
Client App. Upload + envio + auto-download num único wrapper. Ideal para estúdios com trabalhos Maya recorrentes que pretendem uma aplicação de secretária a gerir o ciclo completo sem envolvimento do browser.

Para o fluxo upload-envio-download transversal a DCCs, consulte o .

Resolução de falhas específicas do Maya

Para resolução de problemas gerais que se aplica a todos os DCCs, consulte . Casos específicos do Maya:

Todas as renderizações devolvem preto ou em branco. Verifique que Definições de Renderização → Geral → "Câmara Renderizável" está definida para a câmara pretendida (não a persp predefinida). Verifique também que a câmara de renderização não está oculta no Outliner. Esta é a causa mais comum de renderizações a preto em trabalhos Maya.
"Missing plugin" ou plugin não na prateleira. O plugin de envio tem de ser carregado no Plugin Manager (Janelas → Definições/Preferências → Gestor de Plug-ins). Pesquise o plugin SuperRenders e marque "Carregado" e "Carregar automaticamente." Se o ficheiro de plugin estiver ausente da pasta plug-ins/, execute novamente o instalador a partir do painel da conta.
Remover o plugin antigo antes de reinstalar. Se tiver instalado anteriormente uma versão mais antiga do plugin de envio, remova o ficheiro .mll (Windows) ou .bundle (macOS) antigo de Documentos/maya/<versão>/plug-ins/ antes de instalar a nova versão. O Maya por vezes carrega preferencialmente a versão antiga quando ambas estão presentes.
Falhas de auto-conversão TX. Se "Atualização automática de textura TX" estiver ativa nas Definições de Renderização Arnold, o Maya tenta converter texturas para .tx no momento da renderização. Na render farm, esta conversão pode falhar se as permissões do nó de trabalho não corresponderem à configuração local. A solução fiável é pré-converter texturas para .tx localmente usando maketx (fornecido com Arnold), incluir os ficheiros .tx no arquivo e desativar "Atualização automática de textura TX" antes do envio.
"Error: Legacy Render Layers." O Maya 2017+ usa Render Setup por predefinição; abrir um projeto mais antigo com Render Layers legados pode desencadear este erro na render farm. Converta para Render Setup localmente (Janelas → Editores de Renderização → Render Setup → Importar de Render Layers Legados) antes do envio. A conversão não é destrutiva — os dados de Render Layers legados originais permanecem na cena.
O Arnold Denoiser produz saída com grão. Verifique que o denoiser está configurado com amostras de entrada suficientes (mínimo de amostras AA de 6–10) e que o AOV de variância (N) está ativo. Para Noice com denoise temporal, confirme que o intervalo de fotogramas temporal está corretamente definido em relação ao fotograma que está a ser denoisado.
iRay renderização ativa no ficheiro de cena. O iRay foi descontinuado pela Autodesk e não é suportado na render farm. Se a cena tiver o iRay definido como motor ativo, mude para Arnold (ou V-Ray / Redshift) nas Definições de Renderização → Renderizar Usando antes de enviar.
Ativo em falta no carregamento de cena. Abra o Asset Tracking na estação de trabalho (Janelas → Editores Gerais → File Path Editor), localize os itens em falta, re-ligue e rearquive. A maioria das falhas de "ativo em falta" na render farm tem origem num caminho que mudou após o último pass de Archive.
Câmara errada devido a View to Render bloqueado. Se uma câmara estiver bloqueada ao viewport na cena (Painéis → Perspetiva → câmara → Bloquear Câmara), o Maya pode preferir essa câmara em relação à definida nas Definições de Renderização. Desbloqueie as câmaras bloqueadas ao viewport antes do envio.
Imagem de saída não completa / recortada. Verifique Definições de Renderização → Geral → "Usar Região de Renderização" — se estiver ativa e configurada para uma sub-região, o nó de trabalho renderiza apenas essa região. Desative para saída de fotograma completo.
Yeti ou Ornatrix não pré-instalados. O Yeti e o Ornatrix não estão pré-instalados por predefinição na imagem do nó de trabalho. Contacte o suporte antes do envio para discutir a adição do plugin ao nó de trabalho, ou cozinhe o grooming para geometria Alembic e referencie o cache — a saída cozida renderiza na render farm sem necessitar do plugin.

Referências cruzadas

— fluxo upload, envio, download
— como são calculados os custos de trabalhos Maya
— Irradiance Map, Light Cache, prepass de animação
— guia SFTP, formatos de arquivo
— resolução de problemas transversal a DCCs
— instalação do plugin de envio Maya
— página de destino
— artigo de cobertura de versão
— destino específico Arnold
— destino específico Redshift

FAQ

Q: Quais as versões de Maya que a render farm suporta? A: O Maya 2024, 2025 e 2026 estão pré-instalados em todos os nós de trabalho. O Maya 2023 está disponível a pedido para projetos legados. O Maya LT não é suportado porque não tem a capacidade de exportação de renderização necessária para renderização distribuída. A render farm corresponde automaticamente à versão do ficheiro .ma ou .mb.

Q: É necessário transferir a licença Maya para renderizar na render farm? A: Não. Executamos instalações Maya licenciadas em toda a frota de nós sob licenciamento de nó de renderização Autodesk. A licença Maya local permanece consigo.

Q: Que motor devo escolher — Arnold, V-Ray ou Redshift? A: Arnold para animação de personagens e trabalho VFX (predefinição do Maya; integração de pipeline mais profunda). V-Ray para pipelines de estúdio V-Ray estabelecidos ou archviz com GI intenso. Redshift para iteração GPU rápida em motion design e animação independente. Os três são suportados com licenciamento verificado na nossa render farm e produzem saída previsível em todos os nós de trabalho.

Q: O projeto usa XGen para grooming de personagens. Vai renderizar? A: Sim, desde que os ficheiros de patch XGen (.xgen e .xpd) estejam incluídos no arquivo do projeto. Verifique que o Caminho de Coleção XGen na cena está definido como relativo (./xgen/), não como um caminho absoluto de estação de trabalho. O tempo de renderização por fotograma para cenas com XGen intenso é significativamente maior do que para geometria estática; pré-cozinhar o grooming para Alembic é uma otimização comum para animação onde o grooming é estático.

Q: A cena Maya usa Yeti ou Ornatrix para grooming em vez de XGen — são suportados? A: O Yeti e o Ornatrix não estão pré-instalados por predefinição. Contacte o suporte antes do envio para discutir a adição do plugin à imagem do nó de trabalho. Em alternativa, cozinhe o grooming para geometria Alembic antes do envio — a saída cozida renderiza na render farm sem necessitar do plugin.

Q: Como configurar o Arnold Denoiser para saída de animação limpa? A: Para animação, o fluxo de trabalho temporal Noice produz os resultados mais limpos. Ative os AOVs N (variância) e Z (profundidade) juntamente com a saída beauty, defina as amostras AA para mínimo de 6–10 e configure o Noice com um intervalo de fotogramas temporal (por exemplo, -3 +3 para uma janela de sete fotogramas). O Optix é mais rápido por fotograma, mas não trata a variância de ruído de fotograma para fotograma tão bem quanto o Noice temporal.

Q: Estou a obter erros "missing plugin" quando a render farm tenta carregar a cena. O que verificar? A: Abra a cena numa sessão Maya limpa localmente (feche todas as janelas, reinicie o Maya e depois abra). Verifique o Script Editor para avisos "missing plugin". Os plugins não pré-instalados na render farm têm de ser removidos da lista de plugins da cena (Editar → Plug-ins Desconhecidos → Remover) ou substituídos por equivalentes. Consulte também a secção Resolução de Problemas acima para o fluxo de trabalho "plugin não na prateleira".

Q: É possível renderizar trabalhos com o Maya Software renderer ou Hardware Renderer 2.0? A: O Maya Software é suportado mas raramente usado; recomendamos o Arnold para quase todo o trabalho de produção. O Hardware Renderer 2.0 destina-se a playblasts de viewport e não foi concebido para renderização distribuída — renderize esses localmente na estação de trabalho.

Q: A conversão de textura TX está a falhar na render farm. O que está a acontecer? A: A opção "Atualização automática de textura TX" do Arnold faz com que o nó de trabalho converta as texturas para .tx no momento da renderização, o que pode falhar se as permissões do utilizador do nó de trabalho diferirem da configuração local. A correção fiável: pré-converta todas as texturas para .tx localmente usando maketx, inclua os ficheiros .tx no arquivo do projeto e desative a Atualização TX automática nas Definições de Renderização Arnold antes do envio.

Q: Tenho uma animação stereo 4K com 12.000 fotogramas. A render farm consegue lidar com isso? A: Sim. Para projetos desse tamanho, recomendamos o upload por SFTP em vez do browser (as transferências retomáveis gerem uploads de várias horas de forma segura) e o envio pelo plugin de envio para criação de trabalho mais limpa. O tempo de renderização por fotograma e o custo resultante dependem da complexidade da cena e da escolha do motor; a fornece uma estimativa com base nas entradas.

---