Physically-based Rendering for OpenGL - SUPSI C09910 - in SUPSI Tesi
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Physically-based Rendering for OpenGL
Studente/i Relatore
Brian Dalle Pezze Achille Peternier
Correlatore
—
Committente
SUPSI
Corso di laurea Modulo
Ingegneria Informatica C09910
Anno
2017/18
Data
31 Agosto 2018
i
Indice
Abstract 1
1 Contesto del Progetto 3
1.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Compiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Obbiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Teorie fondamentali 5
2.1 Riflessione e rifrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Microfacet Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Physically-based Rendering 9
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 BRDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Equazione di rendering . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Cook-Torrance BRDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Normal Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Fresnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3 Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Implementazione 17
4.1 Primi passi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Risultati intermedi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Passaggio a Overvision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Decisioni finali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.2 Modifiche alla classe Material . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 Modifiche al Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.3.1 Over3DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.3.2 OVOreader . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Physically-based Rendering for OpenGL
ii INDICE
4.2.3.3 Conversione materiali . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Conclusione 43
5.1 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Miglioramenti futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.1 Subsurface Scattering . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.2 Image-based Lighting . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Allegati 53
Bibliografia 55
Physically-based Rendering for OpenGL
iii
Elenco delle figure
1 Incidenza della luce luce su una superficie . . . . . . . . . . . . . . . . . . . 5
2 Dimostrazione grafica della Microfacet Theory . . . . . . . . . . . . . . . . . . 7
3 Normal Distribution in funzione della roughness, valore crescente da sinistra
verso destra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Diverse intensità di Fresnel su sfere viste in controluce . . . . . . . . . . . . . 13
5 Effetto della Geometry Function con roughness crescente: si può notare
come l’ombra si faccia più marcata e la distinzione meno nitida mentre la
superficie si scurisce leggermente . . . . . . . . . . . . . . . . . . . . . . . . 16
6 Serie di sfere per testare le caratteristiche: sull’asse x c’è un valore crescente
di roughness, mentre sull’asse y un valore crescente di metalness . . . . . . . 18
7 Vista ravvicinata delle sfere metalliche . . . . . . . . . . . . . . . . . . . . . . 19
8 Vista ravvicinata delle sfere dielettriche . . . . . . . . . . . . . . . . . . . . . 20
9 Sfere viste in controluce: notare Fresnel ben visibile su quelle centrali . . . . . 21
10 La sfera a sinistra è mappata come ferro arrugginito, quella a destra come
marmo liscio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11 Snippet delle API di IGameMaterial, si possono notare i getter dei tipici para-
metri per Phong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12 Sfere renderizzate con il modello di Phong (demoBullet) . . . . . . . . . . . . 31
13 Sfere renderizzate con PBR (demoBullet) . . . . . . . . . . . . . . . . . . . . 31
14 Dettaglio di un punto caldo di riflessione con Phong (demoBullet) . . . . . . . 32
15 Dettaglio di un punto caldo di riflessione con PBR (demoBullet) . . . . . . . . 32
16 Dettaglio testa di leone con Phong (demo) . . . . . . . . . . . . . . . . . . . . 33
17 Dettaglio testa di leone con PBR (demo) . . . . . . . . . . . . . . . . . . . . . 33
18 Dettaglio statua di marmo con Phong (demo) . . . . . . . . . . . . . . . . . . 34
19 Dettaglio statua di marmo con PBR (demo) . . . . . . . . . . . . . . . . . . . 34
20 Scena generale della demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
21 Dettaglio statua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
22 Dettaglio pistola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Physically-based Rendering for OpenGL
iv ELENCO DELLE FIGURE
23 Dettaglio sfere di vari materiali . . . . . . . . . . . . . . . . . . . . . . . . . . 47
24 Dettaglio spada. Notare il riflesso del metallo tipico del PBR. . . . . . . . . . . 48
25 Dettaglio teiere di materiale metallico (sopra) e dielettrico (sotto) con rough-
ness crescente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
26 Esempi di Subsurface Scattering a diverse profondità . . . . . . . . . . . . . . 50
27 L’IBL consente di avere un riflesso della scena circostante, rendendo la per-
cezione dei materiali più realistica . . . . . . . . . . . . . . . . . . . . . . . . 51
Physically-based Rendering for OpenGL
v
Elenco delle tabelle
1 F0 per vari materiali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Physically-based Rendering for OpenGL
vi ELENCO DELLE TABELLE Physically-based Rendering for OpenGL
1
Abstract
Il Physically-based rendering (o PBR) è un modello di illuminazione che cerca di simulare in
modo simile alla fisica il funzionamento della luce nel mondo reale, allo scopo di aumentare
il fotorealismo delle scene o rendere più naturali e piacevoli all’occhio i materiali renderizzati.
I PBR sono caratterizzati dall’utilizzo di BRDF (Bidirectional Reflective Distribution Function),
che simulano la riflessione della luce, la conservazione dell’energia (distinzione mutualmen-
te esclusiva tra luce riflessa e rifratta) e l’applicazione della Microfacet Theory, che simula il
comportamento generalizzato di ogni superficie dipendentemente dalla sua rugosità.
Physically-based rendering (PBR) is a lighting model that tries to mimic in a physical-like
manner how light works in the real world in order to improve photorealism and to make ma-
terials appear more natural and pleasant to the human eye.
PBRs are characterized by the implementation of a BRDF (Bidirectional Reflective Distri-
bution Function), that emulates light reflection, an energy conservation principle (mutual di-
stinction between refracted and reflected light) and the applicaton of the Microfacet Theory,
that simulates the general behaviour of a surface based on its roughness.
Physically-based Rendering for OpenGL
2 ELENCO DELLE TABELLE Physically-based Rendering for OpenGL
3
Capitolo 1
Contesto del Progetto
1.1 Descrizione
Lo scopo di questo progetto è quello di riuscire a implementare un modello di illuminazione
physically-based nel motore grafico fornito dal docente e utilizzato al DTI per vari progetti.
Vanno vagliate le opzioni disponibili per quanto riguarda i metodi di rendering physically-
based in utilizzo al momento e la loro compatibilità con le pipeline già presenti nel motore.
1.2 Compiti
• Investigare l’ultima generazione di PBR sviluppata, dalla teoria alla sua implementa-
zione
• Discutere con il docente le diverse varianti di PBR da implementare con attenzione
al miglior rapporto tra potenza computazionale richiesta, complessità algoritmica e
compatibilità con il software di rendering esistente
• Definire il tipo di informazioni che un modello 3D necessita per funzionare con il PBR,
inclusa la ricerca di campioni da usare per sviluppo, testing e validazione
• Integrare il PBR nel software di rendering 3D basato su OpenGL fornito dal docente
1.3 Obbiettivi
• Implementare il PBR 3D in real-time al motore grafico fornito dal docente accertandosi
che tutte le pipeline (rendering diretto e deferred) siano funzionanti
• Estendere il plugin di export/import del motore grafico per i modelli 3D in modo che
supporti tutte le informazioni relative al PBR
Physically-based Rendering for OpenGL4 Contesto del Progetto
• Fornire una dimostrazione che mostri chiaramente i vantaggi del PBR rispetto al
modello di rendering precedente
1.4 Tecnologie
• OpenGL 4.5
• GPU Programming
• C/C++ (Visual Studio, Windows)
• 3D Studio MAX
1.5 Milestones
1. Raccogliere documentazione sulle varianti di PBR più utilizzate
2. Adattare il motore grafico progettato durante il semestre per utilizzare uno shader PBR
3. Implementare e testare la prima versione dello shader
4. Cominciare l’integrazione dello shader in Overvision usando i parametri a disposizione
5. Discutere e implementare cambiamenti alle classi di Overvision per adattarsi allo
shader
6. Adattare i plugin di import/export dei file .OVO ai nuovi parametri di Overvision
7. Creare una demo da aggiungere a quelle presenti in Overvision per dimostrare i
risultati ottenuti
Physically-based Rendering for OpenGL5
Capitolo 2
Teorie fondamentali
Prima di spiegare cos’è e in cosa consiste il PBR è necessario comprendere i fondamenti
su cui si basa.
2.1 Riflessione e rifrazione
Il primo punto da affrontare è come nella nostra simulazione vengono approssimate rifles-
sione e rifrazione, fenomeni che fanno da base teorica per la conservazione dell’energia,
ovvero il principio che ci dice che la luce in uscita non deve essere maggiore della luce in
entrata. Dal punto di vista fisico, che è quello che vogliamo simulare, questo succede per-
ché quando un raggio di luce incide con una superficie si divide in luce riflessa e rifratta. In
termini di computer grafica, la luce riflessa è quella che ci fornisce la componente specular,
mentre quella rifratta (e non assorbita dal materiale) la componente diffuse.
Figura 1: Incidenza della luce luce su una superficie
Fonte: Physically-Based Shading Models in Film and Game Production
Physically-based Rendering for OpenGL6 Teorie fondamentali Come si può notare dall’immagine, la componente diffuse non è null’altro che la luce rifratta uscente da un materiale nelle immediate vicinanze del punto di incidenza. Il subsurface scattering considera anche la luce in uscita a distanza maggiore (l’argomento viene affron- tato più approfonditamente nella sezione 5.2.1). Dal momento che noi consideriamo una grande varietà di materiali, sia metallici che dielet- trici, c’è un’altra cosa di cui dobbiamo tenere conto: i metalli assorbono tutta la luce rifratta e sono quindi privi di componente diffuse. Data questa particolare proprietà è necessario trattarli differentemente dagli altri materiali, ed è per questo che più avanti faremo uso del parametro metalness in determinati calcoli. Va infine puntualizzato che luce rifratta e riflessa sono mutualmente esclusive, questo si- gnifica che la parte di luce rifratta deve essere sottratta alla quantità di luce riflessa. Con questo piccolo accorgimento possiamo sempre essere certi di non violare mai il principio di conservazione dell’energia. Physically-based Rendering for OpenGL
7
2.2 Microfacet Theory
La microfacet theory serve a spiegare come la luce viene riflessa nella nostra simulazio-
ne. Essa dice che ogni materiale, a livello microscopico, è composto da piccoli specchi
che riflettono la luce in modo perfetto. L’allineamento degli specchi influisce direttamente
sulla riflessione speculare che l’osservatore percepisce. In un materiale ruvido gli specchi
saranno allineati in modo caotico, mentre in un materiale liscio saranno molto più regolari:
Figura 2: Dimostrazione grafica della Microfacet Theory
Fonte: Learn OpenGL
Quello che l’osservatore percepisce come riflessione "perfetta" dipende dal numero di spec-
chi allineati all’Halfway Vector, un vettore che sta a metà tra il vettore l della luce incidente
e il vettore v del punto di vista dell’osservatore, ed è calcolato nel seguente modo:
l+v
h=
kl + vk
Meno specchi sono allineati con l’halfway vector, più la riflessione sarà concentrata, e vice-
versa. Il parametro che ci dice quanti specchi, in percentuale, sono allineati con l’halfway
vector è la roughness.
Physically-based Rendering for OpenGL8 Teorie fondamentali Physically-based Rendering for OpenGL
9
Capitolo 3
Physically-based Rendering
3.1 Introduzione
Il Physically-based Rendering, o PBR, è un’insieme di tecniche che ha lo scopo di rappre-
sentare il più fedelmente possibile come la luce funziona nel mondo reale. A dipendenza
del risultato che si vuole ottenere, e se si lavora in real-time oppure no, diversi parametri e
soluzioni possono essere utilizzati. Bisogna comunque tenere a mente che è una tecnica di
shading basata sulla fisica, facente quindi uso di approssimazioni.
Per essere considerato "physically-based" un modello di illuminazione deve generalmente
rispettare questi 3 principi:
• Essere basato sul microfacet surface model
• Attenersi al principio di conservazione dell’energia
• Usare un BDRF "physically-based"
Dopo aver discusso con il docente si è deciso di utilizzare il PBR proposto da Disney e poi
implementato per il real-time da Epic Games per Unreal Engine 4, in quanto è il modello
generalmente più utilizzato e di cui si trova più documentazione (adottato, per esempio,
anche da Unity1 e da Frostbite2 ). Di conseguenza avremo a che fare con tre variabili:
albedo, metalness e roughness.
1
Physically Based Shading in Unity
2
Moving Frostbite to Physically Based Rendering 3.0
Physically-based Rendering for OpenGL10 Physically-based Rendering
3.1.1 BRDF
Il BRDF, o bidirectional reflective distribution function, è una funzione che prende in input
l’angolo di incidenza della luce ωi , l’angolo di uscita verso l’osservatore ωo , la normale della
superficie n e la roughness del materiale. Il BRDF, in base a questi parametri, considera
quanto ogni raggio di luce ωi contribuisce sul totale della luce in uscita su una determinata
superficie (idealmente su ogni microfacet, ma può variare in base all’implementazione). Per
esempio in una superficie completamente liscia tutti i raggi di luce che non hanno ωi = ωo
non contribuiscono alla luce in uscita e ritornano quindi 0.0, mentre l’unico raggio con gli
angoli equivalenti ritornerà 1.0 (contribuzione totale).
Per essere considerato fisico un BRDF deve attenersi al principio di conservazione del-
l’energia.
Avendo seguito quanto proposto da Epic Games e Disney, abbiamo scelto di utilizzare il
Cook-Torrance BRDF.
3.1.2 Equazione di rendering
Ora che abbiamo le basi teoriche necessarie, possiamo andare a descrivere l’equazione di
rendering (o reflectance equation) che andremo ad utilizzare.
Z
Lo (p, ωo ) = BRDF (p, ωi , ωo ) ∗ Li (p, ωi ) ∗ n ∗ ωi ∗ dωi
Ω
Nonostante l’apparente complessità, si può facilmente dissezionare ed analizzare:
• Lo rappresenta il flusso di luce in uscita per un punto p visto da un angolo ωo , quindi
il risultato dei nostri calcoli
R
• L’integrale Ω viene eseguito su un emisfero Ω centrato in un punto p e per ogni raggio
di luce incidente con angolo ωi su tale punto. Nella nostra implementazione, dal
momento che non teniamo conto della luce ambientale, l’integrale è sostituito da un
ciclo che itera su tutte le luci presenti nella scena.
• BRDF è, nel nostro caso, Cook-Torrance
• Li rappresenta la quantità di luce che colpisce il punto p con un angolo ωi
• n e ωi rappresentato rispettivamente la normale della superficie e l’angolo di incidenza
della luce che stiamo considerando
Ora andremo ad esaminare più nel dettaglio come funziona Cook-Torrance prima di passare
all’implementazione effettiva nello shader.
Physically-based Rendering for OpenGL11
3.2 Cook-Torrance BRDF
Nel modello di Cook-Torrance consideriamo sia la parte diffuse che specular:
BRDF = ref raction ∗ lambertianDif f use + ref lection ∗ cookT orrance
Dove refraction e reflection rappresentano rispettivamente il tasso di luce rifratta e quella
riflessa.
La Lambertian Diffuse è un fattore costante dato da:
albedo
lambertianDif f use =
π
Dove albedo rappresenta il colore del materiale. Si è deciso di seguire la scelta di Epic
Games invece di quella Disney3 .
La formula generale del BRDF di Cook-Torrance è la seguente:
D∗F ∗G
cookT orrance =
4 ∗ (ωo · n) ∗ (ωi · n)
• D è la Normal Distribution Function
• F è l’equazione di Fresnel
• G è la Geometry Function
Andremo ora ad esaminare più nel dettaglio il funzionamento di queste componenti del
BRDF.
3
"We evaluated Burley’s diffuse model but saw only minor differences compared to Lambertian diffuse, so
we couldn’t justify the extra cost.", Real Shading in Unreal Engine 4, pag. 2
Physically-based Rendering for OpenGL12 Physically-based Rendering
3.2.1 Normal Distribution
Attraverso la Normal Distribution Function possiamo approssimare statisticamente la per-
centuale di microfacet allineati all’halfway vector. In questo caso, basandoci su quanto
riportato da Disney e Epic Games4 abbiamo scelto l’approssimazione di GGX/Trowbridge-
Reitz5 :
α2
D=
π ∗ ((n · h)2 ∗ (α2 − 1) + 1)2
Ottenendo il seguente risultato:
Figura 3: Normal Distribution in funzione della roughness, valore crescente da sinistra
verso destra
Si può vedere come quanto detto nella sezione 2.2 trova riscontro nell’applicazione pratica:
più alto è il parametro di roughness, meno microfacet sono allineati all’halfway vector e
di conseguenza la riflessione risulta meno concentrata. Si può anche notare come col
progressivo allargarsi del punto di riflessione essa si scurisce: questo è dovuto al principio
di conservazione dell’energia.
4
"We found Disney’s choice [...] to be well worth the cost. The additional expense over using Blinn-Phong
is fairly small, and the distinct, natural appearance produced by the longer “tail” appealed to our artists.", Real
Shading in Unreal Engine 4, pag. 3
5
Nella formula qui riportata si è scelto di mantenere la notazione Disney dove α = roughness2
Physically-based Rendering for OpenGL13
3.2.2 Fresnel
L’equazione di Fresnel descrive il ratio di luce riflessa rispetto alla luce rifratta in base al-
l’angolo di osservazione. Sapendo quanta luce viene riflessa e applicando il principio di
conservazione dell’energia, possiamo facilmente dedurre la quantità di luce assorbita dal
materiale, questo ci torna utile per calcolare reflection e refraction del modello generale.
Tutti i materiali tecnicamente riflettono completamente la luce se guardati con angolo di
90 gradi.
Figura 4: Diverse intensità di Fresnel su sfere viste in controluce
Questo fenomeno è noto come Fresnel ed è descritto dall’omonima equazione. Dal momen-
to che l’equazione applicata all’ottica reale è molto complessa, il rendering physical-based
fa uso solitamente di una sua approssimazione chiamata Fresnel-Schlick :
F = F0 + (1 − F0 ) ∗ (1 − (n · v))5
F0 rappresenta la riflessione base di un materiale, che rappresenta il colore riflesso osser-
vandolo a 0 gradi (direttamente). Qui di seguito una tabella con alcuni esempi6 :
6
A questo indirizzo si può trovare un database con F0 per vari materiali: refractiveindex.info
Physically-based Rendering for OpenGL14 Physically-based Rendering
Material F0 (RGB)
Plastica/Vetro 0.21, 0.21, 0.21
Diamante 0.45, 0.45, 0.45
Ferro 0.77, 0.78, 0.78
Alluminio 0.96, 0.96, 0.97
Acqua 0.15, 0.15, 0.15
Tabella 1: F0 per vari materiali
Fonte: Physically-Based Shading Models in Film and Game Production
La riflessione base viene normalmente calcolata attraverso degli indici di rifrazione (IOR, in-
dices of refraction), metodo che purtroppo funziona solo per materiali dielettrici. Per ovviare
a questo inconveniente dobbiamo precalcolare F0 in modo accettabile e aggiustarlo grazie
al parametro di metalness.
Per fare questo definiamo un F0 accettabile in modo approssimato per la maggior parte dei
dielettrici, e lo interpoliamo con il colore fornito come parametro dal materiale usando il pa-
rametro di metalness come valore di interpolazione (questo procedimento è spiegato più nel
dettaglio nella sezione 4.3). Se il materiale non è metallico manteniamo la riflessione ap-
prossimata, viceversa possiamo usare senza problemi il colore del materiale, dal momento
che i metalli non hanno una componente diffuse.
Va puntualizzato un dettaglio: nella realtà, un materiale o è metallico o è dielettrico, non
ci sono vie di mezzo. Nella computer grafica, per poter rappresentare con più precisione
materiali particolari che sono in parte metallici (p.es. ruggine) si è deciso di manetere un pa-
rametro di "metallicità" variabile. Questo per rimarcare ancora una volta che questi modelli
non sono fisici ma basati sulla fisica.
Physically-based Rendering for OpenGL15
3.2.3 Geometry
Se si considera un materiale ruvido nella realtà si può notare come l’irregolarità della super-
ficie crei delle piccole ombre sulla stessa. Nella computer grafica, a livello macroscopico,
questo si può simulare con l’ambient occlusion, mentre a livello di microfacet si utilizza la
Geometry Function.
Questa funzione serve ad approssimare statisticamente quanti raggi di luce riflessa non rag-
giungono mai l’osservatore perché vengono bloccati da irregolarità nelle microfacet (p.es.
piccole cavità o picchi). Per fare questo prendiamo in considerazione la roughness di un
materiale: più alto è il valore, più raggi vengono ostacolati.
Anche in questo caso ci serviamo di un’approssimazione: in questo caso il modello Schlick
con un piccolo accorgimento per avvicinarci al modello di Smith come suggerito da Epic
Games7 :
(roughness + 1)2
k=
8
n·v
G1 =
(n · v) ∗ (1 − k) + k
n·l
G2 =
(n · l) ∗ (1 − k) + k
G = G1 ∗ G2
Per quanto riguarda il calcolo di k ho deciso di seguire il consiglio della Epic Games8 , ovvero
usare il modello di Schlick ma sostituendo
α
k=
2
e rimappando
roughness + 1 2
α=( )
2
come suggerito da Disney9 , ottenendo quindi il risultato indicato di
(roughness + 1)2
k=
8
7
"We evaluated more options for the specular geometric attenuation term than any other. In the end, we
chose to use the Schlick model, but with k = α2 , so as to better fit the Smith model for GGX", Real Shading in
Unreal Engine 4, pag. 3
8
"[...] as to better fit the Smith model for GGX", Real Shading in Unreal Engine 4, pag. 3
9
"We also chose to use Disney’s modification to reduce “hotness” by remapping roughness", Real Shading
in Unreal Engine 4, pag. 3
Physically-based Rendering for OpenGL16 Physically-based Rendering
Figura 5: Effetto della Geometry Function con roughness crescente: si può notare come
l’ombra si faccia più marcata e la distinzione meno nitida mentre la superficie si scurisce
leggermente
Physically-based Rendering for OpenGL17
Capitolo 4
Implementazione
4.1 Primi passi
Nelle prime fasi del progetto mi è stato richiesto di sperimentare senza considerare Overvi-
sion, in modo che al momento dell’integrazione effettiva ci fosse uno shader già funzionante
dal punto di vista del calcolo dell’illuminazione.
Ho quindi scelto di riadattare il motore grafico sviluppato nei corsi di Grafica e Realtà Vir-
tuale, rimuovendo le funzioni non necessarie e adattando i parametri a quelli che sarebbero
serviti per il PBR. In questo modo si è venuto a creare un motore ad hoc per il test dello
shader.
In questa fase di progetto l’ostacolo più grande è stato riuscire a identificare i vettori di cui
necessitavo. Avendo a disposizione diverse pubblicazioni, alcune teoriche ed altre pratiche,
mi sono dovuto confrontare col fatto che molte di esse davano per scontato di avere i dati
strutturati come nei loro motori grafici. Ho dovuto quindi trovare le dovute corrispondenze e
calcolare i vettori mancanti per poter ottenere dei risultati corretti.
Un altro dettaglio importante è stata la scelta del programma di grafica per costruire la
scena: durante il semestre, nel progetto di gruppo dove avevamo utilizzato il motore, era
stato scelto Blender. Non ho quindi dovuto confrontarmi con eventuali problemi legati al-
l’importare scene e materiali da 3D Studio MAX come è avvenuto in seguito al passaggio a
Overvision.
4.1.1 Risultati intermedi
Alla fine del lavoro sul motore grafico personale, lo shader produceva i seguenti risultati:
Physically-based Rendering for OpenGL18 Implementazione
Figura 6: Serie di sfere per testare le caratteristiche: sull’asse x c’è un valore crescente di
roughness, mentre sull’asse y un valore crescente di metalness
Physically-based Rendering for OpenGL19
Figura 7: Vista ravvicinata delle sfere metalliche
Physically-based Rendering for OpenGL20 Implementazione
Figura 8: Vista ravvicinata delle sfere dielettriche
Physically-based Rendering for OpenGL21
Figura 9: Sfere viste in controluce: notare Fresnel ben visibile su quelle centrali
Physically-based Rendering for OpenGL22 Implementazione
E aggiungendo i diversi livelli di map (roughness, metalness, albedo):
Figura 10: La sfera a sinistra è mappata come ferro arrugginito, quella a destra come
marmo liscio
A questo punto, discutendo con il docente, si sono ritenuti i risultati soddisfacenti e quindi lo
shader pronto all’integrazione con Overvision.
Physically-based Rendering for OpenGL23
4.2 Passaggio a Overvision
Nel passaggio a Overvision, il motore grafico proposto dal docente, ho dovuto tenere conto
principalmente di tre cose:
• In Overvision non ci sono diversi shader intercambiabili similmente al mio motore
grafico, ma invece un unico grande shader che viene costruito in runtime a dipendenza
delle impostazioni dell’utente. Il PBR sarebbe andato a coesistere con la parte di
shader dedicata all’illuminazione (quindi al momento a Phong). Ho dovuto quindi
convertirlo da shader intero a funzione e adattarmi ai parametri che venivano già
passati a Phong.
• In Overvision i materiali vengono processati come strutture e mandati direttamen-
te alla GPU, quindi aggiungere i parametri di cui avevo bisogno avrebbe significa-
to riaggiustare la grandezza della struttura in modo che la memoria non risultasse
disallineata.
• Una delle richieste del progetto era quella di poter importare una scena da 3D Studio
MAX con parametri compresi, avrei quindi dovuto adattare i plugin di import/export dei
materiali.
Le decisioni principali sono state naturalmente prese discutendo con il docente, cercando
di decidere quale sarebbe stata la direzione dello sviluppo di Overvision e come strutturare
il prodotto finale una volta completata l’integrazione. Questo ha fatto sorgere diversi dubbi.
4.2.1 Decisioni finali
Al termine delle discussioni, il docente ha deciso di deprecare Phong nella nuova versione
di Overvision. Questi significa mantenere unicamente lo shader del PBR e eliminare dalla
classe material tutti i vecchi parametri. Per mantenere la compatibilità con le scene e i pro-
getti già creati, si è deciso di integrare nel plugin un sistema di conversione dei materiali da
Phong a Physical Material.
Il docente ha inoltre deciso di implementare una compatibilità con le principali maps del
PBR, ovvero Roughness, Metalness e Albedo. In questo modo l’utente può sia usare i
parametri singoli o caricare textures di sua scelta in 3D Studio MAX. Questo pone delle
limitazioni che verranno affrontate nella sezione 4.3.
Physically-based Rendering for OpenGL24 Implementazione
4.2.2 Modifiche alla classe Material
Inizialmente l’idea era di far coesistere Phong e PBR, quindi anche i loro parametri, ma
come accennato precedentemente Phong è stato deprecato, e con lui tutti i parametri ne-
cessari al suo funzionamento.
Dal momento che per il PBR sono necessari solo tre parametri principali, ovvero Rough-
ness, Metalness e Albedo, la struttura del materiale è cambiata da così:
s t r u c t M a t S t r u c t / / Optimized order for std140 layout
{
vec3 emission ;
f l o a t transparency ;
vec3 ambient ;
float shininess ;
vec3 d i f f u s e ;
u i n t alpha ;
vec3 s p e c u l a r ;
f l o a t roughness ;
vec3 albedo ;
f l o a t metalness ;
vec4 _padding ;
sampler2D t e x t u r e H a n d l e 0 ;
sampler2D t e x t u r e H a n d l e 1 ;
sampler2D t e x t u r e H a n d l e 2 ;
sampler2D t e x t u r e H a n d l e 3 ;
};
Physically-based Rendering for OpenGL25
a così nella sua versione finale:
s t r u c t M a t S t r u c t / / Optimized order for std140 layout
{
vec3 emission ;
f l o a t transparency ;
vec3 albedo ;
u i n t alpha ;
f l o a t roughness ;
f l o a t metalness ;
vec2 _padding ;
sampler2D t e x t u r e H a n d l e 0 ; / / Albedo/diffuse
sampler2D t e x t u r e H a n d l e 1 ; / / Normal map
sampler2D t e x t u r e H a n d l e 2 ; / / Height map
sampler2D t e x t u r e H a n d l e 3 ; / / Roughness map
sampler2D t e x t u r e H a n d l e 4 ; / / Metalness map
sampler2D t e x t u r e H a n d l e 5 ; / / Padding/not used
};
Da notare le texture aggiuntive, utilizzate per la precedentemente citata compatibilità con le
map del PBR.
Physically-based Rendering for OpenGL26 Implementazione 4.2.3 Modifiche al Plugin I cambiamenti apportati al plugin sono sicuramente stati la parte di lavoro maggiore fatta sul codice di Overvision. Una volta fatto funzionare il motore e lo shader inserendo manual- mente i dati e importando unicamente le mesh da 3D Studio MAX, il passo successivo è stato trovare il modo di leggere i parametri utili al PBR. I file .OVO, ovvero il formato utilizzato da Overvision per importare scene, sono scritti a "chunk" di lunghezza definita, questo significa che le mie modifiche dovevano essere appor- tate in modo simmetrico sia all’exporter (da 3D Studio MAX a file .OVO) che all’importer (da file .OVO a scena in Overvision), facendo attenzione a registrare correttamente cambiamenti nelle lunghezze dei chunk relativi ai materiali. Physically-based Rendering for OpenGL
27
4.2.3.1 Over3DS
Over3DS è il plugin che si occupa di esportare una scena di 3D Studio MAX in un file .OVO.
Il mio compito è stato quello di agire nella classe over3ds_material per aggiungere la lettura
dei parametri utili al PBR nel caso l’utente avesse selezionato un materiale fisico.
Per leggere i parametri da un materiale Phong, nel codice originale si utilizzava IGame-
Material, un wrapper alla classe originale presente nelle sdk di 3D Studio MAX che per-
metteva di accedere tramite metodo alle caratteristiche del materiale. Purtroppo le API di
IGameMaterial non permettono di accedere a tutte le proprietà, ma solo a quelle utili per
Phong:
Figura 11: Snippet delle API di IGameMaterial, si possono notare i getter dei tipici
parametri per Phong
Fonte: IGameMaterial Class Reference
Ho dovuto quindi avvalermi di IPropertyContainer, un container ottenibile da qualunque IGa-
meMaterial che fornisce un’estensione delle API, in modo che potessi trovare le proprietà
dei materiali fisici attraverso una query con il nome del parametro:
Physically-based Rendering for OpenGL28 Implementazione
i f ( strcmp ( matClass , " P h y s i c a l M a t e r i a l " ) == 0 )
{
I P r o p e r t y C o n t a i n e r ∗ pbr = mat−>G e t I P r o p e r t y C o n t a i n e r ( ) ;
pbr −>QueryProperty ( _T ( " b a s e _ c o l o r " ) )
−>GetPropertyValue ( _albedo ) ;
albedo = P o i n t 3 ( _albedo ) ;
pbr −>QueryProperty ( _T ( " roughness " ) )
−>GetPropertyValue ( roughness ) ;
pbr −>QueryProperty ( _T ( " metalness " ) )
−>GetPropertyValue ( metalness ) ;
Nota: albedo viene castato a Point3 in quanto è originariamento un Point4.
A questo punto mi rimaneva solo il compito di aggiornare la lunghezza del chunk con i
nuovi parametri estratti.
unsigned i n t chunkId = ( unsigned i n t ) OvObject : : Type : : MATERIAL ;
unsigned i n t chunkSize = / / Material size
( unsigned i n t ) s t r l e n ( name)+1 +
s i z e o f ( OvVector3 ) +
s i z e o f ( OvVector3 ) +
sizeof ( f l o a t ) ∗ 3 +
/ / Textures:
( unsigned i n t ) s t r l e n ( albedoTex )+1 +
( unsigned i n t ) s t r l e n ( normalTex )+1 +
( unsigned i n t ) s t r l e n ( h e i g h t T e x )+1 +
( unsigned i n t ) s t r l e n ( roughnessTex )+1 +
( unsigned i n t ) s t r l e n ( metalnessTex ) + 1 ;
Il supporto per le nuove texture è stato aggiunto dal mio docente una volta presa la decisione
di voler supportare tutti i tipi di map (precedentemente, Height e Normal Map a parte, solo
la Diffuse Map era supportata).
Physically-based Rendering for OpenGL29 4.2.3.2 OVOreader OVOreader è la parte di codice che si occupa di decifrare il file .OVO ed estrarre i parametri da associare a luci, mesh, materiali, etc. in Overvision. Come accennato prima, ho dovuto eseguire in questa parti di codice modifiche simmetriche a quelle effettuate in Over3DS, in modo che i chunk venissero letti nella loro interezza in modo da rimanere allineati con le lunghezze. Qui di seguito la parte di codice dove leggo i dati da file: / / Albedo: memcpy(& albedo , data + p o s i t i o n , s i z e o f ( OvVector3 ) ) ; c o u t
30 Implementazione
4.2.3.3 Conversione materiali
Una volta presa la decisione di deprecare Phong è sorto il problema della retrocompatibili-
tà, dal momento che scene e progetti creati in passato non contenevano materiali fisici, e
riconvertire tutto manualmente sarebbe stato troppo dispendioso. Ho quindi deciso, insieme
al mio docente, di convertire eventuali materiali Phong in fisici nel plugin, ricercando metodi
di conversione possibili.
Cercando online sono emerse due discussioni interessanti anche se relativamente incon-
cludenti1 , dal momento che diversi utenti proponevao loro varianti con diverse opinioni. Mi
sono quindi ispirato a loro provando una formula per la roughness e lasciando la metalness
a 0, in quanto come discusso con il docente Phong si può considerare come un sottoinsie-
me di PBR che genera solo materiali plastici.
La formula è qui di seguito:
/ / Converted to PBR:
metalness = 0 . 0 f ;
roughness = s t d : : max ( pow( 1 − g l o s s i n e s s L v l / 1 2 8 . 0 f , 2 ) , 0.01 f ) ;
Un paio di note:
• Manteniamo 0.01 come valore minimo nominale perché non ha senso per una rough-
ness essere 0, dal momento che significherebbe che non esistono microfacet allinea-
te con l’halfway vector, andando quindi a cozzare con la convinzione intuitiva di avere
una liscezza perfetta
• Il livello di glossiness viene diviso per 128 per portarlo in un range [0-1]
I risultati ottenuti sono i seguenti:
1
[PBR extension] Specify formula to calculate BRDF inputs from material properties #810 e anche glTF 2.0
#67
Physically-based Rendering for OpenGL31
Figura 12: Sfere renderizzate con il modello di Phong (demoBullet)
Figura 13: Sfere renderizzate con PBR (demoBullet)
Physically-based Rendering for OpenGL32 Implementazione
Figura 14: Dettaglio di un punto caldo di riflessione con Phong (demoBullet)
Figura 15: Dettaglio di un punto caldo di riflessione con PBR (demoBullet)
Physically-based Rendering for OpenGL33
Figura 16: Dettaglio testa di leone con Phong (demo)
Figura 17: Dettaglio testa di leone con PBR (demo)
Physically-based Rendering for OpenGL34 Implementazione
Figura 18: Dettaglio statua di marmo con Phong (demo)
Figura 19: Dettaglio statua di marmo con PBR (demo)
Physically-based Rendering for OpenGL35
Il risultato, seppur con margine di miglioramento, è stato ritenuto accettabile visto il tempo a
disposizione da dedicare alla problematica.
Physically-based Rendering for OpenGL36 Implementazione
4.3 Shader
Andremo ora ad esaminare il codice dello shader, commentando le scelte fatte durante lo
sviluppo.
vec3 albedo = m a t e r i a l . albedo ∗
pow ( t e x t u r e ( m a t e r i a l . t e x t u r e H a n d l e 0 , texCoord ) . rgb ,
vec3 ( 2 . 2 ) ) ;
f l o a t roughness = m a t e r i a l . roughness ∗
t e x t u r e ( m a t e r i a l . t e x t u r e H a n d l e 3 , texCoord ) . r ;
f l o a t metalness = m a t e r i a l . metalness ∗
t e x t u r e ( m a t e r i a l . t e x t u r e H a n d l e 4 , texCoord ) . r ;
La mia proposta iniziale per avere un supporto alle map senza inserire if-else (le performan-
ce della GPU ne avrebbero risentito) è stata di generare sempre delle texture 1x1 anche in
mancanza di map selezionate dall’utente. Il colore delle texture 1x1 sarebbe stato deciso in
base al parametro impostato dall’utente e letto da file, in modo da avere un colore uniforme
uguale a quello selezionato in 3D Studio Max nel caso di un lookup delle texture.
Dopo una discussione con il docente, tuttavia, abbiamo optato per questa variante: moltipli-
care il parametro del materiale per il valore contenuto nella texture. In questo modo anche
creando texture 1x1 bianche (placeholder di default già presente in Overvision) il parametro
sarebbe stato moltiplicato per 1.0 (o un vettore[1.0, 1.0, 1.0] nel caso dell’albedo) mante-
nendolo invariato. Impostando delle map invece l’utente può controllarne l’intensità modifi-
cando i parametri del materiale. Il lato negativo, purtroppo, è che il risultato visualizzato in
3D Studio MAX non sarà uguale alla scena renderizzata da Overvision.
Physically-based Rendering for OpenGL37
/ / Output color:
vec3 c o l o r = vec3 ( 0 . 0 f ) ;
/ / View:
vec3 view = n o r m a l i z e ( V − P ) ;
/ / Light Position:
vec3 posMinusP = L . xyz − P ;
vec3 l i g h t D i r = n o r m a l i z e ( posMinusP ) ;
f l o a t l i g h t D i s t = l e n g t h ( posMinusP ) ;
f l o a t nDotL = d o t (N, l i g h t D i r ) ;
/ / Outgoing radiance:
vec3 Lo = vec3 ( 0 . 0 ) ;
/ / Halfway vector:
vec3 h a l f V e c t o r = n o r m a l i z e ( l i g h t D i r + view ) ;
Qui abbiamo delle semplici inizializzazioni dei valori che ci serviranno nel BRDF, come per
esempio l’halfway vector. Calcoliamo inoltre anticipatamente il colore "ambient" del mate-
riale, ovvero quello che ha in assenza di luce. Questo perché nel caso di una spotlight
dobbiamo essere in grado di fornire un colore anche alle parti non illuminate.
Inizializziamo inoltre quello che sarà il colore in output.
/ / Check roughness:
i f ( roughness == 0 . 0 )
roughness = 0 . 0 1 ;
Qui controlliamo che la roughness non sia stata impostata a 0. Una parte del controllo è nel
plugin, qui è casomai l’utente decida di cambiarla manualmente o stia usando delle mappe
non corrette.
Physically-based Rendering for OpenGL38 Implementazione
/ / Spot light?
f l o a t spotAttenuation = 1.0 f ;
i f ( l i g h t . spotExponent > 0 . 0 f )
{
f l o a t s p o t E f f e c t = dot ( l i g h t . d i r e c t i o n , −l i g h t D i r ) ;
i f ( spotEffect < l i g h t . cutoff )
nDotL = − 1.0 f ;
s p o t A t t e n u a t i o n = pow ( s p o t E f f e c t , l i g h t . spotExponent ) ;
}
/ / Compute only if necessary:
i f ( nDotL > 0 . 0 f )
{
A questo punto controlliamo se stiamo utilizzando una spotlight, perché in quel caso ci sarà
una parte della scena su cui non sarà necessario eseguire il BRDF.
/ / Radiance:
float attenuation = spotAttenuation ∗
max ( 0 . 0 f , 1 . 0 f − l i g h t D i s t / l i g h t . r a d i u s ) ;
vec3 r a d i a n c e = l i g h t . c o l o r ∗ a t t e n u a t i o n ;
Calcoliamo la Radiance, ovvero la quantità di luce che colpisce il nostro fragment. Viene
applicata la dovuta attenuazione.
Physically-based Rendering for OpenGL39
/ / Fresnel:
vec3 F0 = vec3 ( 0 . 0 4 ) ;
F0 = mix ( F0 , albedo , metalness ) ;
f l o a t hDotV = max ( d o t ( h a l f V e c t o r , view ) , 0 . 0 ) ;
vec3 F = F0 + ( 1 . 0 − F0 ) ∗ pow ( 1 . 0 − hDotV , 5 . 0 ) ;
Calcoliamo Fresnel come illustrato nella sezione 3.2.2. L’interpolazione con la funzione mix
funziona nel seguente modo:
F 0 ∗ (1 − metalness) + albedo ∗ metalness
Come si può notare, quando la metalness è uguale a 0 viene usato F0 standard per i die-
lettrici, mentre quando è uguale a 1 viene utilizzato l’albedo. Dal momento che i metalli non
hanno diffuse e hanno un indice di riflessione tendenzialmente alto possiamo usare il colore
del materiale come F0. Questo darà al riflesso emesso dal metallo una lieve tinta uguale
all’albedo. Come si può vedere nella Tabella 1, è possibile aggiustare il valore di albedo
per rispecchiare il loro valore di F0 e quindi creare dei metalli più vicini alla loro controparte
reale.
/ / Normal Distribution Function:
f l o a t a = roughness ∗ roughness ;
f l o a t a2 = a ∗ a ;
f l o a t nDotH = max ( d o t (N, h a l f V e c t o r ) , 0 . 0 ) ;
f l o a t nDotH2 = nDotH ∗ nDotH ;
f l o a t nom = a2 ;
f l o a t denom = ( nDotH2 ∗ ( a2 − 1 . 0 ) + 1 . 0 ) ;
denom = PI ∗ denom ∗ denom ;
f l o a t D = nom / denom ;
La Normal Distribution è stata discussa nella sezione 3.2.1 e non c’è molto da aggiungere.
Si può notare anche qui quanto accennato in precedenza: con una roughness uguale a 0 ci
troveremmo uno 0 al nominatore e quindi uno 0 come risultato, che in termini grafici significa
che non vedremo alcun punto caldo della riflessione.
Physically-based Rendering for OpenGL40 Implementazione / / Geometry Function: f l o a t k = pow ( ( roughness + 1 ) , 2 ) / 8 ; f l o a t nDotV = max ( d o t (N, view ) , 0 . 0 ) ; f l o a t G1 = nDotV / ( nDotV ∗ ( 1 . 0 − k ) + k ) ; f l o a t G2 = nDotL / ( nDotL ∗ ( 1 . 0 − k ) + k ) ; f l o a t G = G1∗G2 ; Semplice applicazione della Geometry Function discussa precedentemente. / / Cook-Torrance BRDF: vec3 s p e c u l a r = (D ∗ F ∗ G) / ( 4 ∗ nDotL ∗ nDotV + 0 . 0 0 1 ) ; Possiamo a questo punto assemblare il BRDF con tutte le variabili calcolate in precedenza. / / Energy conservation: vec3 r e f l e c t i o n = F ; vec3 r e f r a c t i o n = vec3 ( 1 . 0 ) − r e f l e c t i o n ; r e f r a c t i o n ∗= 1 . 0 − metalness ; Grazie a Fresnel possiamo calcolare il tasso di luce rifratta dal materiale, che è uguale a 0 se il materiale è metallico. Physically-based Rendering for OpenGL
41
/ / Outgoing radiance sum:
Lo += ( r e f r a c t i o n ∗ ( albedo / PI ) + s p e c u l a r ) ∗ r a d i a n c e ∗ nDotL ;
Infine usiamo l’equazione di rendering per calcolare la luce riflessa. Si può notare come nel
caso di un metallo, con la rifrazione uguale a 0, la Lambertian Diffuse venga ignorata.
/ / Add shadow:
c o l o r += shadow ∗ Lo ;
Aggiungiamo eventuali ombre presenti nella scena.
}
/ / Compute color and apply gamma correction:
color += m a t e r i a l . emission +
g l o b a l . ambient ∗ albedo ∗ ambientOcclusion ;
color = pow ( c o l o r , vec3 ( 1 . 0 / 2 . 2 ) ) ;
/ / Done:
return c o l o r ;
Aggiungiamo al colore calcolato un’eventuale emissione de materiale, la componente am-
bient e l’ambient occlusion.
Physically-based Rendering for OpenGL42 Implementazione Physically-based Rendering for OpenGL
43
Capitolo 5
Conclusione
Dopo aver ricercato e analizzato i PBR più comuni e documentati e aver implementato un
primo shader in un motore grafico personale, sono riuscito ad adattarlo ad Overvision e ad
apportare le modifiche necessarie per l’integrazione completa. Sono inoltre riuscito ad ag-
giornare i plugin di import/export per far fronte ai nuovi parametri richiesti. Infine ho creato
una piccola demo per dimostrare il funzionamento del PBR con vari materiali non ottenibili
con Phong.
Per la realizzazione di questo progetto è stato di particolare aiuto "Learn OpenGL", che
ha saputo darmi una solida base teorica e una struttura iniziale del codice. La documenta-
zione di Epic Games, con i suoi rimandi a quella Disney, è stata una risorsa fondamentale
per comprendere meglio le formule e soprattutto la scelta di determinati parametri, frutto di
loro analisi e sperimentazioni.
Il progetto può dunque dirsi concluso con successo.
Physically-based Rendering for OpenGL44 Conclusione
5.1 Risultati ottenuti
Figura 20: Scena generale della demo
Physically-based Rendering for OpenGL45
Figura 21: Dettaglio statua
Physically-based Rendering for OpenGL46 Conclusione
Figura 22: Dettaglio pistola
Physically-based Rendering for OpenGL47
Figura 23: Dettaglio sfere di vari materiali
Physically-based Rendering for OpenGL48 Conclusione
Figura 24: Dettaglio spada. Notare il riflesso del metallo tipico del PBR.
Physically-based Rendering for OpenGL49
Figura 25: Dettaglio teiere di materiale metallico (sopra) e dielettrico (sotto) con roughness
crescente
Physically-based Rendering for OpenGL50 Conclusione
5.2 Miglioramenti futuri
Avendo costruito delle solide fondamenta con il PBR e le modifiche al plugin per l’importa-
zione dei materiali sono ora disponibili diverse possibili migliorie. Nessuna è strettamente
necessaria al corretto funzionamento del motore grafico: servono unicamente a rendere più
piacevoli e fotorealistici i dettagli delle scene.
5.2.1 Subsurface Scattering
Come accennato nella sezione 2.1, il subsurface scattering prende in considerazione la luce
rifratta in uscita da un materiale a una distanza d dal punto di incidenza. Viene normalmente
utilizzata per renderizzare in modo più realistico materiali come cera, giada o la pelle umana:
considerando la profondità e il colore del materiale si può ricavare quanto la luce uscente
dall’altro lato venga influenzata.
Figura 26: Esempi di Subsurface Scattering a diverse profondità
Fonte: Subsurface Scattering Material for Characters
Anche in questo caso esistono diversi algoritmi di approssimazione, anche se i più con-
venienti dal punto di vista computazionali non offrono risultati particolarmente buoni. Un
approccio possibile è quello che comporta il depth peeling per considerare lo spessore
delle mesh.
Physically-based Rendering for OpenGL51
5.2.2 Image-based Lighting
Per l’image-based lighting (o IBL) serve rispolverare l’integrale che avevamo lasciato da
parte senza troppi pensieri nella sezione 3.1.2, questo modello di illuminazione infatti si
serve della luce proveniente da tutta la scena per renderizzarla. Per riuscire in questa
impresa senza appellarci al ray tracing si costruisce una cubemap simile alla skybox che
si sta utilizzando per la scena, dove in ogni pixel sono contenute le informazioni sul colore
della luce proveniente da quel punto. A dipendenza di quanto si voglia essere precisi nel
rendering, si può aumentare o diminuire gli step da far eseguire all’integrale (che viene
comunque rappresentato da un ciclo for) che deve iterare su tutta la suddetta cubemap.
Figura 27: L’IBL consente di avere un riflesso della scena circostante, rendendo la
percezione dei materiali più realistica
Fonte: Image Based Lighting, Asger Hoedt
Va comunque considerato che questa è una soluzione limitata alle riflessioni di skybox, non
è comparabile alla versatilità di un ray tracer,
Physically-based Rendering for OpenGL52 Conclusione Physically-based Rendering for OpenGL
53
Allegati
1. CD-ROM - Documenti di progetto
Physically-based Rendering for OpenGL54 Conclusione Physically-based Rendering for OpenGL
55
Bibliografia
[1] de Vries, Joey, "Learn OpenGL - An offline transcript of learnopengl.com", Third printing,
June 2017
[2] Karis, Brian, Epic Games, "Real Shading in Unreal Engine 4"
[3] Burley, Brent, Walt Disney Animation Studios, "Physically Based Shading at Disney"
[4] Substance Academy, "The PBR Guide by Allegorithmic", Updated 05.15.2018, Revision
26
[5] Pharr, Matt, "GPU Gems 2: Programming Techniques for High-Performance Graphics
and General-Purpose Computation"
[6] Schlick, Christophe, “An Inexpensive BRDF Model for Physically-based Rendering”,
[7] Introduction to "Physically Based Shading in Theory and Practice" (Video)
[8] Physically Based Shading in Theory and Practice (Video)
Physically-based Rendering for OpenGLPuoi anche leggere
