Skip to main content

A minha renderização na render farm é diferente da minha renderização local

Uma renderização da Super Renders Farm regressa completa — sem erro, sem aviso de ficheiro em falta — mas não corresponde ao que viu no seu preview local. As cores saem diferentes, o frame inteiro está desbotado ou demasiado escuro, o padrão de grão ou ruído não corresponde ao do seu render local com a mesma contagem de samples, ou um elemento específico parece ligeiramente errado em vez de obviamente partido. Nada falhou aqui — o frame simplesmente não corresponde, o que pode ser mais inquietante do que uma renderização que falha de forma clara.

Este guia aborda o aspeto de uma renderização diferente-mas-completa, as três causas estruturais mais comuns, o que a nossa validação verifica e não verifica para isto, e como corrigir e prevenir. Se parte do seu frame está completamente preto, rosa vivo, ou claramente sem detalhe, veja antes texturas ou assets em falta no seu render — esse é um modo de falha relacionado mas distinto.

O aspeto do problema

  • Cores desviadas ou com um tom errado — um material, ou o frame inteiro, apresenta um equilíbrio de cor diferente do seu preview local, sem nada obviamente partido.
  • Desbotado, ou demasiado escuro ou demasiado claro no geral — a imagem inteira está uniformemente mais clara ou mais achatada do que o esperado, não apenas um objeto ou uma área.
  • O padrão de grão ou ruído lê-se de forma diferente, mesmo que o frame tenha terminado com a contagem de samples ou a definição de denoiser que esperava.
  • Um elemento está subtilmente errado, não em falta — a contribuição de uma luz parece mais fraca do que deveria, ou uma variante de material parece ligeiramente errada — distinto das manchas completamente pretas ou dos placeholders rosa choque que significam que um ficheiro não chegou de todo.

Trate qualquer um destes casos primeiro como um problema de gestão de cor, de build, ou de encaminhamento de hardware, não como uma renderização falhada. O trabalho normalmente terminou exatamente como foi instruído — só foi instruído de forma ligeiramente diferente da sua configuração local.

Porque acontece

Três causas estruturais explicam a maior parte do que o suporte vê aqui. Os mecanismos são bem compreendidos; não temos dados confirmados sobre qual ocorre mais frequentemente, pelo que deve tratá-las como igualmente comuns, e não como uma lista ordenada por frequência.

Ficheiros de cor e de assets não incluídos no upload

As configurações OCIO, as LUTs, as caches de textura .tx, os perfis de luz IES, os tiles UDIM, e as referências internas de proxies do motor de renderização normalmente são guardados na sua cena como caminhos, não como dados incorporados. Uma textura totalmente em falta tende a renderizar a preto sólido ou rosa choque vivo — difícil de não notar. Uma configuração OCIO em falta ou uma cache .tx desatualizada é mais discreta: a renderização recorre a uma transformação de cor diferente, ou capta a versão errada do espaço de cor de uma textura, e o frame fica apenas com um aspeto ligeiramente diferente em vez de obviamente partido.

Correção: inclua a configuração OCIO junto com a respetiva pasta luts/ como uma única unidade — nunca uma sem a outra — e inclua as caches .tx e de proxy junto com a sua cena, não apenas os ficheiros de origem a partir dos quais foram geradas.

Incompatibilidade de build do motor de renderização entre a sua máquina e o nó de renderização

Uma diferença de versão menor ou de build no mesmo motor de renderização pode alterar o comportamento predefinido de sampling, filtragem ou inicialização, mesmo quando o trabalho é concluído sem erro. As diferenças de versão entre o build de submissão e o nó de renderização são uma causa bem conhecida deste tipo de incompatibilidade silenciosa.

Correção: diga-nos o seu build exato do motor de renderização — não apenas "V-Ray" ou "Arnold", mas o número de versão — sempre que não tiver a certeza, para que possamos atribuir o seu trabalho a um nó de renderização compatível antes do upload. Confirme a sua versão na matriz de versões e plugins suportados.

Gestão de cor que não viaja com a cena, mais o gamma

A sua cena guarda um caminho para a sua configuração OCIO, não a configuração em si. Se não for incluída no upload, a render farm recorre a uma transformação de cor diferente e cada pixel do frame muda — não apenas um material, o que é um bom indício de que esta é a causa, e não um asset em falta. A definição de gamma de visualização do 3ds Max (1.0 vs 2.2) comporta-se da mesma forma: uma incompatibilidade clareia ou escurece o frame inteiro de forma uniforme.

Correção: incorpore ou empacote a configuração OCIO — com as respetivas LUTs — no seu upload, em vez de a deixar como referência externa, e confirme que a sua definição de gamma de visualização corresponde entre a sua estação de trabalho e o que submete.

Mais um padrão que vale a pena conhecer, menos comum do que os três acima: um denoiser exclusivo para GPU pode não fazer nada, silenciosamente, quando o seu trabalho é atribuído a um nó de CPU — vai ver grão ou ruído extra onde esperava um frame limpo e sem ruído, não um elemento em falta. Escolha um denoiser que o seu hardware de destino realmente suporte, ou confirme que o seu trabalho está a ser encaminhado para um nó de GPU, caso o denoiser precise de um.

O que a nossa validação deteta — e o que não deteta

Correm duas verificações entre o seu upload e o seu primeiro frame — uma verificação no momento da submissão e uma análise da cena do lado da render farm — cobertas na íntegra em texturas ou assets em falta no seu render. Nenhuma delas valida a gestão de cor (OCIO ou LUTs), o gamma de visualização, ou a paridade de build do motor de renderização. Estas situações não geram um erro de ficheiro em falta; produzem um frame que renderiza sem problemas mas com um aspeto diferente. É exatamente por causa dessa lacuna que as causas acima são comuns, e por isso confirmar os detalhes de cor e de build antes do upload — e não depois de uma renderização com um aspeto errado — é a correção que realmente funciona. Um trabalho concluído não é automaticamente um trabalho correspondente.

Lista de verificação de prevenção

  • Inclua a sua configuração OCIO junto com a respetiva pasta luts/ como uma unidade — nunca separadamente.
  • Incorpore ou empacote os ficheiros de gestão de cor no seu upload, em vez de os deixar como referência de caminho externo.
  • Indique o build exato do seu motor de renderização — não apenas o nome do motor — sempre que não tiver a certeza; nós atribuímos o nó de renderização correspondente.
  • Faça corresponder a sua definição de gamma de visualização (por exemplo, 1.0 vs 2.2 no 3ds Max) entre a sua estação de trabalho e a sua submissão.
  • Renderize primeiro um frame de teste — isso apanha uma incompatibilidade de cor ou de build antes de gastar créditos numa sequência completa.
  • Confirme as versões do seu motor de renderização e dos plugins na matriz de versões e plugins suportados antes do upload.

Ver também

FAQ

Q: Porque é que a minha renderização na render farm aparece com uma cor ou brilho diferente em comparação com o meu preview local? A: A causa mais comum é uma configuração de gestão de cor (OCIO) que não viajou com a sua cena — o seu ficheiro guarda um caminho para ela, não a configuração em si, pelo que a render farm recorre a uma transformação de cor diferente e cada pixel muda. Uma incompatibilidade de gamma de visualização (1.0 vs 2.2 no 3ds Max) produz um clareamento ou escurecimento uniforme semelhante. Confirme ambos antes do upload.

Q: O sistema deteta um problema de gestão de cor ou de build do motor de renderização antes de a minha renderização começar? A: Não. A verificação no momento da submissão e a análise da cena do lado da render farm focam-se ambas em saber se a sua cena vai renderizar de todo — uma cena guardada, um motor de renderização suportado, uma câmara e um caminho de saída válidos. Nenhuma delas verifica a gestão de cor OCIO, o gamma de visualização, ou a paridade de build do motor de renderização, pelo que uma incompatibilidade aqui não será assinalada antes de o seu trabalho correr.

Q: A minha renderização terminou sem texturas em falta, mas o padrão de grão ou ruído parece diferente — o que se passa? A: Normalmente não é um problema de asset em falta. É mais frequentemente uma diferença de build do motor de renderização a alterar o comportamento predefinido de sampling, ou um denoiser exclusivo para GPU que não faz nada, silenciosamente, porque o seu trabalho foi atribuído a um nó de CPU. Confirme o seu build exato do motor de renderização, e verifique que hardware o seu denoiser precisa.

Last updated: 10 de julho de 2026