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

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

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

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