Skip to main content

Il render della farm è diverso da quello locale

Un render di Super Renders Farm torna completo — nessun errore, nessun avviso di file mancante — ma non corrisponde a quanto visto nell'anteprima locale. I colori risultano diversi, l'intero frame è slavato o troppo scuro, la grana o il rumore non corrispondono al render locale allo stesso sample count, oppure un elemento specifico appare leggermente sbagliato invece che chiaramente rotto. Qui non fallisce nulla — il frame semplicemente non corrisponde, il che può essere più destabilizzante di un render che si interrompe con un errore netto.

Questa guida illustra come si presenta un render diverso ma completo, le tre cause strutturali più comuni, cosa rileva e cosa non rileva la nostra validazione a riguardo, e come risolvere e prevenire il problema. Se parte del frame è completamente nera, rosa acceso, o presenta dettagli chiaramente mancanti, vedere invece texture o asset mancanti nel render — si tratta di una modalità di guasto correlata ma distinta.

Come si presenta

  • Colori alterati o fuori tono — un materiale, o l'intero frame, presenta un bilanciamento colore diverso rispetto all'anteprima locale, senza nulla di chiaramente rotto.
  • Slavato, oppure troppo scuro o troppo chiaro nel complesso — l'intera immagine è uniformemente più chiara o piatta del previsto, non solo un oggetto o un'area.
  • La grana o il rumore risultano diversi, anche se il frame ha completato il render al sample count o all'impostazione del denoiser previsti.
  • Un elemento è leggermente sbagliato, non mancante — il contributo di una luce risulta più debole del dovuto, oppure una variante di materiale appare leggermente errata — cosa distinta dalle macchie completamente nere o dai placeholder rosa che indicano un file non arrivato affatto.

Considerare prima questi casi come un problema di color management, di build o di instradamento hardware, non come un render fallito. Il job in genere è stato completato esattamente come indicato — è stato semplicemente indicato in modo leggermente diverso rispetto alla propria configurazione locale.

Perché succede

Tre cause strutturali spiegano la maggior parte dei casi visti dal supporto. I meccanismi sono ben compresi; non si dispone di dati confermati su quale si presenti più spesso, quindi è opportuno considerarle ugualmente comuni piuttosto che ordinate per frequenza.

File di color management e asset non inclusi

Le config OCIO, le LUT, le cache texture .tx, i profili luce IES, le tile UDIM e i riferimenti interni ai proxy del renderer sono di norma memorizzati nella scena come percorsi, non come dati incorporati. Una texture completamente mancante tende a renderizzare in nero pieno o rosa acceso — difficile da non notare. Una config OCIO mancante o una cache .tx non aggiornata è più silenziosa: il render ricade su una trasformazione colore diversa, oppure recupera la versione con colorspace errato di una texture, e il frame appare semplicemente un po' sbagliato invece che chiaramente rotto.

Soluzione: includere la config OCIO insieme alla relativa cartella luts/ come unità unica — mai l'una senza l'altra — e includere le cache .tx e proxy insieme alla scena, non solo i file sorgente da cui sono state generate.

Differenza di build del renderer tra la propria macchina e il nodo della farm

Una differenza di versione minore o di build nello stesso renderer può modificare il campionamento, il filtraggio o il comportamento di inizializzazione predefiniti, anche quando il job si completa senza errori. Gli scarti di versione tra la build di invio e il nodo di render sono una causa nota di questo tipo di disallineamento silenzioso.

Soluzione: comunicare la build esatta del renderer — non solo «V-Ray» o «Arnold», ma il numero di versione — ogni volta che sussiste incertezza, in modo da poter assegnare il job a un nodo della farm compatibile prima del caricamento. Verificare la propria versione rispetto alla matrice delle versioni e dei plugin supportati.

Color management che non viaggia, più il gamma

La scena memorizza un percorso alla propria config OCIO, non la config stessa. Se non incluso nel caricamento, la farm ricade su una trasformazione colore diversa e ogni pixel del frame cambia — non solo un materiale, il che è un indizio utile per riconoscere questa causa rispetto a un asset mancante. L'impostazione del gamma di visualizzazione di 3ds Max (1.0 anziché 2.2) si comporta allo stesso modo: un disallineamento schiarisce o scurisce l'intero frame in modo uniforme.

Soluzione: incorporare o impacchettare la config OCIO — con le relative LUT — nel caricamento, anziché lasciarla come riferimento esterno, e verificare che l'impostazione del gamma di visualizzazione corrisponda tra la workstation e quanto inviato.

Un ultimo pattern utile da conoscere, meno comune dei tre precedenti: un denoiser esclusivamente GPU può non fare nulla in modo silenzioso quando il job finisce su un nodo CPU — si noterà grana o rumore in eccesso dove ci si aspettava un frame pulito e denoised, non un elemento mancante. Scegliere un denoiser effettivamente supportato dall'hardware di destinazione, oppure verificare che il job sia instradato verso un nodo GPU se il denoiser lo richiede.

Cosa rileva la nostra validazione — e cosa non rileva

Tra il caricamento e il primo frame vengono eseguiti due controlli — un controllo al momento dell'invio e un'analisi della scena lato farm — descritti per intero in texture o asset mancanti nel render. Nessuno dei due valida il color management (OCIO o LUT), il gamma di visualizzazione o la corrispondenza delle build del renderer. Questi casi non generano un errore di file mancante: producono un frame che si renderizza correttamente e semplicemente appare diverso. Questo è esattamente il motivo per cui le cause sopra descritte sono comuni, e per cui confermare i dettagli di colore e build prima del caricamento — non dopo un render che appare sbagliato — è la soluzione realmente efficace. Un job completato non è automaticamente un job corrispondente.

Checklist di prevenzione

  • Includere la config OCIO insieme alla relativa cartella luts/ come unità unica — mai separatamente.
  • Incorporare o impacchettare i file di color management nel caricamento anziché lasciarli come riferimento a un percorso esterno.
  • Comunicare la build esatta del renderer — non solo il nome del renderer — ogni volta che sussiste incertezza; il nodo della farm viene assegnato di conseguenza.
  • Far corrispondere l'impostazione del gamma di visualizzazione (ad esempio, 1.0 anziché 2.2 in 3ds Max) tra la workstation e l'invio.
  • Renderizzare prima un frame di prova — permette di individuare un disallineamento di colore o build prima di impegnare crediti di render su un'intera sequenza.
  • Confermare le versioni di renderer e plugin rispetto alla matrice delle versioni e dei plugin supportati prima del caricamento.

Correlati

FAQ

D: Perché il render sulla farm risulta spostato di colore o luminosità rispetto all'anteprima locale? A: La causa più comune è una config di color management (OCIO) che non ha viaggiato con la scena — il file memorizza un percorso ad essa, non la config stessa, quindi la farm ricade su una trasformazione colore diversa e ogni pixel cambia. Un disallineamento del gamma di visualizzazione (1.0 anziché 2.2 in 3ds Max) produce uno schiarimento o scurimento uniforme simile. Verificare entrambi prima del caricamento.

D: Il sistema rileva un problema di color management o di build del renderer prima che il render inizi? A: No. Il controllo al momento dell'invio e l'analisi della scena lato farm si concentrano entrambi sulla possibilità che la scena si renderizzi in generale — una scena salvata, un renderer supportato, una camera valida e un percorso di output valido. Nessuno dei due verifica OCIO/color management, gamma di visualizzazione o corrispondenza delle build del renderer, quindi un disallineamento di questo tipo non verrà segnalato prima dell'esecuzione del job.

D: Il render è terminato senza texture mancanti, ma la grana o il rumore appaiono diversi — cosa sta succedendo? A: Di norma non è un problema di asset mancanti. Nella maggior parte dei casi si tratta di una differenza di build del renderer che modifica il comportamento di campionamento predefinito, oppure di un denoiser esclusivamente GPU che non fa nulla in modo silenzioso perché il job è finito su un nodo CPU. Confermare la build esatta del renderer e verificare l'hardware richiesto dal proprio denoiser.

Last updated: 10 luglio 2026