Physically-based Rendering for OpenGL - SUPSI Tesi · 2018. 12. 18. · 1Physically Based Shading...

Physically-based Rendering for OpenGL

Studente/i

Brian Dalle Pezze

Relatore

Achille Peternier

Correlatore

—

Committente

SUPSI

Corso di laurea

Ingegneria Informatica

Modulo

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


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


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


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


v

Elenco delle tabelle

1 F0 per vari materiali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


vi ELENCO DELLE TABELLE


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.


2 ELENCO DELLE TABELLE


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 attenzioneal 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 accertandosiche tutte le pipeline (rendering diretto e deferred) siano funzionanti

• Estendere il plugin di export/import del motore grafico per i modelli 3D in modo chesupporti tutte le informazioni relative al PBR


4 Contesto del Progetto

• Fornire una dimostrazione che mostri chiaramente i vantaggi del PBR rispetto almodello 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


5

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


https://renderwonk.com/publications/s2010-shading-course/hoffman/s2010_physically_based_shading_hoffman_a_notes.pdf

6 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.


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:

h =l + v

‖l + v‖

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.


https://learnopengl.com/PBR/Theory

8 Teorie fondamentali


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.

1Physically Based Shading in Unity2Moving Frostbite to Physically Based Rendering 3.0


https://aras-p.info/texts/files/201403-GDC_UnityPhysicallyBasedShading_notes.pdfhttps://seblagarde.files.wordpress.com/2015/07/course_notes_moving_frostbite_to_pbr_v32.pdf

10 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 = ωonon 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.

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, quindiil risultato dei nostri calcoli

• 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 incidenzadella luce che stiamo considerando

Ora andremo ad esaminare più nel dettaglio come funziona Cook-Torrance prima di passare

all’implementazione effettiva nello shader.


11

3.2 Cook-Torrance BRDF

Nel modello di Cook-Torrance consideriamo sia la parte diffuse che specular:

BRDF = refraction ∗ lambertianDiffuse+ reflection ∗ cookTorrance

Dove refraction e reflection rappresentano rispettivamente il tasso di luce rifratta e quella

riflessa.

La Lambertian Diffuse è un fattore costante dato da:

lambertianDiffuse =albedo

π

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:

cookTorrance =D ∗ F ∗G

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, sowe couldn’t justify the extra cost.", Real Shading in Unreal Engine 4, pag. 2



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:

D =α2

π ∗ ((n · h)2 ∗ (α2 − 1) + 1)2

Ottenendo il seguente risultato:

Figura 3: Normal Distribution in funzione della roughness, valore crescente da sinistraverso 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-Phongis fairly small, and the distinct, natural appearance produced by the longer “tail” appealed to our artists.", RealShading in Unreal Engine 4, pag. 3

5Nella formula qui riportata si è scelto di mantenere la notazione Disney dove α = roughness2


13

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:

6A questo indirizzo si può trovare un database con F0 per vari materiali: refractiveindex.info


https://refractiveindex.info/


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.


https://renderwonk.com/publications/s2010-shading-course/hoffman/s2010_physically_based_shading_hoffman_a_notes.pdf

15

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:

k =(roughness+ 1)2

8

G1 =n · v

(n · v) ∗ (1− k) + k

G2 =n · l

(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

k =(roughness+ 1)2

8

7"We evaluated more options for the specular geometric attenuation term than any other. In the end, wechose 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. 38"[...] as to better fit the Smith model for GGX", Real Shading in Unreal Engine 4, pag. 39"We also chose to use Disney’s modification to reduce “hotness” by remapping roughness", Real Shading

in Unreal Engine 4, pag. 3



Figura 5: Effetto della Geometry Function con roughness crescente: si può notare comel’ombra si faccia più marcata e la distinzione meno nitida mentre la superficie si scurisce

leggermente


17

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:


18 Implementazione

Figura 6: Serie di sfere per testare le caratteristiche: sull’asse x c’è un valore crescente diroughness, mentre sull’asse y un valore crescente di metalness


19

Figura 7: Vista ravvicinata delle sfere metalliche


20 Implementazione

Figura 8: Vista ravvicinata delle sfere dielettriche


21

Figura 9: Sfere viste in controluce: notare Fresnel ben visibile su quelle centrali


22 Implementazione

E aggiungendo i diversi livelli di map (roughness, metalness, albedo):

Figura 10: La sfera a sinistra è mappata come ferro arrugginito, quella a destra comemarmo liscio

A questo punto, discutendo con il docente, si sono ritenuti i risultati soddisfacenti e quindi lo

shader pronto all’integrazione con Overvision.


23

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 motoregrafico, 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 StudioMAX 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.


24 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ì:

struct MatStruct / / Optimized order for std140 layout

{

vec3 emission ;

f l o a t t ransparency ;

vec3 ambient ;

f l o a t sh in iness ;

vec3 d i f f u s e ;

u i n t alpha ;

vec3 specular ;

f l o a t roughness ;

vec3 albedo ;

f l o a t metalness ;

vec4 _padding ;

sampler2D textureHandle0 ;




} ;


25

a così nella sua versione finale:

struct MatStruct / / Optimized order for std140 layout

{

vec3 emission ;

f l o a t t ransparency ;

vec3 albedo ;

u i n t alpha ;

f l o a t roughness ;

f l o a t metalness ;

vec2 _padding ;

sampler2D textureHandle0 ; / / Albedo/diffuse

sampler2D textureHandle1 ; / / Normal map

sampler2D textureHandle2 ; / / Height map

sampler2D textureHandle3 ; / / Roughness map

sampler2D textureHandle4 ; / / Metalness map

sampler2D textureHandle5 ; / / Padding/not used

} ;

Da notare le texture aggiuntive, utilizzate per la precedentemente citata compatibilità con le

map del PBR.


26 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.


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 tipiciparametri 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:


https://help.autodesk.com/view/3DSMAX/2018/ENU/?guid=__cpp_ref_class_i_game_material_html

28 Implementazione

i f ( strcmp ( matClass , " Phys ica l Ma te r i a l " ) == 0)

{

IP roper tyCon ta ine r ∗pbr = mat−>Get IProper tyConta iner ( ) ;pbr−>QueryProperty ( _T ( " base_color " ) )−>GetPropertyValue ( _albedo ) ;albedo = Point3 ( _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 +

sizeof ( OvVector3 ) +

sizeof ( 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 ( heightTex )+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).


29

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 + pos i t i on , sizeof ( OvVector3 ) ) ;

cout

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 = std : : max(pow(1 − g loss inessLv l /128.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


https://github.com/KhronosGroup/glTF/issues/810https://github.com/AnalyticalGraphicsInc/obj2gltf/pull/67https://github.com/AnalyticalGraphicsInc/obj2gltf/pull/67

31

Figura 12: Sfere renderizzate con il modello di Phong (demoBullet)

Figura 13: Sfere renderizzate con PBR (demoBullet)


32 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)


33

Figura 16: Dettaglio testa di leone con Phong (demo)

Figura 17: Dettaglio testa di leone con PBR (demo)


34 Implementazione

Figura 18: Dettaglio statua di marmo con Phong (demo)

Figura 19: Dettaglio statua di marmo con PBR (demo)


35

Il risultato, seppur con margine di miglioramento, è stato ritenuto accettabile visto il tempo a

disposizione da dedicare alla problematica.


36 Implementazione

4.3 Shader

Andremo ora ad esaminare il codice dello shader, commentando le scelte fatte durante lo

sviluppo.

vec3 albedo = ma te r i a l . albedo ∗pow( t e x t u r e ( ma te r i a l . textureHandle0 , texCoord ) . rgb ,

vec3 ( 2 . 2 ) ) ;

f l o a t roughness = ma te r i a l . roughness ∗t e x t u r e ( ma te r i a l . textureHandle3 , texCoord ) . r ;

f l o a t metalness = ma te r i a l . metalness ∗t e x t u r e ( ma te r i a l . textureHandle4 , 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.


37

/ / Output color:

vec3 co lo r = vec3 (0 .0 f ) ;

/ / View:

vec3 view = normal ize (V − P ) ;

/ / Light Position:

vec3 posMinusP = L . xyz − P;vec3 l i g h t D i r = normal ize ( posMinusP ) ;

f l o a t l i g h t D i s t = leng th ( posMinusP ) ;

f l o a t nDotL = dot (N, l i g h t D i r ) ;

/ / Outgoing radiance:

vec3 Lo = vec3 ( 0 . 0 ) ;

/ / Halfway vector:

vec3 ha l fVec to r = normal ize ( 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 .01 ;

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.


38 Implementazione

/ / Spot light?

f l o a t spo tA t tenua t ion = 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 ( s p o t E f f e c t < l i g h t . c u t o f f )

nDotL = −1.0 f ;spo tA t tenua t ion = pow( spo tE f fec 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:

f l o a t a t t enua t i on = spo tA t tenua t ion ∗max(0 .0 f , 1.0 f − l i g h t D i s t / l i g h t . rad ius ) ;

vec3 radiance = l i g h t . co l o r ∗ a t t enua t i on ;

Calcoliamo la Radiance, ovvero la quantità di luce che colpisce il nostro fragment. Viene

applicata la dovuta attenuazione.


39

/ / Fresnel:

vec3 F0 = vec3 ( 0 . 0 4 ) ;

F0 = mix ( F0 , albedo , metalness ) ;

f l o a t hDotV = max( dot ( ha l fVec to 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:

F0 ∗ (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( dot (N, ha l fVec to 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.


40 Implementazione

/ / Geometry Function:

f l o a t k = pow ( ( roughness + 1) , 2) / 8 ;

f l o a t nDotV = max( dot (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 specular = (D ∗ F ∗ G) / (4 ∗ nDotL ∗ nDotV + 0 .001 ) ;

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.


41

/ / Outgoing radiance sum:

Lo += ( r e f r a c t i o n ∗ ( albedo / PI ) + specular ) ∗ radiance ∗ 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:

co lo r += shadow ∗ Lo ;

Aggiungiamo eventuali ombre presenti nella scena.

}

/ / Compute color and apply gamma correction:

co lo r += ma te r i a l . emission +

g loba l . ambient ∗ albedo ∗ ambientOcclusion ;co l o r = pow( co lor , vec3 (1 .0 / 2 . 2 ) ) ;

/ / Done:

return co lo r ;

Aggiungiamo al colore calcolato un’eventuale emissione de materiale, la componente am-

bient e l’ambient occlusion.


42 Implementazione


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.


44 Conclusione

5.1 Risultati ottenuti

Figura 20: Scena generale della demo


45

Figura 21: Dettaglio statua


46 Conclusione

Figura 22: Dettaglio pistola


47

Figura 23: Dettaglio sfere di vari materiali


48 Conclusione

Figura 24: Dettaglio spada. Notare il riflesso del metallo tipico del PBR.


49

Figura 25: Dettaglio teiere di materiale metallico (sopra) e dielettrico (sotto) con roughnesscrescente


50 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.


https://kyongame.com/blog/2017/1/19/subsurface-scattering-material-for-characters

51

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 lapercezione 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,


http://asgerhoedt.dk/?p=533

52 Conclusione


53

Allegati

1. CD-ROM - Documenti di progetto


54 Conclusione


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)


https://youtu.be/j-A0mwsJRmkhttps://youtu.be/zs0oYjwjNEo

AbstractContesto del ProgettoDescrizioneCompitiObbiettiviTecnologieMilestones

Teorie fondamentaliRiflessione e rifrazioneMicrofacet Theory

Physically-based RenderingIntroduzioneBRDFEquazione di rendering

Cook-Torrance BRDFNormal DistributionFresnelGeometry

ImplementazionePrimi passiRisultati intermedi

Passaggio a OvervisionDecisioni finaliModifiche alla classe MaterialModifiche al PluginOver3DSOVOreaderConversione materiali

Shader

ConclusioneRisultati ottenutiMiglioramenti futuriSubsurface ScatteringImage-based Lighting

AllegatiBibliografia

Physically-based Rendering for OpenGL - SUPSI Tesi · 2018. 12. 18. · 1Physically Based Shading...

Documents

Transcript of Physically-based Rendering for OpenGL - SUPSI Tesi · 2018. 12. 18. · 1Physically Based Shading...