Post non adatto ai deboli di cuore

Questo post è il più lungo, complesso ed addentro a cassata che abbia mai scritto fino ad ora, per cui ne è consigliabile una lettura solo a chi ha molta voglia, o vuole interessarsi a come funziona cassata.
Si tratta di un riepilogo di tutto quello che è stato fatto fino ad ora, unito a moltissime cose nuove, ed in effetti è il lavoro che ho svolto negli ultimi tempi, nei quali codice ne ho scritto pochissimo, ed anticipa un libro che ho intenzione di scrivere per tutti gli sviluppatori vari.
Attenzione che non si tratta di nulla di immutabile, ogni cosa che citerò in questo post potrà essere cambiata in futuro, e presumibilmente qualcosa lo sarà. È comunque un post molto indicativo sul funzionamento di cassata e sul suo futuro e le sue possibilità, ne raccomando quindi la lettura a tutti coloro che sono sufficientemente motivati. Eviterò il più possibile termini ed espressioni che potrebbero risultare complessi per chi non è molto addentro all'argomento, ma non credo che riuscirò ad evitarli completamente, per cui cercate di seguire meglio che potete, eventualmente con wikipedia alla mano (meglio quello inglese). :)

Per prima cosa cominciamo col vedere quali sono i componenti in cassata.
Il primo componente è il core, è un demone, quindi un'applicazione che funziona in background. Gestisce tutti i lavori, ognuno dei quali è una scena. Potrebbe essere carino, più avanti, poter stabilire delle priorità sulle scene, o cose simili, in modo da poter renderizzare delle scene di prova senza appesantire le altre, ma non è una priorità.

Poi ci sono i plugin. Questi sono di due tipi. Il primo fornisce delle funzioni utilizzabili dagli shader. Il secondo filtra tutti i file, eccetto uno (che citerò dopo), presi da cassata, per interpretare qualunque file in una maniera che sia comprensibile a cassata od agli shader.
Questo secondo tipo di plugin è interessante, perché tramite questo è possibile aggiungere tipi di immagini non supportate (ad esempio una png sarà letta tramite un plugin, per dire), oppure interpretare shader scritti in qualunque linguaggio si voglia (purché un plugin sia in grado di tradurlo in un unico linguaggio compreso da cassata) e via dicendo.

Altri componenti, già abbondantemente citato, sono gli shader. Gli shader sono dei componenti fondamentali, che dicono come renderizzare qualcosa, ma il loro ruolo preciso sarà chiaro solo più avanti nel post.

Quindi ci sono i front end. Ogni modellatore potrà avere un suo front end (o più di uno) per poter integrare cassata direttamente all'interno del modellatore stesso. In più c'è un front end ufficiale, sganciato da altri modellatori, meringa (che tralaltro è il progetto più avanti dell'insieme di progetti cassata). Tramite i front end si usa cassata, che ricordo che rimane in background, nascosto all'utente. Ovviamente si può accedere con più front end contemporaneamente a cassata, perciò non è necessario che ognuno di questi possieda ogni caratteristica immaginabile, poiché è sempre possibile avviarne un altro se serve.

Poi ci sono i file di scena. Questi non fanno altro che passare parametri agli shader, crearne istanze e definire parametri per ogni pass (cos'è un pass sarà più chiaro dopo).
Una scena può includere altre scene, al più filtrate coi plugin precedenti. Solo la prima scena non può essere filtrata (e questa è l'unica eccezione che dicevo prima).
È importante notare che in questo modo è possibile scrivere front end che in maniera completamente trasparente passino scene di un renderer a cassata. Questa pratica è possibile ma in genere non raccomandabile, perché probabilmente converrebbe utilizzare l'altro renderer, che con ottime probabilità avrebbe prestazioni migliori di cassata e non richiederebbe del lavoro aggiuntivo per scrivere front end che traducano le scene ed eventualmente plugin o shader apposta. In alcuni casi comunque può essere conveniente.

Quindi ci sono tutti i dati. I dati vengono visti come shader da altri shader, quando filtrati dai vari plugin, per cui non si è limitati a nessun tipo. È anche possibile leggere suoni, filmati, immagini vettoriali, testo o qualunque altra cosa venga in mente. L'unica richiesta è avere plugin adatti a leggere il file in questione.

Da questo primo riepilogo è possibile già cogliere una sfumatura della flessibilità di cassata, che però faccio notare, come si può notare da quello che ho già datto, non fa molto. Offre solo la possibilità di estendersi. Alcuni plugin o shader saranno ufficiali, ma molte cose non sono fatte direttamente dal progetto ufficiale. Possono invece essere estese da altri utenti.
A tal proposito nascono due esigenze. La prima, più complessa, è argomento di discussione più avanti nel post, e riguarda la compatibilità tra le varie cose scritte. Sarebbe spiacevole se più utenti scrivessero cose diverse e poi non si potessero usare nello stesso progetto.

La seconda è più semplice da risolvere. C'è il rischio che certi plugin o shader non vengano più mantenuti, oppure rimangano sconosciuti.
Quello che mi piacerebbe fare è prendere quei plugin o shader che abbiano una certa licenza e che siano interessanti, e mantenerli, come viene fatto col linux kernel coi moduli, all'interno dei progetti ufficiali. L'autore potrebbe sempre continuare a mantenere il suo lavoro, ma nel momento in cui mancasse la sua partecipazione un altro utente potrebbe occuparsene, ed inoltre il suo lavoro sarebbe visibile a tutti e già presente quando s'installa cassata.

Ora passo a spiegare come funziona il core.
Un buon modo per approcciarsi al suo funzionamento è vedere come viene renderizzata una scena. Per spiegare questo però prima ho bisogno di spiegare cos'è un pass almeno brevemente, la spiegazione più completa verrà data quando descriverò le scene.
Un pass è una variante di un rendering. Potrebbe avere una qualità diversa, un oggetto in meno, qualunque cosa.

Per prima cosa un front end crea una scena. Quindi passa il file di scena e tutte le informazioni su dove trovare tutti gli altri file utili a cassata, che lo analizza e ritorna eventuali errori.
Successivamente il front end dice di renderizzare un dato pass. Cassata apre un thread e comincia a definire tutte le relazioni tra le sottoscene (che saranno più chiare in seguito) e gli shader. Compila tutti gli shader, quindi mette in esecuzione quello o quelli che servono per ricavare la scena. Quando viene fatta la richiesta di qualche dato (ad esempio l'immagine finale) da parte del front end invia il dato, dopo averlo filtrato col plugin apposito.
Ha anche il ruolo di sincronizzare i thread, ed i processi nel caso del rendering in rete.
Inoltre fornisce una libreria completa di funzionalità utili al rendering agli shader.

Una particolarità molto interessante del core è che utilizza un terzo tipo di plugin, nascosto. Questo renderizza ogni sottoscena, ma utilizzando tipi differenti a seconda del caso e della qualità richiesta, non scendendo così a compromessi ne in velocità ne in qualità (facendo così scegliere all'utente).

Passo a descrivere gli shader. Come si è visto, il core non renderizza alla fin fine nulla, direttamente. Tutto il compito è lasciato agli shader.
Gli shader sono probabilmente la parte più complessa ed articolata di cassata, ma grazie agli elementi presenti su core e plugin il compito di scrivere uno shader è parecchio semplificato.

Gli shader sono dei programmi, spesso di piccola dimensione. Una cosa che li contraddistingue è quella di rimanere in esecuzione. Altri shader, o cassata stesso, possono eseguire determinate funzioni sullo shader.
Ogni shader ha variabili con varie visibilità: a livello di funzione, thread, processo, istanza. Potrebbero introdursi altre visibilità a seconda dell'esigenza. Comunque è anche importante evitare di scrivere sulle variabili con visibilità d'istanza perché molto lente da sincronizzare in rete. Ancora non ho bene in mente come superare il problema di prestazioni in proposito, ma fortunatamente è abbastanza raro utilizzarle.
La parallelizzazione è gestita a livello di shader, ma a livello molto alto. Ad esempio potrebbero esserci delle funzioni per lanciare ed integrare raggi, ed i raggi lanciati vengono automaticamente parallelizzati.
Va detto che scrivere uno shader risulta in genere semplicissimo, perché il core ed eventualmente i plugin offrono funzionalità di livello molto alto. Ad esempio tutte le strutture di accelerazione geometrica non sono fatte tramite shader.

L'usare shader può sembrare un notevole rallentamento. Tuttavia non è così. Intanto gli shader vengono compilati da un JIT, inoltre vengono ottimizzati per la CPU sul quale gireranno (sarebbe itneressante riuscire anche a fare qualcosa su GPU, ma non ho ancora studiato bene l'argomento). Inoltre è possibile compiere ottimizzazioni per scena. Effettivamente gli shader possono essere più lenti che senza, ma potrebbero persino essere più veloci.

Gli shader sono studiati per risultare modulari, e potersi combinare in vari modi. Ad esempio si potrebbero avere shader che rappresentano una geometria, una camera, un metodo per renderizzare la scena e tanto altro.
Rimane quindi importante, come accennato prima, fare in modo che gli shader possano lavorare correttamente assieme. È importantissimo quindi, in seguito, scrivere degli standard che non è obbligatorio seguire, ma che è caldamente raccomandato per poter collaborare con gli altri shader.
Faccio notare che facendo in questo modo è molto facile ridefinire metodi di rendering e quant'altro, e difatti cassata, sebbene sia orientato all'unbias non è unbias. Non solo almeno. :)

Vanno ancora descritti gli algoritmi utilizzati nel core, cosa che verrà fatta più avanti nel post.

Ora descrivo le scene. Come ho detto prima una scena è davvero semplice. Per capire com'è fatta però bisogna spiegare qualche concetto.
Ogni scena contiene delle sottoscene. Queste sottoscene sono semplicemente delle parti che possono venire calcolate senza condividere la stessa memoria. Possono fornire risultati indipendenti, ma anche che possono servire ad altre sottoscene. In questo proposito esistono due modi di comunicare tra le sottoscene. Uno è quello di produrre tutto il risultato, e solo dopo passarlo alle sottoscene a cui serve. L'altro è quello di produrre dati mano a mano quando servono e passarli tra le varie sottoscene.
Un esempio di utilizzo di questo secondo metodo è ad esempio utilizzare due scene, una che renderizza una stanza, l'altra che renderizza un'altra stanza con un televisore che mostra la prima stanza, il tutto rimanendo unbias. Tralaltro le scene possono avere dipendenze circolari, così ad esempio, nella scena di prima, entrambe le stanze hanno un televisore che mostra l'altra stanza, od ad esempio se stessa.

Le scene inoltre definiscono i parametri passati ad uno shader. Possono venire passati anche altri shader, come parametri, il che li rende tutti legati tra di loro.
Un altro modo di passare parametri agli shader è tramite i pass. Un pass non è altro che un profilo che dice quali scene renderizzare, i filtri da utilizzare per ritornare i vari dati (quindi qua per esempio si sceglie che tipo di immagine utilizzare) ed eventuali variabili da passare ad i vari shader per personalizzarli.

Detto questo passiamo a vedere quali sono gli algoritmi utilizzati all'interno di cassata. Va detto che questa lista è davvero incompleta, e moltissimi algoritmi sicuramente verranno aggiunti, specialmente per prestazioni migliori.

Innanzitutto cassata nasce come unbias, e rimane tale quando possibile, a meno di non fornire la scelta. Ovvero quando è possibile fornire una tecnica unbias per risolvere un problema viene fornita, e poi, se presente, si può pensare di fornire anche tecniche bias.
Detto questo non può mancare la presenza di integratori montecarlo. Vista la somiglianza tra integratori montecarlo e quasi-montecarlo si potranno usare entrambi. Questi sono onnipresenti. Sebbene inoltre non sia indispensabile, e si possano usare anche rendering basati su patch, è ovviamente fondamentale fornire tecniche di ray tracing. In particolare probabilmente le tecniche preferite saranno quelle unbias bidirezionali, possibilmente utilizzando tutte le path intermedie e riutilizzando tutte le path che si possono riutilizzare. Un'idea potrebbe essere MLT, ma sono fiducioso che si possa fare altrettanto con tecniche meno determinate da un singolo percorso importante della luce.

Un'altra tecnica importante è l'uso dell'aritmetica affine. Questa tecnica è utilizzata specialmente per il displacement, ma viene utilizzata anche per molti altri compiti. Permettendo di trovare gli errori massimi compiuti nei calcoli è facile ridurli fino ad una soglia scelta dall'utente. Ad esempio per il displacement si potrebbe utilizzare inizialmente un intervallo infinito, trovando il massimo displacement possibile. Quindi lo si dividerebbe sempre di più in modo da ottenere una precisione sempre maggiore di dove andrà un dato punto. Infine, quando si sa che il punto sarebbe sicuramente all'interno di una sfera estremamente piccola, lo si prende per valido. È una tecnica estremamente precisa e molto veloce, certo però non veloce come modificare le geometrie, ma comunque risulta una tecnica che non da errori con geometrie poco fitte o problemi simili.

Un problema che mi ha assillato per molto tempo era come mettere nella zuppa delle tecniche pure qualcosa che permetta di utilizzare materiali non lineari. Questo perché apparte questo particolare non c'è scena che cassata, secondo i termini detti prima, non può renderizzare con la qualità voluta. La soluzione l'ho trovata nel rendering basato su patch. Si fanno diversi rendering uno di seguito all'altro convergendo alla soluzione. Non ho una dimostrazione formale (che tralaltro sarebbe anche complicata), ma sono arrivato alla conclusione che facendo le cose in un certo modo (che non spiego qua perché ancora si stanno affinando) sia possibile convergere sempre ad una soluzione se questa esiste, e guidare, pure, ad una specifica soluzione, qual'ora ne esistano diverse. Questo però richiede un buon modo per produrre patch delle geometrie. Questo modo non è complicato, visto che si possono riutilizzare, ad esempio, le coordinate uv, e tralaltro può essere riutilizzata questa parte di cassata per fare ogni tipo di bake su texture.

Un'altra cosa che mi piacerebbe includere in cassata, e che già in gran parte si più fare con gli strumenti di cui ho parlato nel post è l'inserimento di simulatori, fisici e non, ed in particolare tecniche di auralizzazione. Non sono cose assurde da inserire ma richiedono un bel po' di lavoro sugli shader, e quindi non sono minimamente una priorità, tuttavia sono previsti.

Ovviamente tutte le tecniche sono condite ovunque con caching, e dove possibile vorrei aggiungere anche memoizzazione.

Un'altra cosa sulla quale lavorare (che volendo si può fare anche con quello che già si ha, ma va migliorata) è poter ricominciare il rendering da un punto dove si era arrivati, o progressivamente migliorare un rendering, od ancora unire più pass senza troppi interventi da parte del front end.
Sarebbe carina anche una certa forma d'interattività da parte del front end, in modo che possa cambiare un certo numero di cose in corso.

Detto questo avrò tralasciato molte cose, ma dovrei aver dato un quadro più o meno possibile di cos'è cassata e come funziona. Se qualcuno avrà voglia di leggere tutto e commenterà sarà il benvenuto, specialmente se ha qualche idea in mente. Faccio presente comunque che cassata è tanto flessibile da poterlo davvero considerare il più flessibile tra i renderer che conosco, il suo difetto principale sarà probabilmente prestazionale, ma architetturalmente è studiato per potersi ottimizzare enormemente, così nel tempo potrà diventare anche più veloce di molti renderer che mirano alla velocità più che alla flessibilità. Questo certamente richiederà tempo.

Nuove caratteristiche e ritorno

Urca, nessun post per più di 2 mesi. Tra impegni e poca voglia mi sono preso una vacanza (anche se in questo periodo ho lavorato pure a cassata, ma non più di una 20ina di giorni :) ).
Intanto benritrovati, se mai ci fosse qualcuno, e passiamo subito alle novità.

Cassata è un renderer davvero piccolo, ma estensibile a piacimento, e credo che sia questa la sua forza.Terminare cassata in se è solo metà del lavoro, visto che poi senza gli shader non saprebbe fare proprio nulla. Tuttavia terminare cassata sarebbe già un ottimo risultato, visto che una gran parte del lavoro sarebbe compiuta.
Sebbene la progettazione di cassata sia ancora grezza, con molte cose da risistemare, e piuttosto incompleta, posso dire che il grosso è stato fatto, terminando in questi giorni, ed ho un'idea abbastanza precisa di cosa sarà. Altro discorso sono gli shader ed i plugin, la cui progettazione non è neanche stata cominciata, ma Roma non si è fatta in un giorno :)

Altra buona notizia è che ho finalmente superato l'ultimo limite che avevo! Ora è possibile fare rendering con materiali non lineari (almeno sulla carta). Fatto questo, cassata è, almeno per le mie modeste conoscienze, il renderer più flessibile sulla piazza. Da quello che so (ma liberissimi di smentirmi) non c'è una sola cosa tra i renderer fotorealistici che non sia in grado di fare (fatta eccezione per certe tecniche di rendering scientifico, ma anche la è messo molto, molto bene), e, pur non essendo il suo scopo, anche come renderer non fotorealistico è piazzato piuttosto bene, permettendo sia effetti di shading particolari, come il toon, sia il controllo totale dell'illuminazione, sia effetti di postprocesso, come ad esempio lati sulle figure, effetti bozzetto, sfocatura delle immagini o magari anche effetto acquarello e tante altre cose, più molte altre caratteristiche che ora non sto a dire, e dopotutto non saprei neanche cosa dire, visto che essendo estensibile chi vuole può aggiungere altro (certo con qualche limite, ma neanche così tanti) :)
Faccio notare che il renderer non è affatto studiato per rendering non fotorealistici, e che questa applicazione deriva solo dalla flessibilità enorme presente in cassata, e che è stata un motore importante per tutto questo tempo.

Altra notizia, valuterò bene se è il caso di usare la GPL3 o superiori invece di (com'è attualmente) la GPL 2 o superiori, ora che sia le Qt che altre librerie che uso (od userò) sono anche GPL3.

Come codice non ho fatto praticamente nulla in questo periodo, ma vedrò se nei prossimi giorni riuscirò a fare qualcosa.

Beh, credo di aver esposto tutte le novità importanti, alla prossima :)

Che affinità hai con cassata?

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

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:

• 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 :)

Wow, che forme!

Mi sono preso una giornata sabatica per cercare informazioni sulle geometrie, ed ho fatto davvero delle bellissime scoperte.
La prima, prima su tutte, è quella di poter realizzare le superfici di suddivisione con suddivisione infinita! Il che vuol dire massima correttezza nel rendering, e la tecnica non è neanche particolarmente lenta, anzi! :D
La tecnica si può applicare sicuramente alle catmull-clark ed alle loop, penso anche alle doo-sabin ma non sono ancora sicuro.

Molte delle tecniche che vado ad esporre fra poco sono molto complesse, a livello matematico in genere, ma a volte anche a livello implementativo. Quindi non verranno implementate a breve. Però sono tutte previste per delle versioni future di cassata, c'è solo da aspettare :)

Ecco le cose che verranno implementate (e che sono sicuramente tecnicamente possibili):

• Shader per le geometrie. Questo permette di fare geometrie personalizzate, ad esempio frattali, ma qualunque cosa venga in mente va benissimo.
• Geometrie infinite. Questo vuol dire semplicemente che si possono ad esempio fare dei piani (cosa utile quando si fa magari qualche scena di prova e si han problemi con l'orizonte :) ).
• Mesh, NURBS e superfici di suddivisione catmull-clark, loop e doo-sabin. Le prime 2 a scelta con suddivisione "tradizionale" od infinita (quindi senza più problemi di suddivisione insufficente od altro). Per l'ultima solo la prima soluzione. Tutte le superfici di suddivisione supporteranno anche parametri speciali come piegature ed altre cose simili.
  
• Displacement, sia tramite texture procedurali che immagini.
• CSG, Constructive Solid Geometry, ovvero le operazioni booleane, quindi intersezioni, unioni e differenze (da quel che ho capito sono davvero utili a livello di CAD anche nel rendering, a seconda di come si affronta il rendering). È ancora da decidere come combinare questa tecnica con l'UV-Mapping.
  

Ecco invece quello che mi piacerebbe implementare ma che non sono sicuro sia possibile, per problemi tecnici:

• Doo-sabin suddivise all'infinito come le altre superfici di suddivisione. Sono quasi convinto che si possa fare, ma non ne sono sicuro ancora al 100%.
• Displacement con suddivisioni infinite, quindi un displacement perfetto, senza alcun problema di risoluzione, ne rallentamenti all'aumentare di questa, e via dicendo. Purtroppo da questo punto di vista sono abbastanza scettico sulla sua realizzabilità, ma comunque non si sa mai.
• Applicazione perfetta delle texture su superfici di suddivisione all'infinito. Quest'ultimo punto non deve trarre in inganno perché comunque l'applicazione delle texture sulle superfici di suddivisione, col metodo detto prima, è ottima. Solo che non è proprio perfetta. Sono abbastanza convinto che si possa risolvere, ma non sicuro come per il primo punto di questa lista.

Invece qua c'è una lista delle cose da valutare per l'inserimento (l'unico scopo che avrebbero è ottimizzare il rendering, poiché sono già realizzabili con le strutture viste prima):

• Punti, curve ed altre cose di questo genere, che normalmente non verrebbero visualizzate perché sono adimensionali o monodimensionali, ma che poi verrebbero "ispessite". Possono essere utili per le particelle, per il pelo e per altre tecniche simili. Alternative possibili sono le nurbs o le superfici di suddivisione, ma sono abbastanza lente, quindi avere un oggetto appositamente progettato per queste cose, che permetta di velocizzare il rendering, è senza dubbio preferibile. Faccio comunque notare che la maggior parte delle cose fatte con le particelle possono essere simulate molto meglio con dei materiali appositi. Non è così nel caso del pelo, ma per esempio per fuoco o fumo probabilmente conviene fare un materiale apposito (ma dipende comunque tutto dai casi). È probabile che verranno introdotte.
• Geometrie più semplici come sfere, coni, cilindri, cuboidi ed altre cose simili. Sono tutte estremamente facili da rappresentarsi con le nurbs, ma è da decidere se vale davvero la pena di fare una struttura ottimizzata per gestirle. Non ho idea di quanto siano importanti per alcuni modellatori che ne fanno uso, o per un qualche modo di "fare grafica", se saranno importanti verranno implementate.
  

Lo so che sono una mole enorme di roba, ma non vuol dire che si debbano realizzare tutte ora, anzi. Probabilmente prima che si realizzino tutte passeranno almeno 2-3 anni. Questo post era solo per dire cosa aspettarsi sulle geometrie nei prossimi anni con cassata :)

Il primo formato non si scorda mai

In attesa di avere la nuova estensione ho cominciato a progettare ciò che ci starà dentro il file.
La progettazione è durata poco, un'oretta, anche se c'è da dire che ci penso già da molto, ma proprio perché è durata poco, unito al fatto che ancora molte parti di cassata vanno scritte, la rende solo ed esclusivamente un riferimento, probabilmente cambierà molto nel futuro.
Ciononostante ho fatto in modo che fosse la più corretta possibile.

Ho scritto un semplice file di esempio che illustra ciò che ho pensato, ecco il link.

Nel punto dove c'è ??? non c'è una bizzarra sintassi, ma ancora quella zona è "oscura" :D .
Per il resto, per chi fosse già pratico di XML, noterà che c'è qualche bizzarro uso dei tag, in particolare quell'in invece dei tag diretti, ed un lettore attento noterà anche le use.
Questo è per il particolare meccanismo di uso degli shader che stò progettando per cassata, che non ho mai esposto qui perché ancora troppo immaturo.
Molte cose di quelle che si vedono nel file si riferiscono a cose future, perciò se volete sapere qualcosa chiedete pure.

Quanto cambierà del file che potete vedere non lo so proprio. Penso abbastanza, ma è difficile fare stime, chi vivrà vedrà :)

Per il resto rimanete sintonizzati per altre succulente novità :D

Una prova di creatività

Dico subito che i lavori stanno andando benissimo e lisci come l'olio.
Ora però ho bisogno della vostra creatività :)
Ho bisogno di trovare una bella estensione per i file di descrizione della scena.

Ecco i requisiti che mi piacerebbe avesse:

• estensione di 3 caratteri
• il nome deve potersi leggere come un dolce detto in italiano. La lettura può non essere letterale ma artistica (ad esempio non so quanti di voi sanno che png si legge ping :) ),
• il nome è un acronimo in inglese che descrive cos'è il file,
• il nome contiene la lettera C, che nell'acronimo va espansa con "Cassata".

Proponete quello che volete, va bene pure che non rispetti qualcuno dei punti, ma più ne rispetta meglio è. Alla fine sceglierò la più bella, se ce n'è qualcuna che mi convince.

Per dare un'idea di cosa si potrebbe fare, a me è venuto in mente crd, cassata rendering definition, che si legge cardo, e non va bene sia perché la lettura è troppo artificiosa (ok artistica ma qui si esaggera) sia perché il cardo non è un dolce :)

Ok, allegate tutte le soluzioni che volete allora come commenti, abbondate pure se ne avete tante, se sceglierò una delle vostre estensioni, a meno che non vogliate il contrario (magari per ragioni di privacy o che so io) potete comunicarmi il vostro nome e cognome (anche via email se preferite), che provvederò a metterli nel README indicando che quello è l'autore del nome dell'estensione :)
Se preferite darmi il nome e cognome solo nel caso in cui il vostro nome viene scelto mi sta bene pure, basta che me lo comunichiate e mi diate un recapito per contattarvi (se non lo possiedo già). Non mi approprierò di nessun nome che avete scelto a meno che non scriviate PER ISCRITTO che volete rimanere anonimi nel commento. Mi raccomando, sennò mi obbligate a scartare la vostra estensione a priori :)

Per il resto, inventate, inventate :)

Si ricomincia!

Finalmente ricomincio il lavoro :)
Dico subito che non ho scritto ancora codice, ma mi sono messo a progettare un po' di cose, e poiché sono sempre per uno sviluppo aperto vi illustro subito le novità.

La roadmap stà cambiando notevolmente, non è ancora pronta la nuova quindi non la pubblico, ma sappiate che la vecchia roadmap sta subbendo molti cambiamenti.
Per ora mi limito a dire cosa cambia nella 0.1.

Innanzitutto fermo alcune cose (ovviamente solo momentaneamente) che erano previste per la 0.1, in particolare il rendering distribuito, che verrà presumibilmente reinserito prima dell'uscita della 1.0, ma non ora.
Questo nonostante sia una delle cose più avanti col progetto, ed il motivo è che la complessità aggiunta è molto grande, ed aggiungerla ora è davvero molto pesante.
Il codice comunque rimane, in attesa di essere ripreso in seguito.

Un'altra cosa che cambia è il supporto dei job, che si modifica un po'.
Per spiegare come funzionano i job è necessario spiegare come funziona il processo di rendering e come viene suddiviso.

Innanzitutto abbiamo le scene. Ogni scena è un qualcosa che vogliamo renderizzare. Potrebbe essere un'immagine, un filmato e quant'altro.
Poiché per ora è prematuro cominciare a lavorare su cose come i filmati mi sono limitato al rendering di immagini, e di queste parlerò, più avanti potrò facilmente estendere il tutto in modo che funzioni anche coi filmati :)
Inizialmente cassata renderizzerà solo una scena alla volta, cosa che ovviamente cambierà.

Ogni scena è composta da una serie di layer. I layer sono rendering da fare singolarmente (in realtà la faccenda non sarà sempre così semplice, ho già in mente qualche chicca molto succulenta, ma prima di parlarne voglio avere le idee più chiare).
I layer servono per fare compositing, regolare l'intensità luminosa quando il rendering è finito e quant'altro.
Inizialmente cassata renderizzerà solo un layer per scena.
Ogni layer può avere un tipo diverso usato internamente (leggi il mio vecchio post per capire di che parlo).

Ogni layer è composto da pass. I pass inizialmente saranno virtualmente identici tra di loro, ma in futuro potrebbero essere realizzati con tecniche diverse (magari anche scelte dinamicamente per aumentare la velocità del rendering il più possibile).
Ogni pass sarà un rendering corretto, ed unendo più pass si diminuirà progressivamente il rumore. L'importanza dei pass deriva principalmente da 2 motivi:

• L'utente decide di fare un pass ad una data qualità, viene un rendering e decide che quel rendering va bene, gli piace, ma è troppo rumoroso. Esegue quindi altri pass (magari uno solo ad alta qualità) per ridurre il rumore. Così facendo è possibile sia migliorare la qualità di un rendering, sia riprendere un rendering cominciato precedentemente (ovviamente solo tra un pass e l'altro), sia magari generare un'anteprima in pochi minuti e poi decidere che va bene e migliorarne la qualità.
• Si potrebbero fare tanti pass con il rendering distribuito, e poi unirli tutti assieme in un secondo momento. Questo semplifica molto l'architettura distribuita ed ha buone prestazioni, ma tuttavia non è detto che siano le migliori possibili e poi bisognerà analizzare meglio la situazione.

Infine ogni pass viene ritagliato in job. Ogni job inizialmente si occuperà di renderizzare alcuni pixel dell'immagine. In futuro questi schemi potrebbero cambiare, a seconda dell'algoritmo utilizzato per la generazione del pass, ma in ogni caso un job si occupa di creare un frammento di pass.
L'importanza di un job deriva dal fatto che ogni job è eseguito su un thread diverso, e quindi è possibile utilizzare più core o CPU o quant'altro, e che ogni job può essere virtualmente eseguito su un altro computer, e quindi dare un'altra possibilità di rendering distribuito.

Detto questo vi lascio, se riesco scriverò del codice già sabato (domani, o meglio oggi visto l'orario, avrò degli impegni e non penso che riuscirò a fare nulla, ma non si sa mai :D ).

Pausa ed interni

Beh, per prima cosa, come avevo detto qualche giorno fa sul forum di blender.it, sono in pausa. Quando riprenderò mi farò sentire con le novità.
In attesa della fine della pausa ho preparato un grafico che descrive l'architettura interna di Cassata, ve lo mostro e poi ne commento ogni parte:


Consiglio di cliccarci su per ottenere l'ingrandimento.
Per prima cosa descrivo il funzionamento di Cassata globale, poi fornirò informazioni su ogni blocco e sullo stato attuale.

L'interfaccia (che comunica con l'esterno sia con altri cassata per il rendering distribuito, sia con il modeler o comunque il front end) dice che compiti svolgere al commander.
Questo, capito qual'è il suo compito, comanda di nuovo l'interfaccia (per comandare altri cassata in rendering distribuito) ed instanzia diversi job. Ogni job è eseguito su un thread diverso.
Il job si occupa di renderizzare una parte dell'immagine. Una volta partito tutto i job comunicheranno con la camera, e sarà lei ad invocare l'integratore montecarlo e poi scrivere sull'immagine.

Ora andiamo blocco per blocco:

• Interface: S'interfaccia coi front end e con altri cassata.
• Lo stato attuale è già buono, anche se necessita di parecchie modifiche. Comunque è funzionante.
• Commander: Decide come dividere il lavoro e che lavori fare.
• Attualmente esiste, ma è davvero embrionale.
• Configuration Engine: Legge il file di configurazione di Cassata e decide come influenzare le procedure di rendering e qualunque altra cosa.
• Attualmente esiste e funziona correttamente, ma saranno da aggiungersi opzioni mano a mano che serviranno.
  
• Job 1... n: Eseguono un lavoro.
• Esistono, ma sono appena accennati e l'interfaccia è totalmente da rivedere.
• Scene Engine: Gestisce l'intera scena, compreso il contenuto.
• Praticamente non esiste.
• Camera: Gestisce la camera.
• Nulla ancora fatto.
• Image: Dove viene generata l'immagine, il filmato o quant'altro.
• Nulla ancora fatto.
  
• Montecarlo Integrator: Esegue l'integrazione montecarlo. La magia dell'unbias avviene qui.
• Nulla ancora fatto.
• Shader Engine: Interpreta gli shader e li esegue.
• Nulla ancora fatto.
• Mesh 1... n: In realtà non solo mesh, ma qualunque altro oggetto. Fornisce la geometria del oggetto della scena.
• Non ancora cominciato.
  
• Geometry Engine: Fornisce la geometria della scena.
• Lo si vede agganciato allo shader engine perché in futuro mi piacerebbe che lo fosse, ma probabilmente questo collegamento avverrà dopo Cassata 1.0.
• Non ancora cominciato.
• Material Engine: Gestisce tutti i materiali. Viene interrogato dal geometry engine quando necessario.
• Non ancora cominciato.
• Material 1... n: I materiali della scena. Come La camera (ed in futuro anche le geometrie) viene comandato da shader.
• Non ancora cominciato.

Come vedete il lavoro da fare è tanto e non garantisco che l'architettura interna non cambierà.
Ma andiamo a vedere cosa non c'è nel diagramma.
Moltissimi collegamenti non sono esattamente così o non sono presentati, per semplicità e pulizia del disegno. Ho descritto ad alto livello il funzionamento del renderer, senza scendere eccessivamente nei dettagli, e quindi volutamente ho deciso di tralasciare i dettagli nella scena.
Oltre a questo ho evitato di mettere l'architettura a plugin e l'architettura di caching.
La prima perché è pressocché ovunque ed il disegno sarebbe diventato troppo pesante.
La seconda è pure quasi ovunque ed ancora non progettata, per cui non sapevo neanche cosa mettere.
Mancano anche tutte le gestioni dei layer, soprattutto perché per ora la progettazione è troppo immatura.
Mancano anche molti componenti minori, che in un insieme ad alto livello come questo non erano necessari.

Per il resto non c'è altro da dire, alla prossima :)

Gli sviluppi degli sviluppi dello 0.1

Attualmente mi trovo in un continuo alternarsi di fasi di progettazione e di scrittura del codice, è una fase piuttosto complessa perché è il cuore di tutto cassata 0.1.
Sono soddisfatto pienamente del lavoro svolto fino ad ora ma sono ancora all'inizio e fin quando non raggiungerò la versione 0.1 credo che cassata sarà un casino.
Il motivo è assai semplice: cassata 0.1 contiene, in piccola parte, quasi tutti i punti della roadmap e non solo, anche molto altro. In pratica la maggior parte dei punti della roadmap non saranno un'innovazione completa, ma solo un profondo miglioramento.
Questo fa capire qual'è la complessità della versione che sto sviluppando ora.

Quello che ho fatto fino ad ora a livello di codice è solo l'abbozzo di tantissime tecnologie che per ora non servono a nulla ma che quando unite porteranno a tutta la parte più complessa della versione attuale. Tutto il codice è stato testato ad eccezione dell'architettura plug in, i cui test arriveranno quando caricherò questi plugin (fra parecchio penso).
Quello che è stato invece fatto a livello di progettazione è molto di più.
Ho riprogettato buona parte della rete e dell'interfaccia DBus, abbozzato le politiche dei job, diversi dettagli sulla lettura e sulla composizione di una scena.
Ho anche approfondito alcune tecniche di accelerazione del bidirectional path tracing.

A proposito della roadmap ci sono stati enormi cambiamenti fino ad ora, e molti ce ne saranno, rispetto alla vecchia. Penso che cassata 1.0 sarà più ricco di innovazioni rispetto a quelle scritte, anche se questo richiederà del tempo in più.
Pubblicherò la nuova roadmap quando printa, ma va detto che fondamentalmente non ci sono cambiamenti "vitali" con la vecchia, ma tante piccole cose che però possono fare la differenza.

Purtroppo la 0.1 è ancora piuttosto lontana (ricordo che la 0.1 sarà un renderer a tutti gli effetti, solo scarno e lento), tuttavia i progressi fatti sono notevoli.

Francamente la complessità di alcune parti di questa versione mi spaventano e scoraggiano un po', ma visti i successi che ho avuto ed il fatto di avere tutto sommato le idee relativamente chiare mi confortano. In ogni caso mai come ora credo di aver bisogno del vostro tifo ;)

Arrivederci alle prossime innovazioni, e mi raccomando, fate il tifo ;)