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 :)
lunedì 29 ottobre 2007
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):
Ecco invece quello che mi piacerebbe implementare ma che non sono sicuro sia possibile, per problemi tecnici:
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):
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 :)
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 :)
mercoledì 24 ottobre 2007
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
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
martedì 23 ottobre 2007
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:
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 :)
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 :)
venerdì 19 ottobre 2007
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:
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 ).
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 ).
giovedì 4 ottobre 2007
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:
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 :)
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 :)
giovedì 20 settembre 2007
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 ;)
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 ;)
martedì 11 settembre 2007
Altre novità sulla progettazione
La progettazione del nuovo pezzo di cassata è quasi terminata, e presto ricomincerò a scrivere codice.
In attesa di quest'evento descrivo altre caratteristiche di cassata degne di nota, che verranno (in parte o completamente) introdotte proprio con la nuova progettazione.
Per prima cosa la precisione (questa credo che sia l'innovazione più grande, poiché non conosco altri renderer che fanno una cosa simile).
Ogni layer (vedremo cos'è un layer tra qualche riga) può essere renderizzato a varie precisioni. L'aumento di precisione è necessario all'aumentare della complessità del rendering, ma aumentare la precisione porta un costo, il tempo di rendering. Quindi conviene mantenere la precisione la più bassa possibile per avere tempi di rendering bassi, ma non troppo bassa per non commettere errori nel rendering.
Siccome la scelta della precisione ottimale dipende dalla complessità della scena il sistema da me scelto (scelta da parte dell'utente) credo che sia il più affidabile.
Ecco le precisioni che ci saranno sicuramente (ma altre potrebbero aggiungersi):
Un'altra cosa interessante sono i layer. Ogni layer è una scena che viene renderizzata singolarmente. In seguito (probabilmente dopo cassata 1.0) i layer verranno usati per postprocesso. In attesa di ciò però c'è già un buon modo per utilizzarli. Ispirandomi spudoratamente a Simulens™ (un componente di Maxwell Render™) è possibile cambiare, dopo aver renderizzato una scena, l'intensità di ogni gruppo di luci (ed un gruppo può contenere anche solo una luce). In questo modo è possibile, senza renderizzare alcunché, manipolare in buona quantità l'illuminazione. Non si possono quindi spostare le luci o cambiare di colore, ma si può tranquillamente cambiarne l'intensità a piacere :)
Tutti gli oggetti sono condivisi tra i vari layer, così da non doverli ripetere di volta in volta.
Un altro concetto importante sono i gruppi. Ogni oggetto potrà appartenere a più gruppi, e "vedrà" solo gli oggetti che appartengono ad uno o più gruppi scelti a piacere. La camera ha pure un insieme di gruppi che vede.
Questo permette di fare un primo (ma non sarà comunque l'unico) approccio al rendering non fotorealistico, ed un primo avvicinamento ai fotoinserimenti, perché questa tecnica permette di fare oggetti senza ombra, oggetti che proiettano solo ombre, oggetti che vengono riflessi ma non visti, lamp che fanno luce ma non esistono nella scena e via dicendo. È possibile pensare a qualunque combinazione di effetti, in questo senso. Non è difficile mostrare che sono tutte possibili.
Queste erano le cose da dire degne di nota. Inutile dire che la progettazione non è stata solo questo, questo anzi è da vedersi come un risultato molto parziale, quando sarà finita riprenderò a scrivere codice :)
In attesa di quest'evento descrivo altre caratteristiche di cassata degne di nota, che verranno (in parte o completamente) introdotte proprio con la nuova progettazione.
Per prima cosa la precisione (questa credo che sia l'innovazione più grande, poiché non conosco altri renderer che fanno una cosa simile).
Ogni layer (vedremo cos'è un layer tra qualche riga) può essere renderizzato a varie precisioni. L'aumento di precisione è necessario all'aumentare della complessità del rendering, ma aumentare la precisione porta un costo, il tempo di rendering. Quindi conviene mantenere la precisione la più bassa possibile per avere tempi di rendering bassi, ma non troppo bassa per non commettere errori nel rendering.
Siccome la scelta della precisione ottimale dipende dalla complessità della scena il sistema da me scelto (scelta da parte dell'utente) credo che sia il più affidabile.
Ecco le precisioni che ci saranno sicuramente (ma altre potrebbero aggiungersi):
- fast <- più veloce possibile mantenendo un minimo di precisione. Utile per scene di complessità bassa e medio/bassa. In molti casi è identico a single precision, ma in caso l'architettura lo permetta può avere una precisione anche più bassa.
- single precision <- viene usato il tipo float. Utile per scene di media complessità.
- double precision <- viene usato il tipo double. Utile per scene di complessità elevata.
- personalizzata <- l'utente sceglie esattamente la precisione voluta. Questo metodo è estremamente più lento dei precedenti ed è pensato solo per precisioni estremamente elevate. Raramente si avrà bisogno di tanta precisione, ma se volete realizzare l'intero sistema solare con dentro la terra le persone, ehi, siete pazzi XD Però potete :D (anche se la quantità di spazio e di tempo necessari mi sa che sono davvero proibitive, quindi insomma, potete in teoria :) )
Un'altra cosa interessante sono i layer. Ogni layer è una scena che viene renderizzata singolarmente. In seguito (probabilmente dopo cassata 1.0) i layer verranno usati per postprocesso. In attesa di ciò però c'è già un buon modo per utilizzarli. Ispirandomi spudoratamente a Simulens™ (un componente di Maxwell Render™) è possibile cambiare, dopo aver renderizzato una scena, l'intensità di ogni gruppo di luci (ed un gruppo può contenere anche solo una luce). In questo modo è possibile, senza renderizzare alcunché, manipolare in buona quantità l'illuminazione. Non si possono quindi spostare le luci o cambiare di colore, ma si può tranquillamente cambiarne l'intensità a piacere :)
Tutti gli oggetti sono condivisi tra i vari layer, così da non doverli ripetere di volta in volta.
Un altro concetto importante sono i gruppi. Ogni oggetto potrà appartenere a più gruppi, e "vedrà" solo gli oggetti che appartengono ad uno o più gruppi scelti a piacere. La camera ha pure un insieme di gruppi che vede.
Questo permette di fare un primo (ma non sarà comunque l'unico) approccio al rendering non fotorealistico, ed un primo avvicinamento ai fotoinserimenti, perché questa tecnica permette di fare oggetti senza ombra, oggetti che proiettano solo ombre, oggetti che vengono riflessi ma non visti, lamp che fanno luce ma non esistono nella scena e via dicendo. È possibile pensare a qualunque combinazione di effetti, in questo senso. Non è difficile mostrare che sono tutte possibili.
Queste erano le cose da dire degne di nota. Inutile dire che la progettazione non è stata solo questo, questo anzi è da vedersi come un risultato molto parziale, quando sarà finita riprenderò a scrivere codice :)
sabato 8 settembre 2007
Primo codice per cassata
Finalmente il primo codice è scritto. Illustro cosa ho fatto fino ad ora.
Sono pronte tutte le classi per la comunicazione tra vari cassata (che comunicano in TCP) e tra un cassata ed un'interfaccia grafica. Tutta l'architettura è piuttosto flessibile ed elegante, sembrerebbe (ma son sempre in agguato) bug priva di bug (è già stata testata adeguatamente) ed il metodo di comunicazione è completamente indipendente da quel che c'è sopra.
Oltre a questo è pronta la classe che comanda tutti i thread di rendering, è già stata abbozzata la classe che serve a gestire un thread di rendering ed esiste già la classe (già funzionante anche se con poche opzioni) che legge (e condiziona già le altre classi) il file di configurazione del renderer.
Come se non bastasse è già stato preparato un test framework (senza test attualmente) e la documentazione del codice generata con doxygen. Il tutto sono poco più di 2.000 linee di codice, attualmente (non male, considerando che ho scritto tutto in 8 giorni).
L'unica scelta che potrebbe far storcere il naso a qualcuno è che ho usato una grossissima dipendenza: le Qt.
Mi rendo conto che una dipendenza così grossa non è bello averla in un demone, però mi semplifica davvero enormemente le cose, ho potuto scrivere quello che ho scritto così velocemente e pressocché senza bug solo grazie a questa e quindi credo che lo scotto da pagare sia tutto sommato poca cosa.
Per il futuro so già per sommi capi su cosa lavorare ma prima di rimettermi sul codice è necessaria una pausa di riflessione e studio, in maniera da sapere esattamente cosa implementare.
Ho già scelto in tal proposito un'altra dipendenza, eigen, per la gestione di vettori e matrici.
A presto allora con ancora altri aggiornamenti :)
Sono pronte tutte le classi per la comunicazione tra vari cassata (che comunicano in TCP) e tra un cassata ed un'interfaccia grafica. Tutta l'architettura è piuttosto flessibile ed elegante, sembrerebbe (ma son sempre in agguato) bug priva di bug (è già stata testata adeguatamente) ed il metodo di comunicazione è completamente indipendente da quel che c'è sopra.
Oltre a questo è pronta la classe che comanda tutti i thread di rendering, è già stata abbozzata la classe che serve a gestire un thread di rendering ed esiste già la classe (già funzionante anche se con poche opzioni) che legge (e condiziona già le altre classi) il file di configurazione del renderer.
Come se non bastasse è già stato preparato un test framework (senza test attualmente) e la documentazione del codice generata con doxygen. Il tutto sono poco più di 2.000 linee di codice, attualmente (non male, considerando che ho scritto tutto in 8 giorni).
L'unica scelta che potrebbe far storcere il naso a qualcuno è che ho usato una grossissima dipendenza: le Qt.
Mi rendo conto che una dipendenza così grossa non è bello averla in un demone, però mi semplifica davvero enormemente le cose, ho potuto scrivere quello che ho scritto così velocemente e pressocché senza bug solo grazie a questa e quindi credo che lo scotto da pagare sia tutto sommato poca cosa.
Per il futuro so già per sommi capi su cosa lavorare ma prima di rimettermi sul codice è necessaria una pausa di riflessione e studio, in maniera da sapere esattamente cosa implementare.
Ho già scelto in tal proposito un'altra dipendenza, eigen, per la gestione di vettori e matrici.
A presto allora con ancora altri aggiornamenti :)
mercoledì 29 agosto 2007
Primi passi verso cassata 0.1
Visto che per ora, essendo in fase di progettazione e di studio, non scrivo codice direttamente per cassata, ho deciso di dare notizie qui degli sviluppi.
Molte delle cose che scrivo sono ancora attualmente in progettazione, quello che scrivo non vuole rispecchiare il risultato finale con cassata, si tratta solo di quello che ho pensato fino ad ora.
Il renderer sarà un demone. Questo si metterà in comunicazione, eventualmente, con altri demoni (tramite TCP?) per eseguire calcolo distribuito. I demoni eseguiranno il rendering separatamente e di tanto in tanto si sincronizzeranno tra di loro.
La sincronizzazione prevede anche il passaggio di comandi, in maniera tale da permettere di comandare a distanza tutta la procedura di rendering.
I singoli demoni vengono controllati tramite dbus, il che permette di integrare perfettamente il renderer nella gui di un modeler. Oltre a questo verrà creata una semplice gui (sempre che comunica tramite dbus) per usare il renderer stand alone.
Ogni demone possiede da 0 a più thread per il rendering. Generalmente si vorranno tanti thread quante sono le CPU (od i core o quant'altro) possedute dal computer che esegue il demone. Tuttavia questo non è detto, si potrebbe ad esempio voler eseguire il demone senza thread, in modo da non compilare in locale, ma inviare semplicemente comandi da inviare alla rete.
Per inquadrare le possibilità di quest'architettura mostro uno scenario tipico in uno studio grafico di grosse dimensioni (ad esempio pixar).
Ci saranno 2 tipologie di computer: quelli dei grafici e quelli che renderizzano. Tutti eseguiranno cassata, ma i computer dei grafici avranno semplicemente un cassata che non renderizza, gli altri renderizzeranno.
Un grafico, a questo punto, vorrà eseguire un rendering. Questo rendering verrà semplicemente inviato ai computer che renderizzano, e (a seconda della configurazione della rete) potrà partire subito il rendering, in parallelo agli altri, oppure accodarsi ed attendere che qualche altro rendering termini. Il grafico vedrebbe la sua opera come se fosse lui stesso a renderizzare, ma sfruttando tutta l'enorme rete che c'è dietro e potendo, intanto, continuare a lavorare senza rallentare il rendering.
Qualunque commento, lo sapete, è ben accetto :)
Molte delle cose che scrivo sono ancora attualmente in progettazione, quello che scrivo non vuole rispecchiare il risultato finale con cassata, si tratta solo di quello che ho pensato fino ad ora.
Il renderer sarà un demone. Questo si metterà in comunicazione, eventualmente, con altri demoni (tramite TCP?) per eseguire calcolo distribuito. I demoni eseguiranno il rendering separatamente e di tanto in tanto si sincronizzeranno tra di loro.
La sincronizzazione prevede anche il passaggio di comandi, in maniera tale da permettere di comandare a distanza tutta la procedura di rendering.
I singoli demoni vengono controllati tramite dbus, il che permette di integrare perfettamente il renderer nella gui di un modeler. Oltre a questo verrà creata una semplice gui (sempre che comunica tramite dbus) per usare il renderer stand alone.
Ogni demone possiede da 0 a più thread per il rendering. Generalmente si vorranno tanti thread quante sono le CPU (od i core o quant'altro) possedute dal computer che esegue il demone. Tuttavia questo non è detto, si potrebbe ad esempio voler eseguire il demone senza thread, in modo da non compilare in locale, ma inviare semplicemente comandi da inviare alla rete.
Per inquadrare le possibilità di quest'architettura mostro uno scenario tipico in uno studio grafico di grosse dimensioni (ad esempio pixar).
Ci saranno 2 tipologie di computer: quelli dei grafici e quelli che renderizzano. Tutti eseguiranno cassata, ma i computer dei grafici avranno semplicemente un cassata che non renderizza, gli altri renderizzeranno.
Un grafico, a questo punto, vorrà eseguire un rendering. Questo rendering verrà semplicemente inviato ai computer che renderizzano, e (a seconda della configurazione della rete) potrà partire subito il rendering, in parallelo agli altri, oppure accodarsi ed attendere che qualche altro rendering termini. Il grafico vedrebbe la sua opera come se fosse lui stesso a renderizzare, ma sfruttando tutta l'enorme rete che c'è dietro e potendo, intanto, continuare a lavorare senza rallentare il rendering.
Qualunque commento, lo sapete, è ben accetto :)
lunedì 27 agosto 2007
Rieccomi :D
Per prima cosa dico subito che si è cambiato obbiettivo.
So che vado contro quello che avevo detto, tuttavia ho deciso di passare direttamente a cassata, e non perdere altro tempo, visto che già ne è passato molto.
Questo però vuol dire che le cose da cambiare e ristrutturare durante la lavorazione di cassata 1.0 saranno tantissime, e sconsiglio vivamente l'uso di cassata in produzione (ovvero in qualcosa che non sia un semplice test) fino all'uscita della prima versione stabile.
Una cosa potrebbe funzionare oggi e non funzionare domani, per cui siete avvertiti.
Detto questo ecco la road map attuale di cassata 1.0. È soggetta a cambiamenti anche pesanti, prendetela solo come linea di massima:
0.1 struttura interna
0.2 interfaccia XML
0.3 acceleratori geometrici
0.4 acceleratori d'integrazione
0.5 shader dei materiali
0.6 acceleratori degli shader
0.7 shader delle texture
0.8 interfaccia libreria
0.9 shader delle camere
0.10 geometrie complesse
1.0 revisione completa e porting
Il numero accanto indica a quale versione si troverà quello che si trova alla sua destra.
Analizziamo punto per punto, per descrivere cosa verrà fatto.
0.1: Verrà definita la struttura interna del renderer, a questo punto dovrei essere in grado di disegnare qualcosa, anche se molto poco. Integratori montecarlo, ray casting e mesh vengono introdotti in questa versione.
0.2: Viene definita l'interfaccia XML, che sebbene sarà soggetta a forti cambiamenti (come tutto) fino alla versione 1.0, sarà il più possibile somigliante alla sua forma finale.
0.3: Vengono sviluppati i primi acceleratori geometrici, per poter renderizzare anche scene geometricamente complesse.
0.4: Vengono introdotti altri integratori montecarlo, ad esempio un'idea potrebbe essere l'introduzione del bidirectional ray tracing. In questa parte vengono comunque sviluppati solo gl'integratori più utili, ed in generale la 1.0 non è detto che sarà prestazionalmente poi così veloce.
0.5: Si definisce l'interfaccia degli shader, quindi gli shader dei materiali (che permettono di definire BSDF ed EDF di ogni materiale). Teoricamente sarebbero rappresentabili anche le texture tramite gli shader dei materiali, ma ho volutamente deciso di separare le 2 cose, perché le texture spesso sono disegnate o generate indipendentemente dal materiale.
0.6: Qua vengono definite alcune strutture atte ad accelerare gli shader, che in ogni caso possono (in caso d'impossibilità di questo punto) essere interpretate. Principalmente questa fase prevederà un JIT. Più avanti si potrebbe pensare a qualche sistema adatto ad usare gli shader tramite schede grafiche.
0.7: A questo punto si generano le texture. Fino a questo punto ci sarà un minimo supporto per le texture (quasi inesistente), ma da questo punto in poi si potranno definire tutte le texture che si vogliono, sia immagini (anche di tipi sconosciuti, basta scrivere lo shader adatto) che procedurali.
0.8: Viene definita un'interfaccia per il renderer. Fino a questo punto l'interfaccia esisteva già, ma è solo qua che viene definita piuttosto bene, e pressocché non soggetta a grossi cambiamenti.
0.9: Viene definito il terzo (ed ultimo per quanto riguarda la versione 1.0) tipo di shader di cassata. Permette di definire camere, anche complesse. Da questo shader dipenderanno effetti comuni, come la profondità di campo o la sfocatura dovuta al movimento (DoF e motion blur), ma anche effetti più complessi, ad esempio tone mapping o qualunque altra cosa possa venire in mente. Anche lo spazio di colore dipende da questo, quindi, tanto per dire, è tramite questo che si sceglierà se avere un'immagine in bianco e nero od a colori. Teoricamente qua potrebbe starci anche quello che avviene su blender coi composite nodes, ma ho intenzione di prevedere le cose in maniera più pulita dopo la 1.0.
0.10: L'aggiunta di geometrie, nei miei progetti (ambiziosissimi), sarebbe controllabile via shader. Purtroppo questa è una parte piuttosto complessa, e perciò è posticipata a dopo della versione 1.0. In attesa però di avere questa caratteristica saranno proposte (in questa versione) le geometrie più comuni, come le nurbs, le superfici di suddivisione, forse anche il displacement (che sarà sicuramente presente in versioni successive, c'è solo da chiedersi se verrà introdotto in questa :) ).
1.0: Qua c'è una revisione completa del codice, per trovare bug. Inoltre viene completato, o cominciato il porting sulle piattaforme dove non funziona ancora cassata. Probabilmente windows sarà la piattaforma più complessa in proposito.
Ragazzi, è uscito Cassata :D
A questo punto del lavoro le potenzialità di cassata saranno già molto alte. Certo però mancheranno tantissime altre cose. Non aspiro ad avere un renderer completo dalla prima versione (probabilmente quello che voglio, a questo ritmo, si avrebbe all'incirca per cassata 3.0).
Come vedete il lavoro è tanto, ma procedendo un passetto alla volta non dovrebbe essere troppo difficile. Purtroppo i tempi sono lunghi. Lavorando continuamente prevedo una media all'incirca pari ad un mese per ogni minor version (ma non sono tutte di circa un mese, ce ne sono alcune più lunghe ed altre più corte), e quindi 11 mesi per cassata 1.0. Ovviamente questo non avverrà, perché c'è sempre (come ce ne sono stati già) qualche momento di pausa in cui non lavorerò, o di grandi impegni dove lavorerò meno. Sarebbe utile quindi trovare qualcuno, ma più avanti, non a questo punto del lavoro. Da soli questo progetto è davvero lungo.
È lungo, ma reggibile, anche da solo una persona. Anche ipotizzando di impiegare 5 anni (per cassata 3.0), al termine del progetto si avrebbe un renderer ottimo.
Quello che davvero mi piacerebbe, invece, da parte di voi utenti, è la formazione di una comunità che crei shader e quant'altro. Davvero da soli non è possibile fare tutte queste cose, ma se ognuno fa un materiale quando gli serve, crea una texture procedurale, crea qualcosa che sia venuto bene, e lo rende disponibile alla comunità ben presto si creano librerie enormi di cose già pronte e riutilizzabili nei propri lavori. Come ho detto non posso fare tutto io, ma se ci si unisce si può fare molto.
Visto che il post è corto (è corto, no? XD ) passo a discutere il sondaggio pubblicato.
Ecco i risultati del sondaggio:
Trovi utile il progetto cassata?
2 voti: Non capisco come ho fatto a vivere senza
12 voti: Davvero utile, mi piacerebbe che uscisse il prima possibile
2 voti: Credo che sia un buon progetto, come ce ne sono molti
0 voti: Sono indifferente
0 voti: Non lo trovo un progetto interessante
0 voti: Lo trovo un progetto pessimo
0 voti: Vai a zappare va...
Questo risultato da un lato mi dice che chi mi segue è chi è interessato al progetto. Il che è buono perché chi mi da consigli mi dice esattamente cosa vorrebbe aggiunto senza stravolgere nulla (consigliate quindi :D ), ma è anche male perché non ho pareri troppo contrastanti, che poi alla fine aiutano molto a capire se la direzione presa è quella giusta. Penso che una via di mezzo da questo punto di vista sarebbe stata meglio.
Dall'altro lato invece l'aver voti tutti alti mi da la forza di continuare, ho il tifo :D
Beh, che altro dire. Chi ha avuto la forza di leggere tutto ha il mio rispetto XD
A presto con novità dal mondo cassata :D
So che vado contro quello che avevo detto, tuttavia ho deciso di passare direttamente a cassata, e non perdere altro tempo, visto che già ne è passato molto.
Questo però vuol dire che le cose da cambiare e ristrutturare durante la lavorazione di cassata 1.0 saranno tantissime, e sconsiglio vivamente l'uso di cassata in produzione (ovvero in qualcosa che non sia un semplice test) fino all'uscita della prima versione stabile.
Una cosa potrebbe funzionare oggi e non funzionare domani, per cui siete avvertiti.
Detto questo ecco la road map attuale di cassata 1.0. È soggetta a cambiamenti anche pesanti, prendetela solo come linea di massima:
0.1 struttura interna
0.2 interfaccia XML
0.3 acceleratori geometrici
0.4 acceleratori d'integrazione
0.5 shader dei materiali
0.6 acceleratori degli shader
0.7 shader delle texture
0.8 interfaccia libreria
0.9 shader delle camere
0.10 geometrie complesse
1.0 revisione completa e porting
Il numero accanto indica a quale versione si troverà quello che si trova alla sua destra.
Analizziamo punto per punto, per descrivere cosa verrà fatto.
0.1: Verrà definita la struttura interna del renderer, a questo punto dovrei essere in grado di disegnare qualcosa, anche se molto poco. Integratori montecarlo, ray casting e mesh vengono introdotti in questa versione.
0.2: Viene definita l'interfaccia XML, che sebbene sarà soggetta a forti cambiamenti (come tutto) fino alla versione 1.0, sarà il più possibile somigliante alla sua forma finale.
0.3: Vengono sviluppati i primi acceleratori geometrici, per poter renderizzare anche scene geometricamente complesse.
0.4: Vengono introdotti altri integratori montecarlo, ad esempio un'idea potrebbe essere l'introduzione del bidirectional ray tracing. In questa parte vengono comunque sviluppati solo gl'integratori più utili, ed in generale la 1.0 non è detto che sarà prestazionalmente poi così veloce.
0.5: Si definisce l'interfaccia degli shader, quindi gli shader dei materiali (che permettono di definire BSDF ed EDF di ogni materiale). Teoricamente sarebbero rappresentabili anche le texture tramite gli shader dei materiali, ma ho volutamente deciso di separare le 2 cose, perché le texture spesso sono disegnate o generate indipendentemente dal materiale.
0.6: Qua vengono definite alcune strutture atte ad accelerare gli shader, che in ogni caso possono (in caso d'impossibilità di questo punto) essere interpretate. Principalmente questa fase prevederà un JIT. Più avanti si potrebbe pensare a qualche sistema adatto ad usare gli shader tramite schede grafiche.
0.7: A questo punto si generano le texture. Fino a questo punto ci sarà un minimo supporto per le texture (quasi inesistente), ma da questo punto in poi si potranno definire tutte le texture che si vogliono, sia immagini (anche di tipi sconosciuti, basta scrivere lo shader adatto) che procedurali.
0.8: Viene definita un'interfaccia per il renderer. Fino a questo punto l'interfaccia esisteva già, ma è solo qua che viene definita piuttosto bene, e pressocché non soggetta a grossi cambiamenti.
0.9: Viene definito il terzo (ed ultimo per quanto riguarda la versione 1.0) tipo di shader di cassata. Permette di definire camere, anche complesse. Da questo shader dipenderanno effetti comuni, come la profondità di campo o la sfocatura dovuta al movimento (DoF e motion blur), ma anche effetti più complessi, ad esempio tone mapping o qualunque altra cosa possa venire in mente. Anche lo spazio di colore dipende da questo, quindi, tanto per dire, è tramite questo che si sceglierà se avere un'immagine in bianco e nero od a colori. Teoricamente qua potrebbe starci anche quello che avviene su blender coi composite nodes, ma ho intenzione di prevedere le cose in maniera più pulita dopo la 1.0.
0.10: L'aggiunta di geometrie, nei miei progetti (ambiziosissimi), sarebbe controllabile via shader. Purtroppo questa è una parte piuttosto complessa, e perciò è posticipata a dopo della versione 1.0. In attesa però di avere questa caratteristica saranno proposte (in questa versione) le geometrie più comuni, come le nurbs, le superfici di suddivisione, forse anche il displacement (che sarà sicuramente presente in versioni successive, c'è solo da chiedersi se verrà introdotto in questa :) ).
1.0: Qua c'è una revisione completa del codice, per trovare bug. Inoltre viene completato, o cominciato il porting sulle piattaforme dove non funziona ancora cassata. Probabilmente windows sarà la piattaforma più complessa in proposito.
Ragazzi, è uscito Cassata :D
A questo punto del lavoro le potenzialità di cassata saranno già molto alte. Certo però mancheranno tantissime altre cose. Non aspiro ad avere un renderer completo dalla prima versione (probabilmente quello che voglio, a questo ritmo, si avrebbe all'incirca per cassata 3.0).
Come vedete il lavoro è tanto, ma procedendo un passetto alla volta non dovrebbe essere troppo difficile. Purtroppo i tempi sono lunghi. Lavorando continuamente prevedo una media all'incirca pari ad un mese per ogni minor version (ma non sono tutte di circa un mese, ce ne sono alcune più lunghe ed altre più corte), e quindi 11 mesi per cassata 1.0. Ovviamente questo non avverrà, perché c'è sempre (come ce ne sono stati già) qualche momento di pausa in cui non lavorerò, o di grandi impegni dove lavorerò meno. Sarebbe utile quindi trovare qualcuno, ma più avanti, non a questo punto del lavoro. Da soli questo progetto è davvero lungo.
È lungo, ma reggibile, anche da solo una persona. Anche ipotizzando di impiegare 5 anni (per cassata 3.0), al termine del progetto si avrebbe un renderer ottimo.
Quello che davvero mi piacerebbe, invece, da parte di voi utenti, è la formazione di una comunità che crei shader e quant'altro. Davvero da soli non è possibile fare tutte queste cose, ma se ognuno fa un materiale quando gli serve, crea una texture procedurale, crea qualcosa che sia venuto bene, e lo rende disponibile alla comunità ben presto si creano librerie enormi di cose già pronte e riutilizzabili nei propri lavori. Come ho detto non posso fare tutto io, ma se ci si unisce si può fare molto.
Visto che il post è corto (è corto, no? XD ) passo a discutere il sondaggio pubblicato.
Ecco i risultati del sondaggio:
Trovi utile il progetto cassata?
2 voti: Non capisco come ho fatto a vivere senza
12 voti: Davvero utile, mi piacerebbe che uscisse il prima possibile
2 voti: Credo che sia un buon progetto, come ce ne sono molti
0 voti: Sono indifferente
0 voti: Non lo trovo un progetto interessante
0 voti: Lo trovo un progetto pessimo
0 voti: Vai a zappare va...
Questo risultato da un lato mi dice che chi mi segue è chi è interessato al progetto. Il che è buono perché chi mi da consigli mi dice esattamente cosa vorrebbe aggiunto senza stravolgere nulla (consigliate quindi :D ), ma è anche male perché non ho pareri troppo contrastanti, che poi alla fine aiutano molto a capire se la direzione presa è quella giusta. Penso che una via di mezzo da questo punto di vista sarebbe stata meglio.
Dall'altro lato invece l'aver voti tutti alti mi da la forza di continuare, ho il tifo :D
Beh, che altro dire. Chi ha avuto la forza di leggere tutto ha il mio rispetto XD
A presto con novità dal mondo cassata :D
domenica 19 agosto 2007
Come potete vedere: pausa
Com'è successo altre volte (credo altre 3) il progetto è attualmente in pausa, e già da un po' (almeno un paio di settimane). Penso di riprendere fra non molto, tuttavia non è una garanzia, dipende dagl'impegni.
Comunque non pensiate che il progetto sia morto, anzi. Se ha sopravvissuto ad altre 3 pause (credo) uscendone sempre più rinvigorito non vedo perché non dovrebbe resistere a questa :)
Presto ricomincerò a lavorare.
Intanto dico cosa avevo fatto. Il porting verso le modifiche che porteranno a poter introdurre i KD Tree è quasi completo, ma permangono 2 bug da correggere. Corretti questi e fatta un'altra oretta di lavoro, bug permettendo le modifiche saranno completate e potrò passare all'implementazione dei KD Tree. La cosa che ovviamente mi spaventa di più sono quei 2 bug XD
In ogni caso allora a presto, poi dirò anche che ne penso del sondaggio che ho fatto, al mio rientro :)
Comunque non pensiate che il progetto sia morto, anzi. Se ha sopravvissuto ad altre 3 pause (credo) uscendone sempre più rinvigorito non vedo perché non dovrebbe resistere a questa :)
Presto ricomincerò a lavorare.
Intanto dico cosa avevo fatto. Il porting verso le modifiche che porteranno a poter introdurre i KD Tree è quasi completo, ma permangono 2 bug da correggere. Corretti questi e fatta un'altra oretta di lavoro, bug permettendo le modifiche saranno completate e potrò passare all'implementazione dei KD Tree. La cosa che ovviamente mi spaventa di più sono quei 2 bug XD
In ogni caso allora a presto, poi dirò anche che ne penso del sondaggio che ho fatto, al mio rientro :)
venerdì 27 luglio 2007
Secondo documento
Ecco il secondo documento che scrivo.
Probabilmente molto più interessante del precedente per i lettori, visto che parla di cosa dovrebbe essere in futuro cassata.
Il link, come quello precedente, è provvisorio, verranno spostate tutte cose nel repository ufficiale di cassata più avanti, in ogni caso eccolo:
http://yotavga.altervista.org/futuro.pdf
Ancora una volta fate copia-incolla, visto che altervista controlla la provenienza quando si segue un link ed esclude qualunque percorso proveniente da un altro sito.
Alla prossima :)
Probabilmente molto più interessante del precedente per i lettori, visto che parla di cosa dovrebbe essere in futuro cassata.
Il link, come quello precedente, è provvisorio, verranno spostate tutte cose nel repository ufficiale di cassata più avanti, in ogni caso eccolo:
http://yotavga.altervista.org/futuro.pdf
Ancora una volta fate copia-incolla, visto che altervista controlla la provenienza quando si segue un link ed esclude qualunque percorso proveniente da un altro sito.
Alla prossima :)
mercoledì 25 luglio 2007
Lunga ristrutturazione per torrone
Ho finito lo studio che mi serviva per i kd-tree. Ora però, per poter implementare tutto ciò che ho imparato e pensato, e lasciare anche spazio per nuove cose, la struttura interna di torrone non è più sufficente. È necessario ristrutturarlo profondamente e riscriverne alcune componenti.
Il lavoro comincerà oggi stesso, e penso che occuperà 1-2 settimane.
Però fra una settimana parto (per pochi giorni), quindi mettete in conto 3 settimane come tempo massimo.
Vi farò sapere delle novità più avanti.
Alla prossima :)
Il lavoro comincerà oggi stesso, e penso che occuperà 1-2 settimane.
Però fra una settimana parto (per pochi giorni), quindi mettete in conto 3 settimane come tempo massimo.
Vi farò sapere delle novità più avanti.
Alla prossima :)
domenica 22 luglio 2007
Il primo articolo sull'architettura di cassata
Ho completato il primo articolo sull'architettura di cassata. Sono solo alcune idee, e come tali vanno prese. Nulla di definitivo ne altro. Per chi volesse leggerlo:
http://yotavga.altervista.org/gestione_memoria.pdf
Si consiglia di fare copia-incolla del link, poiché altervista fa dei controlli sulla provenienza e non mostra i link se presi da altri siti.
http://yotavga.altervista.org/gestione_memoria.pdf
Si consiglia di fare copia-incolla del link, poiché altervista fa dei controlli sulla provenienza e non mostra i link se presi da altri siti.
venerdì 20 luglio 2007
A proposito dei ritardi su cassata
So di non dovere spiegazioni a nessuno, ma questo post vuole segnalare che il progetto non è morto.
Ho molti impegni oltre questo progetto, il che ha causato quasi un fermo di cassata, ma solo temporaneo, conto di riprendere nel giro di al massimo qualche settimana, salvo imprevisti.
Mi spiace che il progetto debba subire simili ritardi, ma essendo solo e non facendo solo questo non posso mandare il progetto avanti ogni giorno.
Comunque le idee che mi vengono e ronzano in testa non si fermano ;)
A presto quindi :)
Ho molti impegni oltre questo progetto, il che ha causato quasi un fermo di cassata, ma solo temporaneo, conto di riprendere nel giro di al massimo qualche settimana, salvo imprevisti.
Mi spiace che il progetto debba subire simili ritardi, ma essendo solo e non facendo solo questo non posso mandare il progetto avanti ogni giorno.
Comunque le idee che mi vengono e ronzano in testa non si fermano ;)
A presto quindi :)
giovedì 12 luglio 2007
A proposito di cassata 1.0
Ho deciso di scrivere un post un po' diverso dai classici post che scrivo in genere, per descrivere cosa stò facendo ora e cosa penso di fare per il futuro.
Qualcuno dei lettori (e ce ne sono, a me sembra che siano quasi tutti su blender.it XD ) probabilmente sa qual'è l'importanza di un'interfaccia, ma ne parlerò qui per spiegarlo anche a chi non lo sapesse.
Innanzitutto va detto che per interfaccia non intendo gui. Intendo quello strato che interpreta le scene e comunica con gli shader.
Una buona interfaccia è indispensabile, perché deve rimanere a lungo. Immaginate che cosa succederebbe se di punto in bianco cambio il modo in cui si salva una scena. Chiunque stia facendo dei lavori ci penserà 100 volte prima di decidere di aggiornare. Questo è un grave problema per il progresso tecnologico del renderer.
Perciò ciò che mi serve è un'interfaccia che sia stabile (dovrà cambiare profondamente solo in casi rarissimi), flessibile (dovrò poter sviluppare tante cose nel frattempo) e che non leda le prestazioni.
Fare un'interfaccia così necessita anche di sapere per lo meno per sommi capi verso che direzione potrà espandersi internamente il renderer, e quindi diventa tutto un equilibrio di difficile soluzione.
Ho intenzione di fare uscire diverse versioni di cassata (la prima sarà la 0.1) ritenute relativamente stabili, e man mano sempre più complete, con l'unico limite di avere un'interfaccia ancora da stabilizzarsi.
La versione 1.0 invece, infine, avrà un'interfaccia stabile, ma uscirà fra parecchio tempo (anni?).
Questo ovviamente non vuol dire che cassata sarà inusabile, solo che mi prenderò diverso tempo per la stabilizzazione dell'interfaccia. Nel frattempo già cassata sarà utilizzabilissimo, e chissà, magari avrà una discreta cerchia di utenti.
Prima di far uscire comunque cassata 0.1 voglio almeno avere una vaga idea di come sarà l'interfaccia. Per farlo devo sperimentare e provare tante cose, perché come detto l'architettura interna influenzia anche la progettazione dell'interfaccia. Questo è quello che stò facendo attualmente.
Per quanto riguarda l'uscita di cassata 0.1, come data indicativa, e soggetta comunque anche a cambiamenti notevoli (non prendetela seriamente, è solo un'indicazione) vorrei farla uscire intorno a fine 2007 - inizio 2008. Raggiunta cassata 0.1 vorrei che già fosse possibile renderizzare scene comuni, con la disponibilità di almeno shader per costruire materiali abbastanza diffusi in natura (anche magari approssimati ma con approssimazioni decenti) e non troppo lento. Per intenderci vorrei riuscire, per lo meno, ad ottenere immagini qualitativamente (ma probabilmente non prestazionalmente) al livello di indigo 0.5.
Qualcuno dei lettori (e ce ne sono, a me sembra che siano quasi tutti su blender.it XD ) probabilmente sa qual'è l'importanza di un'interfaccia, ma ne parlerò qui per spiegarlo anche a chi non lo sapesse.
Innanzitutto va detto che per interfaccia non intendo gui. Intendo quello strato che interpreta le scene e comunica con gli shader.
Una buona interfaccia è indispensabile, perché deve rimanere a lungo. Immaginate che cosa succederebbe se di punto in bianco cambio il modo in cui si salva una scena. Chiunque stia facendo dei lavori ci penserà 100 volte prima di decidere di aggiornare. Questo è un grave problema per il progresso tecnologico del renderer.
Perciò ciò che mi serve è un'interfaccia che sia stabile (dovrà cambiare profondamente solo in casi rarissimi), flessibile (dovrò poter sviluppare tante cose nel frattempo) e che non leda le prestazioni.
Fare un'interfaccia così necessita anche di sapere per lo meno per sommi capi verso che direzione potrà espandersi internamente il renderer, e quindi diventa tutto un equilibrio di difficile soluzione.
Ho intenzione di fare uscire diverse versioni di cassata (la prima sarà la 0.1) ritenute relativamente stabili, e man mano sempre più complete, con l'unico limite di avere un'interfaccia ancora da stabilizzarsi.
La versione 1.0 invece, infine, avrà un'interfaccia stabile, ma uscirà fra parecchio tempo (anni?).
Questo ovviamente non vuol dire che cassata sarà inusabile, solo che mi prenderò diverso tempo per la stabilizzazione dell'interfaccia. Nel frattempo già cassata sarà utilizzabilissimo, e chissà, magari avrà una discreta cerchia di utenti.
Prima di far uscire comunque cassata 0.1 voglio almeno avere una vaga idea di come sarà l'interfaccia. Per farlo devo sperimentare e provare tante cose, perché come detto l'architettura interna influenzia anche la progettazione dell'interfaccia. Questo è quello che stò facendo attualmente.
Per quanto riguarda l'uscita di cassata 0.1, come data indicativa, e soggetta comunque anche a cambiamenti notevoli (non prendetela seriamente, è solo un'indicazione) vorrei farla uscire intorno a fine 2007 - inizio 2008. Raggiunta cassata 0.1 vorrei che già fosse possibile renderizzare scene comuni, con la disponibilità di almeno shader per costruire materiali abbastanza diffusi in natura (anche magari approssimati ma con approssimazioni decenti) e non troppo lento. Per intenderci vorrei riuscire, per lo meno, ad ottenere immagini qualitativamente (ma probabilmente non prestazionalmente) al livello di indigo 0.5.
mercoledì 4 luglio 2007
Ma che bel dipinto!
Molte modifiche. Diversi bug sono stati corretti, in particolare uno sull'illuminazione globale ed uno sul conto dei raggi.
Ma soprattutto ora funzionano le texture :D
Per l'occasione, per mostrare quanto influenzia l'illuminazione indiretta, ho prodotto 2 rendering, identici eccetto che per il calcolo dell'illuminazione indiretta:
Innanzitutto mostro unimmagine senza illuminazione indiretta, durata circa 6 minuti e mezzo con un consumo della CPU del 75% (1.080.000 raggi):
Quella invece completa è durata poco meno di 2 ore e mezza, con un consumo della CPU dell'80% (33.777.037.841.920 raggi):
Ho voluto mettere il consumo della CPU e lo metterò d'ora in poi perché spesso faccio altre cose e falso i tempi altrimenti a seconda di cosa faccio mentre renderizzo. In particolare i vecchi rendering erano spesso sopra il 90% (spesso abbondantemente).
Comunque come si capisce lo sfondo è una texture, precisamente un'immagine OpenEXR.
Il codice volendo può usare tranquillamente già texture procedurali e quant'altro, e c'è un'implementazione completa dell'uv mapping.
Alla prossima :)
Ma soprattutto ora funzionano le texture :D
Per l'occasione, per mostrare quanto influenzia l'illuminazione indiretta, ho prodotto 2 rendering, identici eccetto che per il calcolo dell'illuminazione indiretta:
Innanzitutto mostro unimmagine senza illuminazione indiretta, durata circa 6 minuti e mezzo con un consumo della CPU del 75% (1.080.000 raggi):
Quella invece completa è durata poco meno di 2 ore e mezza, con un consumo della CPU dell'80% (33.777.037.841.920 raggi):
Ho voluto mettere il consumo della CPU e lo metterò d'ora in poi perché spesso faccio altre cose e falso i tempi altrimenti a seconda di cosa faccio mentre renderizzo. In particolare i vecchi rendering erano spesso sopra il 90% (spesso abbondantemente).
Comunque come si capisce lo sfondo è una texture, precisamente un'immagine OpenEXR.
Il codice volendo può usare tranquillamente già texture procedurali e quant'altro, e c'è un'implementazione completa dell'uv mapping.
Alla prossima :)
martedì 26 giugno 2007
Qualche modifica interessante
Sono stato via per via della linea, ora mancherò 6 giorni perché domani parto, ma intanto vi tengo informati sui pochi progressi su torrone (c'ho lavorato solo ieri, causa studio).
Molte ristrutturazioni, qualche piccola ottimizzazione (da poco, sembrerebbe inferiore al 10%) ma soprattutto ristrutturazioni interne che mi permettono, finalmente, di poter modificare il codice in maniera da poter inserire informazioni locali sulla mesh (e non solo globali). Questo vuol dire texture ovviamente. Ma le texture verranno in seguito (prossima cosa da fare). Inoltre credo che farò diverse altre cosette tramite queste modifiche.
Ho cominciato a studiare pure le libOpenEXR per il supporto delle texture (ebbene si, supporto alle HDRi fin da fra poco :) ).
Inoltre è arrivato il libro, che ho cominciato a leggere. Molto interessante, ho preso diversi spunti già e penso che imparerò molto. Finita la faccenda texture mi metterò, come promesso, a fare un kd-tree.
Nient'altro da aggiungere, ci si vedrà a presto, dopo che sarò tornato :)
Molte ristrutturazioni, qualche piccola ottimizzazione (da poco, sembrerebbe inferiore al 10%) ma soprattutto ristrutturazioni interne che mi permettono, finalmente, di poter modificare il codice in maniera da poter inserire informazioni locali sulla mesh (e non solo globali). Questo vuol dire texture ovviamente. Ma le texture verranno in seguito (prossima cosa da fare). Inoltre credo che farò diverse altre cosette tramite queste modifiche.
Ho cominciato a studiare pure le libOpenEXR per il supporto delle texture (ebbene si, supporto alle HDRi fin da fra poco :) ).
Inoltre è arrivato il libro, che ho cominciato a leggere. Molto interessante, ho preso diversi spunti già e penso che imparerò molto. Finita la faccenda texture mi metterò, come promesso, a fare un kd-tree.
Nient'altro da aggiungere, ci si vedrà a presto, dopo che sarò tornato :)
venerdì 8 giugno 2007
Nuovo rendering e notizie varie
Son stato via perché avevo internet giù.
Ho implementato delle nuove ottomizzazioni, che permettono di avere anche più di 2 volte il rendering più veloce in molti casi. Il rendering che mostro ora è durato poco meno di 2 ore:
Il numero di raggi valutati per questo rendering è ben 7.711.423.254.272 (ora posso controllarlo grazie ad una modifica al renderer). Attenzione che però i raggi non sono tutti indipendenti tra di loro, al contrario il numero di raggi totalmente indipendenti tra di loro è poco più di un milione.
Ora mi fermerò, sono in attesa di un libro, Physically Based Rendering: From Theory to Implementation, che mi permetterà di approfondire ora varie cose sulle geometrie, in futuro anche diversi aspetti sui materiali e su diverse altre cose.
Alla prossima.
Ho implementato delle nuove ottomizzazioni, che permettono di avere anche più di 2 volte il rendering più veloce in molti casi. Il rendering che mostro ora è durato poco meno di 2 ore:
Il numero di raggi valutati per questo rendering è ben 7.711.423.254.272 (ora posso controllarlo grazie ad una modifica al renderer). Attenzione che però i raggi non sono tutti indipendenti tra di loro, al contrario il numero di raggi totalmente indipendenti tra di loro è poco più di un milione.
Ora mi fermerò, sono in attesa di un libro, Physically Based Rendering: From Theory to Implementation, che mi permetterà di approfondire ora varie cose sulle geometrie, in futuro anche diversi aspetti sui materiali e su diverse altre cose.
Alla prossima.
lunedì 4 giugno 2007
Ora si sta al calduccio! - supplemento 1
Dimenticavo, i tempi di rendering dell'immagine mostrata sono intorno alle 2 ore e mezza :)
A che ci sono do qualche altro dato: per ogni pixel vengono sparati 4 raggi col jittering, l'illuminazione diretta è calcolata con 32 raggi, quindi ogni raggio quando sbatte si può dividere in massimo 16 raggi, con una probabilità di venire assorbito proporzionale (ma in parte sceglibile dall'utente) al BSDF ed all'angolazione del raggio (questo per accelerare la convergenza).
A che ci sono do qualche altro dato: per ogni pixel vengono sparati 4 raggi col jittering, l'illuminazione diretta è calcolata con 32 raggi, quindi ogni raggio quando sbatte si può dividere in massimo 16 raggi, con una probabilità di venire assorbito proporzionale (ma in parte sceglibile dall'utente) al BSDF ed all'angolazione del raggio (questo per accelerare la convergenza).
Ora si sta al calduccio!
Fatto il rendering, ho chiuso la camera un po' indietro (eh, si sta al calduccio :D ), il rendering non è di altissima qualità ma è più decente. Si vede il tetto più chiaro ed anche l'ombra risulta più luminosa. Inoltre la luminosità è salita anche perché ho aumentato l'emissione luminosa dell'area light presente sul tetto.
Buona visione:
Buona visione:
Conferme sull'illuminazione globale
Il titolo non è simpatico come i precedenti, ma mica posso inventarmene uno ogni volta :D
Dunque, do la conferma che tutti i test sono passati, e sembrerebbe che l'illuminazione globale funzioni bene.
Ho svolto diverse modifiche al renderer, sebbene piccole, che permettono ora una velocizzazione del rendering di più del 30%, ed inoltre ho modificato la scena, che ora da molto più valore al lavoro svolto.
Purtroppo ottenere un'immagine buona non è cosa semplice, sembra che il rendering duri più di 8 ore, davvero troppo.
Stò valutando se è il caso di eseguire domani un rendering apposto, oppure fare un rendering decente ma non ottimo, domani deciderò.
Finita questa parte credo che i ritmi scenderanno temporaneamente un po', apparte i vari altri impegni ho da studiare ed approfondire lo studio dei kd-tree, che conosco molto poco, e che (per chi non fosse pratico di strutture dati simili) permetteranno di velocizzare molte operazioni con le geometrie, specialmente per quanto riguarda le collisioni dei raggi sulle superfici.
Molto è ancora da fare, ma onestamente non credevo di arrivare a risultati così buoni in così poco tempo.
Non conto che durerà ancora a lungo XD Però finché dura meglio :D
Dunque, do la conferma che tutti i test sono passati, e sembrerebbe che l'illuminazione globale funzioni bene.
Ho svolto diverse modifiche al renderer, sebbene piccole, che permettono ora una velocizzazione del rendering di più del 30%, ed inoltre ho modificato la scena, che ora da molto più valore al lavoro svolto.
Purtroppo ottenere un'immagine buona non è cosa semplice, sembra che il rendering duri più di 8 ore, davvero troppo.
Stò valutando se è il caso di eseguire domani un rendering apposto, oppure fare un rendering decente ma non ottimo, domani deciderò.
Finita questa parte credo che i ritmi scenderanno temporaneamente un po', apparte i vari altri impegni ho da studiare ed approfondire lo studio dei kd-tree, che conosco molto poco, e che (per chi non fosse pratico di strutture dati simili) permetteranno di velocizzare molte operazioni con le geometrie, specialmente per quanto riguarda le collisioni dei raggi sulle superfici.
Molto è ancora da fare, ma onestamente non credevo di arrivare a risultati così buoni in così poco tempo.
Non conto che durerà ancora a lungo XD Però finché dura meglio :D
domenica 3 giugno 2007
E luce fu!
Qualche aggiornamento.
Per prima cosa ho completato la gestione dell'illuminazione indiretta, ma il renderer risulta molto lento.
Per chi mi seguisse da qualche tempo saprà che è una cosa che ripeto sempre :D Il renderer attualmente è incredibilmente più veloce che all'inizio, ma risulta ancora molto lento :)
Domani farò numerosi test per vedere se è tutto ok, quindi vi darò la conferma o smentita che sia tutto apposto, ma per ora sembra tutto perfetto.
Vi mostro un rendering un po' rumoroso, durato un'ora e mezza (i tempi cominciano a rialzarsi, come si vede):
Faccio notare un po' di cose altrimenti difficili da vedere.
La parte centrale dell'ombra non è più nera, ma grigia, merito dei riflessi sulle pareti :D
Le parti più illuminate sono quelle più in fondo, questo perché mancando la parete più vicina alla camera, i raggi che si trovano vicini alla camera tendono a fuggire via, nel vuoto. È possibile notare (alzate la luminosità se non riuscite a vederlo) che la parte più in fondo del tetto è un po' più chiara. Nulla di che, ma si vede che ci sono i riflessi.
Il corpo fluttuante, di sotto, è completamente assorbente, quindi non riflette nulla.
Per il resto non c'è altro da dire, farò un rendering che lo valorizzi di più, ho già alzato la luminosità, domani farò altre prove.
Al prossimo post :)
Per prima cosa ho completato la gestione dell'illuminazione indiretta, ma il renderer risulta molto lento.
Per chi mi seguisse da qualche tempo saprà che è una cosa che ripeto sempre :D Il renderer attualmente è incredibilmente più veloce che all'inizio, ma risulta ancora molto lento :)
Domani farò numerosi test per vedere se è tutto ok, quindi vi darò la conferma o smentita che sia tutto apposto, ma per ora sembra tutto perfetto.
Vi mostro un rendering un po' rumoroso, durato un'ora e mezza (i tempi cominciano a rialzarsi, come si vede):
Faccio notare un po' di cose altrimenti difficili da vedere.La parte centrale dell'ombra non è più nera, ma grigia, merito dei riflessi sulle pareti :D
Le parti più illuminate sono quelle più in fondo, questo perché mancando la parete più vicina alla camera, i raggi che si trovano vicini alla camera tendono a fuggire via, nel vuoto. È possibile notare (alzate la luminosità se non riuscite a vederlo) che la parte più in fondo del tetto è un po' più chiara. Nulla di che, ma si vede che ci sono i riflessi.
Il corpo fluttuante, di sotto, è completamente assorbente, quindi non riflette nulla.
Per il resto non c'è altro da dire, farò un rendering che lo valorizzi di più, ho già alzato la luminosità, domani farò altre prove.
Al prossimo post :)
venerdì 1 giugno 2007
Ma non diciamo cassate!
Salve a tutti.
Questo blog nasce per l'esigenza di trovare un posto per parlare di un mio progetto, cassata, ma penso che lo utilizzerò anche ad altri scopi. Per chi fosse interessato solo a cassata potrà visionare i post etichettati "cassata", e tralasciare gli altri.
Per chi non sapesse che cosa è cassata:
Si tratta di un renderer, per la precisione nasce come renderer unbias, ma verranno introdotte (a scelta dell'utente, e solo quando lo ritiene necessario) anche tecniche bias ma molto efficaci per aumentare le prestazioni del renderer, specialmente in casi limite (molte luci, scene complesse, subsrface scattering e via dicendo), oppure nei casi in cui un dato modello non si riesca a rendere unbias (materiali a comportamento non lineare e via dicendo).
Il renderer è pieno di caratteristiche interessanti, e sarà in grandissima parte espandibile tramite shader. Soprattutto si tratterà, a quanto ne so (se qualcuno sapesse diversamente che commenti, orsù :D ), del primo renderer open source unbias adatto alla produzione (miro alto :D ).
Per chi volesse saperne di più qua c'è una discussione approfondita di cos'è stato fatto fino ad ora:
http://www.blender.it/forum/viewtopic.php?t=5422&start=0
purtroppo è necessario essere loggati al forum di blender.it per vedere il post.
Si rimanda anche a
http://sourceforge.net/projects/cassata
per conoscere altri dettagli.
Attualmente, al contrario di quanto scritto su sourceforge, il progetto è passato (da poco) dalla LGPL alla GPL.
Sebbene d'ora in poi tutte le novità passeranno di qui, continuerò a pubblicare sul forum di blender.it le cose più importanti o che ritengo sia il caso pubblicare.
Stò anche valutando l'ipotesi di fare un riassunto di ciò che c'è scritto su blender.it, o persino un mirror, da inserire qui, con tanto d'immagini, per chi non volesse registrarsi.
Intanto do alcune informazioni fondamentali che risultano utili a chi non ha seguito affatto il progetto fino ad ora.
Al momento è in lavorazione torrone, un renderer che viene utilizzato per fare esperimenti prima d'introdurli in cassata. È scritto in Python, Pyrex e C++, in questo momento, ma ho eseguito diversi porting e non escludo di cambiare ancora linguaggi.
Torrone è attualmente lento, ma ci sono state enormi velocizzazioni, che raggiungono, nel caso limite provato, fino a quasi 360 volte la velocità iniziale.
Al momento torrone è in grado di calcolare solo l'illuminazione diretta, ma nei prossimi giorni lavorerò proprio su questo, ottenendo il calcolo dell'illuminazione globale.
L'ultima questione è quella di scrivere post in inglese. È una cosa che sarebbe utile, magari scrivendo i post bilingua, ma per il momento mi astengo dal farlo.
In seguito potrò cambiare idea e scrivere post bilingua, od inglese direttamente, ma credo che prima cassata dovrà prendere un po' di popolarità.
Questo blog nasce per l'esigenza di trovare un posto per parlare di un mio progetto, cassata, ma penso che lo utilizzerò anche ad altri scopi. Per chi fosse interessato solo a cassata potrà visionare i post etichettati "cassata", e tralasciare gli altri.
Per chi non sapesse che cosa è cassata:
Si tratta di un renderer, per la precisione nasce come renderer unbias, ma verranno introdotte (a scelta dell'utente, e solo quando lo ritiene necessario) anche tecniche bias ma molto efficaci per aumentare le prestazioni del renderer, specialmente in casi limite (molte luci, scene complesse, subsrface scattering e via dicendo), oppure nei casi in cui un dato modello non si riesca a rendere unbias (materiali a comportamento non lineare e via dicendo).
Il renderer è pieno di caratteristiche interessanti, e sarà in grandissima parte espandibile tramite shader. Soprattutto si tratterà, a quanto ne so (se qualcuno sapesse diversamente che commenti, orsù :D ), del primo renderer open source unbias adatto alla produzione (miro alto :D ).
Per chi volesse saperne di più qua c'è una discussione approfondita di cos'è stato fatto fino ad ora:
http://www.blender.it/forum/viewtopic.php?t=5422&start=0
purtroppo è necessario essere loggati al forum di blender.it per vedere il post.
Si rimanda anche a
http://sourceforge.net/projects/cassata
per conoscere altri dettagli.
Attualmente, al contrario di quanto scritto su sourceforge, il progetto è passato (da poco) dalla LGPL alla GPL.
Sebbene d'ora in poi tutte le novità passeranno di qui, continuerò a pubblicare sul forum di blender.it le cose più importanti o che ritengo sia il caso pubblicare.
Stò anche valutando l'ipotesi di fare un riassunto di ciò che c'è scritto su blender.it, o persino un mirror, da inserire qui, con tanto d'immagini, per chi non volesse registrarsi.
Intanto do alcune informazioni fondamentali che risultano utili a chi non ha seguito affatto il progetto fino ad ora.
Al momento è in lavorazione torrone, un renderer che viene utilizzato per fare esperimenti prima d'introdurli in cassata. È scritto in Python, Pyrex e C++, in questo momento, ma ho eseguito diversi porting e non escludo di cambiare ancora linguaggi.
Torrone è attualmente lento, ma ci sono state enormi velocizzazioni, che raggiungono, nel caso limite provato, fino a quasi 360 volte la velocità iniziale.
Al momento torrone è in grado di calcolare solo l'illuminazione diretta, ma nei prossimi giorni lavorerò proprio su questo, ottenendo il calcolo dell'illuminazione globale.
L'ultima questione è quella di scrivere post in inglese. È una cosa che sarebbe utile, magari scrivendo i post bilingua, ma per il momento mi astengo dal farlo.
In seguito potrò cambiare idea e scrivere post bilingua, od inglese direttamente, ma credo che prima cassata dovrà prendere un po' di popolarità.
Iscriviti a:
Post (Atom)
