Configurare Blender per il rendering cloud

Blender sulla nostra render farm utilizza Cycles (CPU e GPU/Optix) — il motore di render per i lavori Blender sulla nostra piattaforma. Eevee non è disponibile: richiede un contesto di visualizzazione attivo e non può essere eseguito sui nodi di rendering headless (vedi la nota su Eevee nella sezione Note specifiche per motore di rendering). Questa pagina tratta il packaging del progetto — più semplice in Blender rispetto alla maggior parte dei DCC grazie al modo in cui Blender gestisce i percorsi degli asset — le note specifiche per motore di rendering, il rendering di animazioni multi-camera e il troubleshooting specifico per Blender.

Per un posizionamento d'insieme di Blender sulla nostra render farm — esempi di prezzi, scelta GPU vs CPU, add-on supportati — consulta l'articolo (l'articolo su V-Ray include il contesto Blender). Per benchmark specifici di Cycles GPU su RTX 5090, consulta .

Versioni supportate

Blender 4.0, 4.1, 4.2 (LTS), 4.3 e 4.4 sono preinstallati su ogni worker. Supportiamo le versioni LTS di Blender come scelta consigliata per il lavoro in produzione, poiché Blender 4.2 LTS riceve correzioni di bug fino al 2026 ed è il target stabile per la maggior parte degli studi. La render farm rileva automaticamente la versione salvata nel tuo file .blend.

Una nota sul ritmo di rilascio di Blender: Blender distribuisce una versione principale ogni tre-quattro mesi più una versione LTS annuale. Distribuiamo le nuove versioni entro due settimane dalla loro disponibilità pubblica — il cadenzamento dei rilasci di Blender è più rapido rispetto ai DCC proprietari, quindi la render farm si aggiorna di conseguenza.

Packaging del progetto Blender

Un progetto Blender è il file .blend più eventuali asset esterni — texture, file audio, cache di simulazione, file .blend di librerie collegate ed EXR HDRI per l'illuminazione ambientale. La risoluzione dei percorsi di Blender è più permissiva rispetto agli altri DCC (utilizza sia percorsi assoluti che relativi e scorre diverse posizioni di ricerca come fallback), ma per il rendering cloud è consigliabile raccogliere tutto in una cartella di progetto coerente.

Il metodo di packaging più semplice è la funzione integrata di Blender "Pack Into .blend":

Apri il tuo progetto. File → External Data → Find Missing Files (per verificare che nulla sia già rotto in locale).
Incorpora gli asset nel file .blend. File → External Data → Pack All Into .blend. Blender incorpora tutte le texture, i suoni e le immagini collegate direttamente nel file .blend.
Salva il progetto. Il file .blend è ora autonomo — tipicamente da 10 a 100 volte più grande dell'originale, a seconda del numero di texture.
Carica il singolo file .blend (non è necessario un archivio se il tuo .blend è inferiore a qualche GB; per file più grandi, comprimilo in .tar.gz o .7z per un upload più rapido).

Un secondo metodo di packaging che produce un upload più leggero è "Make Paths Relative" con struttura manuale delle cartelle:

File → External Data → Make All Paths Relative. Tutti i percorsi degli asset diventano relativi alla directory del file .blend.
Verifica che tutti gli asset si risolvano correttamente con File → External Data → Report Missing Files. Il report non dovrebbe mostrare file mancanti.
Posiziona tutti gli asset referenziati in sottocartelle relative al file .blend. Struttura standard: project/scene.blend più project/textures/, project/cache/, project/hdr/, ecc.
Archivia l'intera cartella in .tar.gz o .7z e caricala.

Il metodo con percorsi relativi è preferibile per librerie di texture molto grandi (dove Pack Into .blend produrrebbe un singolo file difficile da gestire) e per progetti che riutilizzano la stessa libreria di texture su più scene.

Cosa verificare prima dell'invio

Una breve checklist pre-invio:

Il motore di rendering attivo è impostato su Cycles. Properties → Render Properties → Render Engine determina se il worker utilizza Cycles o Workbench. Impostalo su Cycles per il rendering in produzione — Eevee non è supportato sulla render farm (vedi Note specifiche per motore di rendering). Assicurati che corrisponda alle intenzioni del progetto.
L'intervallo di frame è impostato. Properties → Output Properties → Frame Start / Frame End. La render farm rispetta questo intervallo esattamente.
Il percorso di output utilizza token relativi. Il predefinito //tmp/####.png va bene; il prefisso // significa "relativo al file .blend". Evita percorsi assoluti come D:\renders\.
Il formato di output corrisponde alla pipeline downstream. Sequenza PNG con alpha per il compositing, OpenEXR Multilayer per l'output completo dei pass, video FFmpeg per la consegna diretta. Per il rendering di animazioni, le sequenze di immagini sono fortemente preferibili all'output video diretto.
La gestione del colore è impostata. Properties → Render Properties → Color Management. Il predefinito Filmic + sRGB funziona per la maggior parte dei progetti. Se il tuo progetto utilizza ACES o una configurazione OCIO personalizzata, includi i file di configurazione OCIO nella cartella del progetto e verifica che il percorso si risolva correttamente sul worker.
La camera attiva è impostata. La camera attiva della scena (Properties → Scene Properties → Camera) determina quale camera viene renderizzata. Assicurati che corrisponda a quella attesa.

Note specifiche per motore di rendering

Cycles (CPU)

Cycles CPU è eseguito sul nostro 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 della GPU, scene con librerie di texture molto grandi, o progetti che necessitano dell'output bit-perfect esatto che Cycles CPU produce.

Note di configurazione:

Licenza: Blender è gratuito e open source; nessuna preoccupazione di licenza sulla render farm.
Campionamento: Cycles Render Properties → Sampling → Render Samples. Il campionamento adattivo con un Noise Threshold di 0,01 produce output pulito per l'animazione; soglie inferiori (0,005, 0,002) per qualità più elevata a scapito del tempo di rendering.
Denoising: Cycles supporta OpenImageDenoise (OIDN) e Optix (solo GPU). OIDN viene eseguito su CPU e produce buoni risultati per immagini statiche e animazioni; configuralo in Render Properties → Sampling → Denoise.
Light tree: Blender 3.4+ include il campionamento light tree per scene con molte luci. Abilitalo in Render Properties → Sampling per scene con centinaia di sorgenti luminose.

Cycles (GPU / Optix)

Cycles GPU è eseguito sul nostro tier di worker NVIDIA RTX 5090 (32 GB di VRAM per scheda). È significativamente più veloce di Cycles CPU per la maggior parte delle scene (tipicamente da 5 a 15 volte più veloce), in particolare per i progetti con ray tracing intensivo.

Note di configurazione:

Dispositivo: Properties → Render Properties → Device → GPU Compute. Il backend Optix (che utilizza i core RT sulle GPU NVIDIA) è abilitato di default sui nostri worker.
Limiti VRAM: 32 GB di VRAM per worker sono sufficienti per la maggior parte dei progetti archviz e di animazione. Per progetti che si avvicinano al limite VRAM, l'opzione "Persistent Data" in Render Properties → Performance riduce i tempi di caricamento per frame ma aumenta l'utilizzo massimo di VRAM. Per progetti che superano 32 GB, passa a Cycles CPU o dividi la scena in porzioni renderizzabili.
Denoiser Optix: Più veloce di OIDN per l'animazione. Configuralo in Render Properties → Sampling → Denoise → Use OptiX. Richiede una GPU NVIDIA (fornita dal nostro tier di worker).

Eevee (non supportato)

Eevee non è disponibile sulla render farm. Eevee richiede un contesto di visualizzazione attivo (una sessione interattiva OpenGL/GPU) e non può essere eseguito in modalità server headless in cui operano i nostri nodi di rendering; pertanto il rendering con Eevee non è supportato. Un progetto il cui motore attivo è impostato su Eevee non verrà renderizzato — imposta il Render Engine su Cycles prima di inviare il lavoro.

Se hai bisogno dell'aspetto rapido e derivato dal real-time di Eevee, eseguilo in locale. Per il rendering cloud, Cycles GPU sul nostro parco RTX 5090 (con il denoiser Optix) offre un'iterazione rapida con output fisicamente accurato; è il motore di rendering in produzione supportato per Blender sulla render farm.

Cycles CPU vs Cycles GPU — quale scegliere

Cycles GPU sul tier RTX 5090 è il predefinito: è tipicamente da 5 a 15 volte più veloce per frame rispetto a Cycles CPU e gestisce la maggior parte delle scene archviz, di animazione e con ray tracing intensivo entro i suoi 32 GB di VRAM. Scegli Cycles CPU quando una scena supera 32 GB di VRAM, dipende da librerie di texture molto grandi, o necessita dell'output bit-perfect esatto prodotto dal percorso CPU (fino a 256 GB di RAM per nodo). Entrambi producono lo stesso risultato Cycles fisicamente accurato — la GPU termina più velocemente per frame, la CPU ha il tetto di memoria più elevato.

Rendering multi-camera

Per progetti che richiedono di renderizzare la stessa scena da più angolazioni in un unico invio, Blender supporta due approcci:

Approccio 1: scene multiple con diverse camere attive

Blender consente più scene per file .blend. Ogni scena può avere la propria camera attiva e le proprie impostazioni di rendering:

Nel progetto, crea una nuova scena per ciascuna angolazione (Scene → New Scene → Link Objects).
Imposta la camera attiva di ogni scena sulla camera corrispondente.
Al momento dell'invio, la render farm renderizza la scena impostata come "Active". Per renderizzare più scene, invia ciascuna come un lavoro separato.

Approccio 2: View Layer per camera (Blender 2.8+)

Un approccio più efficiente per molte angolazioni è l'utilizzo di View Layer con diverse camere attive:

In Properties → View Layer, crea un View Layer per ciascuna angolazione.
In Properties → Output Properties → Output → Use Multi-View, configura stereo o multi-view se applicabile.
Configura i percorsi di output per View Layer utilizzando il token {layer} nel nome del file di output.
Invia il lavoro; il worker renderizza tutti i View Layer abilitati in un unico passaggio.

Per turntable archviz tipici (da 8 a 16 angolazioni), l'Approccio 2 è significativamente più efficiente perché la scena viene caricata una sola volta per frame e renderizza tutte le viste dalla stessa scena caricata.

Flusso di invio

Tre canali di invio sono compatibili con i progetti Blender:

Upload via web + invio tramite dashboard. Carica il file .blend (o la cartella di progetto archiviata), poi invia tramite il sito web. Questo è il percorso di invio più comune per gli utenti Blender.
Client App. Upload + invio + download automatico in un unico strumento.
Plugin di invio. È disponibile un add-on Blender per l'invio con un clic direttamente da Blender; installalo dal tuo pannello di controllo.

Per il flusso upload-invio-download cross-DCC, consulta .

Risoluzione dei problemi specifici di Blender

Per il troubleshooting generale applicabile a tutti i DCC, consulta . Casi specifici di Blender:

Alcuni oggetti nella scena non vengono renderizzati. Causa più comune: il toggle "Render Visibility" dell'oggetto è disabilitato. Nell'outliner, passa il cursore sulla riga dell'oggetto e verifica che l'icona della camera (Disable in Renders) sia abilitata. Controlla anche che l'oggetto non si trovi su un View Layer nascosto.
Texture mancanti nonostante Pack Into .blend. Verifica che Pack All Into .blend sia stato eseguito dopo le ultime modifiche alle texture. Se hai ricaricato le texture dopo il packaging, potrebbero essere tornate a riferimenti esterni. Esegui nuovamente il packing e salva.
Il rendering restituisce colori neri o errati. Controlla le impostazioni Color Management (Properties → Render Properties → Color Management). La causa più comune è un mismatch nel View Transform — assicurati che sia la tua workstation che il worker utilizzino lo stesso View Transform (Filmic è il predefinito e la scelta più sicura).
Il lavoro Cycles GPU viene eseguito su CPU. Verifica che Properties → Render Properties → Device sia impostato su GPU Compute e non su CPU. Controlla anche che il backend Optix sia selezionato se la tua scena richiede accelerazione hardware per il ray tracing.
Lo shader OSL personalizzato non funziona al rendering. Cycles supporta OSL (Open Shading Language), ma gli shader OSL personalizzati devono essere inclusi nell'archivio del progetto. I file shader OSL (.osl) devono trovarsi in una posizione accessibile al worker — la soluzione più semplice è inserirli nella stessa cartella del file .blend e referenziarli con un percorso relativo.
Add-on mancante sul worker. Gli add-on comuni (Animation Nodes, BlenderKit, Sverchok, FLIP Fluids, ecc.) potrebbero non essere preinstallati. Per Animation Nodes e simili add-on procedurali, la soluzione alternativa è convertire in bake la geometria procedurale in mesh prima dell'invio. Per altri add-on, contatta il supporto per discutere l'aggiunta all'immagine del worker.

Riferimenti correlati

— flusso di upload, invio e download
— come vengono calcolati i costi dei lavori Blender
— guida SFTP, formati di archivio
— troubleshooting cross-DCC
— installazione dell'add-on Blender
— articolo benchmark

FAQ

Q: Quali versioni di Blender supporta la render farm? A: Blender 4.0, 4.1, 4.2 LTS, 4.3 e 4.4 sono preinstallati su ogni worker. Seguiamo il cadenzamento dei rilasci di Blender e distribuiamo le nuove versioni entro due settimane dalla disponibilità pubblica. Blender 4.2 LTS è la scelta consigliata per il lavoro in produzione perché riceve correzioni di bug fino al 2026. Q: Posso renderizzare scene Eevee sulla render farm? A: No — Eevee richiede un contesto di visualizzazione attivo e non può essere eseguito sui nodi di rendering headless utilizzati dalla render farm; pertanto il rendering con Eevee non è supportato. Imposta il tuo Render Engine su Cycles prima di inviare il lavoro. Per un'iterazione rapida, Cycles GPU sul nostro parco RTX 5090 (con il denoiser Optix) è tipicamente da 5 a 15 volte più veloce di Cycles CPU per la stessa scena, quindi la GPU è la scelta predefinita a meno che la tua scena non superi 32 GB di VRAM. Q: La mia scena usa BlenderKit / Sverchok / Animation Nodes — verrà renderizzata? A: Gli asset BlenderKit già scaricati e salvati nel .blend verranno renderizzati correttamente (diventano dati mesh standard una volta posizionati). Sverchok e Animation Nodes sono procedurali — se la geometria procedurale non è stata convertita in bake su una mesh statica, il worker potrebbe produrre output inatteso. Esegui il bake della geometria procedurale in mesh (Sverchok: Set/Bake to Mesh; Animation Nodes: bake to action) prima dell'invio. Q: Devo incorporare le texture nel .blend o posso caricarle come file separati? A: Entrambe le opzioni funzionano. Pack Into .blend è la più semplice perché produce un singolo file autonomo. Il metodo con percorsi relativi e struttura di cartelle è preferibile per librerie di texture molto grandi dove Pack Into .blend produrrebbe un singolo file difficile da gestire. Assicurati di eseguire "Find Missing Files" prima di entrambi gli approcci per confermare che nulla sia rotto in locale. Q: Il rendering è completato ma i colori appaiono diversi rispetto al viewport della mia workstation. A: Nella maggior parte dei casi si tratta di un mismatch nella Color Management o nel View Transform. Controlla Properties → Render Properties → Color Management sulla tua workstation e verifica che le impostazioni salvate includano View Transform: Filmic (il predefinito). I Look Transform (alto contrasto, basso contrasto, ecc.) e i valori di Exposure sono anch'essi incorporati nel .blend e vengono applicati sul worker. Q: Sto renderizzando un'animazione. Devo usare un file video o una sequenza di immagini come output? 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 bene su tutta la render farm — il worker che riceve il lavoro renderizza tutti i frame in sequenza e codifica un unico file video. Le sequenze di immagini permettono alla render farm di distribuire i frame su più worker in parallelo, il che è significativamente più veloce per qualsiasi animazione superiore a circa 100 frame. Q: Il mio progetto usa shader OSL personalizzati. Funzioneranno sulla render farm? A: Sì, se i file shader .osl sono inclusi nell'archivio del progetto e referenziati tramite percorsi relativi nei nodi shader. La soluzione più semplice è inserire tutti i file .osl nella stessa cartella del file .blend. Q: Come si confronta il costo del rendering GPU vs CPU sulla render farm? A: Il rendering GPU è tipicamente più veloce per frame (da 5 a 15 volte per Cycles), ma il costo per worker è più elevato perché le macchine GPU sono costose. Il costo totale di un rendering è approssimativamente comparabile tra Cycles CPU e Cycles GPU per la maggior parte delle scene — la GPU termina più velocemente ma costa di più al minuto. Per stime di costo specifiche in base alla tua scena, il fornisce un confronto per frame e per lavoro. Q: Posso renderizzare simulazioni Blender (fluidi, fumo, capelli) sulla render farm? A: Per le simulazioni, i file di cache devono essere convertiti in bake localmente prima, poi inclusi nell'upload del progetto. La render farm renderizza i frame rispetto alla cache convertita; non esegue simulazioni live. Questo è l'approccio standard su tutti i DCC — il bake delle simulazioni è lavoro da workstation, il rendering dei frame è lavoro da render farm.

---

[PHASE 2D: cover image needed — 1200x675px WebP]