Benvenuti nel thread dedicato alle discussioni tecniche sui videogiochi usciti ed in uscita. In questo thread si discute dell'aspetto meramente tecnologico dei videogiochi, lasciando quindi da parte il lavoro artistico, che pure contribuisce, in maniera non trascurabile, alla resa visiva complessiva. Si può discutere di titoli per qualsiasi console, anche portatile, e qualsiasi configurazione PC, così come di titoli 2D o 3D; non c'è limite, purché i discorsi siano sensati e si consideri il rapporto tra il gioco di cui si discute e l'hardware su cui gira.
Di seguito alcune norme di buona condotta:
- evitare paragoni tra le diverse versioni di un videogioco, per quelli c'è il thread dedicato ai confronti dei multipiattaforma;
- è possibile confrontare videogiochi diversi, che girano sulla stessa piattaforma o su piattaforme diverse. In ogni caso sono graditi commenti logici, evitando confronti diretti tra generi diametralmente opposti o tra videogiochi che girano su piattaforme con caratteristiche intrinseche diverse;
- evitare post volti a denigrare una piattaforma: qui si discute di videogiochi, non di hardware;
- chiedere consigli per la configurazione di un PC da gaming o consigli sui settaggi da impostare nelle versioni PC dei videogiochi;
- è, invece, possibile chiedere la configurazione ed i settaggi usati per gli screen e/o video postati dei videogiochi in versione PC;
- è possibile discutere e postare screen e/o video di videogiochi con mod o strumenti simili (ad es. texture pack) che ne modificano la resa visiva, limitandosi però a quelle modifiche che incidono sulla resa tecnica e tralsciando quelle che influiscono sull'aspetto artistico (ad es. mod che introducono il cel shading nei videogiochi che in versione vanilla non usano questa particolare scelta artistica);
- è assolutamente vietato offendere gli altri utenti per le opinioni espresse.
BREVE DIZIONARIO TECNICO
Aliasing: Scalettature presenti sulle linee diagonali nell'immagine. Può essere mitigato aumentando la risoluzione, usando filtri anti-aliasing o mediante l'effetto blur (sfocatura).
Ambient occlusion: Filtro che simula l'impatto sull'illuminazione dato dall'interazione della fonte di luce con corpi ed oggetti, i quali creano coni d'ombra.
Frame rate: Numero di fotogrammi visualizzati per ogni secondo di video. Un frame rate con forti sbalzi comporta scatti improvvisi del video o rallentamenti.
Frame time: Tempo di permanenza sul pannello di un singolo frame che compone il video, misurato in millisecondi. Un frame time non costante può comportare scatti nel video, anche in presenza di un frame rate stabile.
G-sync: Tecnologia hardware creata da Nvidia che sincronizza in tempo reale la fequenza del pannello rispetto il frame rate del video riprodotto. In questo modo non può verificarsi il tearing. Successivamente AMD ha creato una tencologia analoga denominata FreeSync.
HDR: Acronimo di high dynamic range. Un'immagine HDR presenta una illuminazione e, conseguentemente, una resa dei colori più realistica rispetto un'immabine SDR (standard dynamic range). Per poter visualizzare correttamente le immagini HDR sono necessari pannelli appositamente abilitati.
Illuminazione globale: Sistema di illuminazione basato non solo sulle fonti di luce, ma anche sull'interazione della luce con le superfici di corpi ed oggetti presenti, sui quali la luce può "rimbalzare", eventualmente subendo anche modifiche alla gradazione ed intesità in ragione delle caratteristiche della superficie con cui interagisce, per illuminare punti che non raggiungerebbe direttamente dalla fonte.
Motion blur: Effetto sfocato volto a riprodurre la "scia" che si ha in fotografia quando vengono ripresi soggetti in movimento da un punto di vista fisso, opure quando vengono ripresi soggetti immobili da un punto di vista in movimento.
Risoluzione: Numero di pixel che compongono un singolo frame. Risoluzioni inferiori a 1280*720 (ogni frame è composto da 1280 colonne di 720 pixel ciascuna) sono definite SD (standard definition), mentre le risoluzioni superiori a 1280*720 sono definite HD (high definition). Le risoluzioni maggiori di 3840*2160 sono definite UHD (ultra high definition). Alcune risoluzioni intermedie diffuse sono 1600*900, 1920*1080 (full HD) e 2560*1440.
Tearing: Difetto di sincronia tra la fonte del video ed il pannello su cui è riprodotto il video. Tale difetto comporta che su parte del pannello viene visualizzato il frame aggiornato mentre su altra parte del pannello viene visualizzato un frame precedente, creando così il tearing (strappo) nella zona "di confine" tra i due frame differenti visualizzati sulle due parti del pannello. Può essere contrastato usando il v-sync oppure utilizzando pannelli che sincronizzano automaticamente la propria frequenza di fotogrammi rispetto la sorgente.
Texture: Immagini utilizzate per "coprire" i modelli poligonali al fine di introdurre dettagli e rendere i modelli più verosimili. Possono essere disegnate manualmente, ottenute da una fotografia od ottenute con una tecnica mista (fotografia successivamente modificata da un artista).
V-sync: Soluzione software per elimanre il tearing. La produzione di fotogrammi per secondo viene limitata per coincidere con il numero massimo di fotogrammi per secondo che possono essere mostrati dal pannello in uso. Tale soluzione presenta, tuttavia, un difetto evidente: il tetto al numero di fotogrammi al secondo da produrre può essere impostato solo usando multipli di 30, quindi, nel caso la fonte del video non riesca a garantire il frame rate prescelto, il frame rate sarà automaticamente ridotto al multiplo di 30 immediatamente inferiore, con evidenti sbalzi del frame rate.
APPROFONDIMENTI
Metodi di AA (si ringrazia Rock3r):
- SSAA (SuperSampling AA): E' il metodo di AA per eccellenza. Elimina l'aliasing sulle geometrie, shader aliasing, shimmering...tutto. Tra i contro ci sono l'estremo costo sulle performance e l'uso sproporzionato di VRAM.
- OGSSAA (ordered grid): Renderizza l'immagine a risoluzioni maggiori per poi scalarla a quella del monitor, è anche chiamato downsampling.
- SGSSAA (sparse grid): Renderizza l'immagine diverse volte, applicando ogni volta un offset in direzioni diverse. Alla fine le varie immagini vengono unite via post processing per ottenere il risultato finale.
- MSAA (Multisampling AA): Probabilmente è il più usato ed il più noto. A differenza dell'SSAA è decisamente più leggero ma agisce solo sulle geometrie e quindi non fa niente contro lo shader aliasing. Inoltre non va d'accordo con il deferred rendering, con le DX11 è stata introdotta qualche soluzione anche per questo ma solitamente i risultati sono comunque scarsi (soprattutto considerando il confronto tra il rapporto prestazioni/qualità sui motori forward rendering), basta vedere Battlefield 3.
- TXAA (non so per cosa stia l'acronimo ma la T dovrebbe essere "Temporal" ? E' un nuovo metodo AA sviluppato da NVIDA e Timothy Lottes (lo stesso dell'FXAA ) e disponibile per ora esclusivamente per le schede Kepler e le serie successive di NVIDIA. Gli obiettivi per questo TXAA sono la riduzione significativa dell'aliasing soprattutto in movimento, una migliore resa con le geometrie alpha tested (come lo è solitamente la vegetazione), una resa corretta quando c'è l'HDR e l'assenza di ghosting. Il tutto senza eccessive richieste di risorse hardware. L'immagine finale sarà però meno nitida rispetto ad altre forme di AA. Per Timothy Lottes, però, questo non è un difetto ma un modo per avvicinarsi all'obiettivo di ottenere un risultato più "cinematografico" possibile.
- MLAA (Morphological AA): Metodo post-processing originariamente presentato da Intel ed usato su PS3 attraverso il Cell (God of War 3 dovrebbe essere stato il primo titolo con MLAA). Successivamente AMD ne ha creato una versione esclusiva per le proprie schede video. L'MLAA analizza il frame, cerca le zone con alto contrasto e applica un blur localizzato. Le considerazioni che seguono sono valide per la versione di MLAA che gira sulle GPU, ossia quella selezionabile via driver dai possessori di GPU AMD. Riduce l'aliasing ma per forza di cose non preserva la nitidezza dell'immagine dato che intacca anche le textures. Crea problemi ai testi e all'HUD. Personalmente ritengo la versione AMD ancora molto acerba rispetto ad altre forme di AA simili.
- FXAA (Fast Approximate AA): Deriva direttamente dall'MLAA ed è stato sviluppato da Timothy Lottes. E' sempre post processing e si può inserire facilmente in più o meno qualsiasi motore.
- Migliora sensibilmente sia le performance che la qualità rispetto all'MLAA ma ne mantiene anche i difetti dovuti al fatto che è pur sempre un metodo post processing.
- SMAA (Subpixel Morphological AA): Simile a quanto scritto sopra per l'FXAA ma con la differenza che preserva in modo maggiore la nitidezza dell'immagine. Inoltre alcune versioni di SMAA lavorano in coppia con particolari forme di MSAA/SSAA per una migliore resa con i sub-pixel. La versione scaricabile e applicale sui PC (Injector) però non supporta queste features. E' sviluppato da Jorge Jimenez.
Forward VS Deferred Con il rendering tradizionale (forward rendering) il processo di shading, ossia la determinazione del colore finale del pixel, avviene più o meno in questo modo: per ogni geometria nella scena si guarda quale luce o luci la interessano e infine si “calcola” il risultato finale basandosi sul materiale dell'oggetto stesso. Questo ci porta ad avere un costo computazionale dello shading pari a numero geometrie * numero luci (nella peggior ipotesi). Quindi, se abbiamo più oggetti colpiti da diverse luci, verrebbero sprecate parecchie risorse perchè ad ogni luce aggiunta si è costretti a renderizzare un'altra volta la geometria e se ad esempio avessimo 3 oggetti poligonali uno davanti all'altro verrebbero compresi nel processo di shading pure quelle parti non necessarie perchè sono coperte dall'oggetto che sta davanti e che quindi non sono visibili. Con il deferred rendering invece viene creato il cosiddetto “g-buffer” che contiene gli attributi fondamentali delle geometrie (vedremo più avanti nel dettaglio), in seguito l'illuminazione è processata usando appunto le informazioni presenti nel g-buffer e viene applicata proprio come se fosse un effetto di post processing in 2D. Quindi la formula sarebbe numero geometrie + numero luci. E' chiaro che nelle situazioni con più di un paio di luci dinamiche il risparmio di risorse spese per l'illuminazione è tantissimo, potenzialmente si possono avere centinaia di luci dinamiche assieme senza troppi problemi. Inoltre la differenza tra avere una moltitudine di luci oppure averne una sola ma che copre gran parte delle geometrie è quasi nulla ...più o meno. G-buffer (Geometry buffer) Il g-buffer è un insieme di più buffer intermedi (render targets) che contengono le informazioni necessarie per il processo dell'illuminazione, quindi i vari attributi delle geometrie e dei materiali. Sono richiesti almeno questi 3:
Ci sarebbe davvero da scrivere pagine e pagine sull'aliasing 
Il problema con le trasparenze è pure lui abbastanza evidente, infatti i g-buffer ha solo le informazioni sulle superfici vicine e non su quelle che stanno “dietro”. C'è il modo per avere oggetti trasparenti con il deferred rendering ma è talmente complesso che al 99,9% gli sviluppatori ritornano al forward rendering quando si tratta di renderizzarle. In definitiva questo metodo di rendering si sta diffondendo sempre di più (il futuro Unreal Engine 4 ad esempio sarà deferred), ha i suoi vantaggi come pure qualche problema apparentemente insormontabile. Ci sono già soluzioni ibride o modificate ad hoc per avere i maggiori benefici possibili e le possibilità sono grandissime, l'illuminazione globale in tempo reale è possibile appunto grazie al fatto che si possono posizionare moltissime luci per simularne l'effetto. Sarebbe praticamente infattibile con un motore forward. Vedremo in futuro come si evolverà la situazione :morris82: Bon, questa è giusto un' infarinatura generale su un argomento che comunque è bello complesso (g-buffer ed i suoi formati e MRT soprattutto). Io non sono un granché con le spiegazioni e non sono né programmatore né sviluppatore ma spero comunque di essere stato di qualche aiuto 
Se avete domande o correzioni scrivete pure.
- Albedo, diffuse o texture color: semplicemente il colore “neutro” delle textures.
- Depth (oppure world position che comunque può essere ottenuto dal depth): necessario per quelle luci che non colpiscono tutti gli oggetti in modo uguale, come le luci locali che interessano solo gli oggetti più vicini.
- Normal: in breve definisce se una superficie deve essere illuminata o no.
- Luci dinamiche come se piovesse e senza troppa preoccupazione per le performance.
- Semplice da implementare.
- Niente spreco di risorse dovute al fatto che solo i pixel visibili sono processati.
- Con le informazioni del g-buffer si possono inserire diversi effetti di post processing in modo relativamente semplice.
- Nessun supporto nativo per l'hardware antialiasing, l'MSAA (risolto in parte).
- Niente trasparenze (...non è vero... ma vediamo dopo).
- Il costo sulla memoria è importante, sia come spazio richiesto che come bandwidth.
- La differenziazione dei materiali è strettamente legata al g-buffer e quindi potenzialmente limitata.
- Tante luci sì ...ma quelle che castano ombre saranno comunque limitate.
Ci sarebbe davvero da scrivere pagine e pagine sull'aliasing Il problema con le trasparenze è pure lui abbastanza evidente, infatti i g-buffer ha solo le informazioni sulle superfici vicine e non su quelle che stanno “dietro”. C'è il modo per avere oggetti trasparenti con il deferred rendering ma è talmente complesso che al 99,9% gli sviluppatori ritornano al forward rendering quando si tratta di renderizzarle. In definitiva questo metodo di rendering si sta diffondendo sempre di più (il futuro Unreal Engine 4 ad esempio sarà deferred), ha i suoi vantaggi come pure qualche problema apparentemente insormontabile. Ci sono già soluzioni ibride o modificate ad hoc per avere i maggiori benefici possibili e le possibilità sono grandissime, l'illuminazione globale in tempo reale è possibile appunto grazie al fatto che si possono posizionare moltissime luci per simularne l'effetto. Sarebbe praticamente infattibile con un motore forward. Vedremo in futuro come si evolverà la situazione :morris82: Bon, questa è giusto un' infarinatura generale su un argomento che comunque è bello complesso (g-buffer ed i suoi formati e MRT soprattutto). Io non sono un granché con le spiegazioni e non sono né programmatore né sviluppatore ma spero comunque di essere stato di qualche aiuto Se avete domande o correzioni scrivete pure.In breve, con il supersampling si prendono più samples per ogni pixel in modo che quando l'immagine sarà risolta verrà fatta la media tra i diversi samples che darà il colore finale del pixel: immagina un normale rombo nero su sfondo bianco, senza AA avresti solo pixel completamente neri e pixel completamente bianchi, mentre con l'AA avendo più samples (e facendo la media del colore) il risultato mostrerebbe dei pixel sui lati obliqui di diverse gradazioni di grigio riducendo così l'aliasing (più samples vengono usati e più si riduce l'aliasing ...e più pesa sulle prestazioni). Nei metodi post processing come FXAA e SMAA base invece "semplicemente" il programma cerca gli "spigoli" e applica del blur ...certo è che lo shader deve riconoscere dove applicare il blur e dove no, ma ti basta sapere che i samples per pixel sono sempre uguali a 1 e questo fa la differenza tra le 2 tipologie (MSAA e SSAA/ vs AA post processing). Ora, tornando all'SSAA questi samples possono esser presi seguendo una griglia ordinata ed il risultato sarebbe il classico OGSSAA che non è altro che quello usato spesso adesso su PC tramite downsampling, aumenti la risoluzione per ogni lato e scali a quella del monitor. Se invece li prendi in ordine sparso o ruotando la famosa griglia hai rispettivamente SGSSAA e RGSSAA, non mi addentro di più su questi due perchè ho ancora diverse cose poco chiare a riguardo. All'inizio credevo che l'Ubersampling di The Witcher 2 fosse OGSSAA ma poi da quanto ho capito è invece più simile a SGSSAA/RGSSAA. In diversi giochi per rimediare all'aliasing è possibile renderizzare a risoluzioni particolari, magari lasciando un' asse alla res "normale" e l'altra al doppio o comunque maggiore a quella del target finale, poi verrà appunto scalata solo su quell'asse riducendo così l'AA es. gioco generato alla risoluzione 1280*1440 ---> immagine finale 1280*720. Così avresti una via di mezzo tra prestazioni e resa visiva. Mi viene in mente Soul Calibur 5 i cui sviluppatori fecero qualcosa di simile: su X360 il gioco veniva renderizzato ad una risoluzione leggermente superiore e poi riportato a 720p, quindi usufruiva del supersampling. Certo, il risultato non cambiava la vita ma è giusto per dimostrare che questa tecnica può tranquillamente essere usata anche sulle console attuali, in questo caso addirittura in un titolo a 60fps. Quindi supersampling è un termine piuttosto generico, non bisogna subito pensare alle opzioni PC ammazza framerate e non implica per forza l'uso di risoluzioni altissime ma comprende qualsiasi cosa che permetta di avere più di un sample per pixel (per ogni pixel). Non è un metodo particolarmente efficiente, anzi... però, dato che si stanno diffondendo i motori deferred, l'MSAA è sempre meno usato a causa delle scarse prestazioni su questo tipo di engine e quindi potrebbe essere un'alternativa. E' per questo motivo che ho ipotizzato la possibilità di usare il supersampling a supporto dell'FXAA, qualcosa di leggero come 1920*1440@1080p (scalando solo un asse) o 1,2x per entrambi gli assi ...insomma che sia anche poco ma che aiuti l'FXAA che ricordo, avendo a disposizione solo un sample per pixel, usato da solo avrà sempre problemi di shimmering e altri artefatti, negli screenshot va anche bene ma in movimento no. Ultima nota, il supersampling è spesso usato anche nei vari buffer intermedi in un gioco o solo selettivamente: esempio in Killzone 2 per il pass della luce (è deferred pure lui) o molto più comune è il cosiddetto "transparency supersampling" che è applicato solo alle textures alpha (usato parecchio soprattutto sulla vegetazione tipo foglie, erba, ecc...).
Come ho dette ieri volevo parlare un po' del famigerato Physically Based Rendering (abbreviato PBR) dato che è una delle "ultime " novità nel campo della grafica 3D, real time e non. The Order 1886, Ryse, Killzone Shadowfall, Star Citizen (che sta andando verso il PBR), il futuro Unreal Engine 4 e molti altri progetti presenti e futuri hanno come denominatore comune proprio il physically based rendering. Ho trovato un bel portfolio sul forum di Polycount di un artista che ha iniziato a lavorare con PBR e le immagini dei suoi lavori sono utili per capire i cambiamenti rispetto a prima: Questa è una pistola da softair, renderizzata usando Toolbag 2 di Marmoset che è un avanzato motore real-time usatissimo dagli artisti per "testare" i loro lavori sul campo, recentemente passato anche al PBR.
ma in verità voglio prendere in esame un altro suo modello con cui si riesce a capire meglio la situazione:
- Albedo: è il colore base del materiale, precedentemente anche chiamato diffuse (pure adesso in verità ma è meglio solo albedo d'ora in poi). Se avete visto una texture normale prima d'ora questa vi sembrerà un po' diversa dal solito, il saldatore come vedete dal render è tutto colorato mentre il suo albedo è praticamente solo nero, grigio e rosso. Il motivo è presto spiegato, tutti i materiali metallici (conduttori) con il PBR devono avere l'albedo nero, gli altri tipi di materiali che non sono conduttori (legno, plastica, rocce, tessuti vari e tutto il resto) invece useranno il colore base reale, nel caso della saldatrice il manico è di gomma mentre il resto è fatto di materiali metallici. Il motivo è strettamente legato all'interazione tra materiali e luce che c'è anche nel mondo reale ma non voglio dilungarmi oltre quindi si fa così perchè sì, bon. Un'altra cosa molto importante nell'albedo quando si lavora con il PBR è che deve avere meno informazioni sulla luce baked possibili, meglio niente del tutto perchè sarà poi il motore in tempo reale ad occuparsi di queste cose. Prima era normale creare una texture diffuse contenente già alcune informazioni come ad esempio l'occlusione ambientale ma ora non serve più, sarebbe pure deleterio. Se si vuole l'AO si crea una texture a parte.
- Reflectance: definisce la quantità di luce che viene riflessa da un materiale. A qualcuno potrebbe far venire in mente le vecchie specular maps ...ma quelle non erano textures solitamente in scala di grigi mentre questa è tutta colorata? WTF!? Il fatto è che la reflectance map è molto diversa ed il motivo per la quale qui sia piuttosto colorata deriva da quello che ho scritto sopra, i metalli avendo l'albedo nero "prendono il colore" da questa texture. Se ci fate caso nella realtà i riflessi speculari dei metalli hanno proprio il colore del metallo, se prendete un lingotto d'oro (chi non ce l'ha sottomano) vedrete che il suo riflesso speculare è tendente al giallino, idem il rame (sull'arancione/rosa) o il bronzo (... bronzeo) o qualunque altro metallo come si vede bene nel render del saldatore. Questa texture dovrebbe anche tenere conto dell'indice di rifrazione -IOR- di un oggetto, si cercano i dati dei materiali reali online e a seconda del loro valore RGB il motore usa queste informazioni per il calcolo per lo shading.
- Roughness: (anche chiamata gloss map) descrive quanto un materiale è ruvido o liscio, parlando a livelli microscopici. Quindi per farla breve se è uno specchio o no, con tutte le vie di mezzo; in questo caso più la parte è bianca e più sarà lucida e viceversa. Guardate il pezzo rosso di plastica del saldatore, nella roughness map è grigio scuro ossia molto poco lucido (non glossy). La quasi totalità dei graffi, danni da usura e cose simili sono stati apportati in questa texture e questi piccoli dettagli nel risultato finale fanno la differenza, modificandola ad hoc si può anche usare per simulare un materiale bagnato. PBR tra le tante cose equivale anche a energy conservation, la quantità di luce riflessa non può essere maggiore di quella ricevuta e questa immagine mostra bene le conseguenze:
Più la superficie si fa "ruvida" (rough) e più il riflesso si allarga e allo stesso tempo diminuisce di intensità, proprio per il principio della conservazione dell'energia.
- Normal: grazie a dio la normal map è uguale al passato
Skin Rendering (si ringrazia Cifa per il contributo)
Visto che oggi di studiare non ne ho voglia scrivo una prima puntata di 'sta cosa che annoierà i più, ma magari ad uno o due può interessare
Mi metto a scriverla a puntate perchè so che non avrò mai il tempo di scrivere un papiro tutto di colpo, quindi di questo mi scuso in anticipo. In testa ho una cosa del tipo: :D Ora purtroppo mi devo fermare che c'ho un fottio di roba arretrata da studiare, spero di scrivere la seconda parte al più presto e/o aggiungere qualcosa a questo. Questo post oltretutto non contiene neanche per sbaglio tutti i dettagli che sarebbero da coprire quando si parla delle sopracitate cose, ma era giusto per dare un infarinatura. Oltretutto mi sono buttato in questo campo da una settimana circa, quindi potrei aver commeso diversi errori di cui mi scuso anticipatamente 
Spero di correggerli nel caso me ne dovessi accorgere. Altra cosa da sottolineare: non mi sono focalizzato su come ottenere le texture, normali ed i valori/parametri necessari per la nostra BRDF e (approssimazione di) BSSRDF. E' n'altra faticata di cui se volete posso raccontare qualcosa. ___ NOTA 1: Per la componente speculare, viene tipicamente usata la Kelemen/Szirmay-Kalos Specular BRDF per la sua efficienza. In questa tocca considerare termini di Fresnel e tanta altra roba che purtroppo difficilmente interessa e che non è facilmente spiegabile ad un "pubblico" eterogeneo e con credo non una preparazione universitaria di fisica/matematica/grafica. ___ EDIT: Mi scuso anche del fatto che ci saranno milioni di errori grammaticali e che magari l'esposizione è confusa. Ormai sto perdendo l'abitudine a scrivere in Italiano e ho scritto tutto di getto EDIT2: Maggior parte di questo post si basa sul capitolo 14 di GPU Gems3 di Nvidia e scritto da d'Eon e Luebke. E' un articolo formidabile che invito tutti quelli che desiderano di dargli un occhio. Nelle prossime parti questa fonte verrà riutilizzata, ma attingerò da alcune altre.
Mi metto a scriverla a puntate perchè so che non avrò mai il tempo di scrivere un papiro tutto di colpo, quindi di questo mi scuso in anticipo. In testa ho una cosa del tipo: :D Ora purtroppo mi devo fermare che c'ho un fottio di roba arretrata da studiare, spero di scrivere la seconda parte al più presto e/o aggiungere qualcosa a questo. Questo post oltretutto non contiene neanche per sbaglio tutti i dettagli che sarebbero da coprire quando si parla delle sopracitate cose, ma era giusto per dare un infarinatura. Oltretutto mi sono buttato in questo campo da una settimana circa, quindi potrei aver commeso diversi errori di cui mi scuso anticipatamente Spero di correggerli nel caso me ne dovessi accorgere. Altra cosa da sottolineare: non mi sono focalizzato su come ottenere le texture, normali ed i valori/parametri necessari per la nostra BRDF e (approssimazione di) BSSRDF. E' n'altra faticata di cui se volete posso raccontare qualcosa. ___ NOTA 1: Per la componente speculare, viene tipicamente usata la Kelemen/Szirmay-Kalos Specular BRDF per la sua efficienza. In questa tocca considerare termini di Fresnel e tanta altra roba che purtroppo difficilmente interessa e che non è facilmente spiegabile ad un "pubblico" eterogeneo e con credo non una preparazione universitaria di fisica/matematica/grafica. ___ EDIT: Mi scuso anche del fatto che ci saranno milioni di errori grammaticali e che magari l'esposizione è confusa. Ormai sto perdendo l'abitudine a scrivere in Italiano e ho scritto tutto di getto EDIT2: Maggior parte di questo post si basa sul capitolo 14 di GPU Gems3 di Nvidia e scritto da d'Eon e Luebke. E' un articolo formidabile che invito tutti quelli che desiderano di dargli un occhio. Nelle prossime parti questa fonte verrà riutilizzata, ma attingerò da alcune altre.- 1/3: Motivazioni e basi sull'interazione con la luce
- 2/3: Algoritmi real time: qualche base (questa parte purtroppo sarà castrata dato fino a quanto posso spingermi senza introdurre tecnicismi )
- 3/3: Particolari su altri vari fattori e componenti coinvolte. Il colore.
Ignorando tutti i vari simboli, la BRDF in un contesto di PBR, ci dice come la luce viene riflessa da una superficie, in particolare data una direzione da cui la luce arriva, ci dice in che percentuale la luce viene riflessa in una data direzione d'uscita (di riflessione). Questa sarà diversa per ogni materiale dato che ovviamente ogni materiale riflette la luce in modo diverso. Ci sarebbero almeno una decina di pagine per spiegare meglio la BRDF, ma non ci è utile adesso e penso che sia noioso ai più (ancor più di questo post qua
) quindi mi fermo a questo. Bene, fighissimo, usiamo la BRDF anche con la pelle! Eh no. E' proprio qua la chiave di tutto. Se guardate la figura di prima potete vedere come con la BRDF non ci si interessa affatto di quello che succede all'interno della superficie e nella pelle succede di tutto quando la luce penetra all'interno. Diventa dunque fondamentale considerare il subsurface scattering, ovverosia il processo a cui è "sottoposta" la luce sotto la pelle. Questa farà un sacco di giri, verrà in parte assorbita e poi uscirà fuori.
Ultima modifica da un moderatore:
