Troubleshooting dei problemi di qualità di rendering

I problemi di qualità del rendering sono diversi dai problemi di errore del rendering. Un errore significa che il job non è stato completato. Un problema di qualità significa che si è completato, ma il risultato è sbagliato — troppo luminoso, troppo scuro, geometria mancante, la camera sbagliata, output che non corrisponde a ciò che si vede nel viewport. Questi problemi sono quasi sempre a livello di configurazione piuttosto che di infrastruttura, il che significa che sono risolvibili dal Suo lato una volta che si sa dove guardare.

Questa pagina illustra i problemi di qualità del rendering che vediamo più spesso sulla farm, organizzati per sintomo. Per il troubleshooting degli errori dei job — job che non si completano affatto, che vanno in crash a metà frame o che restituiscono codici di errore — vedere . Per i dettagli di configurazione specifici per DCC e le impostazioni al momento del rendering più importanti per ogni motore, vedere il documento setting-up-* pertinente.

Una regola pratica su cui facciamo affidamento ogni giorno nel supporto: i problemi di qualità del rendering sono quasi sempre riproducibili. Se un rendering torna sbagliato dalla farm, la stessa scena renderizzata localmente — stesso motore, stessa versione, stesse impostazioni, stesso file di scena — di solito produce lo stesso output sbagliato. Questa riproducibilità è la chiave diagnostica. Se il locale corrisponde alla farm, il problema è all'interno della scena e si può risolvere senza toccare nulla dal lato farm. Se locale e farm differiscono, il problema è ambientale: una mancata corrispondenza dei percorsi, una mancata corrispondenza delle versioni, un asset mancante, oppure una configurazione che viaggia con la workstation ma non con il file di scena.

Le sezioni seguenti seguono questa logica diagnostica, ordinate per frequenza con cui vediamo ogni pattern nella linea di supporto.

Mancata corrispondenza di luminosità o colore rispetto al rendering locale

Questo è il problema di qualità più comune che vediamo, di gran lunga. Il rendering torna più chiaro, più scuro, più saturo, o visibilmente diverso di colore rispetto a ciò che mostra il viewport locale. Quasi sempre la causa è la gestione del colore — il worker sta interpretando la pipeline lineare, sRGB o Filmic in modo diverso rispetto al viewport della workstation, oppure il tagging dello spazio colore delle texture è incoerente.

Cinque cose da controllare, in ordine di frequenza:

1. Mancata corrispondenza del View Transform. In Blender, si trova in Render Properties → Color Management → View Transform. Il default è Filmic. Se il viewport della workstation mostra Filmic ma il file di scena salvato è impostato su Standard (o viceversa), l'output renderizzato usa il valore salvato, non lo stato del viewport. In Maya, l'equivalente è Color Management in Render Settings → Common (con ACES, sRGB o Raw come opzioni comuni). In 3ds Max, controllare le impostazioni Gamma e LUT in Customize → Preferences → Gamma and LUT. In Cinema 4D, guardare in Render Settings → Output → Color Profile. Il viewport potrebbe mostrare un transform mentre il file salvato ne specifica un altro — il renderer usa il valore salvato.
2. Tagging dello spazio colore delle texture. Le texture usate come dati di colore (diffuse, albedo, base color) devono essere taggate come sRGB o Color. Le texture usate come dati (normal map, roughness, displacement, metallic, opacity) devono essere taggate come Non-Color, Linear o Raw. Una normal map taggata come sRGB causerà una deriva dell'illuminazione sottile ma pervasiva — la matematica non funziona correttamente quando la texture attraversa una curva gamma extra. Esaminare il grafo shader o il browser delle texture prima dell'invio. Questa è la causa singola più comune dei ticket "il mio rendering sembra sbiadito".
3. Deriva della configurazione OCIO. Se la workstation usa una configurazione OCIO personalizzata — ACES 1.3, AgX, una configurazione specifica dello studio — i file di configurazione OCIO devono essere inclusi nell'archivio del progetto, e il file di progetto deve referenziarli tramite un percorso relativo (non un percorso assoluto che esiste solo sulla propria macchina). Quando il worker si avvia e legge la scena, cerca la configurazione OCIO nel percorso specificato dal file di scena. Se il file non è presente, il renderer si ricade silenziosamente sulla sua configurazione default (tipicamente Filmic per Blender, sRGB per la maggior parte degli altri), e i colori derivano.
4. Il formato di output incorpora il colore diversamente da quanto ci si aspetta. I formati di output che non portano metadati dello spazio colore — PNG, JPEG, BMP — baked il display transform nei valori dei pixel. EXR (lineare, 32-bit) preserva i dati grezzi scene-referred e applica il view transform nella fase del compositor. Se si confronta un output PNG dalla farm con un output EXR dello stesso rendering, appaiono diversi intenzionalmente. Non è un bug; è come funzionano i formati. Quando si visualizzano entrambi con il View Transform corrispondente applicato nel compositor, dovrebbero concordare.
5. Deriva dell'esposizione o del post-processing. Alcuni DCC salvano un "look" di post-processing o una compensazione dell'esposizione nel file di scena ma la applicano diversamente durante il rendering. Controllare il nodo di output del rendering, l'impostazione dell'esposizione della camera e qualsiasi nodo di compositing a valle del layer di rendering. Un'esposizione del viewport di −0,5 EV che non si applica al momento del rendering produrrà un rendering mezzo stop più luminoso del previsto.

Il test diagnostico che raccomandiamo per ogni ticket di luminosità: renderizzare lo stesso frame della scena problematica sulla propria workstation con le stesse impostazioni dell'invio alla farm. Se locale corrisponde alla farm, la gestione del colore della scena è configurata intenzionalmente nel modo in cui è — il viewport sta solo mostrando un'interpretazione diversa. Se locale differisce dalla farm, controllare prima l'inclusione della configurazione OCIO e il tagging dello spazio colore delle texture.

Camera non rilevata o "no camera in scene"

Il renderer non riesce a trovare una camera da cui renderizzare. Il job si interrompe prima che vengano prodotti frame, oppure l'output è vuoto / viewport default. Tre cause comuni:

1. Nessuna camera contrassegnata come renderizzabile. In Maya, Render Settings → Common → Renderable Cameras determina quale camera viene renderizzata. Il default è persp, che è la vista prospettica dal viewport di modellazione — raramente è quello che si vuole per uno shot finale. Impostare il flag renderizable sulla camera che si vuole effettivamente. In Blender, la camera attiva della scena (Properties → Scene Properties → Camera) è quella che viene renderizzata, e solo quella. In Cinema 4D, il campo Render Settings → Output → Camera sovrascrive quale camera viene renderizzata se impostato; altrimenti viene usata la camera attiva dell'editor. In 3ds Max, Render Setup → Common → Camera (o il menu a tendina View) seleziona la camera di rendering.
2. La camera renderizzabile è nascosta. In alcuni DCC (in particolare Maya), una camera nascosta nello schema è ancora renderizzabile finché è contrassegnata come renderizzabile in Render Settings. In altri (in particolare Blender, dove la camera attiva deve essere visibile per la modalità "Camera View" del viewport), nascondere la camera non influisce direttamente sul rendering — ma se si è recentemente ristrutturata la scena, verificare che la camera attesa sia nella scena attiva e non in una collezione separata, render layer, take o scena che non è selezionata.
3. Il viewport bloccato sovrascrive la camera renderizzabile. In 3ds Max e Maya, un pattern di "viewport bloccato" può causare che il renderer usi la camera corrente del viewport piuttosto che quella intesa. Questo si presenta come "no camera" (se il viewport è su una vista prospettica non camera che il renderer rifiuta) oppure come "camera sbagliata" (la sezione successiva). Sbloccare il viewport prima dell'invio, o impostare esplicitamente View to Render in Render Setup.

Per la configurazione specifica della camera nel DCC, vedere , , o .

La scena renderizzata non ha luci

La geometria viene renderizzata, ma la scena è completamente buia, oppure l'illuminazione è molto più scura del previsto — spesso un aspetto wireframe-su-nero che suggerisce che nessuna luce raggiunga le superfici.

Quattro cose da controllare:

1. Le luci sono disabilitate nella visibilità al rendering. In Maya, le luci hanno un flag di visibilità al rendering per-render nell'Attribute Editor (Visibility → Render). Una luce visibile nello schema può ancora essere esclusa dal calcolo al momento del rendering. In Blender, la visibilità al rendering dell'oggetto luce (il toggle dell'icona camera nello schema) controlla se la luce contribuisce al rendering — separata dal toggle dell'icona occhio del viewport.
2. Le luci sono su un View Layer, Render Layer o Collection nascosti. Una luce visibile nel viewport ma assegnata a un layer non renderizzato non contribuirà. Verificare che le luci siano sul layer o nella collezione che viene renderizzata, non su un layer fratello nascosto al momento del rendering.
3. L'illuminazione ambientale è disabilitata. Se la scena si basa sull'illuminazione ambientale HDRI — comune nell'archviz e nella visualizzazione di prodotti — verificare che l'ambiente sia abilitato in Render Properties. In Blender, World → Surface deve avere l'Environment Texture o il Background shader collegato. In Maya, il nodo ambiente Hypershade deve essere collegato allo slot ambiente al momento del rendering della scena. In 3ds Max, Environment and Effects (shortcut tastiera 8) deve avere l'HDRI assegnato, e in V-Ray, l'override V-Ray Environment è un'impostazione separata che sovrascrive l'ambiente della scena.
4. GI o Indirect Lighting è disabilitato. Per V-Ray e Corona, la Global Illumination è un'impostazione separata dalla "presenza di luci nella scena". Una scena progettata per i rimbalzi GI ma con GI disabilitato nel preset di rendering attivo apparirà scura anche se ogni luce diretta è configurata correttamente. In V-Ray, GI → Enable global illumination deve essere attivo. In Corona, GI → Solver deve essere impostato (Path tracing o UHD Cache). In Redshift, GI → Enable GI deve essere attivo. Vedere per la configurazione della cache GI specifica per motore che segue questa abilitazione.

Un rapido test diagnostico: aggiungere temporaneamente un'unica luce Sun o Directional con intensità 1,0 dall'alto della scena e renderizzare un frame. Se anche questa non appare nell'output, il problema è la visibilità del layer o della collezione, non la configurazione della sorgente luminosa. Se il sole di test viene renderizzato correttamente, le luci originali sono il problema — lavorare attraverso i quattro controlli sopra.

Viene renderizzata la camera sbagliata nonostante si sia specificata quella corretta

Si imposta la Camera A come camera di rendering, ma l'output mostra la vista della Camera B. Questo è uno dei problemi di qualità più frustranti perché il file di scena sembra corretto all'ispezione — il flag renderizable è sulla camera giusta, la camera attiva è quella che si vuole. La causa è quasi sempre una di queste tre cose:

1. View bloccata nel viewport in 3ds Max o Maya. Un viewport bloccato (clic destro sull'etichetta del viewport → Lock) sovrascrive la selezione della camera in Render Setup. Il renderer usa la camera del viewport, non quella configurata. Sbloccare il viewport prima di salvare la scena, oppure impostare esplicitamente View to Render in Render Setup → Common (Maya) o Render Setup → Output (3ds Max). Questa è la causa più comune dei ticket "camera sbagliata" negli invii 3ds Max — il blocco è facile da impostare accidentalmente con una scorciatoia da tastiera ed è facile da non notare prima dell'invio.
2. Scena multi-camera con la camera attiva sbagliata. Se la scena ha più telecamere — turntable, hero, beauty, detail, alternative — verificare quale è impostata come camera attiva per la scena corrente, take o render layer. In Cinema 4D, ogni Take può avere la propria camera; in Blender, ogni scena ha la propria camera attiva; in Maya, i layer di Render Setup possono sovrascrivere la camera per layer. La camera che viene renderizzata è quella assegnata al livello layer/take/scena che si è inviato, non l'ultima selezionata nel viewport.
3. Mancata corrispondenza di Take, scena o render-layer. Si è inviato il Render Layer A ma eredita la camera dal Master, e la camera del Master è la Camera B? Succede. Inviare sempre dal take o layer che ha esplicitamente la camera intesa, ed evitare di fare affidamento sull'ereditarietà a meno di non aver verificato la catena.

L'immagine di output è parziale, ritagliata o non è a frame completo

Il rendering è tornato ma solo parte del frame è riempita — il resto è nero, trasparente o ripete il colore del viewport. Quattro cose da controllare:

1. Render Region è abilitato. In V-Ray, Corona, Arnold e diversi altri renderer, un'opzione "Region" consente di renderizzare solo un sub-rettangolo del frame completo per un'anteprima rapida. Se Region era abilitato durante i test locali e non è stato disabilitato prima dell'invio, il worker renderizza solo quella regione — il resto del frame rimane al suo colore di riempimento default. Questa è la causa singola più comune dei ticket di output parziale.
2. Mancata corrispondenza della risoluzione di output tra scena e impostazione di rendering. La risoluzione di output in Render Properties e la dimensione effettiva del frame nel file di output devono corrispondere. Se l'apertura della camera nella scena è impostata su una risoluzione e l'output su un'altra, il renderer potrebbe produrre un riempimento parziale — la camera "vede" un'area più piccola rispetto alla tela di output, e la regione vuota rimane senza colore.
3. Mancata corrispondenza del rapporto d'aspetto tra camera e output. Una camera con un aspetto 1,78 che renderizza su un output 1,0 produrrà un'immagine parziale — la vista della camera non riempie il frame di output. Verificare che il rapporto d'aspetto del film-back della camera corrisponda al rapporto d'aspetto dell'output, o che "Fit Resolution Gate" (o il suo equivalente — i diversi DCC lo chiamano diversamente: "Resolution Gate Fit", "Camera Aperture", "Film Gate") sia impostato su fill, horizontal, vertical o overscan come richiede lo shot.
4. Impostazioni di bordo o crop nel formato di output. Alcuni DCC e alcuni formati di output consentono di impostare un bordo di rendering indipendente dal gate di risoluzione della camera. Verificare che il bordo (in Render Properties, o negli attributi della camera) copra l'intera area di output prevista, non una sotto-regione ritagliata.

Rendering neri o vuoti

Il rendering si completa con successo — nessun errore, nessun avviso — ma ogni pixel è nero o completamente uniforme. Più comune su Maya, ma lo vediamo su tutti i DCC.

Cinque cose da controllare:

1. Mancata corrispondenza del toggle dei layer. In Maya, la geometria potrebbe essere visibile nel viewport ma disabilitata al livello di visibilità al rendering (Display → Hide → Hide All Cameras, o per oggetto Render Stats → Primary Visibility = off). In Blender, l'equivalente è il toggle della visibilità al rendering (icona camera) nello schema. La causa più comune è la ristrutturazione dei layer di una scena dopo i test e il dimenticare di abilitare la visibilità al rendering sul nuovo layer o sulla nuova collezione.
2. Piani di clipping della camera impostati in modo errato. Se il piano di clipping vicino o lontano è impostato in modo sbagliato — piano lontano troppo vicino alla camera, piano vicino dietro la geometria — la camera non include la geometria nel suo view frustum. I piani di default (vicino 0,1, lontano 1000-10000 a seconda della scala della scena) sono di solito corretti; questo accade dopo una regolazione manuale, specialmente quando si lavora a scale di scena insolite (grandi set architettonici o rendering di prodotti microscopici).
3. Luci renderizzabili ma emissione disabilitata. Se si usano materiali emissivi come luci, verificare che lo shader di emissione sia abilitato e abbia un'intensità diversa da zero. Alcuni workflow disattivano l'emissione durante l'interazione nel viewport per evitare il calore della GPU e dimenticano di riabilitarla prima dell'invio.
4. Campionamento troppo basso per produrre output visibile. Con riduzioni aggressive del campionamento path-trace (campioni-per-pixel molto bassi), le scene molto scure possono produrre output completamente nero fino a quando i campioni non aumentano abbastanza da convergere. Renderizzare un singolo frame localmente con le stesse impostazioni per verificare; se il rendering locale è anche completamente nero con lo stesso numero di campioni, aumentare il campionamento o controllare la configurazione dell'illuminazione.
5. Nodo di output del rendering configurato in modo errato (Blender, Houdini). Nel compositor di Blender e nella rete ROP di Houdini, la catena di nodi di output può essere configurata per scartare il risultato del rendering prima del salvataggio. Verificare che il nodo Composite sia collegato a Render Layers (Blender) o che il percorso di output del ROP sia impostato correttamente e che la modalità di output non sia "Null" (Houdini).

Per Maya in particolare, vedere per il workflow di selezione della camera e render-stats che previene la causa più comune dei rendering neri su quel DCC.

Alcuni oggetti nella scena non vengono renderizzati

Un oggetto specifico è visibile nel viewport ma manca dall'output renderizzato. Il resto della scena si renderizza correttamente. Comune su tutti i DCC, leggermente più comune su Blender perché il modello di visibilità a tre vie di Blender (viewport / render / select) è facile da configurare in modo errato.

Cinque cose da controllare:

1. Toggle della visibilità al rendering sull'oggetto. Nello schema di Blender, passare il mouse sulla riga dell'oggetto — tre icone controllano la visibilità: occhio (viewport), camera (render), schermo (selezionabilità). Assicurarsi che l'icona camera sia abilitata per l'oggetto mancante. In Maya, Attribute Editor → Render Stats → Primary Visibility deve essere attivo. In 3ds Max, le proprietà dell'oggetto Object Properties → Rendering → Visibility devono essere impostate sopra 0 (e Renderable deve essere selezionato).
2. L'oggetto è su una Collection, layer o set nascosti. Le collezioni in Blender hanno visibilità separata per viewport e rendering. La collezione potrebbe essere visibile nel viewport ma esclusa dal rendering tramite il toggle dell'icona camera sulla riga della collezione. In Maya, l'assegnazione del Display Layer dell'oggetto e l'assegnazione del Render Layer sono separati; in 3ds Max, Layer Properties → Renderable deve essere attivo per ogni layer che contiene geometria renderizzabile.
3. Il materiale dell'oggetto è invisibile. Un materiale con opacità zero, alpha zero, o problemi di blending alpha si renderizzerà come effettivamente invisibile — la geometria è presente ma trasparente. Verificare l'opacità del materiale, l'alpha, la trasparenza e qualsiasi impostazione di alpha-blend. Problema comune: un materiale impostato per il riferimento "ghost" nel viewport e mai ripristinato prima dell'invio.
4. Lo stack di modificatori nasconde la geometria. Alcuni modificatori (Boolean, Mask, Decimate con impostazioni estreme, Build) possono effettivamente eliminare la geometria dall'output del rendering anche se la mesh sorgente è visibile nella modalità viewport dello stack di modificatori. Disabilitare i modificatori uno alla volta sull'oggetto mancante per identificare qual è il colpevole, poi correggere le impostazioni del modificatore o applicarlo/bake prima dell'invio.
5. L'oggetto è un proxy o un'istanza con un riferimento rotto. Gli oggetti proxy (V-Ray Proxy, Redshift Proxy, Arnold Standin), le cache Alembic e le istanze referenziano file esterni. Se il percorso del riferimento è rotto — percorso assoluto errato, file mancante nell'archivio, condivisione di rete che non esiste sul worker — il proxy viene renderizzato come niente. Questo si sovrappone con §Asset mancanti di seguito; vedere quella sezione per il workflow completo di controllo dei percorsi.

Configurazioni errate della cache GI, dell'irradiance e della light-cache

Questa sezione si sovrappone con la ma copre i sintomi che si manifestano come problemi di qualità piuttosto che come problemi di prestazioni. Se il rendering torna con flickering tra i frame, illuminazione indiretta a macchie, banding nelle aree scure, o illuminazione visibilmente diversa su frame adiacenti della stessa animazione, la causa è quasi sempre una configurazione della cache GI che non sopravvive al rendering distribuito.

Il problema principale: le cache GI in V-Ray (Irradiance Map, Light Cache), Corona (UHD Cache, Path tracing) e Redshift (Irradiance Cache, Photon Map) sono dataset di illuminazione precomputati. Quando si renderizza un'animazione, la cache deve essere (a) precomputata una volta e riutilizzata su ogni frame, oppure (b) calcolata per frame con qualità sufficientemente alta da sembrare identica frame-per-frame. Mescolare le due — lasciare che ogni worker calcoli la propria cache per frame a bassa qualità — produce flickering visibile, perché il pattern di rumore di ogni worker è diverso.

Quattro configurazioni errate comuni e cosa fare:

1. Modalità GI per-frame nell'animazione. La modalità "Single frame" di V-Ray per Irradiance Map e Light Cache calcola una cache fresca per ogni frame. Su una farm distribuita, ogni worker calcola la propria — non la condividono. Il risultato è il flickering dell'animazione. Passare a "Multiframe Incremental" con il file di cache salvato su disco, oppure precomputare la cache come prepass separato e usare "From file" per il pass dell'animazione effettivo. Vedere per il workflow completo.
2. Il percorso del file di cache è locale e mancante sui worker. Se si è salvata un'Irradiance Map precomputata in C:\Users\NomeUtente\Documents\maps\ir.vrmap e si è inviato il job, i worker non hanno quel file. Ricadono nel calcolo per-frame (la prima causa sopra) e l'animazione flickera. Salvare i file di cache nella cartella del progetto, usare percorsi relativi e includere i file di cache nell'archivio del progetto prima dell'invio.
3. La qualità della cache è troppo bassa per la scena. Anche se configurata correttamente (precomputata, inclusa nell'archivio), una Light Cache a 500 subdiv o un'Irradiance Map con qualità "Very Low" può essere insufficiente per una scena archviz scura e con molto GI. I rendering sembrano rumorosi o a macchie, specialmente negli angoli e sotto i mobili. Aumentare le suddivisioni o usare il preset Universal come baseline.
4. UHD Cache riutilizzata su camera incompatibili. UHD Cache (Corona, V-Ray) è dipendente dalla vista della camera. Una cache precomputata per la Camera A e riutilizzata sulla Camera B produrrà un'illuminazione sbagliata — la cache "pensa" che la camera sia in un posto in cui non è. Se si renderizzano più camera della stessa scena, precomputare un'UHD Cache per camera, oppure usare Path tracing (senza cache) per la coerenza cross-camera.

Per la configurazione completa della cache GI, le note di versione per V-Ray 6.x e il workflow di pre-calcolo che viene inviato alla farm correttamente, vedere .

Asset mancanti — texture, proxy, riferimenti, plugin

Il rendering si completa ma parti della scena sono evidentemente sbagliate: le texture sono rosa (default di Maya per le texture mancanti), viola (default di V-Ray), a scacchiera (Arnold), o magenta solido (Blender). I proxy vengono renderizzati come bounding box o spazio vuoto. Materiali specifici vengono renderizzati come il placeholder "mancante" del motore.

La causa è la risoluzione dei percorsi. Il file di scena referenzia gli asset tramite percorso, e sul worker quei percorsi non si risolvono. Sei cose da controllare:

1. Percorsi assoluti nel file di scena. Se la scena referenzia texture in C:\Users\NomeUtente\Progetto\textures\legno.jpg, il worker non ha quel percorso. Usare percorsi relativi (./textures/legno.jpg o ../textures/legno.jpg) o impacchettare gli asset nel file di scena. La maggior parte dei DCC ha un workflow "Make Paths Relative" o "Resource Collector" che converte i percorsi assoluti in relativi prima dell'invio — File Path Editor di Maya, Asset Tracking di 3ds Max, File → External Data → Make Paths Relative di Blender, File → Save Project with Assets di Cinema 4D, Pre-Render Script di Houdini con hou.findFile.
2. Asset non inclusi nell'archivio del progetto. I percorsi relativi aiutano, ma solo se gli asset che referenziano sono effettivamente presenti nell'archivio caricato. Eseguire lo strumento di consolidamento del progetto del DCC (o semplicemente comprimere l'intera cartella del progetto incluse texture, cache, riferimenti e HDRI) prima dell'invio. Non fidarsi di aver caricato tutto — verificare con un confronto della lista.
3. Mancata corrispondenza della capitalizzazione. Windows non fa distinzione tra maiuscole e minuscole (Texture.JPG e texture.jpg sono lo stesso file); i worker della farm eseguono Linux, che fa distinzione tra maiuscole e minuscole (sono file diversi). Un file di scena che referenzia Texture.JPG non troverà texture.jpg su un worker Linux. La maggior parte dei DCC converte i percorsi in minuscolo all'esportazione — ma non sempre. Se si vedono texture specifiche mancanti solo sulla farm, controllare la capitalizzazione del nome file effettivo rispetto alla capitalizzazione nel riferimento del file di scena.
4. Plugin non installato sui worker. Se la scena dipende da un plugin di terze parti — Forest Pack, RailClone, Phoenix FD, MultiScatter, GrowFX, Ornatrix — il worker deve avere quel plugin installato alla stessa versione. Installiamo i plugin principali in anticipo, ma verificare che la versione specifica sia supportata controllando il documento pertinente per il DCC. Se il plugin non è supportato, sarà necessario bakare l'output del plugin (scattering su mesh, capelli su mesh) prima dell'invio, oppure contattare il supporto.
5. Scene collegate o referenziate con percorsi rotti. Se la scena principale referenzia una sotto-scena (reference Maya, Linked Library Blender, XRef Scene 3ds Max), e il percorso della sotto-scena è assoluto o esterno all'archivio, il worker non riesce a trovarlo. Le sotto-scene devono essere nell'archivio e referenziate relativamente, proprio come le texture.
6. Mancata corrispondenza della versione degli asset. Meno comune ma vale la pena controllare: una scena salvata in Maya 2026 con asset che dipendono da tipi di nodo specifici di Maya 2026 non verrà renderizzata correttamente su un worker che esegue Maya 2024. Abbinare la versione di salvataggio della scena alla versione del worker elencata nel documento setting-up-* pertinente.

Se si sono controllati tutti e sei e gli asset mancano ancora, il team di supporto può estrarre il log del worker al momento del rendering per il job e identificare esattamente quale percorso dell'asset non è riuscito a risolversi. Quel log restringe la causa da "qualcosa manca" a "questo file specifico in questo percorso specifico".

Deriva del colore nell'output EXR vs PNG dello stesso rendering

Si è renderizzata la stessa scena sia in EXR che in PNG e i colori non corrispondono. Di solito è un comportamento atteso piuttosto che un bug, ma sorprende le persone abbastanza regolarmente da meritare la propria sezione.

EXR memorizza dati floating-point lineari senza un color transform baked. PNG (e JPEG, BMP) bake il display transform nei valori dei pixel. Quando si visualizza l'EXR in un compositor con il Filmic, ACES, sRGB o AgX display transform corrispondente applicato, dovrebbe corrispondere visivamente al PNG — i dati sottostanti sono gli stessi, ma la codifica è diversa.

Due situazioni in cui questo diventa un problema effettivo:

1. La gestione del colore del compositor differisce dalla gestione del colore del DCC. Se si renderizza un EXR con ACES View Transform applicato nel DCC, poi si apre l'EXR in un compositor (Nuke, Fusion, After Effects, Resolve) configurato per sRGB o senza gestione del colore, il risultato visualizzato sarà diverso. Configurare il compositor per usare lo stesso View Transform / configurazione OCIO del DCC. Questo è uno dei problemi di onboarding del compositor più comuni che vediamo — l'EXR è corretto, il compositor lo interpreta in modo sbagliato.
2. Il PNG è stato salvato con un View Transform diverso dall'EXR. Alcuni DCC consentono override del View Transform per formato. Se si imposta EXR su "Raw" e PNG su "sRGB" nelle stesse impostazioni di output della scena, produrranno risultati visivamente diversi dallo stesso rendering, per design. Controllare le impostazioni di output per formato e standardizzare su un unico transform a meno che non si necessiti specificamente di variazione per formato.

Flusso diagnostico generale

Quando appare un problema di qualità del rendering, lavorare attraverso questi passaggi in ordine. La maggior parte dei ticket si risolve ai passaggi 1–3 senza escalation.

1. Riprodurre localmente. Renderizzare un frame della scena problematica sulla propria workstation con le stesse impostazioni dell'invio alla farm. Se locale corrisponde alla farm, il problema è nella scena — correggere la scena. Se locale differisce dalla farm, il problema è ambientale: percorso, versione del plugin, configurazione OCIO o archivio degli asset.
2. Controllare Color Management e View Transform. Questo causa circa il 40% dei problemi di qualità che vediamo nella linea di supporto.
3. Controllare la selezione della camera in Render Settings. ~20% — camera sbagliata, viewport bloccato, mancata corrispondenza di layer o take.
4. Controllare Render Region, Border o Crop. ~10% — output parziale.
5. Controllare la visibilità di Layer, Collection o Render Layer. ~15% — oggetti mancanti, luci mancanti, scene scure.
6. Controllare il tagging dello spazio colore delle texture. ~10% — deriva della luminosità sottile ma pervasiva.
7. Controllare la configurazione della cache GI per il flickering dell'animazione. ~3% — vedere .
8. Controllare i percorsi degli asset e la completezza dell'archivio. ~2% — texture rosa, proxy mancanti.

Se i passaggi 1–8 non identificano la causa, il team di supporto estrarrà il log del worker per il job e restringerà la causa a uno stato specifico della flotta di worker, una mancata corrispondenza della versione del renderer o un problema di configurazione che possiamo affrontare dal nostro lato. Inviare un messaggio al supporto con l'ID del job, l'output sbagliato e una descrizione di ciò che ci si aspettava — è sufficiente per iniziare la traccia.

Riferimenti incrociati

• — troubleshooting degli errori dei job (il job non si è completato affatto)
• — workflow di upload, invio, download
• — cache GI, Irradiance Map, Light Cache, configurazione UHD Cache
• — packaging degli archivi del progetto, consolidamento degli asset, prevenzione degli asset mancanti
• — configurazione della camera Maya, render-layer, render-stats
• — blocchi della camera 3ds Max, rendering regionale, impostazioni Gamma e LUT
• — sistema Take di Cinema 4D, tag della camera, profilo colore
• — visibilità al rendering Blender, gestione del colore, Filmic vs AgX
• — gestione del colore AE per l'output del rendering compositing
• — riferimento alla camera ROP Houdini, configurazione del nodo di output

FAQ

Q: Il rendering è tornato più scuro del mio viewport. Cosa è cambiato? A: Quasi sempre una mancata corrispondenza del Color Management o del View Transform. Il color transform del file di output riflette le impostazioni salvate in Render Properties → Color Management, non lo stato corrente del viewport. Verificare che View Transform (Filmic, AgX, Standard, sRGB, ACES) e le impostazioni Look siano salvati correttamente nel progetto prima dell'invio, e che il tagging dello spazio colore delle texture sia coerente (sRGB per le texture a colori, Non-Color per le texture di dati).

Q: Il rendering è tornato senza illuminazione. La scena ha luci, le vedo nel viewport. A: Controllare quattro cose in ordine: (1) il toggle della visibilità al rendering di ogni luce (separato dalla visibilità nel viewport); (2) su quale Render Layer, View Layer o Collection si trovano le luci, e se quel layer è abilitato per il rendering; (3) se l'ambiente HDRI è abilitato in Render Properties o nel World shader; (4) se GI o Indirect Lighting è abilitato nelle impostazioni di rendering attive per i motori che lo gestiscono separatamente (V-Ray, Corona, Redshift).

Q: La camera sbagliata è stata renderizzata anche se ho selezionato quella giusta in Render Settings. A: Molto probabilmente una condizione "View Locked" in 3ds Max o Maya — un viewport bloccato sovrascrive la selezione della camera in Render Settings. Sbloccare il viewport, oppure impostare esplicitamente View to Render in Render Setup del DCC prima dell'invio. Verificare anche che il Take, la Scena o il Render Layer inviato abbia la camera intesa al livello del layer, poiché alcuni DCC ereditano la camera da un genitore.

Q: Perché l'output EXR e PNG dello stesso rendering sembrano diversi? A: EXR memorizza dati floating-point lineari senza un display transform baked; PNG bake il display transform nei valori dei pixel. Quando si visualizza l'EXR in un compositor con il View Transform corrispondente applicato, dovrebbe sembrare uguale al PNG. Se sembrano diversi nel compositor, la gestione del colore del compositor non corrisponde a quella del DCC — configurare il compositor per usare la stessa configurazione OCIO e View Transform.

Q: Un oggetto specifico manca dal rendering ma è visibile nel viewport. A: Controllare (1) il flag di visibilità al rendering dell'oggetto (separato dalla visibilità nel viewport — icona camera in Blender, Primary Visibility in Maya, Renderable in 3ds Max); (2) la visibilità della Collection, Render Layer o Display Layer in cui vive l'oggetto; (3) se un modificatore (Boolean, Mask, Decimate) sta nascondendo la geometria al momento del rendering; (4) se l'oggetto è un proxy con un riferimento esterno rotto (vedere anche la sezione Asset mancanti).

Q: Il rendering è tornato parziale o ritagliato. Metà del frame è nero. A: Controllare se Render Region (o Border, Crop) è abilitato nel renderer. Il rendering regionale produce un riempimento parziale del frame di output. Disabilitare Region prima dell'invio, o impostarlo sull'intero frame. Verificare anche che il rapporto d'aspetto della camera corrisponda al rapporto d'aspetto dell'output, e che la risoluzione di output in Render Properties corrisponda alla risoluzione del film-back della camera.

Q: Le mie texture sembrano sbiadite o supersaturate rispetto alla workstation. A: Tagging dello spazio colore delle texture. Le texture a colori (diffuse, albedo, base color) devono essere taggate come sRGB o Color; le texture di dati (normal, roughness, displacement, metallic, opacity) devono essere taggate come Non-Color, Linear o Raw. Le texture con tag errato causano una deriva del colore sottile ma coerente, specialmente sui materiali PBR dove la gamma della normal map è importante.

Q: Sul mio computer è impostata la configurazione OCIO di ACES. La farm la rispetta? A: Sì, se i file di configurazione OCIO sono inclusi nell'archivio del progetto e il file di progetto referenzia la configurazione tramite un percorso relativo. Se i file di configurazione OCIO mancano dall'archivio, il worker ricade sulla configurazione default del DCC (tipicamente Filmic per Blender, sRGB per la maggior parte degli altri) e i colori divergeranno. Includere sempre la cartella di configurazione OCIO nell'archivio del progetto.

Q: L'animazione flickera — ogni frame sembra avere un'illuminazione indiretta diversa. A: Configurazione errata della cache GI. In V-Ray, passare dall'Irradiance Map "Single frame" a "Multiframe Incremental" con la cache salvata su disco, e precomputare la cache come prepass oppure usare il preset Universal Path tracing. Per altri motori, vedere le impostazioni della cache GI corrispondenti — la regola è la stessa: precomputare una volta e riutilizzare, oppure usare una modalità senza cache (Path tracing) per la coerenza cross-frame. Vedere per il workflow completo.

Q: Le mie texture si renderizzano come rosa, viola o magenta sulla farm. A: Asset mancanti. Il file di scena referenzia texture a percorsi che il worker non riesce a risolvere — di solito percorsi Windows assoluti (C:\Users\...), asset non inclusi nell'archivio del progetto, oppure mancate corrispondenze di capitalizzazione tra il filesystem Windows e quello Linux del worker. Usare percorsi relativi, eseguire lo strumento di consolidamento del progetto del DCC prima dell'invio e verificare che l'archivio includa ogni texture referenziata.

Q: La scena Forest Pack / Phoenix FD / Ornatrix è tornata con gli oggetti del plugin mancanti. A: Mancata corrispondenza della versione o della compatibilità del plugin sul worker. Controllare il documento o pertinente per le versioni dei plugin supportate sulla flotta di worker. Se la versione è supportata, la scena dovrebbe renderizzarsi correttamente — in caso contrario, bakare l'output del plugin su mesh prima dell'invio, oppure contattare il supporto per verificare lo stato di installazione della versione specifica del plugin.

---