Ottime notizie da un lato, bruttine (ma non poi particolarmente brutte) dall'altro.
Dopo aver passato delle ore a studiare documenti su internet per risolvere il problema del displacement (tant'è che oggi non ho programmato nulla) posso dire di aver trovato le basi teoriche per risolverlo!
Si tratta dell'aritmetica affine, un bellissimo modello di analisi numerica autovalidante.
Questa teoria mi permette non solo di risolvere il problema del displacement, ma anche di risolvere altri problemi secondari e di ottimizzare maggiormente alcune cose dentro cassata.
Si tratta, è vero, di un'approssimazione, ma del tutto paragonabile come dimensioni e caratteristiche a quella che viene fuori usando i numeri in virgola mobile, e la si può ridurre a piacere, in modo, appunto, da renderla davvero paragonabile a quella generata svolgendo calcoli col tipo usato al momento. In pratica è possibile accorparla all'unica approssimazione numerica che ho mai fatto in tutto il renderer (quasi inevitabile), ed è sufficiente aumentare i temi di rendering e la ram usati per ridurla (qual'ora ce ne sia bisogno, non è una cosa così comune :) ).
Tra parentesi faccio notare che tutti i renderer unbias non sono davvero unbias per colpa di queste approssimazioni, però sono talmente piccole e trascurabili che non le si prende minimamente in considerazione. Di contro il mio sarebbe il primo renderer unbias di cui sono a conoscienza che aumentando i tempi di rendering è in grado di far diminuire a piacere questi errori.
Fin qua direi ottime notizie. La "brutta" notizia è che l'introduzione dell'aritmetica affine mi porterà via del tempo in progettazione.
Anche se a livello di codice in questo punto della lavorazione di cassata le cose da fare per riadattare ciò che ho già scritto sono pressocché nulle, la progettazione, per quanto non cambi proprio visceralmente, è comunque condizionata in quasi tutto ciò che ho fatto, ed ho bisogno di un periodo di tempo per rimettere le cose apposto.
Oltretutto si tratta di una tecnica nuova, che non conoscevo fino a 10 ore fa. Anche se ho già letto e compreso molte cose, prima di poterla padroneggiare bene passerà un po'.
Credo di aver detto tutto, alla prossima :)
mercoledì 28 novembre 2007
martedì 27 novembre 2007
Novità e parecchio codice nuovo
Ormai penso che l'avrete capito. Ogni tanto faccio un mare di cose per cassata e poi mi eclisso per un breve periodo :)
È qualche giorno che sono sopra il codice e sono molte le novità sia in fase di progettazione che d'implementazione. Penso che mi ci dedicherò ancora pochi giorni e poi riavrò una bella eclissi di un paio di settimane o chissà quanto XD
Intanto illustro quanto è stato fatto in questa settimana (giorno più giorno meno ho lavorato una settimana).
Ho implementato (non è proprio finito, ma diciamo quasi, piccole modifiche verranno fatte mano a mano andrò avanti) il parser per le scene XML.
Davvero complicatissimo, è attualmente la parte più complessa dell'intero cassata, ed anche a renderer finito penso rimarrà tra le più complesse in assoluto, probabilmente nella top 5.
Per chi fosse curioso ecco il codice:
scene.cpp
scene.h
Altre implementazioni sono state fatte qua e la, in particolare ho cominciato a definire il sistema dei plugin per i tipi, ma ancora c'è moltissimo da fare (forse riuscirò ad abbozzare tutto prima della prossima pausa, chissà XD ).
Per quanto riguarda la progettazione ho definito meglio il sistema per gli shader, e tralaltro (non che sia proprio "progettazione") mi sono informato un po' meglio sul discorso licenze.
Qua c'è una lista degli shader che verranno utilizzati nel rendering:
Poiché lo reputo interessante ecco una descrizione più approfondita di cosa si più fare ed a cosa servono tutti e 7 i tipi di shader:
Lo shader camera indica come funziona l'"occhio" che vede la scena. Cosa è in grado di vedere e cosa no.
Questo include anche i colori visibili, la polarizzazione, il DoF, il motion blur ed altre cose simili. Per capire perché anche queste cose influiscono pensate ad una macchina fotografica, dove potete cambiare esposizione, apertura ed altre cose simili.
Effetti come il glow non sono del tutto rappresentabili però in questo shader (come si vedrà vengono svolti dal filter).
Lo shader geometry indica la geometria di un oggetto.
Oggetti vari, come nurbs, mesh o qualunque altra cosa, verranno implementati con questo.
Lo shader material dice come una geometria gestisce i raggi. Un material può anche emettere raggi, nel qual caso è una sorgente luminosa.
Lo shader layer è probabilmente il più semplice dopo il generic, ma spiegarlo non è così semplice. Vediamo cosa riesco a fare :)
Questo shader modifica la posizione e la visibilità degli oggetti, in pratica compone la scena. Se per esempio un oggetto si muove nella scena, scompare e riappare, od ancora viene visto solo da certi oggetti viene deciso dal layer (per esempio se di un oggetto si vede solo l'ombra questo verrà fatto coi layer).
Lo shader filter sembrerebbe un classico postprocesso delle immagini (quello che fanno i nodi in blender, per intenderci).
Sebbene lo scopo sia esattamente quello, l'approccio è parecchio differente. Il tutto avviene infatti in maniera completamente unbias, e così è del tutto ininfluente la risoluzione delle immagini.
Effetti come il glow, postprocesso delle immagini o cose simili vengono fatti qua.
Lo shader volume è davvero molto interessante. Può cambiare a suo piacimento ciò che vuole di un raggio. Direzione, intensità, può generarne anche dal nulla, può fare ciò che vuole. In realtà fa anche quello che fanno material e geometry, ma non solo.
Il motivo per cui esistono material e geometry è che in molti casi simulare ciò che viene richiesto per fare oggetti tramite il volume (cosa che risulterebbe senza dubbio più realistica ma indistinguibile ad occhio nudo) è semplicemente improponibile in termini di tempo.
Alcuni effetti, come ombre e luci volumetriche, fuoco, fumo ed altre cose simili, sono fatte tramite questo shader. Se si vuole ottenere il massimo realismo con effetti come il subsurface scattering lo si può fare sempre con questo shader, ma lo sconsiglio per via dei tempi. Sarà presente un'approssimazione (estremamente più realistica di quella che c'è in blender in ogni caso) come shader material per l'SSS, per cui generalmente non si dovrà aspettare una vita.
Lo shader generic serve solo per appoggiare gli altri shader, fornisce codice che non deve così essere riscritto per ogni singolo shader che ne fa uso, ma che così può essere scritto una sola volta.
Va detto che tutti gli shader sono praticamente identici tra loro, cambia solo il modo in cui il renderer li tratta, e tutti gli shader possono essere collegati nei modi più disparati per offrire cose molto interessanti.
Per esempio supponiamo di avere 2 materiali, uno opaco ed uno semitrasparente. Vogliamo che il materiale semitrasparente agisca come superficie che sta sopra quello opaco. Si scrive un terzo shader, ASSOLUTAMENTE GENERICO, che fa la sovrapposizione di 2 materiali e gli si collegano i 2 materiali assieme. Et voila, le jeu son fé :) (sarà giusto il mio francese? XD )
Tutti gli shader sono in funzione del tempo in qualche modo, quindi tutti animabili.
Inoltre tutti gli shader descrivono com'è fatta la scena, non come renderizzarla. Le 2 cose sono totalmente svincolate.
Ciò che sto cercando di fare (con un discreto successo) è di avere tutto totalmente unbias.
Non sono sicuro di poter fare tutto unbias, in particolare c'è un solo, singolo aspetto che mi lascia perplesso: il displacement!
Ho già pensato ad alcune soluzioni approssimate, ma è proprio quello che voglio evitare.
Una delle cose belle di un renderer unbias è che la descrizione della scena è totalmente ignara di come la scena verrà renderizzata, con quale qualità. Non si va a fornire, oggetto per oggetto, qualche parametro sulla qualità di un oggetto perché questo appaia correttamente nella scena. Tutte le soluzioni da me pensate per il displacement hanno questo problema, e comunque non sono unbias. Alcune sono anche abbastanza belle da vedere e veloci, ma non sono unbias.
Sono scettico sulla possibilità di trovare una soluzione a questo che è in effetti l'unico ostacolo reale a ciò che voglio fare tra quelli che ho incontrato finora, e se sarà necessario inserirò il displacement alla meno peggio, però se troverò qualcosa per risolvere il problema la inserirò ben volentieri, e continuerò a cercare in proposito (nota che con gli shader volume, facendo oggetti reali, e non approssimazioni come fa il geometry, sono abbastanza fiducioso che si possa rappresentare il displacement in maniera unbias, ma la cosa è davvero troppo lenta per poter esser presa in considerazione).
Per il resto, ho fatto un altro post interminabile, dico che avevo dimenticato le metaball dall'elenco del post precedente, che saranno realizzate e sono possibili in maniera unbias, a presto con altre notizie :)
È qualche giorno che sono sopra il codice e sono molte le novità sia in fase di progettazione che d'implementazione. Penso che mi ci dedicherò ancora pochi giorni e poi riavrò una bella eclissi di un paio di settimane o chissà quanto XD
Intanto illustro quanto è stato fatto in questa settimana (giorno più giorno meno ho lavorato una settimana).
Ho implementato (non è proprio finito, ma diciamo quasi, piccole modifiche verranno fatte mano a mano andrò avanti) il parser per le scene XML.
Davvero complicatissimo, è attualmente la parte più complessa dell'intero cassata, ed anche a renderer finito penso rimarrà tra le più complesse in assoluto, probabilmente nella top 5.
Per chi fosse curioso ecco il codice:
scene.cpp
scene.h
Altre implementazioni sono state fatte qua e la, in particolare ho cominciato a definire il sistema dei plugin per i tipi, ma ancora c'è moltissimo da fare (forse riuscirò ad abbozzare tutto prima della prossima pausa, chissà XD ).
Per quanto riguarda la progettazione ho definito meglio il sistema per gli shader, e tralaltro (non che sia proprio "progettazione") mi sono informato un po' meglio sul discorso licenze.
Qua c'è una lista degli shader che verranno utilizzati nel rendering:
- camera: Sceglie quali raggi emettere o catturare;
- geometry: Indica dove i raggi sbattono;
- material: Mostra in che modo i raggi interagiscono laddove sbattono;
- layer: Indica quali oggetti disegnare;
- filter: Combina vari layer come si vuole;
- volume: Indica come i raggi si comportano dove non rimbalzano;
- generic: Produce risultati utili agli altri tipi.
Poiché lo reputo interessante ecco una descrizione più approfondita di cosa si più fare ed a cosa servono tutti e 7 i tipi di shader:
Lo shader camera indica come funziona l'"occhio" che vede la scena. Cosa è in grado di vedere e cosa no.
Questo include anche i colori visibili, la polarizzazione, il DoF, il motion blur ed altre cose simili. Per capire perché anche queste cose influiscono pensate ad una macchina fotografica, dove potete cambiare esposizione, apertura ed altre cose simili.
Effetti come il glow non sono del tutto rappresentabili però in questo shader (come si vedrà vengono svolti dal filter).
Lo shader geometry indica la geometria di un oggetto.
Oggetti vari, come nurbs, mesh o qualunque altra cosa, verranno implementati con questo.
Lo shader material dice come una geometria gestisce i raggi. Un material può anche emettere raggi, nel qual caso è una sorgente luminosa.
Lo shader layer è probabilmente il più semplice dopo il generic, ma spiegarlo non è così semplice. Vediamo cosa riesco a fare :)
Questo shader modifica la posizione e la visibilità degli oggetti, in pratica compone la scena. Se per esempio un oggetto si muove nella scena, scompare e riappare, od ancora viene visto solo da certi oggetti viene deciso dal layer (per esempio se di un oggetto si vede solo l'ombra questo verrà fatto coi layer).
Lo shader filter sembrerebbe un classico postprocesso delle immagini (quello che fanno i nodi in blender, per intenderci).
Sebbene lo scopo sia esattamente quello, l'approccio è parecchio differente. Il tutto avviene infatti in maniera completamente unbias, e così è del tutto ininfluente la risoluzione delle immagini.
Effetti come il glow, postprocesso delle immagini o cose simili vengono fatti qua.
Lo shader volume è davvero molto interessante. Può cambiare a suo piacimento ciò che vuole di un raggio. Direzione, intensità, può generarne anche dal nulla, può fare ciò che vuole. In realtà fa anche quello che fanno material e geometry, ma non solo.
Il motivo per cui esistono material e geometry è che in molti casi simulare ciò che viene richiesto per fare oggetti tramite il volume (cosa che risulterebbe senza dubbio più realistica ma indistinguibile ad occhio nudo) è semplicemente improponibile in termini di tempo.
Alcuni effetti, come ombre e luci volumetriche, fuoco, fumo ed altre cose simili, sono fatte tramite questo shader. Se si vuole ottenere il massimo realismo con effetti come il subsurface scattering lo si può fare sempre con questo shader, ma lo sconsiglio per via dei tempi. Sarà presente un'approssimazione (estremamente più realistica di quella che c'è in blender in ogni caso) come shader material per l'SSS, per cui generalmente non si dovrà aspettare una vita.
Lo shader generic serve solo per appoggiare gli altri shader, fornisce codice che non deve così essere riscritto per ogni singolo shader che ne fa uso, ma che così può essere scritto una sola volta.
Va detto che tutti gli shader sono praticamente identici tra loro, cambia solo il modo in cui il renderer li tratta, e tutti gli shader possono essere collegati nei modi più disparati per offrire cose molto interessanti.
Per esempio supponiamo di avere 2 materiali, uno opaco ed uno semitrasparente. Vogliamo che il materiale semitrasparente agisca come superficie che sta sopra quello opaco. Si scrive un terzo shader, ASSOLUTAMENTE GENERICO, che fa la sovrapposizione di 2 materiali e gli si collegano i 2 materiali assieme. Et voila, le jeu son fé :) (sarà giusto il mio francese? XD )
Tutti gli shader sono in funzione del tempo in qualche modo, quindi tutti animabili.
Inoltre tutti gli shader descrivono com'è fatta la scena, non come renderizzarla. Le 2 cose sono totalmente svincolate.
Ciò che sto cercando di fare (con un discreto successo) è di avere tutto totalmente unbias.
Non sono sicuro di poter fare tutto unbias, in particolare c'è un solo, singolo aspetto che mi lascia perplesso: il displacement!
Ho già pensato ad alcune soluzioni approssimate, ma è proprio quello che voglio evitare.
Una delle cose belle di un renderer unbias è che la descrizione della scena è totalmente ignara di come la scena verrà renderizzata, con quale qualità. Non si va a fornire, oggetto per oggetto, qualche parametro sulla qualità di un oggetto perché questo appaia correttamente nella scena. Tutte le soluzioni da me pensate per il displacement hanno questo problema, e comunque non sono unbias. Alcune sono anche abbastanza belle da vedere e veloci, ma non sono unbias.
Sono scettico sulla possibilità di trovare una soluzione a questo che è in effetti l'unico ostacolo reale a ciò che voglio fare tra quelli che ho incontrato finora, e se sarà necessario inserirò il displacement alla meno peggio, però se troverò qualcosa per risolvere il problema la inserirò ben volentieri, e continuerò a cercare in proposito (nota che con gli shader volume, facendo oggetti reali, e non approssimazioni come fa il geometry, sono abbastanza fiducioso che si possa rappresentare il displacement in maniera unbias, ma la cosa è davvero troppo lenta per poter esser presa in considerazione).
Per il resto, ho fatto un altro post interminabile, dico che avevo dimenticato le metaball dall'elenco del post precedente, che saranno realizzate e sono possibili in maniera unbias, a presto con altre notizie :)
Iscriviti a:
Post (Atom)
