Gian Carlo Mingati. Design and development for interactive media.

Image credits: p5sunflow rendering test - GC Mingati
Primi test con p5sunflow, un 3D render engine open source con tanto di global illumination (una serie di algoritmi realizzati per aggiungere realismo alle scene 3D - riflessi, rifrazioni, ombre) originariamente chiamato Sunflow. Sunflow è un raytracer scritto in Java e reso compatibile con Processing da hipstersinc più di un anno fa col nome p5sunflow che poi però, a partire dalla versione 1.0 del framework, non ha più funzionato.
Finalmente qualcuno ha apportato le opportune modifiche e p5sunflow può nuovamente essere utilizzato per rendere “your Processing sketches look sexy as hell”.
Niente male davvero.

3D and XML data
Applet and code http://www.openprocessing.org/visuals/?visualID=5451 - GC Mingati
Tutti conoscete Google Analitycs. Se lo avete installato su qualcuna delle pagine del vs. sito, avrete visto che bei report che fa (con Flash) e quante opzioni abbia; inoltre si possono esportare i report in vari formati e oggi, quello che ha destato il mio interesse è il formato XML.
Processing permette di leggere un file XML, ma la libreria proXML permette di leggere e scrivere un file XML. In particolare, di questa nuova libreria scritta da Christian Riekoff, mi piace il modo intuitivo in cui si può navigare il DOM di un XML… bene, e allora? Ho usato proXML per costruire (facilmente) un grafico 3D delle visite al mio plugin jQuery slideViewer, sulla base dei dati di un report di Analitycs per il periodo 22 settembre - 22 ottobre 2009. La Applet ed il codice sorgente sono visualizzabili a questa URL.

The Extensible Markup Language XML has become the standard for exchanging structured data in Internet applications. proXML allows you to easily integrate and manipulate this data in Processing.

Se usate Processing e volete smanettare coi vostri report, andate sul vostro Analitycs e salvatevi il report in formato XML. Questo sketch costruirà un grafico a barre navigabile (via peasyCam) esponendo dati per: URL della pagina, periodo di riferimento, visite totali, giorno con maggiori visite (cubo blu), giorni del periodo di riferimento; non è che aggiunga chissà cosa ai report di Analitycs, però è un altro modo di visualizzarli e sopratutto per me, è un modo per esplorare nuove librerie e nuovi modi per fare le cose che mi piacciono, e alla fine, per integrare Processing col mio lavoro di tutti i giorni. Per muoversi intorno al grafico tasto sx click + drag; per avvicinarsi/allontanarsi tasto dx click + drag.

Al mio rientro dal fantastico viaggio di nozze negli US, ho cercato di vedere cosa mi ero perso in un mese di completo isolamento da Internet; per 30 giorni non ho controllato mail, visto sketches, controllato le statistiche, nulla di nulla. Solo una lunga immersione in infiniti landscapes, colori mozzafiato, scenari da far West attraverso Utah, Nevada e Arizona, con punte a New York, Las Vegas e San Francisco. 6000 chilometri con mia moglie Alessandra e presto metterò sù una gallery con le foto più belle anche se già vi dico che nessuna foto renderà mai giustizia alle immagini che ho in testa, ai vasti scenari del south-west, roba da restare senza fiato, davvero.

Image credits: Capitol Reef National Park, 52 Scenic Dr Torrey, UT 84775, USA
Painted with Processing - GC Mingati

Durante questi trenta giorni è stata pubblicata questa interessante intervista agli ideatori di Processing (Ben Fry, Casey Reas), il framework col quale indago su generative graphics, geometry, chaos, particles e qualsiasi altra cosa desti il mio interesse: Daniel Shiffman ha condotto questa intervista pubblicata su Rhizome che vi invito a leggere. Processing stà crescendo, nuove librerie ed entusiasmanti novità sono in fase di sviluppo e vedranno la luce con le versioni 1.5 - 2.0. In particolare il sistema di gestione dei video abbandonerà QuickTime in favore del framework multimediale opensource GStreamer ed inoltre Processing sarà molto meglio integrato con OpenGL, cosa che renderà il framework (le applicazioni che useranno OpenGL) molto più veloci (molti, molti più FPS…); uno degli studenti di Reas, Andrés Colubri, stà lavorando all’integrazione di GStreamer e OpenGL in Processing. Con la versione 2.0, verrà rivisitato anche l’IDE.

Interessante anche processingjs.org (ricordate il porting JavaScript delle parti 2D di Processing eseguito da John Resig? Ne abbiamo parlato qualche tempo fà in ogni modo giusto per ricapitolare in due parole si tratta della possibilità (usando JavaScript ed il tag canvas - parte integrante delle specifiche HTML 5) di effettuare un rendering dinamico di immagini bitmap; il lavoro, continuato da Al MacDonald stà portando alla nascita di una community e fà crescere l’interesse nei confronti del framework perchè permette di ‘disegnare’ senza usare le Applet Java (non è quindi necessario installare un Java runtime environment o nessun altro plugin, ma basta avere un browser di ultima generazione); inoltre la semplicità delle API e della sintassi lo rendono (e lo renderanno sempre di più) uno degli strumenti ideali per lo sviluppo di rich-user-interfaces, widgets per la data-visualization e per lo sviluppo di giochi web-based favorendo la sperimentazione ed incrementando la già notevolissima notorietà di Processing.

Image credits: Rotation Incident - GC Mingati
Ho iniziato ad investigare sul renderer 3D di Processing (P3D):
se aggiungiamo un terzo parametro nel setup della nostra applicazione, size(800, 600, P3D), significa che intendiamo usare il renderer tridimensionale di Processing, il più compatibile ed indipendente da librerie esterne (come per esempio OPENGL) ma leggermente più lento se si ha a che fare con forme geometriche complesse e molti vertici.
Per iniziare, ho usato i metodi box e sphere per creare forme molto semplici in 3D e ho cercato di capire il funzionamento di camera e luci. Creare un box è stato un attimo, ma per renderlo realistico avrei dovuto vestirlo con una texture; purtroppo i box creati col metodo statico box(w,h,l) non sono “texturizabili”. Per fare ciò, ho capito che dovevo comprendere come usare vertici e primitive in Processing.
Non c’è niente da fare, se vuoi fare 3D da codice devi studiarti un minimo di OPENGL: ok, allora devo disegnare un cubo creando prima i suoi sei lati, ognuno composto da 4 vertici - quindi non basta dire box(larghezza, altezza, profondità) - e ad ogni lato applicare una texture (il grosso è disegnarlo, vestire una superficie piatta è semplice). Non mi dilungo troppo anche perchè è solo l’inizio, ma sono felice del primissimo risultato; ho capito che risultati sorprendenti (cioè che mi sorpendono) sono possibili già solo capendo il sistema di primitive (x,y,z) .

Premendo “l” si attiva/disattiva una luce direzionale; premendo il tasto sx del mouse muove la camera, tasto dx zoomin/zoomout e tasto centrale pan; il movimento della cam è gestito da una libreria esterna per Processing, PeasyCam sviluppata da Jonathan Feinberg.

The PeasyCam is positioned on a sphere whose radius is the given distance from the look-at point. Rotations are around axes that pass through the looked-at point.

La grafica 3D come la conosciamo oggi, ha origine dalla teoria della prospettiva a punto unico di fuga, o prospettiva lineare centrica, sviluppata più di 600 anni fa dall’architetto fiorentino Filippo Brunelleschi. Con l’ausilio di due tavolette in legno ed uno specchio, egli calcolava le distanze tra oggetto e punto di osservazione, e così poteva disegnare una sorta di intelaiatura prospettica utile alla rappresentazione artistica e dimostrò l’esistenza di una sorta di punto di fuga all’orizzonte, verso il quale gli oggetti rimpicciolivano.

Poco dopo questa tecnica fu codificata e artisti come Albrecht Dürer iniziarono ad ideare tecniche e apparati atti a produrre rappresentazioni convincenti (realistiche) di spazi 3D su quadri (2D). Anticipando metodologie moderne come il ray-tracing, questi apparati furono i progenitori delle odierne graphic cards, capaci di disegnare miliardi di vertici al secondo. Oggi artisti, designers, architetti e ingegneri usano il computer per creare, manipolare e produrre forme tridimensionali.

In parte tratto da “Processing: A Programming handbook for Visual Designers and Artists”; testo di Simon Greenwold, tradotto dal sottoscritto

Image credits: Scattered Letters from Algirdas Rascius’s Processing code.
Con estremo piacere ho notato che su openprocessing.org, nella classifica dei most favorite’d sketches ci sono ben 4 dei miei sketches fatti con Processing. aah… la mia dose di autostima giornaliera.

Lavorando sul concetto dello steering vector (così ricavabile: ‘desired_velocity’ minus ‘velocity’) - un algoritmo ideato alla fine degli anni 80 da Craig W. Reynolds per far muovere in maniera automatica e pseudo-naturale degli oggetti (characters) nel loro mondo digitale implementando strategie per cercare, muoversi, arrivare, seguire, scappare, seguire un percorso, evitare ostacoli… insomma una sorta di intelligenza artificiale che facesse sembrare ‘vivo’ e in grado di prendere decisioni un character - sono arrivato a creare questo mostriciattolo, una sorta di anemone/medusa.

Senza entrare troppo nei dettagli che comunque potete leggere qui, qui e dal sorgente, ci basti sapere che per ottenere questo movimento ‘organic-like’ dei tentacoli del nostro anemone marino, ho applicato il metodo dello steering vector ad una serie di particelle contenute in 110 ArralyList (s) (particle Systems) con differente massa; il metodo riceve in input un vettore target (un punto x,y) e ritorna una ‘forza’ vettore steer (sterzante) che fa muovere in quella direzione l’oggetto. Poichè la chiave qui è la velocità col quale le particelle si muovono verso il target e visto che hanno massa differente, avremo le parti tonde dei tentacoli (più pesanti) che vi arrivano dopo e quelle più leggere che vi arrivano prima… inoltre usando una semplice sinusoide ecco che l’anemone sembra ‘pulsare’ ed in più ogni ‘tentacolo’ (il singolo particle system fatto di 100 particelle) ruota a partire dalla sua posizione iniziale.

Il bello di Processing, come direbbe Robert Hodgin è che non hai mai idea di dove ’sei diretto’ mentre lavori, cioè, le cose prendono forma mentre scrivi codice e magari parti con un’idea e alla fine ottieni un’altra cosa. Volete sapere a cosa stavo lavorando? Volevo simulare i coronal loops del sole, cioè quegli sbuffi di materia/plasma che si possono osservare sul sole se lo si osserva durante un’eclisse. Poi mi sono reso conto che la versione 2D già realizzata non poteva essere migliorata (a livello di prestazioni) se non facendola divenire 3D con opengl e quindi ho ‘ripiegato’ su quest’altro progetto.

QT .mov file - 19.2Mb

Ecco, nello scorso post dicevo che forse sarebbe valsa la pena di proseguire la ricerca nel campo dei ‘pixel’ per arrivare ad una specie di word processor che usa questo sistema di particelle per comporre i caratteri a video; una prima Applet corredata di sorgente è visualizzabile qui ed in questo video. Per ora ha un bug: non posso cancellare i caratteri e c’è un problema con l’ultima lettera a dx.

Esigenza: trovare un modo per spostare dei punti (istanze di una ipotetica classe con proprietà relative a massa, accelerazione, velocità e posizione e relativo moto e forze - da qui l’effetto ‘organico’ se si usano sempre Vettori per muovere un punto) verso un determinato altro punto. Esiste in processing un metodo statico (get(x,y)) per ricavare il colore e (per come esso viene ricercato) la posizione x y del suddetto pixel (con un doppio loop per popolare un Array 2D).
Ipotizzando di avere una scritta o una forma all’occhio non visibile - perchè renderizzata con un canale alpha troppo basso, ma sufficiente ad essere rilevato come un valore rgb (es. 122545) - ecco che di conseguenza si può (sopratutto) conoscere quella posizione in coordinate cartesiane xy; da qui ho voluto - con la solita classe dei precedenti esperimenti che però appena sono creati vengono solo accelerati verso un altro punto - creare delle istanze che sanno - anche - quale è la loro origine, cioè per ognuna una posizione ‘originaria’ espresa in x ed y alla quale si può ‘tornare’ magari premendo un tasto.
Più o meno è questo il concetto di base e comunque il codice è visualizzabile in questa pagina insieme alla Applet. Premendo un tasto, tutte si spostano verso la loro origine perchè viene applicata una accelerazione verso quel punto; tutte insieme danno origine ad una forma o come in questo caso, del testo. Ma potrebbbe essere il solo colore nero di una qualsiasi foto, non visibile all’occhio ma scannerizzata pixel per pixel da una più evoluta classe Pixel(x, y, color, mass etc)…

Il prossimo step (e su questo progetto forse vale la pena spendere qualche ora) sarebbe di far andare le particelle in una certa direzione che viene impostata in tempo reale, cioè caratteri che si formano mentre si scrive sulla tastiera … E se pò fà…

Ah un’ultima nota su Processing. Ovviamente per quasi qualsiasi applicazione scriviate e certamente per tutte quelle che hanno un otput video, c’è sempre la possibilità (per default, solo importando una delle librerie presenti nel pacchetto) di fare un movie quicktime della grandezza che la vs macchina permette di generare come questo (QT movie 19.729 Kb) in tempo reale mentre la vostra applicazione gira nel suo IDE oppure gererare jpg, png, tiff e pdf.

Emitter series, realizzati con Processing; qui trovate la Applet ed il sorgente della prima versione. Di questa seconda versione, denominata IR1916 (come la galassia a noi più lontana, circa 120 milioni di anni luce dalla Terra) ho caricato il file .mov su Vimeo; purtroppo la compressione non risparmia i singoli pixel in movimento - che sono il particolare che ho cercato e ricercato - e per questo consiglio di scaricare il .mov originale nel portfolio (se scrollate, lo trovate); ho comunque estratto alcuni frames dai quali si nota come l’uso del perlin noise fà sì che si formino delle textures durante la generazione delle particelle e anche per spiegare i concetti di base che governano la colorazione di questo Emitter. mò, con due minuti lo spiego…

Il mio secondo sketch fatto con processing. magnet-ink.

In modalità HSB i colori sono distribuiti su una gamma di 360 possibilità (H), poi c’è la saturazione (S) con scala da 0 a 100 e lo stesso vale per la luminosità (B). Con questo nuovo sketch continuo la mia esplorazione della classe Vector3D: un campo gravitazionale (in realtà è un nuovo vettore di coordinate, e al click calcoliamo la differenza di posizione tra il mouse e tutte le particelle) è creato dal mouse e l’effetto di tavolozza magnetica è dato dal fatto che i colori vengono creati in base alla posizione delle due stecchette da 3px bianche poste a sx e dx dello schermo; tali colori sono strettamente connessi con la massa (in realtà è una doppia mappatura cioè colore in base all’indicatore e massa in base all’indicatore).

L’accelerazione verso il mouse è: accelerazione = Forza / Massa e siccome la massa è variabile, i rossi saranno sempre prossimi al mouse (attratti con più forza e, una volta rilasciati più soggetti all’attrito) e i blu essendo più pesanti arrivano ‘dopo’ verso il mouse e l’attrito li ferma dopo, anche. E ‘ normale, se prendete due biglie di ferro una da 1Kg e l’altra da 1/2 Kg e le lanciate lungo un piano, quella più pesante a parità di velocità iniziale, si fermerà dopo.

Ho distribuito i 360 colori in rapporto all’altezza dello schermo (mi sembrava più semplice ) e sempre in base alla posizione delle due stecchette (li chiameremo indicatori), la particella nascente viene anche dotata di una massa (più è alto l’indicatore verso il punto y=0, meno massa ha la particella). E così progressivamente dall’alto verso il basso le particelle hanno colore e massa differente. Quelle rosse, create in alto avranno massa leggerissima quelle in mezzo (gialle, verdi, azzurre) media e quelle in basso, blu, turchesi, alta.

Ma quante particelle? 35000. Ah. Eh; ho scoperto che in processing, se si usa il renderer P3D, size(800, 600, P3D) si possono applicare calcoli a molte particelle (e anche l’alpha incide sulla smoothness del rendering), ma la cosa che rende possibile il tutto, è l’uso di un ArrayList per craere/distruggere le particelle. Eh si, perchè la tavolozza magnetica magnet-ink ha a disposizione il numero massimo di oggetti definito come limite dell’array (35000). Se una particella tocca il bordo viene eliminata - remove(i) - e crata un’altra al suo posto, in una posizione (quindi con colore, massa e posizione) relativi alla posizione dell’indicatore. Così la tavolozza disegna sempre e soltanto le particelle nuove, rese disponibili sotto forma di nube di particelle colorate con un determinato colore non appena altre escono dallo schermo. Ed escono, poichè c’è un effetto di gravità che trasporta inevitabilmente le particelle fuori dallo schermo, in basso.

Giocateci un pò, io ce posso stare minuti. Un consiglio: fate brevi click col mouse, cercate di mantenere le particelle (tutte) intorno al mouse e poi, in base a dove si trovano gli indicatori (alto o basso) cliccate e muovete il mouse.
Forme che ricordano le esplosioni delle galassie si formeranno in magnet-ink. In più ha un effetto ‘nevicata’ e visto che siamo in periodo…. buone Feste e buona fine e buon inizio!