
V-Ray 6 su una Cloud Render Farm: Guida Pratica 2026
Panoramica
Introduzione
V-Ray è un punto di riferimento nel rendering di produzione da oltre due decenni, e V-Ray 6 è ancora la versione utilizzata quotidianamente da una larga fetta degli studi. Le nuove versioni principali vengono rilasciate, le pipeline le validano lentamente, e un progetto archviz in 4K da consegnare la settimana prossima non può aspettare una migrazione di versione. Quindi, anche con V-Ray 7 ora disponibile, molte delle scene che arrivano a una V-Ray 6 cloud render farm sono costruite, illuminate e approvate nella versione 6 — e devono essere renderizzate nello stesso modo su migliaia di core come su una singola workstation.
È proprio qui che risiedono la maggior parte dei problemi. Una scena V-Ray 6 che si renderizza perfettamente sulla macchina su cui è stata costruita può produrre flicker, perdere asset o silenziosamente tornare al motore sbagliato nel momento in cui i suoi frame vengono distribuiti tra i nodi di lavoro che non hanno mai visto la cartella del progetto. Presso Super Renders Farm abbiamo trascorso anni a osservare esattamente quali passaggi sopravvivono a quel salto e quali si rompono. Questa guida illustra cosa è cambiato in V-Ray 6 per chi effettivamente preme il tasto render, come la versione si comporta nelle applicazioni host che supportiamo, quando V-Ray GPU batte V-Ray CPU (e quando non lo fa), e come preparare una scena in modo che i frame distribuiti tornino puliti. Nulla di tutto ciò presuppone l'acquisto di proprie licenze di rendering o la necessità di accedere da remoto a una macchina per gestire una coda.
Cosa ha cambiato V-Ray 6 per chi effettua il rendering
Buona parte della discussione su V-Ray 6 si concentra su comodità di modellazione e look-dev. Ciò che conta su una render farm è più ristretto: quali funzionalità cambiano il lavoro che un nodo di rendering deve svolgere, la dimensione del file da trasferire o i plugin che devono essere installati. Alcune funzionalità del ciclo V-Ray 6 sono genuinamente rilevanti per la render farm.

V-Ray 6 funzionalità di rendering — Enmesh, Chaos Scatter, V-Ray Decals e nuvole volumetriche
Enmesh distribuisce una mesh sorgente su una superficie al momento del rendering invece di incorporare quella geometria nella scena. Si pensi a cotte di maglia, facciate perforate, tessuti intrecciati, griglie. Poiché la geometria viene generata sul nodo durante il rendering anziché essere memorizzata nel file, il .vrscene che viaggia verso ogni nodo rimane leggero e la geometria pesante esiste solo nella memoria di rendering. È un vantaggio reale su una render farm: meno trasferimento di rete, e RAM che scala con il rendering anziché con il file salvato.
Chaos Scatter ha introdotto la dispersione nativa direttamente in V-Ray — vegetazione, rocce, copertura del terreno — risolti proceduralmente al momento del rendering. Il vantaggio lato render farm è la riduzione delle dipendenze: una scena distribuita con Chaos Scatter non necessita di un plugin di dispersione di terze parti con licenza installata su ogni nodo, il che rappresenta un elemento in meno che può essere mancante quando un frame arriva su un nodo di lavoro.
V-Ray Decals proiettano un materiale su una superficie senza toccare le sue UV o la topologia — etichette, adesivi, usura superficiale, segnaletica. Si risolvono interamente all'interno della pipeline di V-Ray, quindi l'unica cosa di cui un nodo ha bisogno è l'accesso alle texture map del decal.
Il cielo procedurale e le nuvole volumetriche consentono di costruire un cielo come parametri anziché come un HDRI fisso, con nuvole che si comportano come veri volumi nella scena. Questi rendering sono più pesanti per frame, ma sono completamente paralleli per frame — ogni nodo calcola i propri frame senza dipendenze dai vicini — quindi si distribuiscono in modo efficiente. L'avvertenza riguarda la memoria V-Ray GPU: i cieli volumetrici densi consumano VRAM, e un cielo complesso è spesso più sicuro su CPU.
Il V-Ray Frame Buffer continua a guadagnarsi il suo posto in una pipeline di render farm. Il suo Light Mix consente di separare e ribilanciare singole luci o gruppi di luci dopo che il rendering è terminato, direttamente dagli elementi di rendering salvati, senza nuovi rendering. Quando un direttore chiede di "riscaldare la luce principale e abbassare il riempimento" il giorno dopo che una sequenza è stata completata, questa regolazione avviene in compositing anziché tornare in coda — che è il tipo di modifica meno costoso possibile. E Chaos Cosmos, la libreria di asset integrata, è comoda nel viewport ma introduce il singolo errore più comune che si vede su una render farm; maggiori informazioni nella sezione del workflow, perché vale la pena affrontarlo correttamente.
V-Ray 6 nelle DCC che renderizziamo
V-Ray 6 viene fornito come integrazioni separate per le applicazioni host separate, e il fatto rilevante per la render farm è che tutte convergono sullo stesso formato di distribuzione: un file .vrscene renderizzato da V-Ray Standalone. L'host in cui si modella è importante per il proprio workflow; importa molto meno al nodo, che esegue semplicemente la scena esportata.
Sulla nostra render farm, le applicazioni host attraverso cui eseguiamo V-Ray sono 3ds Max, Maya, Cinema 4D e Houdini. 3ds Max con V-Ray è il punto di riferimento per l'archviz e il percorso più comune che vediamo — interni, esterni, visualizzazione di prodotti. Maya con V-Ray copre lo stesso ambito per le pipeline VFX e di animazione. Cinema 4D con V-Ray serve studi di motion e design. Houdini con V-Ray for Houdini completa il quadro per le scene costruite proceduralmente, dove la geometria guidata da VEX e da nodi viene risolta nella scena esportata al momento dell'esportazione. Se si desidera il dettaglio per applicazione, vengono mantenute landing page per 3ds Max, Maya, Cinema 4D e Houdini, e una panoramica specifica per V-Ray alla pagina V-Ray cloud render farm.
Due limiti onesti vale la pena dichiarare chiaramente. SketchUp dispone della propria integrazione V-Ray, ma SketchUp non è una delle applicazioni host che eseguiamo sulla render farm. Gli utenti di SketchUp hanno comunque un percorso pulito: V-Ray for SketchUp può esportare un .vrscene direttamente, e quel file viene renderizzato su V-Ray Standalone esattamente come uno esportato da 3ds Max — quindi la scena raggiunge la render farm senza che SketchUp sia installato in alcun posto. L'alternativa è portare il modello in 3ds Max, ricollegare i materiali ed esportare da lì, il che è più lavoro ma fornisce il set di strumenti completo di 3ds Max per la pulizia. In entrambi i casi, il rendering avviene tramite l'esportazione di un host supportato, non all'interno di SketchUp.
L'altro limite è Blender. Sulla nostra render farm, le scene Blender vengono renderizzate in Cycles — il renderer di produzione nativo di Blender — non in V-Ray. Quindi se la pipeline è V-Ray, gli host sono i quattro sopra indicati; se è Blender, si lavora con Cycles, che è un workflow diverso.
V-Ray GPU vs V-Ray CPU su una render farm: la decisione reale
V-Ray 6 offre due motori di rendering che condividono materiali e illuminazione ma si comportano in modo molto diverso una volta scalati. Scegliere quello sbagliato è uno degli errori più costosi su una render farm, perché di solito non ci si accorge finché i frame non tornano.
Si parta dalla realtà senza fronzoli: la maggior parte del lavoro V-Ray è ancora lavoro CPU. Tra i lavori che vediamo, circa il 70% del rendering è CPU — V-Ray (CPU), Corona, Arnold CPU — e la maggior parte di questo è archviz. V-Ray CPU scala quasi linearmente con i core fisici, motivo per cui i server ad alto numero di core si adattano così bene. La nostra flotta CPU è costruita su macchine dual Intel Xeon E5-2699 V4 con 96–256 GB di RAM ciascuna, per un totale di 20.000+ core CPU, e un interno in 4K che richiede ore su una workstation viene suddiviso in quel pool frame per frame. In modo cruciale, il rendering CPU indirizza la RAM di sistema, non la VRAM, quindi un interno ricco di texture con materiali PBR in 4K e 8K sull'intero set non incontra un limite di memoria come può fare una GPU. Per l'archviz di qualità finale su larga scala, la CPU è di solito il valore predefinito sicuro.
V-Ray GPU è l'altro 30%, ed è genuinamente più veloce — quando la scena si adatta. Funziona in due modalità: una modalità CUDA ampiamente compatibile, e una modalità RTX che utilizza i core di ray tracing hardware sulle GPU NVIDIA di classe RTX per un aumento delle prestazioni dipendente dalla scena. Le nostre macchine GPU sono dotate di schede RTX 5090 con 32 GB di VRAM ciascuna, e quel numero di VRAM è tutta la storia. La VRAM è il principale vincolo del rendering GPU: se la geometria e le texture di una scena si adattano, V-Ray GPU è eccellente per l'iterazione e per gli interni di complessità moderata. Il salto da 24 GB (una tipica scheda workstation di fascia alta) a 32 GB è la differenza tra una scena che risiede interamente in memoria e una che deve eseguire il paging dei dati tramite out-of-core, il che penalizza le prestazioni. Per le scene che eseguivano il paging su una scheda da 24 GB, avere semplicemente lo spazio disponibile può essere la parte più rilevante dell'aumento di velocità. Questo è stato testato esattamente su hardware RTX 5090 nel test di velocità V-Ray GPU e nella panoramica più ampia sulle prestazioni di rendering RTX 5090; la pagina GPU cloud render farm illustra come sono configurati questi nodi.
La decisione, sintetizzata:
| Scegliere V-Ray GPU quando… | Scegliere V-Ray CPU quando… |
|---|---|
| La geometria della scena + le texture si adattano alla VRAM (o quasi) | La scena supera la VRAM anche con out-of-core (set urbani di grandi dimensioni, 100+ GB di texture) |
| Si desidera iterazione rapida e frame di test veloci | È necessario il set di funzionalità più maturo per la consegna finale |
| Visualizzazione interni/prodotti di complessità moderata | Il rendering utilizza qualcosa ancora mancante dalla parità GPU |
| Si renderizza su nodi GPU specificatamente | Si desidera un comportamento prevedibile su un pool principalmente CPU |
V-Ray 6 supporta anche una modalità ibrida in cui i core CPU e la GPU sullo stesso nodo contribuiscono a un unico rendering, il che è utile quando una scena GPU è al limite del suo budget di memoria. L'errore da evitare è assumere che "la GPU sia sempre più veloce". Per una scena archviz di grandi dimensioni e ricca di texture, V-Ray CPU è spesso più veloce nel complesso perché non lotta contro un limite di memoria. È necessario abbinare il motore alla scena, non alla retorica.
Preparare una scena V-Ray 6 per un rendering pulito su una render farm
Questa è la parte che determina se i frame tornano utilizzabili. I meccanismi non sono complicati, ma alcuni di essi falliscono silenziosamente, che è il modo peggiore di fallire.
Il percorso di distribuzione. Il modo canonico per renderizzare V-Ray su una render farm è esportare la scena come .vrscene e lasciare che V-Ray Standalone la renderizzi su ogni nodo. La conseguenza importante riguarda le licenze: un nodo che esegue V-Ray Standalone non necessita di una licenza 3ds Max, Maya o Cinema 4D per renderizzare — ha bisogno di V-Ray. Sulla nostra render farm, quelle licenze di rendering sono incluse nel prezzo pagato per renderizzare; non è necessario portare la propria licenza e non occorre installare nulla. Questo è il significato pratico di "completamente gestito" — nessun desktop remoto, nessun server di licenze da gestire, nessuna configurazione software per nodo da parte del cliente. È anche la linea netta tra questo e un modello di noleggio di infrastruttura, dove si noleggerebbero macchine bare-metal e si fornirebbe la propria licenza.
Distribuzione dei frame, non Distributed Rendering. Questi due concetti vengono costantemente confusi. Una render farm distribuisce frame interi tra i nodi — il nodo A renderizza il frame 1, il nodo B renderizza il frame 2, e così via. Il Distributed Rendering (DR) di V-Ray è qualcosa di diverso: più macchine che collaborano su un singolo frame, suddividendo i bucket sulla rete in tempo reale. Il DR è uno strumento da studio per un singolo frame hero enorme; aggiunge latenza di rete, richiede versioni di V-Ray identiche ovunque, ed è meno efficiente su larga scala. Per praticamente ogni animazione e sequenza di immagini, la distribuzione dei frame è il modello corretto, ed è ciò che fa di default una render farm.

Distribuzione dell'intervallo di frame rispetto a V-Ray Distributed Rendering su una render farm
GI senza flicker. Per l'animazione, questa è la scelta che crea problemi. Brute Force GI con una Light Cache per frame calcola l'illuminazione indipendentemente per ogni frame — più lento per frame, ma zero flicker e nessuna dipendenza tra frame, quindi qualsiasi nodo può renderizzare qualsiasi frame in qualsiasi ordine. Questo è il default anti-flicker consigliato per l'animazione distribuita. L'approccio Irradiance Map è più veloce per frame perché precalcola una soluzione GI e la riutilizza, ma funziona solo per animazioni di volo della camera con luci e oggetti statici, e ogni nodo deve leggere la stessa mappa precalcolata da un percorso condiviso. Il fallimento classico: la mappa viene salvata in un percorso locale come C:\Users\artist\scene.vrmap, i nodi non riescono a trovarla, e ogni frame ricalcola silenziosamente la GI — producendo esattamente il flicker che si stava cercando di evitare. Se si utilizza Irradiance Map, si calcoli una volta, si spedisca il file con il job, e si aggiorni il percorso. In caso di dubbio, si utilizzi Brute Force.
Denoising. V-Ray 6 offre il V-Ray Denoiser (CPU), l'NVIDIA AI Denoiser (richiede una GPU NVIDIA sul nodo) e Intel Open Image Denoise (CPU, funziona ovunque). Tutti e tre operano per frame senza stato tra i frame, quindi sono sicuri per il rendering completamente parallelo. Il consiglio standard: salvare sempre il pass beauty grezzo, non denoisato, insieme all'output denoisato. Se il denoiser sfuma un dettaglio, si può ri-denoisare in post-produzione invece di ri-renderizzare la sequenza.
Asset Chaos Cosmos — il killer silenzioso. Questo è l'errore di render farm più comune per V-Ray 6 per i nuovi utenti, e fallisce silenziosamente. Gli asset Cosmos vengono scaricati nella cache Cosmos locale. Quando si esporta il .vrscene, quegli asset vengono referenziati tramite i loro percorsi locali. I nodi non hanno la cache Cosmos dell'utente, quindi si trovano di fronte a una scena che punta a file inesistenti — e il risultato è vegetazione mancante, oggetti grigi o un cielo vuoto, senza alcun errore esplicito. La soluzione è raccogliere gli asset prima di inviare il job: si utilizzi lo strumento di raccolta asset / "pack project" di V-Ray per raccogliere ogni file Cosmos e di texture in una cartella accanto alla scena e aggiornare tutti i percorsi relativi. In questo modo il job è autonomo. Se si salta questo passaggio, si dovrà ri-renderizzare. La stessa disciplina si applica alle texture normali — qualsiasi riferimento tramite un percorso locale assoluto è un asset mancante in attesa di manifestarsi.

Pipeline di distribuzione V-Ray 6 dall'esportazione DCC ai nodi di rendering V-Ray Standalone
Upload. Si comprima il progetto come .tar.gz o .7z — gli archivi .zip non sono supportati per l'upload, quindi occorre ricomprimere prima di inviare un progetto zippato. Per le scene molto grandi, SFTP o il client desktop è più affidabile di un upload tramite browser. L'output di rendering rimane disponibile per 45 giorni, quindi si scarichino i frame completati tempestivamente o si lasci che il client li scarichi automaticamente.
Una checklist pre-volo prima dell'invio
La maggior parte dei rendering falliti su render farm sono riconducibili a quattro o cinque cause ripetibili. Eseguire un singolo frame di test sulla render farm prima di impegnarsi in una sequenza da 2.000 frame costa pochi minuti e intercetta quasi tutti i problemi. Ecco la versione breve fornita agli utenti:
| Verifica | Perché è importante su una render farm | Soluzione rapida |
|---|---|---|
| Asset raccolti e percorsi aggiornati | Percorsi locali assoluti (texture, Cosmos) = asset mancanti sui nodi | Raccogliere asset / aggiornare percorsi relativi con "pack project" |
| Metodo GI scelto consapevolmente | Irradiance Map su una scena in movimento = flicker | Brute Force + Light Cache per l'animazione come default |
| Motore adatto alla scena | Scena GPU oltre la VRAM si blocca; scena CPU su GPU spreca il nodo | Verificare il consumo di VRAM nel frame buffer prima |
| Pass grezzi e denoisati salvati | Un denoising errato significa altrimenti un nuovo rendering | Salvare sia il beauty che gli elementi denoisati |
| Un frame di test renderizzato sulla render farm | Successo locale ≠ successo sulla render farm | Inviare il frame 1, confermare, poi inviare l'intervallo |
| Progetto compresso come .tar.gz / .7z | .zip non è accettato | Ricomprimere prima dell'upload |
I costi seguono la stessa logica per unità tra i motori, il che rende la stima semplice: il rendering CPU viene fatturato a $0,004 per GHz-ora, e il rendering GPU a $0,003 per OctaneBench-ora, con tutte le licenze dei motori di rendering già incluse in quelle tariffe. I nuovi account iniziano con $25 di credito di rendering gratuito per eseguire esattamente il tipo di test su frame singolo descritto sopra, e i crediti non scadono. Il dettaglio completo si trova nella pagina prezzi, e se si stanno confrontando i provider anziché i motori, il nostro confronto tra render farm per V-Ray illustra cosa cercare.
FAQ
Q: È possibile renderizzare V-Ray 6 su una cloud render farm senza aggiornare a V-Ray 7?
A: Sì. Le scene V-Ray 6 vengono renderizzate tramite V-Ray Standalone da un .vrscene esportato, e non è necessario migrare prima a una versione principale più recente. Molte pipeline di produzione rimangono deliberatamente su V-Ray 6, e una render farm renderizza la versione con cui la scena è stata costruita e approvata.
Q: È necessario acquistare una propria licenza V-Ray per il rendering cloud? A: No. Sulla nostra render farm, la licenza di rendering V-Ray è inclusa nella tariffa per unità di rendering, quindi non è necessario portare o pagare per una licenza separata per il rendering. Questa è la differenza tra una render farm completamente gestita e un modello di noleggio di infrastruttura, dove si noleggerebbero macchine e si fornirebbe la propria licenza software.
Q: V-Ray GPU o V-Ray CPU — quale si dovrebbe usare su una render farm? A: Si utilizzi V-Ray GPU quando la geometria e le texture della scena si adattano alla VRAM e si desidera velocità per interni o iterazione; si utilizzi V-Ray CPU quando la scena è grande e ricca di texture o richiede il set di funzionalità più maturo per la consegna finale. La CPU indirizza la RAM di sistema anziché la VRAM, quindi gestisce le scene archviz di grandi dimensioni che costringerebbero una GPU a un paging out-of-core più lento.
Q: Come si evita il flicker GI in un'animazione V-Ray 6 renderizzata su molti nodi? A: Si utilizzi Brute Force GI con una Light Cache per frame come default — calcola l'illuminazione indipendentemente per ogni frame, quindi i nodi distribuiti non disaccordano mai. Si riservi il metodo Irradiance Map solo per voli della camera con luci e oggetti statici, e ci si assicuri che la mappa precalcolata si trovi su un percorso condiviso accessibile da ogni nodo.
Q: Perché gli asset Chaos Cosmos sono mancanti quando i frame tornano dalla render farm? A: Gli asset Cosmos vengono referenziati tramite percorsi locali che esistono solo nella propria cache, quindi i nodi di rendering non riescono a trovarli e gli oggetti vengono renderizzati grigi, mancanti o vuoti senza alcun errore esplicito. Occorre raccogliere e aggiornare tutti gli asset in una cartella di progetto autonoma prima di inviare — lo strumento di raccolta asset di V-Ray lo fa — in modo che la scena contenga tutto il necessario.
Q: È possibile renderizzare una scena V-Ray for SketchUp sulla render farm?
A: Sì, tramite esportazione. SketchUp non è un'applicazione host che eseguiamo, ma V-Ray for SketchUp può esportare un .vrscene che viene renderizzato direttamente su V-Ray Standalone, oppure si può portare il modello in 3ds Max ed esportare da lì. Il rendering avviene tramite la scena esportata di un host supportato, non all'interno di SketchUp.
Q: Qual è la differenza tra una render farm e V-Ray Distributed Rendering? A: Una render farm distribuisce frame interi su molte macchine, che è il modello efficiente per animazioni e sequenze di immagini. V-Ray Distributed Rendering (DR) invece suddivide i bucket di un singolo frame su più macchine in tempo reale — utile per un singolo frame hero molto grande, ma più lento e fragile su larga scala, e non è il modo in cui le sequenze vengono renderizzate su una render farm.
About Alice Harper
Blender and V-Ray specialist. Passionate about optimizing render workflows, sharing tips, and educating the 3D community to achieve photorealistic results faster.


