Gian Carlo Mingati
design and development for interactive media

HyperCube - GC Mingati
Viste le considerazioni degli ultimi mesi in materia di grafica generativa con Processing, e sperimentazione sulla possibile ramificazione degli alberi 3D, non potevo non affrontare lo studio degli L-Systems che poi, sono niente di più che un sistema ricorsivo di riscrittura di stringhe. Ah bene, chissà che mi credevo. Si, ma richiedono moltissima sperimentazione anche se a prima vista appaiono semplici.

In questo breve primo post sugli L-Systems voglio solo annotare alcuni concetti di base nel solito monologo - non necessariamente chiaro e comprensbile - atto a tener traccia dei miei progressi, se di progressi posso parlare; tutti gli L-System, come già visto per gli automi, funzionano richiamando sempre una stessa funzione - sono ricorsivi - che implementa determinate regole e possono essere realizzati con questi elementi:

• Una grammatica generativa (assioma, regole, processo di sostituzione)
• Un parser (di stringhe)

La grammatica generativa.
Per grammatica di un sistema semplice si intende un set di 3 simboli come F+-
I simboli si differenziano in terminali e non-terminali; i simboli terminali (+-) servono, per esempio, a ‘girare’ entro un certo angolo un oggetto disegnato; i simboli non-terminali (F) servono a disegnare un nuovo oggetto. Questi simboli sono convenzioni, si posso usare tutti i simboli che si vuole, ma é sempre meglio attenersi alle convenzioni, per praticità.
All’inizio del processo viene letto un assioma e cioé un simbolo (o più simboli) del linguaggio predefinito (F ma anche F+F o più lunga) a partire dal quale inizia il processo di sostituzione ricorsiva; potremmo definirlo il ’seme’ del processo. A seguire viene applicata la regola, scritta con un qualsiasi elemento del linguaggio predefinito, come per esempio: F+-F–F+F. Ogni volta che il parser incontra un carattere F (non-terminale), genera una nuova forma e rigenera per intero la regola, una volta per ogni simbolo non-terminale; ogni volta che il parser incontra un simbolo terminale (+-) ruota il sistema di coordinate prima di generarla. Voilà, ecco il branching? Non proprio, le piante crescono in un contesto tridimensionale e quindi non basta girare su un asse soltanto. Vanno perciò introdotti altri simboli per effettuare il push ed il pop del matrix stack; per convenzione sono []<>^&
In un contesto bidimensionale però sono sufficienti i set di caratteri di base F+- per creare il Koch snowflake e lo Sierpinski triangle, che sono ritenuti un tipo di frattale.

Il parser.
Questo é il cuore di un L-System, é la funzione ricorsiva che applica la regola iniziale (assioma) e da il via alla generazione della nuova stringa. Ad ogni loop - o generazione - la stringa viene analizzata carattere-per-carattere e genera una nuova stringa, più grande, fino all’infinito. Il solo limite é la potenza del computer sul quale gira il sistema.

L-System test
Axiom: F
Rule: F-<[F>-^-<F]>+F

Insomma, c’è molto da sperimentare perchè le cose si fanno davvero complicate quando si cerca di controllare la complessità/caoticità proprie degli L-Systems; l’appeal estetico di questi sistemi (queste due immagini non sono appealing, ma rendolo l’idea della rapidità di crescita e caoticità di forma ottenibili in sole 6-7 generazioni) risiede nella imprevedibilità delle forme che si possono creare. La tentazione di creare ‘arte’ generativa con questi sistemi é forte, ma c’è un ma: essi sono ricorsivi e deterministici, cioè si ottiene - a fronte di una certa regola - sempre la stessa forma, per quanto inaspetattamente stravagante; per questo esiste la possibilità di complicare ulteriormente la faccenda con sistemi randomici, parametrici, dipendenti dal contesto e/o da altri fattori. Di queste amenità continuerò l’esplorazione, chissà che non mi esca qualcosa di interessante.

VIZLAB - Digital Images for Architecture and Design - www.vizlab.it
Image credits: Parque Comercial Empresarial, Los Carmenes, Spain, 2009 - © adhoc msl + modostudio

Gli amici di modostudio hanno chiesto la mia collaborazione per un nuovo progetto: Vizlab. Vizlab é il loro Visualization Department cioé l’area dello studio dedicata ai rendering; per un buon showcase dei loro incredibili lavori, abbiamo pensato di realizzare una gallery di immagini fullscreen con una interfaccia minimale ed effetti di fading fra una slide e l’altra, con jQuery, ovviamente. Dai rendering pubblicati ci si rende subito conto che ricerca, sviluppo ed un elevato livello tecnico rappresentano il motore e la vision del gruppo; modostudio/vizlab é una realtà tra le più promettenti del panorama italiano… e come si dice? Una immagine vale più di mille parole.

Dal punto di vista design/development del minisito, oltre a consigliarvi di dare uno sguardo al codice JavaScript (jQuery), posso anticiparvi che parti di esso potrebbero essere utilizzate per costruire soluzioni similari o più avanzate; non entrerò troppo nel dettaglio ma posso dire che data l’esigenza di dover visualizzare delle immagini a fullscreen, l’unico problema poteva essere quello di dover attendere il caricamento delle stesse (5, 25 o 100 e molto grandi) prima di far partire lo slideshow (come avviene per slideViewer e slideViewer Pro). Per risolvere il problema ho pensato di sviluppare una soluzione in cui gli oggetti immagine vengono reperiti a partire da un file JSON nel quale si trovano il path e la descrizione - non sono quindi inseriti del DOM della pagina; in questo modo, definito un limite minimo di attesa (per es. si attenda che le prime 3 immagini siano in memoria) é possibile far partire lo slideshow. Non é di certo una soluzione non intrusiva (se JavaScript é disabilitato non si vede nulla) ma se state tutti in fissa con FaceBook vuol dire che avete tutti JS abilitato.

In realtà si tratta del motore per slideshow basati su JSON che avevo ideato per visualizzare le mie foto da flickr ma che non ho mai realmente completato e reso pubblico sotto forma di plugin poichè in questo momento sono più interessato allo sviluppo con Processing. In ogni caso, usando il metodo getJSON() é possibile parsare un file di questo tipo ed utilizzarlo per costruire a runtime tutto il DOM che volete; poche righe di codice per un risultato professionale e la base per un plugin molto interessante, che mi riprometto di completare, prima o poi.

Self-Portrait, March 2010.
Fun with Processing and OpenCV.
Finalmente sono riuscito a far funzionare OpenCV (Processing implementation) sul mio PC. Questa immagine è il risultato della elaborazione con Processing e OpenCV del video feed proveniente dalla mia webcam: analizzando la luminosità brightness() dei singoli pixel di ogni frame, e sapendo che il risultato è per forza compreso nel range 0-255, è possibile usare tale valore per spostare sull’asse Z dei vertici che una volta uniti, formeranno delle linee. Maggior brighness maggior Z cioè più vicino.

Image credits: Conus Textile. Wikipedia.
Il pattern del guscio é generato con meccanismi che ricordano quelli degli automi cellulari, cioé ogni cellula secerne pigmento a seconda dello stato di attività delle cellule adiacenti.

Ho indagato sull’ offscreen buffer di Processing, ed in particolare su come lo si può usare per ottenere e manipolare immagini generate a runtime. Con l’oggetto PGraphics e i metodi beginDraw() ed endDraw(), è possibile disegnare (anche in 3D) fuori dallo schermo, e poi usare l’immagine ottenuta per eseguire ulteriori calcoli e/o applicare effetti e usarla come fosse una qualsiasi immagine da visualizzare a schermo; in realtà pGraphics si usa molto spesso per l’output ad alta risoluzione da Processing (per es. immagini TIFF da 3000 px di larghezza), ma in questo caso, ho utilizzato questi buffer (nel mio caso sono 6, 251 px di lato) per disegnare una serie di patterns per mezzo di un automa unidimensionale. Gli automi sono molto interessanti perchè a dispetto della loro apparente semplicità producono risultati inaspettati e sorprendenti; frattali, automi, L-systems e in genere tutte le funzioni ricorsive governate da ‘regole’ servono a comprendere e spiegare i modelli morfologici di una grande varietà di organismi del mondo che ci circonda; in computer graphics quindi, questa serie di algoritmi e regole rappresentano l’unica via per poter simulare efficacemente organismi complessi, come le piante.

Elementary Cellular Automaton
http://www.openprocessing.org/visuals/?visualID=8207 - GC Mingati

Un Cellular Cutomata (CA) di tipo unidimensionale é un sistema composto da griglie di celle e regole che definiscono le modalità di comportamento di ogni cella, per ogni nuova generazione, a seconda dello stato (colore) dei suoi vicini. In altre parole, supponendo di avere una riga di 3 pixel posti orizzontalmente ed il pixel di mezzo bianco con gli altre due vicini neri, possiamo stabilire, di generazione in generazione quale sarà il colore risultante da questa condizione di vicinato. Avremo quindi una nuova condizione, a cui applicare una nuova regola. E così via. Ci sono 8 possibili configurazioni di vicinato da cui scaturiscono 256 possibili regole.

Nella Applet ho usato l’oggetto PGraphics per disegnare un automa su ogni faccia. Una volta completato il render delle facce, potete premere ‘r’ da tastiera per disegnare nuovi pattern.

Image credits: Perlin noise visualization.
http://www.openprocessing.org/visuals/?visualID=8172 - GC Mingati

La funzione noise() é comoda per generare una serie di numeri in successione con casualità controllata; la tecnica inventata da Ken Perlin negli anni ‘80 é stata spesso usata in computer graphics per imitare l’ apparente randomicità delle textures in natura o per riprodurre terreni, forme ecc. In queste immagini, si può vedere come il ‘Perlin noise’, influenzando la velocità delle particelle rosse, faccia variare il moto delle stesse ammassandole in forme sinuose che ricordano i vasi sanguigni e i meandri dei fiumi visti da grande altitudine. Nella Applet, ho aggiunto attrito e gravità orizzontale per influenzare ulteriormente questo ordine aggiungendo disordine; ne é derivato un caos su cui ho voluto indagare qualche ora.

Lo scorso mese di ottobre, ho acquistato un MiniMag - della tedesca Multiplex. Dicevo ma che aerei, non c’è paragone; vuoi mettere la complessità, le performances, la bellezza del volo stazionario e traslato degli elicotteri? E invece inizio a prenderci sempre più gusto, al punto che in tutto questo periodo invernale ho raramente levato in volo il Logo500 in favore di questo piccolo e leggerissimo modello in Elapor® - un materiale brevettato da Multiplex simile all’EPP (Expanded PolyPropylene), ma molto più resistente.

Ecco una breve recensione su questo famigerato modello stravenduto in tutto il mondo, adatto a principianti e piloti con esperienza intermedia; il MiniMag è un trainer ad ala alta del peso di 550/600 gr. (all-up-weight), molto semplice da montare, leggero e facile da far volare. Tutti i modelli Multiplex sono fatti in Elapor e si assemblano con poche ore di lavoro incollando le parti con colla cianoacrilica; il kit contiene i due gusci della fusoliera, le ali (costituite da un unico pezzo) con relativi incavi per i servi, la deriva, il piano di coda, un resistente carrello in acciaio, tiranteria, rinforzi, decals ed un motore a spazzole classe 400. Investigando un po sui vari forum ho capito che era meglio dotarlo da subito di un motore più potente tipo brushless Hacker A20-22L ed elica 8×6; scelta azzeccata visto che con questo motore, associato ad una batteria 3S (11,1V 1300mAh) si ottengono decolli ‘verticali’ e si esce facilmente da qualsiasi situazione di incertezza con ‘un tocco’ alla manetta del gas; gli assorbimenti sono inferiori ai 20A, e per ogni pacco batterie ci si diverte per una decina di minuti.

Il modello non é dotato di ruotino di coda sterzante, quindi non c’è possibilità di rullare in posizione attendendo l’ok della torre così come non c’è modo di mantenerlo allineato alla pista una volta atterrati ma il decollo (col motore Hacker) avviene in 3 metri scarsi ed una volta in aria il MiniMag rivela da subito caratteristiche di volo molto prevedibili, buona manovrabilità, ottime doti di planata ed è molto, molto rilassante (rispetto al mio Logo500 con i suoi 700 Watt di assorbimento ed un peso di 2.5Kg che ti costringe ad un continuo controllo ed impegno perchè non permette errori); un modello adatto a tutti, che si può far volare anche senza gli alettoni (ricavabili dalle apposite scanalature nelle ali) ma che consiglio di utilizzare, perchè rendono il tutto molto più governabile e si riesce a volare con venti medio/sostenuti - a patto di avere un pista di atterraggio orientata nella direzione del vento, perchè per esperienza vi assicuro che atterrare con venti laterali con un modello così leggero non è facile; piccolo e facilmente trasportabile, il MiniMag sarà il vostro compagno di viaggio per le scampagnate e le vacanze al lago (si possono mettere galleggianti per atterrare e partire dall’acqua) e vi permetterà di farvi le ossa per poter passare a modelli più grandi ed impegnativi in balsa e/o materiali compositi come per esempio questo bellissimo de Havilland Canada DHC-6 Twin Otter della americana Hangar 9.

de Havilland Canada DHC-6 Twin Otter. © Hangar 9

Alcuni dati sul MiniMag: apertura alare 1010 mm; lunghezza 820 mm; area delle ali 22 dm2; carico alare (FAI) 26 gr/dm2; motorizzazione consigliata Hacker A20-22L + prop 8×6 + batteria 3S; funzioni: timone/elevatore/alettoni.

Investigando ulteriormente nella modellazione di coni e clindri al fine di poter generare alberi realistici, ho preso (come é naturale se si usa Processing) tutta un’altra strada; per realizzare ciò che avevo in mente avevo due problemi da risolvere: (1) orientare un oggetto nella direzione di un punto in continuo movimento e/o generato randomicamente e (2) scrivere una funzione di branching per i rami. Il punto 1 mi sembrava ragionevolmente semplice da risolvere, ma ben presto mi sono reso conto che non lo era affatto. Il punto 2, senza aver risolto il punto 1 era inutile affrontarlo. Grazie all’aiuto di Dave Bollinger però ho potuto fare il reverse-engineering del codice che descrive le coordinate sferiche ed in particolare, dato un punto iniziale ed uno finale, trattarli come fossero il centro ed un punto sulla superficie di una sfera e quindi calcolare raggio e rotazione sugli assi.

// Let particle b coords be the desired base center, and particle a coords be the desired top center.
Particle a;
Particle b;
//If that's where the center of the base stays, then the center of the top needs to end up at:
PVector c = new PVector(a.position().x()-b.position().x(),a.position().y()-b.position().y(),a.position().z()-b.position().z());
float h = dist(0,0,0,c.x,c.y,c.z);
//then define the radius
float r = sqrt(pow(c.x,2)+pow(c.y,2)+pow(c.z,2));
float theta = atan2(c.y,c.x);
float phi = acos(c.z/r); //thank you Dave!
pushMatrix();
//now translate to b position
translate(b.position().x(),b.position().y(),b.position().z());
//and rotate the new tentacle segment
rotateZ(theta);
rotateY(phi);
rotateX(-HALF_PI);
//Segment to rotate
popMatrix();

Queste poche righe, in Processing permettono di ruotare un qualsiasi oggetto nella direzione definita da un altro sistema di coordinate; se volete usarlo per i vostri esperimenti, troverete la Applet corredata di classi nel link sotto al video, o anche qui; col mouse e tasto sx premuto potete ruotare la bestia, e avvicinarvi ed allontanarvi col tasto dx.

Tentacles.
Il mostro é nato perchè una volta trovato il modo di orientare i nuovi coni verso la direzione voluta, ed avendo definito ognuno dei due punti di ancoraggio del cono (centro della circonferenza inferiore e centro della circonferenza superiore) con altrettante particelle unite da una spring (una molla), ecco che variando le distanze variava la lunghezza del cono ed anche (per via del ‘molleggio’ e qualche altro parametro) la rotazione. E’ stato un attimo creare tentacoli. Le particelle e le springs sono realizzate con la libreria per Processing traer.physics la quale permette anche - dato un sistema di particelle - di definire una gravità sui 3 assi ed un attrito. Applicando attrito, una gravità negativa sull’asse y, una differente massa per ogni particella del tentacolo (crescente verso la parte più lontana dalla base) ed una gravità che varia continuamente tra -1 ed 1 sull’asse x, ecco che i tentacoli hanno iniziato a muoversi sinuosamente e l’effetto finale é davvero naturale. Ho aggiunto una texture ‘urticante’ et voilà: Tentacles. Una bestia velenosissima - in genere le creature marine con colori sgargianti sono sempre velenose.

Image credits: magTentacle
http://www.openprocessing.org/visuals/?visualID=7207 - GC Mingati

Qualche mese fa, Sue Jenkins (Luckychair) mi ha chiesto il permesso - prontamente accordato - per poter pubblicare sul suo libro di prossima uscita “Web Design All-in-One For Dummies“, in una sezione relativa alla creazione di gallerie di immagini, un tutorial su slideViewer - il mio famigerato quanto semplice (per dummies?) jQuery plugin; il libro è uscito, e alle pagine 447-449 (Chapter 8 > Creating slide shows) si parla proprio del mio plugin e di come costruire una galleria di immagini per il proprio sito. Sono piccole soddisfazioni, ma questo dimostra quanto alla fine, lavorare ‘per gli altri’ porti sempre buoni frutti.

In celebration of jQuery’s 4th birthday, the jQuery team announces the latest major release of the jQuery JavaScript library! A lot of coding, testing, and documenting has gone into this release.

Innanzi tutto, felice 2010.

Sarà stata l’aria di Ortisei, la neve e i boschi ma da quando sono tornato ho in mente di voler realizzare degli alberi con Processing. Ho creato una versione molto semplificata e stilizzata di un pino (per il momento é quanto sono riusciuto a pensare con qualche ora di tempo libero) ma ammetto che per realizzare forme convincenti c’è molto da approfondire sulle strutture geometriche e matematiche costruite dalla natura - in particolare sui frattali. Si può trovare qualche compromesso, probabilmente, ma ritengo interessante cercare di riprodurre il pattern col quale si dispongono e suddividono i rami nelle piante. Si lo so, non ci siamo. Almeno non al primo sketch.

Per creare questi alberelli ’simil-Lego’ ho pensato di partire disegnando un tronco principale (una linea posizionata randomicamente e con altezza casuale, il cui spessore diminuisce mentre si sale) e dei rami, anche questi con spessore e lunghezza decrescente.

Per i rami ho quindi semplicemente disegnato delle rette le cui coordinate esterne x e z (come fosse solo in 2D) fossero: x = initPos.x + radius * cos(theta); z = initPos.z + radius * sin(theta); qui PVector initPos contiene le coordinate x, y, z del tronco; radius è la lunghezza del ramo, e diminuisce mentre si sale. In pratica non ho fatto altro che calcolare alcuni dei punti che descrivono una serie di cerchi con raggio decrescente e poi ho usato tali coordinate per descrive l’ancoraggio del secondo punto (quello esterno) dei rami (i punti iniziali sono gli stessi del tronco). Salendo con la y (-y) ecco che i rami vengono wrappati attorno al tronco e divengono sempre più corti, fino alla cima, dove radius è 0. Il codice dello sketch e la Applet li trovate nel link sotto al video (il risultato finale è abbastanza gradevole).

Image credits: Recursive Tree. Rendered with p5sunflow lib - GC Mingati

Ecco invece una versione in cui rami e tronchi sono formati da coni/cilindri. Questo mi permette di ottenere un effetto 3D pieno e - se riesco - texturizabile; ma quello che appare subito evidente é che usando una funzione ricorsiva si ottengono rapidamente più rami (una funzione ricorsiva richiama se stessa fino a quando una data condizione non viene raggiunta - in questo esempio un numero di 5 cicli). Anche questo esempio é visibile sotto forma di Applet a questa url, ma credo dovrò cambiare radicalmente modalità di generazione: la ricursività non soddisfa la randomicità di forma/lunghezza che desidero poichè in realtà i rami nascono ruotati randomicamente sugli assi Z ed X solo alla prima generazione; i rami più piccoli sono copie rimpicciolite dei primi e non sono riuscito a trovare un modo per allontanarli dai loro ’simili’; credo però che aggiungendo una forza magnetico-repulsiva ad ogni ramo eviterò che essi si sovrappongano (al momento è inevitabile) e probabilmente avranno una forma più naturale.

Image credits: pineTree forest
http://www.openprocessing.org/visuals/?visualID=6824 - GC Mingati

Anche quest’anno quindi parecchi progetti da realizzare - alcuni ancora troppo complessi visti i miei skills attuali e per il tempo che richiedono (terreni 3D, alberi, flocking e piante mosse dal vento) e altri certamente più ‘alla portata’ (approfondire Struts e lo sviluppo delle apps J2EE) ma tutti comunque necessiteranno di costanza ed impegno. Ho un anno a diposizione, e Saturno contro…