Il motore di rendering è l’insieme degli algoritmi che trasformano i dati della scena 3D (modelli, materiali, illuminazione, etc) nelle immagini bitmap/raster chiamate render. Le immagini digitali posseggono una profondità colore espressa in bit per pixel (bpp) e calcolata come potenza di due. Con Blender potremo utilizzare la classica profondità colore Truecolor a 24 bit, ossia 2 elevato alla ventiquattresima potenza (2²⁴) equivalente a una tavolozza di ben 16.777.216 colori, oppure spingerci a una profondità di 48 Bit. Per trattare un così vasto numero di colori è necessario adottare un modello matematico che descrive ogni singola tonalità tramite tre coordinate, un po’ come si fa per stabilire la posizione dei punti geometrici nello spazio 3D. Il modello colore utilizzato nella computer grafica è l’RGB (Rosso, Verde e Blu) direttamente ispirato alla fisiologia stessa della vista umana. L’hardware grafico utilizzerà invece uno Spazio Colore poiché dovrà trasformare il modello colore (entità astratta) in immagini correttamente percepibili tramite un monitor. Lo spazio colore che a noi interessa è l’sRGB che troverete impostato di default nel contesto properties dedicato al rendering
La profondità colore per ognuna delle tre componenti può essere di 8 o 16 bit, nel primo caso (il più comune) abbiamo 256 livelli rispettivamente tra Nero e Rosso/Verde/Blu (256×256×256 equivale proprio a 224.). Blender permette di definire i colori in tre modi diversi:
- Tramite le componenti RGB
- Tramite le componenti HSV (Colore, Saturazione, Valore)
- Tramite stringa esadecimale HEX (una sorta di indirizzo che individua univocamente il colore).
Il tutto semplicemente utilizzando un’intuitiva tavolozza chiamata ruota dei colori che avremo modo di approfondire successivamente.
Per la precisione noi tratteremo immagini RGBA e non RGB, vale a dire con il canale aggiuntivo Alpha dedicato alla trasparenza del pixel. Una volta ottenuto il nostro render (tasto F12 oppure Render>Render Image) lo andremo a salvare su Hard Disk scegliendo il formato nel contesto Output delle properties, icona 
qui troviamo diversi formati grafici suddivisi in:
- Non Compressi (bmp)
- Compressi senza perdita (png)
- Compressi con perdita (jpeg)
- Che supportano il canale alpha (Png, Targa, Tiff)
più altri formati speciali come ad esempio il Radiance HDR che incontreremo nel paragrafo 4.5.
La profondità colore di 16 bit per canale (disponibile nei formati png e tiff) è utile per evitare perdite di dati durante le conversioni a livello hardware e nell’eventuale fase di post-processing dei nostri render, ma esiste un limite riguardante la percezione umana dei colori che di fatto ha reso il truecolor lo standard nella costruzione degli stessi monitor (il mercato oggi offre modelli con una maggiore profondità, utilizzati anche in ambito gaming). Nei casi in cui la profondità colore mostrasse qualche limite, specie nelle immagini truecolor con una tinta dominante, la tecnica del dithering (par 5.2) unita alle alte risoluzioni riuscirà perfettamente a ingannare l’occhio.
Indipendentemente dal motore grafico scelto, Blender necessita innanzitutto che la scena abbia almeno un oggetto di tipo camera. La fotocamera è lo strumento creato per catturare immagini dallo spettro visibile grazie all’interazione fisica tra i raggi luminosi che raggiungono l’obiettivo e quindi la pellicola (oppure i sensori a semiconduttore dell’era digitale). In Blender troviamo l’equivalente virtuale della fotocamera nell’Object Camera, rappresentato nella 3D View da una piramide a base quadrata con un triangolo che può essere pieno oppure vuoto.
In qualsiasi scena potremo inserire tutte le camere che desideriamo, ma solo una di esse sarà quella attiva (contrassegnata dal triangolo pieno) e dal cui punto di vista partirà il rendering che ovviamente verrà influenzato dalle impostazioni scelte per la camera stessa. Qualsiasi camera può essere resa quella attiva selezionandola e premendo Ctrl-0 del tastierino numerico. Le impostazioni della camera si trovano nel contesto properties Object Data, icona 
argomento che avremo modo di approfondire più avanti. Al momento concentriamoci sulle differenze e similitudini che intercorrono tra le due tipologie di rendering esistenti in Blender: Eevee e Cycles. Il primo è un motore 3D di tipo PBR (Physically Based Rendering) che mira a un buon compromesso tra realismo e velocità grazie a dei modelli matematici studiati per simulare in modo efficiente l’illuminazione su qualsiasi tipo di superficie (opaca, semitrasparente, riflettente, etc). Con Eevee il calcolo di un singolo fotogramma può durare una frazione di secondo (animazioni 3D in real time) fino a diversi minuti, ciò in base al grado di precisione impostato per il rendering, alla complessità dei vari modelli e i loro materiali, il tutto senza dimenticare la risoluzione scelta per i nostri render. L’insieme dei calcoli necessari è interamente eseguito dalla GPU in modo analogo a quanto avviene con i celebri engine commerciali UE4 o Unity, anch’essi di tipo PBR. Nel lungo periodo di gestazione di Blender 2.8 (innumerevoli release alpha e beta) Eevee ha convinto utenti e sviluppatori di poter divenire qualcosa di più di una semplice anteprima real time da affiancare a Cycles, e oggi nelle release 2.9x si presenta come un engine con cui è possibile renderizzare tutti quei progetti che non richiedono un’esatta simulazione del comportamento fisico della luce, ma una resa finale approssimativamente realistica (render in alto). Eevee e Cycles utilizzano il medesimo sistema di “Shading” (ombreggiatura) derivato dal comune approccio PBR. Lo shader (ombreggiatore) ha il compito di simulare gli effetti dell’illuminazione diretta in base ai parametri scelti per la superficie del modello, come ad esempio la riflessione diffusiva o altre impostazioni più particolareggiate come la presenza di asperità (roughness) o rilievi (bump), magari ricorrendo a particolari texture (tessiture o trame). Le analogie tra i due engine in realtà finiscono qui, poiché Cycles elabora non solo l’illuminazione diretta proveniente dalle sorgenti di luce, ma anche quella frutto dei rimbalzi dei raggi luminosi (illuminazione indiretta), parliamo cioè di un engine Global Illumination. Considerando l’enorme differenza tecnologica che intercorre tra Eevee e Cycles, è del tutto inutile procedere a un confronto diretto a colpi di render. Se come detto Eevee aiuta a risparmiare tempo con una resa spesso appagante ma non del tutto realistica, Cycles spreme al massimo la potenza hardware del nostri PC in modo da raggiungere il vero fotorealismo, ovviamente con tempi di elaborazione considerevolmente superiori. Attenzione però, nel rendering 3D il fotorealismo non è mai frutto del lavoro dei soli algoritmi, esso richiede un accurato studio dell’illuminazione e dei materiali, oltre a una certa esperienza e un occhio ben allenato. In questo capitolo ci occuperemo di Eevee, impostato come engine di default, dopodiché il passaggio a Cycles sarà del tutto naturale e indolore.
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.