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 :)
sabato 8 settembre 2007
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 :)
Iscriviti a:
Post (Atom)
