fbpx

4.1 – Cycles – Illuminazione Globale

Cycles è un motore di rendering definito Unbiased poiché ricorre a un integratore path tracing (evoluzione del raytracing) privo di errori sistematici (bias). Lo scopo di Cycles è quello di raggiungere risultati tendenti al vero fotorealismo che comportano l’esecuzione di un’enorme quantità di calcoli, con maggiori tempi di attesa e quindi minore possibilità per l’utente di sperimentare. Fortunatamente Cycles sfrutta la potenza delle schede grafiche moderne, anche quelle non professionali e dedicate al gaming, grazie al cosiddetto GPU Rendering. I vantaggi sono effettivamente molteplici perché come avremo modo di vedere Cycles integra nativamente il bouncing (rimbalzo) dei raggi luminosi, risultando nel contesto dell’illuminazione globale (diretta + indiretta) molto più efficiente e preciso di Eevee. E non finisce qui, perché Cycles riesce anche a utilizzare contemporaneamente GPU e CPU per provare ad accelerare ulteriormente il rendering. Arriviamo dunque agli svantaggi: il primo è che la quantità di memoria di una GPU è limitata rispetto a quella del sistema; ad esempio saprete già che con una spesa contenuta è possibile installare sul proprio computer anche 32 giga byte di ram, con i quali si riesce a gestire progetti decisamente complessi. Le GPU hanno invece una ram fissa e non espandibile che varia da uno a quattro gigabyte nei modelli più economici e/o datati, fino a oltre 8 gigabyte per le schede video di fascia alta. Allo stato attuale del suo sviluppo, Cycles necessita che la GPU gestisca nella propria ram tutti i dati relativi ai modelli e alle texture, senza poter ricorrere alla memoria di sistema quando quella video viene esaurita, con conseguenze che vanno dall’impossibilità di proseguire il lavoro su GPU (ma si può in qualsiasi momento passare alla CPU) fino a episodi d’instabilità e blocco del software (casi a dire il vero molto rari). Le GPU supportate al meglio sono quelle del produttore Nvidia a causa dell’architettura di elaborazione in parallelo CUDA che ha preso maggiormente piede nell’ambito del GPU Rendering. Inoltre le moderne schede Nvidia RTX possono essere sfruttate a fondo tramite il framework OptiX. Fortunatamente Cycles sfrutta le API HIP in modo da supportare anche le GPU AMD (Vega, Rdna). Nella scheda System delle Preferences trovate il pannello Cycles Render Devices (CUDA, OPTIX, HIP) dove potrete decidere quali schede dovranno occuparsi del render, con o senza l’ausilio della CPU.

Impiegando un’unica gpu sia per il rendering, sia per la visualizzazione dell’ambiente desktop del sistema operativo, e quindi dell’interfaccia stessa di Blender, potrebbero verificarsi rallentamenti tali da rendere poco utilizzabile il computer durante le fasi di rendering (specie avvicinandosi al limite dell’esaurimento ram dedicata alla gpu). Nel caso non foste in possesso dei requisiti hardware necessari a utilizzare Cycles Render via GPU, non disperate, poiché esso funziona senza limitazione alcuna impiegando unicamente la CPU e la ram di sistema. A partire dalle release 2.8x di Blender sono state introdotte significative ottimizzazioni del codice per il rendering via CPU. Un processore centrale di fascia alta vi renderà abbastanza produttivi. Chiunque possegga una GPU Nvidia serie GTX/RTX 10xx/20xx/30xx, o equivalente AMD, può scaricare il bench ufficiale dal sito: opendata.blender.org ed eseguirlo sia con la CPU, sia con la GPU, in modo da rendersi conto fin da subito della maggiore efficienza e velocità di Cycles nel GPU rendering.
La maggiore potenza e precisione di Cycles non implica che esso sia più complesso di Eevee. Anzi, al contrario tutto diviene più semplice come dimostra la minore quantità di pannelli e opzioni nel contesto render.

Perché dunque se Cycles è così preciso e semplice, finora si è preferito dare precedenza e persino più spazio a Eevee? L’istantaneità (o quasi) del rendering in eevee consente al principiante di imparare molto più in fretta le regole fondamentali della grafica 3D. Soltanto dopo aver raggiunto un certo grado di conoscenza, nonché raffinato il proprio occhio, diverrà evidente il vantaggio di avere a disposizione un engine meraviglioso come Cycles. Alla consueta scena di default aggiungiamo un piano immediatamente sotto la base del cubo. Dal risultato nella Viewport in modalità Rendered possiamo notare due principali peculiarità.

La prima è che il rendering mostra un’ombreggiatura molto più complessa di quella che si ottiene di default con Eevee, il quale raggiunge tale dettaglio solo attivando varie funzioni (l’ambient occlusion ad esempio). La seconda è la presenza di un rumore piuttosto accentuato nelle zone d’ombra. Utilizzando una GPU di fascia alta il rendering dell’anteprima di questa scena molto elementare dura pochi secondi, magari non vi sarete neanche accorti che il risultato finale non è stato raggiunto istantaneamente, ma in una rapida sequenza di passi. Infatti in alto a sinistra nella Viewport, compare prima la dicitura Path Tracing Sample (campioni) . Raggiunto il valore massimo di sample la scritta verrà sostituita da “Rendering Done”. Cycles appartiene a una tipologia di rendering che non conclude il proprio lavoro al raggiungimento di un 100%, ma dovremo esser noi a troncare il processo stabilendo preventivamente un numero massimo di iterazioni (o un tempo limite). Nel contesto render troviamo il pannello Sampling dove potremo differenziare il numero di campioni stabilendo un limite min e max sia per la Viewport, sia per il rendering (F12). Di default è attiva la spunta a Noise Thresold con un valore pari a 0,01. Ciò farà in modo che l’engine non giungerà al numero inserito in Max Samples, fermandosi prima. Disattivando la spunta, o inserendo zero, cycles si fermerà al raggiungimento del valore di Max Samples.

Capirete molto presto che a seconda della scena da renderizzare sarebbe inutile oltrepassare un certo numero di samples (individuabile con una serie di prove) in quanto il risultato finale resterebbe sostanzialmente invariato. Consiglio di lasciare a 0 il valore di Min Samples e diminuire a 64/128 il Max Samples di default impostato a 1024 per la Viewport e 4096 per il render, ossia valori troppo alti per le prove iniziali che andremo a fare (sebbene tutto dipenda dalla GPU). Impostando zero in Max Sample (preview) Cycles non smetterà mai di renderizzare. Al momento lasciamo disattivo il Denoise.
I samples sono i campioni che Cycles impiega nel processo di rasterizzazione di ogni pixel dell’immagine. In Cycles noterete che per qualsiasi variazione dei parametri della scena, Blender renderizzerà nuovamente la stessa. Provate dunque ad attivare la modalità Walk/Fly o ad effettuare alcune trasformazioni sulle mesh e/o fonti luminose in scena, potreste trovare eccitante, specie se in possesso di una gpu discretamente potente, questa approssimazione di un rendering fotorealistico in pseudo real time. Nonostante non sia strettamente necessario comprendere nel dettaglio il funzionamento di questo engine, poiché acquisiremo sul campo la necessaria esperienza per padroneggiarlo, a grandi linee possiamo dire che in Cycles i raggi luminosi vengono divisi in quattro categorie, quelli che provengono dalla camera, quelli riflessi dalle superfici, quelli trasmessi attraverso le superfici (e volumi) e infine i raggi utili a determinare le ombre trasparenti. Nel pannello Light Paths, contesto render, possiamo variare il numero massimo di rimbalzi (bounces) di tali raggi luminosi.

La luce riflessa genera a sua volta:

  • un numero massimo di bounces diffuse (riflessione diffusiva)
  • un numero massimo di bounces glossy (riflessione speculare)
  • un numero massimo di bounces transmission (trasmissione nitida).

Integrators Preset a semplificarci la vita che troverete cliccando l’icona

  • Direct Light limita al massimo gli effetti dell’illuminazione indiretta e dei rimbalzi.
  • Fast Global Illumination
  • Full Global Illumination
  • Limited Global Illumination consente una buona implementazione dell’illuminazione indiretta.

(alcuni valori di Bounces potranno essere diminuiti in funzione del tipo di materiali che avremo in scena). Consiglio di tenere l’impostazione di default, in seguito vedremo alcune variazioni mirate a ridurre la presenza di rumore e artefatti nel render finale. Tra le restanti opzioni presenti nel contesto Render è interessante il pannello Film (pellicola)

dove aumentare la luminosità del rendering senza dover forzare l’energia delle lamp (che potrebbero portare alla comparsa di aliasing in zone a contrasto elevato, oppure di eccessivo rumore video nelle zone d’ombra) semplicemente aumentando il parametro Exposure. Mettendo la spunta a Transparent non verrà renderizzato lo sfondo e sarà possibile salvare l’immagine di un oggetto, come PNG, direttamente “scontornato”.
Da una prima occhiata anche il contesto World (che verrà approfondito in seguito) ci appare molto simile a quello visto in Eevee. Il background, grigio scuro di default, in realtà non è un semplice colore di sfondo ma un’illuminazione ambientale minima che impedirà alle superfici non direttamente illuminate, né colpite da rimbalzi dei raggi luminosi, di apparire come totalmente nere.

Qui in alto la scena di default con il colore del World cambiato da grigio a nero, in modo che esso non possa agire da illuminazione ambientale. Inserendo un piano al di sotto del cubo, notiamo subito il comportamento della luce in Cycles, che diffondendosi realmente con dei rimbalzi, porterà il lato in precedenza nero ad avere un’ombreggiatura più realistica.

Dirigiamoci quindi nel contesto Material per dare al cubo un colore diverso da quello di default (potete usare il principled shader azzerando specular e roughness). Notiamo subito un effetto che evidenzierà ancora una volta la natura fisicamente coerente del motore Cycles.

In prossimità del cubo il piano assume una sfumatura rossastra sia nelle zone d’ombra, sia in quelle direttamente illuminate; oltre al fatto che il perimetro dell’ombra andrà a variare da un contorno netto a uno progressivamente soft.

Tutto ciò che nel capitolo precedente si è detto riguardo i materiali e il texturing continua a valere in Cycles, con il vantaggio che non dovremo stavolta attivare all’occorrenza funzionalità aggiuntive del rendering, poiché: occlusione ambientale, riflessioni e rifrazioni, vengono tutte elaborate nativamente. L’anteprima Material Preview continua ad essere gestita da Eevee, quindi scegliendo di visualizzare in essa le luci e il world della scena, otterrete un confronto diretto e immediato tra i due engine. Inoltre nella modalità rendered di cycles è possibile disattivare il world e le luci in uso per utilizzare lo stesso comodo sfondo HDRI impostato in material preview.

Anticipo subito che difficilmente le scene curate ed elaborate in uno dei due engine, risulteranno altrettanto ben definite nell’altro senza adeguati aggiustamenti. La differenza che subito salta all’occhio passando da Eevee a Cycles è che una scena ben illuminata diventa immediatamente più scura. La natura fisicamente coerente di Cycles contempla infatti la perdita di energia luminosa dovuta ai rimbalzi dei raggi tracciati da questo engine. Ciò consente di ottenere una migliore resa delle ombreggiatura, ma sarà necessaria una maggiore emissione complessiva di luce. In effetti solo per Cycles potremo realmente parlare di un engine Physically Based Rendering, in quanto lo shading in eevee è solo un’approssimazione (per quanto ottima) adatta al rendering real time. Qui potete vedere un confronto immediato tra il rendering in Eevee e in Cycle:

Paragrafo successivo
Paragrafo precedente

Torna all’Indice


Nell’augurarti un divertente e produttivo studio di Blender, ti ricordo che puoi supportare questo progetto in due diversi modi: con una piccola donazione (paypal) oppure acquistando la versione PDF (su lulu.com) impaginata in modo professionale e ottimizzata per la visione su Tablet.  



>Acquista l’ebook (PDF) su lulu.com in piena sicurezza con paypal e carte prepagate<