Configurare Blender per il rendering cloud

Blender sulla nostra farm esegue Cycles (CPU e GPU con Optix) ed Eevee Next — i due renderer di produzione inclusi in Blender 4.x. Rispetto ai DCC proprietari, Blender ha un vantaggio utile: un file .blend può essere reso completamente autonomo dall'interno dell'applicazione, quindi il packaging per una render farm è spesso una singola azione di menu invece di una ricerca manuale degli asset. Questa pagina illustra tale flusso dall'inizio alla fine: packaging, verifica pre-invio, note per renderer per Cycles CPU / Cycles GPU / Eevee Next, rendering di animazioni multi-camera, i tre canali di invio e la risoluzione dei problemi specifici di Blender. Gli errori cross-DCC sono trattati in .

Per esempi di prezzi e la scelta GPU rispetto a CPU sulla nostra farm, si veda . Per i benchmark Cycles GPU sulla flotta RTX 5090, si veda .

Versioni supportate

Blender 4.0, 4.1, 4.2 LTS, 4.3 e 4.4 sono preinstallati su ogni worker. La farm abbina automaticamente la versione salvata del file .blend — non c'è alcun selettore di versione da gestire; il worker legge l'intestazione del file e lancia il binario corrispondente.

Blender distribuisce una versione principale ogni tre-quattro mesi più una versione LTS annuale. Le nuove versioni vengono provisionate entro circa due settimane dalla disponibilità pubblica. Si raccomanda Blender 4.2 LTS per il lavoro di produzione poiché riceve correzioni di bug fino al 2026 ed è la destinazione stabile per la maggior parte degli studi.

I file salvati in Blender 3.x vengono aperti sui worker 4.x, ma due casi richiedono attenzione: i render Eevee Legacy potrebbero non corrispondere all'output di Eevee Next (si veda la sezione Eevee Next), e i file molto vecchi 2.7x / 2.8x dovrebbero essere aperti localmente, risalvati in 4.x e testati prima dell'invio. Se è necessario renderizzare un progetto vecchio, salvare prima una copia bloccata sulla versione; la farm non può effettuare il downgrade di un salvataggio 4.x.

Packaging del progetto Blender

Un progetto Blender è il file .blend più eventuali asset esterni — texture, file audio, cache di simulazione, file .blend di libreria collegata, profili IES, file di configurazione OCIO, HDRI EXR e qualsiasi file shader .osl. La risoluzione dei percorsi di Blender è più permissiva di quella di altri DCC, ma in cloud rendering questa permissività si ritorce contro: un percorso risolto sulla propria workstation tramite la logica di fallback di Blender potrebbe non risolversi allo stesso modo su un worker, con conseguente comparsa di segnaposto magenta per texture mancanti.

Sono supportati tre pattern di packaging. Scegliere quello più adatto alle dimensioni del progetto e alla frequenza di riutilizzo degli asset tra scene.

Pattern 1 — Pack Resources (consigliato per la maggior parte dei progetti)

"Pack Resources" integrato di Blender incorpora tutti i dati esterni nel .blend stesso, producendo un singolo file autonomo.

1. File → External Data → Find Missing Files. Percorre il progetto e segnala i riferimenti non risolti; correggere prima localmente qualsiasi problema.
2. File → External Data → Pack Resources. Blender incorpora tutte le texture, i suoni, i profili IES e le immagini collegate nel .blend.
3. Salvare il progetto. Il .blend packed è ora autonomo — ci si aspetti che cresca 10×–100× a seconda del numero di texture e della risoluzione.
4. Caricare il singolo .blend. Non è necessario un archivio a meno che il file non sia abbastanza grande da richiedere la compressione per velocizzare l'upload — tipicamente sopra qualche GB.

Pattern 2 — Make Paths Relative + struttura di cartelle (per librerie di texture grandi)

Per i progetti in cui Pack Resources produrrebbe un singolo file di dimensioni non gestibili, il pattern dei percorsi relativi mantiene il .blend piccolo e spedisce gli asset come cartelle accanto ad esso.

1. File → External Data → Make All Paths Relative. Tutti i percorsi degli asset diventano relativi alla directory .blend (prefisso percorso //).
2. File → External Data → Report Missing Files. Non dovrebbe mostrare nulla. Correggere qualsiasi elemento segnalato prima di continuare.
3. Posizionare tutti gli asset referenziati in sottocartelle relative al .blend. Struttura standard: project/scene.blend più project/textures/, project/cache/, project/hdr/, project/osl/, project/lib/. Evitare spazi nei nomi delle cartelle.
4. Archiviare l'intera cartella del progetto come .tar.gz o .7z e caricare l'archivio.

Pattern 3 — Librerie collegate (avanzato; studi con librerie di asset condivise)

Blender supporta il collegamento di librerie, in cui un file .blend referenzia oggetti, materiali o scene da un altro .blend. Questo è comune negli studi con librerie di asset condivise (prop, personaggi, materiali):

1. Rendere prima i percorsi relativi (Pattern 2 passo 1).
2. Verificare che ogni collegamento di libreria si risolva localmente tramite File → External Data → Find Missing Files.
3. Includere ogni .blend di libreria collegata nell'archivio. Un riferimento come //../shared/props/sedia.blend si risolve solo se il file esiste a quel percorso sul worker. Testare localmente spostando l'intera cartella di progetto in una nuova posizione e aprendo la scena master — se si apre correttamente, gli stessi percorsi si risolveranno sul worker.
4. Valutare di rendere le librerie locali per i job di lunga durata. File → External Data → Make Library Override converte i riferimenti in copie modificabili all'interno del .blend, scambiando dimensioni del file con autonomia.

Cosa verificare prima dell'invio

Un breve checklist pre-volo applicabile prima di qualsiasi invio:

• Il render engine attivo è impostato. Properties → Render Properties → Render Engine — Cycles, Eevee Next o Workbench. Il worker rispetta ciò che si salva.
• L'intervallo di fotogrammi è impostato. Properties → Output Properties → Frame Start / Frame End. La farm rispetta questo intervallo esattamente.
• Il percorso di output usa token relativi. Il prefisso // significa "relativo al file .blend." Evitare percorsi assoluti come D:\renders\ — non possono essere risolti sui worker Linux.
• Il formato di output corrisponde alla pipeline downstream. Sequenza PNG con alpha per il compositing, OpenEXR Multilayer per l'output pass completo. Per l'animazione, le sequenze di immagini sono fortemente preferite all'output video diretto.
• La gestione del colore è impostata. Properties → Render Properties → Color Management. Il Filmic + sRGB predefinito funziona per la maggior parte dei progetti. Per ACES o una configurazione OCIO personalizzata, includere i file di configurazione OCIO nella cartella del progetto.
• La camera attiva è impostata. La camera attiva della scena (Properties → Scene Properties → Camera) determina quale camera viene renderizzata. "Camera sbagliata renderizzata" è tra i ticket di assistenza Blender più frequenti ed è tra i più facili da prevenire.
• Le cache di simulazione sono baked. Le simulazioni di fluidi, fumo, tessuti, capelli e corpi morbidi devono essere baked localmente prima; la farm esegue il rendering rispetto alla cache baked e non esegue simulazioni live. Includere la cartella cache nell'upload.
• Le light probe sono baked. Le probe Eevee Next — Irradiance Volume, Reflection Plane, Reflection Cube — devono essere baked localmente e i dati baked salvati con il .blend (Render Properties → Light Probes → Bake Indirect Lighting). Probe non baked producono illuminazione indiretta piatta o assente.

Note specifiche per renderer

Cycles (CPU)

Cycles CPU gira sul tier di worker Dual Intel Xeon E5-2699 V4 (fino a 256 GB di RAM per nodo). È la scelta per scene che superano la VRAM GPU, progetti con librerie di texture molto grandi o scene che usano funzionalità non ancora supportate sul backend GPU.

• Licenza: Blender è gratuito e open source; nulla da autorizzare, nessuna licenza da consumare.
• Campionamento: Render Properties → Sampling → Render Samples. Adaptive Sampling con Noise Threshold 0.01 è un buon default per l'animazione; soglie più basse (0,005, 0,002) per qualità superiore a scapito del tempo di rendering. Time Limit (per fotogramma) è un utile limite di sicurezza per i lavori di animazione.
• Denoising: Cycles supporta OpenImageDenoise (OIDN) e Optix (solo GPU). OIDN gira su CPU e produce buoni risultati per still e animazioni; configurare in Render Properties → Sampling → Denoise. Per l'animazione, abilitare il denoising temporale (OIDN 2.x in Blender 4.2+) per ridurre lo sfarfallio fotogramma per fotogramma.
• Light Tree: Blender 3.4+ include Light Tree Sampling per scene con molte luci. Abilitare in Render Properties → Sampling → Light Tree per interni archviz o illuminazione scenica con centinaia di sorgenti luminose.

Cycles (GPU / Optix)

Cycles GPU gira sul tier di worker NVIDIA RTX 5090 (32 GB di VRAM per scheda). È tipicamente 5–15× più veloce per fotogramma rispetto a Cycles CPU per archviz e animazione, e di più per shot VFX path-traced con molti volumi e SSS.

• Device: Properties → Render Properties → Device → GPU Compute. Il backend Optix (RT core su GPU NVIDIA) è abilitato per impostazione predefinita sui nostri worker.
• VRAM: 32 GB per worker sono sufficienti per la maggior parte dei progetti archviz, motion design e animazione con più texture 4K. Per i progetti che si avvicinano al limite, "Persistent Data" in Render Properties → Performance riduce il tempo di caricamento per fotogramma a fronte di un VRAM di picco leggermente superiore. Per i progetti che superano i 32 GB, passare a Cycles CPU sul tier Xeon o suddividere la scena.
• Optix denoiser: Più rapido di OIDN per l'animazione e scelta predefinita su GPU. Configurare in Render Properties → Sampling → Denoise → Use OptiX. Per le still statiche, OIDN produce spesso un output leggermente più pulito; per l'animazione, la modalità temporale di Optix è generalmente il compromesso migliore.
• Parità funzionale: Capelli, volumi, SSS, OSL (4.0+, con requisiti hardware), Adaptive Subdivision — tutti supportati su Cycles GPU in 4.x. Il divario funzionale CPU/GPU è sostanzialmente chiuso.

Eevee Next

Eevee Next gira sul tier di worker GPU. È la scelta per motion design, rendering stilizzati, iterazione veloce e previz, dove il budget per fotogramma conta più della fedeltà assoluta.

• Campionamento e riflessioni: Render Properties → Sampling controlla il numero di campioni per pixel. Per i finali, 64–128 campioni producono tipicamente un output pulito. Le Light Probe, le Screen-Space Reflections e le Screen-Space Refractions devono essere baked o configurate per ogni shot.
• Eevee Next vs Eevee Legacy: Blender 4.2+ include Eevee Next come nuova architettura (nome interno BLENDER_EEVEE_NEXT rispetto al Legacy BLENDER_EEVEE). I vecchi progetti 3.x con Eevee Legacy potrebbero richiedere aggiustamenti alla migrazione; testare un singolo fotogramma localmente prima di inviare un'animazione.
• Volumetrics: La pipeline volumetrica di Eevee Next differisce significativamente dalla versione Legacy. I volumi che si renderizzavano correttamente in Eevee Legacy potrebbero mostrare differenze di densità o scattering. Verificare localmente prima dell'invio.
• Baking delle light probe: Critico e fonte del ticket di assistenza Eevee più comune. Render Properties → Light Probes → Bake Indirect Lighting. Effettuare il bake localmente, salvare e i dati baked viaggiano con il file. Probe non baked producono illuminazione indiretta piatta o assente.

Workbench

Workbench è il renderer viewport di Blender, utile per fotogrammi di anteprima tecnica (pass Matte ID, turntable clay, anteprima AO). Gira su worker CPU o GPU; inviare allo stesso modo di Cycles o Eevee, con Render Engine impostato su Workbench prima del salvataggio.

Confronto rapido Cycles GPU vs Eevee Next

| Aspetto | Cycles GPU | Eevee Next | |---|---|---| | Velocità di rendering (scena tipica) | Più lento per fotogramma, fisicamente accurato | Più veloce per fotogramma, derivato dal real-time | | Fotorealismo | Più alto | Più basso (migliora ad ogni release) | | Sfarfallio animazione | Basso (con modalità temporale Optix denoiser) | Può essere più alto; necessita bake probe | | Vincolo VRAM | 32 GB limite fisso; fallback su CPU | 32 GB ma utilizzo tipicamente inferiore | | Qualità volumetrics | Path-traced, accurato | Approssimato; verificare localmente prima dell'invio | | Miglior uso | Archviz, VFX, animazione fotorealistica | Motion design, stilizzato, iterazione veloce |

Rendering multi-camera

Per i progetti che devono eseguire il rendering della stessa scena da più angolazioni della camera in un singolo invio, Blender supporta più pattern. Scegliere in base alla relazione tra gli angoli.

Pattern A — Più scene con diverse telecamere attive

Blender consente più scene per .blend, ciascuna con la propria camera attiva e impostazioni di rendering:

1. Creare una nuova scena per ogni angolazione della camera (Scene → New Scene → Link Objects condivide i dati affinché le modifiche si propaghino).
2. Impostare la camera attiva di ogni scena.
3. All'invio, la farm renderizza la scena contrassegnata come "Active" al momento del salvataggio. Per renderizzare più scene, inviare ciascuna come job separato.

Il Pattern A è la scelta giusta quando gli angoli necessitano di campionamento, formati di output o risoluzioni diversi.

Pattern B — View Layer per camera (Blender 2.8+)

Per molte angolazioni della camera che condividono le impostazioni di rendering, usare View Layer ciascuno con una camera attiva diversa:

1. In Properties → View Layer, creare un View Layer per ogni angolazione della camera.
2. Associare la camera di ogni View Layer tramite una proprietà Camera sul layer (o controllare la camera attiva nel Compositor).
3. Configurare i percorsi di output per View Layer usando il token {layer} nel nome del file di output.
4. Inviare; il worker esegue il rendering di tutti i View Layer abilitati in un unico pass.

Per i turntable archviz tipici (8–16 angolazioni della camera), il Pattern B è più efficiente perché la scena si carica una volta sola e tutte le viste vengono renderizzate dallo stesso stato caricato. Un singolo job multi-camera che produce N sequenze di output costa meno di N job a singola camera.

Pattern C — Output multiplo nel Compositor (avanzato)

Per la post-produzione complessa per camera, il Compositor può instradare il render di ogni camera verso un diverso nodo File Output. Stesso pattern degli export AOV multi-layer. Usare il Pattern B a meno che non si abbia un reale motivo di post-produzione per ricorrere al Compositor.

Flusso di invio

Tre canali di invio funzionano per i progetti Blender. Scegliere quello più adatto al proprio workflow.

• Upload web + invio tramite pannello di controllo. Caricare il .blend packed (o la cartella di progetto archiviata) sul proprio account, poi inviare tramite il pannello di controllo. Il pannello legge l'intestazione del .blend per rilevare la versione di Blender, il render engine, l'intervallo di fotogrammi e la camera attiva, e precompila il modulo di invio. Confermare o sovrascrivere, inviare, monitorare.
• Client App. La Client App (Windows / macOS) racchiude upload + invio + download automatico. Dopo l'installazione, trascinare il .blend o l'archivio sull'app, confermare il modulo di invio, e l'app gestisce upload, monitoraggio avanzamento e download dei fotogrammi man mano che vengono completati.
• Plugin di invio (add-on Blender). Un add-on Blender per l'invio in-app è disponibile; installarlo dal pannello di controllo dell'account. Il plugin legge le impostazioni di rendering della scena corrente, richiede override (intervallo di fotogrammi, percorso di output, risoluzione) e invia senza uscire da Blender.

Per il flusso cross-DCC upload-invia-scarica si veda la . Per i passaggi di installazione del plugin si veda .

Risoluzione dei problemi Blender

Per la risoluzione dei problemi generali valida per tutti i DCC (asset mancanti, scostamento intervallo di fotogrammi, errori percorso di output), si veda . I seguenti casi sono specifici di Blender.

• Alcuni oggetti della scena non vengono renderizzati. Causa più comune: la "Render Visibility" dell'oggetto (icona camera nell'outliner) è disabilitata. Verificare anche che l'oggetto non si trovi su un View Layer nascosto, e controllare Object Properties → Visibility → Ray Visibility (Camera, Diffuse, Gloss, Transmission, Volume, Shadow).
• Texture mancanti nonostante Pack Resources. Verificare che Pack Resources sia stato eseguito dopo le ultime modifiche alle texture. Se le texture sono state ricaricate dopo il packaging, potrebbero essere tornate a riferimenti esterni. Ri-pacchettizzare e ri-salvare.
• Il rendering restituisce fotogrammi neri o colore errato. Di solito un conflitto di View Transform. Confermare che Properties → Render Properties → Color Management usi View Transform: Filmic (il default) sulla workstation e nel file salvato. I Look Transform e i valori di Exposure sono incorporati nel .blend e si applicano sul worker.
• Le light probe Eevee Next non vengono baked sul worker. Il worker non effettua il bake; le probe devono essere baked localmente e salvate con il .blend. Render Properties → Light Probes → Bake Indirect Lighting, salvare, caricare.
• Il job Cycles GPU gira su CPU invece. Verificare che Properties → Render Properties → Device sia impostato su GPU Compute. Se il file è stato creato su una workstation senza GPU NVIDIA, il valore Device salvato potrebbe essere impostato su CPU per default.
• Shader OSL personalizzato non riesce al rendering. Cycles supporta OSL, ma i file .osl devono essere inclusi nell'archivio e referenziati tramite percorso relativo. Posizionarli nella stessa cartella del .blend. OSL su GPU ha requisiti hardware che potrebbero non essere compatibili con ogni shader; se uno shader funziona su CPU ma non su GPU, renderizzare quella scena sul tier CPU.
• Riferimento a libreria collegata non risolto. Una libreria collegata si risolve solo se il .blend collegato è presente al percorso previsto sul worker. Usare il packaging Pattern 2 e includere ogni libreria collegata nell'archivio. Eseguire File → External Data → Find Missing Files localmente prima dell'upload.
• Add-on mancante sul worker. Add-on diffusi (Animation Nodes, BlenderKit, Sverchok, FLIP Fluids) potrebbero non essere tutti preinstallati. Per add-on procedurali, effettuare il bake della geometria in mesh statiche prima dell'invio (Sverchok: Set/Bake to Mesh; Animation Nodes: bake to action; Geometry Nodes: Apply modifier). Per altri add-on, contattare l'assistenza per richiederne l'aggiunta all'immagine worker.
• Animazione con sfarfallio (Cycles). Di solito varianza di rumore fotogramma per fotogramma. Aumentare i campioni, abbassare l'Adaptive Sampling Noise Threshold, abilitare il denoising temporale (OIDN 2.x o Optix). Confermare che la modalità Random Seed (Render Properties → Sampling → Advanced → Seed) sia coerente con l'intento del progetto — Animated per variazione naturale, fisso per output bit-stabile.
• Animazione con sfarfallio (Eevee Next). Quasi sempre light probe non baked o obsolete. Ri-effettuare il bake di Indirect Lighting, salvare, ricaricare. Le Screen-Space Reflections che dipendono dallo stato del viewport possono anch'esse sfarfallare — preferire le Reflection Probe per riflessioni pulite.

Riferimenti incrociati

• — workflow carica, invia, scarica valido per tutti i DCC
• — come vengono calcolati i costi dei job Blender, modello di prezzi GHz-ora
• — guida SFTP, formati di archivio, trasferimento file di grandi dimensioni
• — risoluzione dei problemi cross-DCC (asset mancanti, intervallo fotogrammi, percorso output, drift gestione colore)
• — installazione dell'add-on Blender per l'invio in-app
• — wrapper desktop per upload + invio + download
• — flusso di invio tramite pannello di controllo
• — articolo benchmark con dati Cycles GPU
• — articolo comparativo con sezione dedicata a Blender

FAQ

Q: Quali versioni di Blender supporta la farm? A: Blender 4.0, 4.1, 4.2 LTS, 4.3 e 4.4 sono preinstallati su ogni worker. Seguiamo il ciclo di release di Blender e provisioniamo le nuove versioni entro circa due settimane dalla disponibilità pubblica. Blender 4.2 LTS è la scelta consigliata per il lavoro di produzione poiché riceve correzioni di bug fino al 2026. La farm abbina automaticamente la versione salvata del file .blend — non è necessario selezionare una versione all'invio. Q: Dovrei renderizzare con Cycles o Eevee Next? A: Cycles per archviz fotorealistica, VFX e animazione dove conta il trasporto della luce fisicamente accurato. Eevee Next per motion design, lavoro stilizzato, iterazione veloce e previz dove il costo per fotogramma conta più della fedeltà assoluta. Cycles GPU sulla nostra flotta RTX 5090 è tipicamente 5–15× più veloce per fotogramma rispetto a Cycles CPU per la stessa scena, quindi GPU è la scelta Cycles predefinita a meno che la scena non superi i 32 GB VRAM o richieda funzionalità che necessitano il backend CPU. Q: La mia scena usa BlenderKit / Sverchok / Animation Nodes / Geometry Nodes — verrà renderizzata? A: Gli asset BlenderKit già scaricati e salvati nel .blend si renderizzano correttamente — una volta posizionati diventano dati mesh standard. Sverchok e Animation Nodes sono procedurali; se la geometria procedurale non è stata baked in una mesh statica, il worker potrebbe produrre output inatteso. Effettuare il bake della geometria procedurale in mesh (Sverchok: Set/Bake to Mesh; Animation Nodes: bake to action; Geometry Nodes: Apply modifier sul node tree risultante) prima dell'invio. I Geometry Nodes che si risolvono a runtime senza bake funzionano generalmente, ma testare prima un singolo fotogramma localmente. Q: Devo pacchettizzare le texture nel .blend, o posso caricarle come file separati? A: Entrambi i pattern funzionano. Pack Resources è il più semplice perché il risultato è un singolo file autonomo. Percorsi relativi + struttura di cartelle è preferibile per librerie di texture molto grandi e progetti che condividono una libreria di texture tra scene. Eseguire Find Missing Files prima di entrambi gli approcci per confermare che nulla sia rotto localmente. Q: Il render è terminato, ma i colori sembrano diversi rispetto al viewport della workstation. A: Nella maggior parte dei casi si tratta di un conflitto di View Transform. Confermare che Properties → Render Properties → Color Management usi View Transform: Filmic (il default) sulla workstation e nel file salvato. I Look Transform e i valori di Exposure sono incorporati nel .blend e si applicano sul worker. Q: Sto renderizzando un'animazione. Dovrei esportare su file video o sequenza di immagini? A: Sequenza di immagini, quasi sempre. PNG con alpha (per il compositing) o OpenEXR Multilayer (per i pass completi) è lo standard. L'output video diretto (FFmpeg) non si parallelizza — un worker renderizza tutti i fotogrammi in sequenza e codifica un file. Le sequenze di immagini permettono alla farm di distribuire i fotogrammi su più worker in parallelo, il che è più veloce per qualsiasi animazione superiore a circa 100 fotogrammi. Q: Come si confronta il costo del rendering GPU rispetto al CPU sulla farm? A: GPU è tipicamente più veloce per fotogramma (5–15× per Cycles), ma la tariffa per worker è più alta. Il costo totale è approssimativamente comparabile per la maggior parte delle scene — GPU termina in meno tempo reale ma addebita di più al minuto. Il fornisce un confronto per fotogramma e per job per la scena specifica. Q: Posso renderizzare simulazioni Blender (fluido, fumo, capelli, tessuti) sulla farm? A: Effettuare il bake della cache di simulazione localmente prima, poi includere la cartella cache nell'upload del progetto. La farm esegue il rendering dei fotogrammi rispetto alla cache baked; non esegue simulazioni live. Effettuare il bake su disco (Cache Type → All Frames + Save Cache to Disk), confermare che la cartella cache si trovi nella cartella del progetto, pacchettizzare e caricare.

---