Resolução de problemas de qualidade de renderização

Os problemas de qualidade de renderização são diferentes dos problemas de falha de renderização. Uma falha significa que o trabalho não foi concluído. Um problema de qualidade significa que foi concluído, mas o resultado está errado — demasiado brilhante, demasiado escuro, geometria em falta, câmara errada, saída que não corresponde ao que se vê no viewport. Estes problemas são quase sempre de nível de configuração em vez de nível de infraestrutura, o que significa que são resolúveis da parte do utilizador assim que se sabe onde procurar.

Esta página percorre os problemas de qualidade de renderização que vemos mais frequentemente na render farm, organizados por sintoma. Para resolução de problemas de falhas de trabalhos — trabalhos que não concluem, colidem a meio de um fotograma, ou devolvem códigos de erro — consultar . Para detalhes de configuração específicos de cada DCC e as definições de tempo de renderização que mais importam para cada motor, consultar o documento configurar-* relevante.

Uma regra de trabalho útil que aplicamos todos os dias no suporte: os problemas de qualidade de renderização são quase sempre reproduzíveis. Se uma renderização devolver um resultado errado da render farm, a mesma cena renderizada localmente — mesmo motor, mesma versão, mesmas definições, mesmo ficheiro de cena — produzirá geralmente a mesma saída errada. Essa reprodutibilidade é a chave de diagnóstico. Se o local corresponder à render farm, o problema está dentro da cena e pode ser resolvido sem tocar em nada do lado da render farm. Se o local diferir da render farm, o problema é ambiental: incompatibilidade de caminho, incompatibilidade de versão, recurso em falta, ou uma configuração que acompanha a estação de trabalho mas não o ficheiro de cena.

As secções abaixo seguem essa lógica de diagnóstico, ordenadas pela frequência com que vemos cada padrão na linha de suporte.

Incompatibilidade de brilho ou cor face à renderização local

Este é o problema de qualidade mais comum que vemos, com grande margem. A renderização devolve resultados mais claros, mais escuros, mais saturados ou visivelmente diferentes em cor do que o viewport local mostra. Quase sempre, a causa é a gestão de cor — o worker está a interpretar o pipeline linear, sRGB ou Filmic de forma diferente do viewport da estação de trabalho, ou a marcação do espaço de cor das texturas é inconsistente.

Cinco aspetos a verificar, por ordem de frequência:

1. Incompatibilidade de View Transform. No Blender, está em Propriedades de Renderização → Gestão de Cor → View Transform. O padrão é Filmic. Se o viewport da estação de trabalho mostra Filmic mas o ficheiro de cena guardado está definido como Standard (ou vice-versa), a saída renderizada usa o valor guardado, não o estado do viewport. No Maya, o equivalente é Gestão de Cor em Definições de Renderização → Comum (com ACES, sRGB ou Raw como opções comuns). No 3ds Max, verificar as definições de Gamma e LUT em Personalizar → Preferências → Gamma e LUT. No Cinema 4D, consultar Definições de Renderização → Saída → Perfil de Cor. O viewport pode mostrar uma transformação enquanto o ficheiro guardado especifica outra — o renderizador usa o valor guardado.
2. Marcação do espaço de cor das texturas. As texturas usadas como dados de cor (difusa, albedo, cor base) devem ser marcadas como sRGB ou Cor. As texturas usadas como dados (mapas normais, rugosidade, deslocamento, metálico, opacidade) devem ser marcadas como Non-Color, Linear ou Raw. Um mapa normal marcado como sRGB causará uma deriva de iluminação subtil mas generalizada — a matemática não funciona corretamente quando a textura passa por uma curva de gamma extra. Verificar através do grafo de shaders ou do browser de texturas antes da submissão. Esta é a causa mais comum dos tickets de "a minha renderização parece desbotada".
3. Deriva da configuração OCIO. Se a estação de trabalho usa uma configuração OCIO personalizada — ACES 1.3, AgX, uma configuração específica do estúdio — os ficheiros de configuração OCIO devem ser incluídos no arquivo do projeto, e o ficheiro de projeto deve referenciá-los através de um caminho relativo (não um caminho absoluto que só existe na máquina local). Quando o worker arranca e lê a cena, procura a configuração OCIO no caminho especificado pelo ficheiro de cena. Se o ficheiro não estiver lá, o renderizador reverte silenciosamente para a sua configuração padrão (tipicamente Filmic para Blender, sRGB para a maioria dos outros), e as cores derivam.
4. O formato de saída incorpora cor de forma diferente do esperado. Os formatos de saída que não transportam metadados de espaço de cor — PNG, JPEG, BMP — gravam a transformação de ecrã nos valores de píxeis. O EXR (linear, 32 bits) preserva os dados brutos referenciados à cena e aplica a transformação de visualização na fase de composição. Se comparar uma saída PNG da render farm com uma saída EXR da mesma renderização, parecem diferentes propositadamente. Não é um erro; é como os formatos funcionam. Quando ambos são visualizados com a View Transform correspondente aplicada no compositor, devem corresponder.
5. Deriva de exposição ou pós-processamento. Alguns DCCs guardam um "look" de pós-processamento ou compensação de exposição no ficheiro de cena mas aplicam-no de forma diferente na renderização. Verificar o nó de saída de renderização, a definição de exposição da câmara e quaisquer nós de composição downstream da camada de renderização. Uma exposição de viewport de −0,5 EV que não se aplica em tempo de renderização produzirá uma renderização meio ponto mais brilhante do que o esperado.

O teste de diagnóstico que recomendamos em todos os tickets de brilho: renderizar um fotograma da cena problemática na estação de trabalho com as mesmas definições da submissão à render farm. Se o local corresponder à render farm, a gestão de cor da cena está configurada de forma intencional — o viewport apenas mostra uma interpretação diferente. Se o local diferir da render farm, verificar primeiro a inclusão da configuração OCIO e as marcações de espaço de cor das texturas.

Câmara não detetada ou "nenhuma câmara na cena"

O renderizador não consegue encontrar uma câmara de onde renderizar. O trabalho aborta antes de produzir fotogramas, ou a saída está vazia / é o viewport padrão. Três causas comuns:

1. Nenhuma câmara marcada como renderizável. No Maya, Definições de Renderização → Comum → Câmaras Renderizáveis determina qual câmara renderiza. O padrão é persp, que é a vista em perspetiva do viewport de modelação — raramente o que se pretende para uma imagem final. Definir o indicador de renderizável na câmara pretendida. No Blender, a câmara ativa da cena (Propriedades → Propriedades da Cena → Câmara) é a que renderiza, e apenas essa. No Cinema 4D, o campo Definições de Renderização → Saída → Câmara substitui qual câmara renderiza se estiver definido; caso contrário é usada a câmara ativa do editor. No 3ds Max, Configuração de Renderização → Comum → Câmara (ou o menu suspenso Vista) seleciona a câmara de renderização.
2. A câmara renderizável está oculta. Em alguns DCCs (notavelmente Maya), uma câmara que está oculta no outliner ainda é renderizável desde que esteja marcada como renderizável nas Definições de Renderização. Noutros (notavelmente Blender, onde a câmara ativa deve estar visível para o modo "Vista de Câmara" do viewport funcionar), ocultar a câmara não afeta diretamente a renderização — mas se a cena foi recentemente reestruturada, verificar se a câmara esperada está na cena ativa e não numa coleção, camada de renderização, take ou cena separada que não está selecionada.
3. Viewport bloqueado substitui a câmara renderizável. No 3ds Max e no Maya, um padrão de "viewport bloqueado" pode fazer o renderizador usar a câmara atual do viewport em vez da câmara pretendida. Isto aparece como "nenhuma câmara" (se o viewport estiver numa vista em perspetiva sem câmara que o renderizador rejeita) ou "câmara errada" (a secção seguinte). Desbloquear o viewport antes da submissão, ou definir explicitamente Vista para Renderizar na Configuração de Renderização.

Para configuração de câmara específica de cada DCC, consultar , , , ou .

A cena renderizada não tem luzes

A geometria renderiza, mas a cena está completamente escura, ou a iluminação é muito mais escura do que o esperado — frequentemente com aspeto de wireframe sobre preto que sugere que nenhuma luz atinge as superfícies.

Quatro aspetos a verificar:

1. As luzes estão desativadas na visibilidade de renderização. No Maya, as luzes têm um indicador de visibilidade por renderização no Editor de Atributos (Visibilidade → Renderização). Uma luz visível no outliner pode ainda estar excluída do cálculo em tempo de renderização. No Blender, a visibilidade de renderização do objeto de luz (o ícone de câmara no outliner) controla se a luz contribui para a renderização — separado do ícone de olho do viewport.
2. As luzes estão numa Camada de Vista, Camada de Renderização ou Coleção oculta. Uma luz que é visível no viewport mas atribuída a uma camada não renderizada não contribuirá. Verificar se as luzes estão na camada ou coleção que está a ser renderizada, não numa camada paralela que está oculta em tempo de renderização.
3. A iluminação de ambiente está desativada. Se a cena depende de iluminação de ambiente HDRI — comum em archviz e visualização de produto — verificar se o ambiente está ativado nas Propriedades de Renderização. No Blender, Mundo → Superfície deve ter a Textura de Ambiente ou shader de Fundo ligados. No Maya, o nó de ambiente do Hypershade deve estar ligado ao slot de ambiente em tempo de renderização da cena. No 3ds Max, Ambiente e Efeitos (atalho de teclado 8) deve ter o HDRI atribuído, e no V-Ray, a sobreposição de Ambiente V-Ray é uma definição separada que substitui o ambiente da cena.
4. GI ou Iluminação Indireta está desativada. Para V-Ray e Corona, a Iluminação Global é uma definição separada de "luzes presentes na cena". Uma cena projetada para ricochetes GI mas com GI desativado no preset de renderização ativo parecerá escura mesmo que todas as luzes diretas estejam corretamente configuradas. No V-Ray, GI → Ativar iluminação global deve estar ativado. No Corona, GI → Solucionador deve estar definido (Path tracing ou UHD Cache). No Redshift, GI → Ativar GI deve estar ativado. Consultar o para a configuração de cache GI específica do motor que se segue a esta ativação.

Um teste de diagnóstico rápido: adicionar temporariamente uma única luz Solar ou Direcional com intensidade 1,0 de cima da cena e renderizar um fotograma. Se nem isso aparecer na saída, o problema é de visibilidade de camada ou coleção, não de configuração de fonte de luz. Se o sol de teste renderizar corretamente, as luzes originais são o problema — trabalhar através das quatro verificações acima.

Renderiza câmara errada apesar de especificar a correta

Foi definida a Câmara A como câmara de renderização, mas a saída mostra a vista da Câmara B. Este é um dos problemas de qualidade mais frustrantes porque o ficheiro de cena parece correto à inspeção — o indicador de renderizável está na câmara certa, a câmara ativa é a pretendida. A causa é quase sempre uma de três coisas:

1. Vista bloqueada no viewport no 3ds Max ou Maya. Um viewport bloqueado (clique com botão direito na etiqueta do viewport → Bloquear) substitui a seleção de câmara da Configuração de Renderização. O renderizador usa a câmara do viewport, não a configurada. Desbloquear o viewport antes de guardar a cena, ou definir explicitamente Vista para Renderizar na Configuração de Renderização → Comum (Maya) ou Configuração de Renderização → Saída (3ds Max). Esta é a causa mais comum de tickets de "câmara errada" nas submissões de 3ds Max — o bloqueio é fácil de definir acidentalmente com um atalho de teclado e fácil de ignorar antes da submissão.
2. Cena com múltiplas câmaras com a câmara ativa errada. Se a cena tem múltiplas câmaras — turntable, principal, beauty, detalhe, alternativas — verificar qual está definida como câmara ativa para a cena atual, take ou camada de renderização. No Cinema 4D, cada Take pode ter a sua própria câmara; no Blender, cada cena tem a sua própria câmara ativa; no Maya, as camadas do Render Setup podem substituir a câmara por camada. A câmara que renderiza é a câmara atribuída ao nível de camada / take / cena submetido, não a que foi selecionada por último no viewport.
3. Incompatibilidade de Take, cena ou camada de renderização. A Camada de Renderização A foi submetida mas herda a câmara do Master, e a câmara do Master é a Câmara B? Acontece. Submeter sempre a partir do take ou camada que tem explicitamente a câmara pretendida, e evitar depender de herança a não ser que se tenha verificado a cadeia.

A imagem de saída é parcial, cortada ou não preenche o fotograma completo

A imagem renderizada é devolvida mas apenas parte do fotograma está preenchida — o resto é preto, transparente ou repete a cor do viewport. Quatro aspetos a verificar:

1. Renderização de Região está ativada. No V-Ray, Corona, Arnold e vários outros renderizadores, uma opção "Região" permite renderizar apenas um sub-retângulo do fotograma completo para pré-visualização rápida. Se Região estava ativada durante os testes locais e não foi desativada antes da submissão, o worker renderiza apenas essa região — o resto do fotograma permanece na cor de preenchimento padrão. Esta é a causa mais comum de tickets de saída de fotograma parcial.
2. Incompatibilidade de resolução de saída entre cena e definição de renderização. A resolução de saída das Propriedades de Renderização e o tamanho real do fotograma no ficheiro de saída devem corresponder. Se a abertura da câmara da cena está definida para uma resolução e a saída está definida para outra, o renderizador pode produzir um preenchimento parcial — a câmara "vê" uma área mais pequena do que a área de saída, e a região vazia permanece sem cor.
3. Incompatibilidade de proporção de aspeto entre câmara e saída. Uma câmara com proporção 1,78 a renderizar para uma saída 1,0 produzirá uma imagem parcial — a vista da câmara não preenche o fotograma de saída. Verificar se a proporção de suporte de filme da câmara corresponde à proporção de saída, ou se "Ajustar Gate de Resolução" (ou o equivalente — os DCCs nomeiam isto de forma diferente: "Ajuste do Gate de Resolução", "Abertura da Câmara", "Gate de Filme") está definido para preencher, horizontal, vertical ou overscan conforme a imagem requerer.
4. Definições de border ou corte no formato de saída. Alguns DCCs e alguns formatos de saída permitem definir um border de renderização independente do gate de resolução da câmara. Verificar se o border (nas Propriedades de Renderização, ou nos atributos da câmara) abrange toda a área de saída pretendida, não uma sub-região cortada.

Renderizações pretas ou em branco

A renderização completa com sucesso — sem erros, sem avisos — mas todos os píxeis são pretos ou completamente uniformes. Mais comum no Maya, mas vemos em todos os DCCs.

Cinco aspetos a verificar:

1. Incompatibilidade de alternância de camadas. No Maya, a geometria pode ser visível no viewport mas desativada ao nível de visibilidade de renderização (Exibir → Ocultar → Ocultar Todas as Câmaras, ou Estatísticas de Renderização por objeto → Visibilidade Primária = desligado). No Blender, o equivalente é a alternância de visibilidade de renderização (ícone de câmara) no outliner. A causa mais comum é reestruturar as camadas de uma cena após os testes e esquecer de ativar a visibilidade de renderização na nova camada ou coleção.
2. Planos de recorte da câmara definidos incorretamente. Se o plano de recorte próximo ou distante estiver definido errado — plano distante demasiado próximo da câmara, plano próximo atrás da geometria — a câmara não inclui a geometria no seu frustum de visão. Os planos padrão (próximo 0,1, distante 1000–10000 dependendo da escala da cena) são geralmente adequados; isto acontece após ajuste manual, especialmente ao trabalhar em escalas de cena incomuns (grandes conjuntos arquitetónicos ou renders de produto microscópicos).
3. Luzes renderizáveis mas emissão desativada. Se estiver a usar materiais emissivos como luzes, verificar se o shader de emissão está ativado e tem força diferente de zero. Alguns fluxos de trabalho desativam a emissão durante a interação no viewport para evitar aquecimento da GPU e esquecem de a reativar antes da submissão.
4. Amostragem demasiado baixa para produzir saída visível. Com reduções agressivas de amostragem de path trace (amostras por píxel muito baixas), cenas muito escuras podem produzir saída completamente preta até as amostras aumentarem o suficiente para convergir. Renderizar um único fotograma localmente com as mesmas definições para verificar; se a renderização local também estiver completamente preta com a mesma contagem de amostras, aumentar a amostragem ou verificar a configuração de iluminação.
5. Nó de saída de renderização mal configurado (Blender, Houdini). No compositor do Blender e na rede ROP do Houdini, a cadeia de nós de saída pode ser configurada para descartar o resultado da renderização antes de guardar. Verificar se o nó Composite está ligado a Render Layers (Blender) ou se o caminho de saída do ROP está definido corretamente e o modo de saída não é "Nulo" (Houdini).

Para Maya especificamente, consultar para o fluxo de trabalho de seleção de câmara e estatísticas de renderização que previne a causa mais comum de renderizações pretas nesse DCC.

Alguns objetos da cena não estão a renderizar

Um objeto específico é visível no viewport mas está em falta na saída renderizada. O resto da cena renderiza corretamente. Comum em todos os DCCs, ligeiramente mais comum no Blender porque o modelo de visibilidade triplo do Blender (viewport / renderização / seleção) é fácil de configurar incorretamente.

Cinco aspetos a verificar:

1. Alternância de visibilidade de renderização no objeto. No outliner do Blender, passar o rato sobre a linha do objeto — três ícones controlam a visibilidade: olho (viewport), câmara (renderização), ecrã (selecionabilidade). Garantir que o ícone de câmara está ativado para o objeto em falta. No Maya, Editor de Atributos → Estatísticas de Renderização → Visibilidade Primária deve estar ativado. No 3ds Max, Propriedades do Objeto → Renderização → Visibilidade deve estar definido acima de 0 (e Renderizável deve estar marcado).
2. O objeto está numa coleção, camada ou conjunto oculto. As coleções no Blender têm visibilidade separada de viewport e renderização. A coleção pode ser visível no viewport mas excluída da renderização via a alternância do ícone de câmara na linha da coleção. No Maya, a atribuição de Camada de Exibição e a atribuição de Camada de Renderização do objeto são separadas; no 3ds Max, Propriedades de Camada → Renderizável deve estar ativado para cada camada que contém geometria renderizável.
3. O material do objeto é invisível. Um material com opacidade zero, alfa zero, ou problemas de mistura de alfa renderizará como efetivamente invisível — a geometria está lá mas é transparente. Verificar a opacidade, alfa, transparência e quaisquer definições de mistura de alfa do material. Armadilha comum: um material que foi configurado para referência "fantasma" no viewport e nunca restaurado antes da submissão.
4. A pilha de modificadores oculta a geometria. Alguns modificadores (Booleano, Máscara, Decimate com definições extremas, Build) podem efetivamente eliminar geometria da saída de renderização mesmo que a malha de origem seja visível no modo viewport da pilha de modificadores. Desativar os modificadores um de cada vez no objeto em falta para identificar qual é o culpado, depois corrigir as definições do modificador ou aplicar / gravar antes da submissão.
5. O objeto é um proxy ou instância com referência quebrada. Os objetos proxy (V-Ray Proxy, Redshift Proxy, Arnold Standin), as caches Alembic e as instâncias referenciam ficheiros externos. Se o caminho de referência estiver quebrado — caminho absoluto errado, ficheiro em falta no arquivo, partilha de rede que não existe no worker — o proxy renderiza como nada. Isto sobrepõe-se com §Recursos em falta abaixo; consultar essa secção para o fluxo de trabalho completo de verificação de caminhos.

Configurações incorretas da cache GI, irradiância e cache de luz

Esta secção sobrepõe-se com o mas cobre os sintomas que se manifestam como problemas de qualidade em vez de problemas de desempenho. Se a renderização devolver cintilação entre fotogramas, iluminação indireta manchada, banding em áreas escuras, ou iluminação visivelmente diferente em fotogramas adjacentes da mesma animação, a causa é quase sempre uma configuração de cache GI que não sobrevive à renderização distribuída.

O problema central: as caches GI no V-Ray (Mapa de Irradiância, Cache de Luz), Corona (UHD Cache, Path tracing) e Redshift (Cache de Irradiância, Mapa de Fotões) são conjuntos de dados de iluminação pré-computados. Ao renderizar uma animação, a cache deve ser (a) pré-computada uma vez e reutilizada em todos os fotogramas, ou (b) computada por fotograma com qualidade suficientemente alta para parecer idêntica fotograma a fotograma. Misturar os dois — deixar cada worker computar a sua própria cache por fotograma com baixa qualidade — produz cintilação visível, porque o padrão de ruído de cada worker é diferente.

Quatro configurações incorretas comuns e o que fazer:

1. Modo GI por fotograma em animação. O modo "Fotograma único" do V-Ray para Mapa de Irradiância e Cache de Luz computa uma cache nova para cada fotograma. Numa render farm distribuída, cada worker computa a sua própria — não as partilham. O resultado é cintilação de animação. Mudar para "Multi-quadro Incremental" com o ficheiro de cache guardado em disco, ou pré-computar a cache como um pré-passo separado e usar "A partir de ficheiro" para o passo de animação real. Consultar o para o fluxo de trabalho completo.
2. O caminho do ficheiro de cache é local e está em falta nos workers. Se foi guardado um Mapa de Irradiância pré-computado em C:\Utilizadores\NomeUtilizador\Documentos\mapas\ir.vrmap e o trabalho foi submetido, os workers não têm esse ficheiro. Revertam para cálculo por fotograma (a primeira causa acima) e a animação cintila. Guardar os ficheiros de cache na pasta do projeto, usar caminhos relativos, e incluir os ficheiros de cache no arquivo do projeto antes da submissão.
3. Qualidade de cache demasiado baixa para a cena. Mesmo quando configurada corretamente (pré-computada, incluída no arquivo), uma Cache de Luz com 500 subdivisões ou Mapa de Irradiância na qualidade "Muito Baixa" pode ser insuficiente para uma cena de archviz escura com GI pesado. As renderizações ficam com aspeto de ruído ou manchas, especialmente em cantos e sob mobiliário. Aumentar as subdivisões ou usar o preset Universal como linha de base.
4. UHD Cache reutilizada entre câmaras incompatíveis. A UHD Cache (Corona, V-Ray) é dependente da vista da câmara. Uma cache pré-computada para a Câmara A e reutilizada na Câmara B produzirá iluminação errada — a cache "pensa" que a câmara está num lugar onde não está. Se renderizar múltiplas câmaras da mesma cena, pré-computar uma UHD Cache por câmara, ou usar Path tracing (sem cache) para consistência entre câmaras.

Para configuração completa de cache GI, notas de versão para V-Ray 6.x e o fluxo de trabalho de pré-cálculo que é enviado limpo para a render farm, consultar o .

Recursos em falta — texturas, proxies, referências, plugins

A renderização completa mas partes da cena estão obviamente erradas: as texturas são cor-de-rosa (padrão do Maya para textura em falta), roxas (padrão do V-Ray), em xadrez (Arnold) ou magenta sólido (Blender). Os proxies renderizam como caixas delimitadoras ou espaço vazio. Materiais específicos renderizam como o marcador de "em falta" do motor.

A causa é a resolução de caminhos. O ficheiro de cena referencia recursos por caminho, e no worker, esses caminhos não resolvem. Seis aspetos a verificar:

1. Caminhos absolutos no ficheiro de cena. Se a cena referencia texturas em C:\Utilizadores\NomeUtilizador\Projeto\texturas\madeira.jpg, o worker não tem esse caminho. Usar caminhos relativos (./texturas/madeira.jpg ou ../texturas/madeira.jpg) ou empacotar os recursos no ficheiro de cena. A maioria dos DCCs tem um fluxo de trabalho "Tornar Caminhos Relativos" ou "Recolhedor de Recursos" que converte caminhos absolutos em relativos antes da submissão — Editor de Caminhos de Ficheiros do Maya, Controlo de Recursos do 3ds Max, Ficheiro → Dados Externos → Tornar Caminhos Relativos do Blender, Ficheiro → Guardar Projeto com Recursos do Cinema 4D, Pré-script de Renderização do Houdini com hou.findFile.
2. Recursos não incluídos no arquivo do projeto. Os caminhos relativos ajudam, mas apenas se os recursos que referenciam estiverem efetivamente presentes no arquivo carregado. Executar a ferramenta de consolidação de projeto do DCC (ou simplesmente comprimir toda a pasta do projeto incluindo texturas, caches, referências e HDRIs) antes da submissão. Não confiar que tudo foi carregado — verificar com uma comparação de lista.
3. Incompatibilidade de maiúsculas/minúsculas. O Windows não distingue maiúsculas/minúsculas (Textura.JPG e textura.jpg são o mesmo ficheiro); os workers da render farm executam Linux, que distingue maiúsculas/minúsculas (são ficheiros diferentes). Um ficheiro de cena que referencia Textura.JPG não encontrará textura.jpg num worker Linux. A maioria dos DCCs usa minúsculas nos caminhos ao exportar — mas nem sempre. Se vir texturas específicas em falta apenas na render farm, verificar as maiúsculas/minúsculas do nome real do ficheiro face às maiúsculas/minúsculas na referência do ficheiro de cena.
4. Plugin não instalado nos workers. Se a cena depende de um plugin de terceiros — Forest Pack, RailClone, Phoenix FD, MultiScatter, GrowFX, Ornatrix — o worker deve ter esse plugin instalado na mesma versão. Pré-instalamos os principais plugins, mas verificar se a versão específica é suportada consultando o documento do DCC relevante. Se o plugin não for suportado, será necessário gravar a saída do plugin (dispersão para malha, cabelo para malha) antes da submissão, ou escalar para o suporte.
5. Cenas vinculadas ou referenciadas com caminhos quebrados. Se a cena principal referencia uma sub-cena (referência Maya, Biblioteca Vinculada Blender, Cena XRef 3ds Max), e o caminho da sub-cena é absoluto ou externo ao arquivo, o worker não consegue encontrá-la. As sub-cenas devem estar no arquivo e referenciadas de forma relativa, tal como as texturas.
6. Incompatibilidade de versão de recursos. Menos comum mas vale a pena verificar: uma cena guardada no Maya 2026 com recursos que dependem de tipos de nó específicos do Maya 2026 não renderizará corretamente num worker a executar o Maya 2024. Corresponder a versão de guardação da cena à versão do worker listada no documento configurar-* relevante.

Se foram verificados os seis aspetos e os recursos ainda estão em falta, a equipa de suporte pode obter o registo do worker em tempo de renderização do trabalho e identificar exatamente qual caminho de recurso falhou ao resolver. Esse registo restringe a causa de "algo está em falta" para "este ficheiro específico neste caminho específico".

Deriva de cor em saídas EXR vs PNG da mesma renderização

A mesma cena foi renderizada para EXR e PNG e as cores não correspondem. Isto é geralmente comportamento esperado em vez de um erro, mas surpreende pessoas com frequência suficiente para merecer a sua própria secção.

O EXR armazena dados de ponto flutuante linear sem uma transformação de cor incorporada. O PNG (e JPEG, BMP) incorpora a transformação de ecrã nos valores de píxeis. Ao visualizar o EXR num compositor com a transformação de ecrã Filmic, ACES, sRGB ou AgX correspondente aplicada, deve corresponder ao PNG visualmente — os dados subjacentes são os mesmos, mas a codificação é diferente.

Duas situações em que isto se torna um problema real:

1. A gestão de cor do compositor difere da gestão de cor do DCC. Se for renderizado um EXR com View Transform ACES aplicado no DCC, e depois o EXR for aberto num compositor (Nuke, Fusion, After Effects, Resolve) configurado para sRGB ou sem gestão de cor, o resultado exibido será diferente. Configurar o compositor para usar o mesmo View Transform / configuração OCIO que o DCC. Este é um dos problemas mais comuns de integração de compositor que vemos — o EXR está correto, o compositor está a interpretá-lo erradamente.
2. O PNG foi guardado com uma View Transform diferente do EXR. Alguns DCCs permitem substituições de View Transform por formato. Se o EXR estiver definido como "Raw" e o PNG como "sRGB" nas mesmas definições de saída da cena, produzirão resultados visualmente diferentes da mesma renderização, propositadamente. Verificar as definições de saída por formato e normalizar numa única transformação a menos que seja especificamente necessária variação por formato.

Fluxo de diagnóstico geral

Quando surge um problema de qualidade de renderização, percorrer estes passos por ordem. A maioria dos tickets resolve-se nos passos 1–3 sem escalada.

1. Reproduzir localmente. Renderizar um fotograma da cena problemática na estação de trabalho com as mesmas definições da submissão à render farm. Se o local corresponder à render farm, o problema está na cena — corrigir a cena. Se o local diferir da render farm, o problema é ambiental: caminho, versão de plugin, configuração OCIO ou arquivo de recursos.
2. Verificar Gestão de Cor e View Transform. Esta é a causa de ~40% dos problemas de qualidade que vemos na linha de suporte.
3. Verificar a seleção de câmara nas Definições de Renderização. ~20% — câmara errada, viewport bloqueado, incompatibilidade de camada ou take.
4. Verificar Região de Renderização, Border ou Corte. ~10% — saída parcial.
5. Verificar visibilidade de Camada, Coleção ou Camada de Renderização. ~15% — objetos em falta, luzes em falta, cenas escuras.
6. Verificar marcação de espaço de cor das texturas. ~10% — deriva de brilho subtil mas generalizada.
7. Verificar configuração de cache GI para cintilação de animação. ~3% — consultar o .
8. Verificar caminhos de recursos e integridade do arquivo. ~2% — texturas cor-de-rosa, proxies em falta.

Se os passos 1–8 não identificarem a causa, a equipa de suporte obterá o registo do worker para o trabalho e restringirá a causa a um estado específico da frota de workers, uma incompatibilidade de versão do renderizador, ou um problema de configuração que podemos resolver do nosso lado. Enviar uma mensagem de suporte com o ID do trabalho, a saída errada e uma descrição do que era esperado — isso é suficiente para iniciar o rastreio.

Referências cruzadas

• — resolução de problemas de falhas de trabalhos (o trabalho não foi concluído de todo)
• — fluxo de upload, envio, download
• — configuração de cache GI, Mapa de Irradiância, Cache de Luz, UHD Cache
• — empacotamento de arquivo de projeto, consolidação de recursos, prevenção de recursos em falta
• — câmara Maya, camada de renderização, configuração de estatísticas de renderização
• — bloqueios de câmara 3ds Max, renderização de região, definições de Gamma e LUT
• — sistema Take do Cinema 4D, tags de câmara, perfil de cor
• — visibilidade de renderização Blender, gestão de cor, Filmic vs AgX
• — gestão de cor AE para saída de renderização de composição
• — referência de câmara ROP do Houdini, configuração de nó de saída

FAQ

Q: A renderização devolveu resultado mais escuro do que o viewport. O que mudou? A: Quase sempre uma incompatibilidade de Gestão de Cor ou View Transform. A transformação de cor do ficheiro de saída reflete as definições guardadas de Propriedades de Renderização → Gestão de Cor, não o estado atual do viewport. Verificar se View Transform (Filmic, AgX, Standard, sRGB, ACES) e as definições de Aspeto estão guardadas corretamente no projeto antes da submissão, e que a marcação de espaço de cor das texturas é consistente (sRGB para texturas de cor, Non-Color para texturas de dados).

Q: A renderização devolveu resultado sem iluminação. A cena tem luzes, podem ver-se no viewport. A: Verificar quatro aspetos por ordem: (1) a alternância de visibilidade de renderização de cada luz (separada da visibilidade do viewport); (2) em que Camada de Renderização, Camada de Vista ou Coleção as luzes estão, e se essa camada está ativada para renderização; (3) se o ambiente HDRI está ativado nas Propriedades de Renderização ou no shader Mundo; (4) se GI ou Iluminação Indireta está ativada nas definições de renderização ativas para motores que a controlam separadamente (V-Ray, Corona, Redshift).

Q: A câmara errada renderizou apesar de ter selecionado a correta nas Definições de Renderização. A: Muito provavelmente uma condição "Vista Bloqueada" no 3ds Max ou Maya — um viewport bloqueado substitui a seleção de câmara das Definições de Renderização. Desbloquear o viewport, ou definir explicitamente Vista para Renderizar na Configuração de Renderização do DCC antes da submissão. Verificar também se o Take, Cena ou Camada de Renderização submetida tem a câmara pretendida ao nível da camada, uma vez que alguns DCCs herdam câmara de um pai.

Q: Por que é que as saídas EXR e PNG da mesma renderização parecem diferentes? A: O EXR armazena dados de ponto flutuante linear sem uma transformação de ecrã incorporada; o PNG incorpora a transformação de ecrã nos valores de píxeis. Ao visualizar o EXR num compositor com a View Transform correspondente aplicada, deve parecer igual ao PNG. Se parecerem diferentes no compositor, a gestão de cor do compositor não corresponde à do DCC — configurar o compositor para usar o mesmo perfil OCIO e View Transform.

Q: Um objeto específico está em falta na renderização mas visível no viewport. A: Verificar (1) o indicador de visibilidade de renderização do objeto (separado da visibilidade do viewport — ícone de câmara no Blender, Visibilidade Primária no Maya, Renderizável no 3ds Max); (2) a visibilidade da Coleção, Camada de Renderização ou Camada de Exibição onde o objeto reside; (3) se algum modificador (Booleano, Máscara, Decimate) está a ocultar a geometria em tempo de renderização; (4) se o objeto é um proxy com referência externa quebrada (consultar também a secção Recursos em falta).

Q: A renderização devolveu resultado parcial ou cortado. Metade do fotograma está preto. A: Verificar se Renderização de Região (ou Border, Corte) está ativada no renderizador. A renderização de região produz um preenchimento parcial do fotograma de saída. Desativar Região antes da submissão, ou defini-la para o fotograma completo. Verificar também se a proporção de aspeto da câmara corresponde à proporção de saída, e se a resolução de saída nas Propriedades de Renderização corresponde à resolução de suporte de filme da câmara.

Q: As texturas ficam desbotadas ou sobressaturadas em comparação com a estação de trabalho. A: Marcação de espaço de cor das texturas. As texturas de cor (difusa, albedo, cor base) devem ser marcadas como sRGB ou Cor; as texturas de dados (normal, rugosidade, deslocamento, metálico, opacidade) devem ser marcadas como Non-Color, Linear ou Raw. As texturas com marcação incorreta causam deriva de cor subtil mas consistente, especialmente em materiais PBR onde o gamma do mapa normal importa.

Q: A configuração ACES OCIO está definida na estação de trabalho. A render farm respeita-a? A: Sim, se os ficheiros de configuração OCIO estiverem incluídos no arquivo do projeto e o ficheiro de projeto referenciar a configuração através de um caminho relativo. Se os ficheiros de configuração OCIO estiverem em falta no arquivo, o worker reverte para a configuração padrão do DCC (tipicamente Filmic para Blender, sRGB para a maioria dos outros), e as cores derivarão. Incluir sempre a pasta de configuração OCIO no arquivo do projeto.

Q: A animação cintila — cada fotograma parece ter iluminação indireta diferente. A: Configuração incorreta da cache GI. No V-Ray, mudar do Mapa de Irradiância em "Fotograma único" para "Multi-quadro Incremental" com a cache guardada em disco, e pré-computar a cache como um pré-passo ou usar o preset Universal de Path tracing. Para outros motores, consultar as definições de cache GI correspondentes — a regra é a mesma: pré-computar uma vez e reutilizar, ou usar um modo sem cache (Path tracing) para consistência entre fotogramas. Consultar o para o fluxo de trabalho completo.

Q: As texturas renderizam como cor-de-rosa, roxo ou magenta na render farm. A: Recursos em falta. O ficheiro de cena referencia texturas em caminhos que o worker não consegue resolver — geralmente caminhos absolutos Windows (C:\Utilizadores\...), recursos não incluídos no arquivo do projeto, ou incompatibilidades de maiúsculas/minúsculas entre o sistema de ficheiros Windows e o sistema de ficheiros Linux do worker. Usar caminhos relativos, executar a ferramenta de consolidação de projeto do DCC antes da submissão, e verificar se o arquivo inclui todas as texturas referenciadas.

Q: A cena Forest Pack / Phoenix FD / Ornatrix devolveu os objetos de plugin em falta. A: Incompatibilidade de versão ou compatibilidade de plugin no worker. Verificar o documento ou relevante para as versões de plugin suportadas na frota de workers. Se a versão for suportada, a cena deve renderizar corretamente — se não, gravar a saída do plugin para malha antes da submissão, ou contactar o suporte para verificar o estado de instalação da versão específica do plugin.

---