Tre o quattro settimane fa, il fotografo Ken Schles mi ha contattato chiedendomi se potevo aiutarlo ad implementare slideViewerPro (il mio jQuery gallery engine) sul suo sito; mi capita abbastanza spesso di ricevere richieste di ‘aiuto’ o di implementazioni di nuove features. Questo ‘Ken’ mi aveva inviato anche una url per vedere come stava implementando l’engine e per farsi aiutare a risolvere alcuni problemi di allineamento su altri elementi della pagina; incollo la url nel browser e appena parte lo slider ecco apparire volti molto noti, tra i quali mi sembra di riconoscere Rod Stewart, Alicia Keys e Martin Scorsese. Dico, ma chi é questo Ken? Leggo la sua bio e mi accorgo che é uno dei fotografi americani più noti ed importanti, con esposizioni permanenti al MoMa di New York, autore di libri definiti una “intellectual milestones in photography” (Süddeutsche Zeitung) e di foto degli album di rock bands come Cypress Hill e Green Day, solo per citarne alcune. Insomma un pro della macchina fotografica.

In un primo momento ho tentato di applicare qualche fix al CSS ma mi sono subito reso conto che avendo Ken costruito quel sito nell’arco di alcuni anni, si era portato dietro parecchie incongruenze e ripetizioni inutili nelle dichiarazioni; un altro grande problema risiedeva nel fatto che nessuna pagina aveva lo stesso markup della precedente: ogni pagina era unica. Ovvio, un progetto amatoriale ma tutto sommato abbastanza bene eseguito; si vede che usa un Mac e che il suo browser di riferimento deve essere Safari: ha usato selettori ed animazioni ‘tipiche’ del webkit, molto avanzate e questo mi ha stupito. Comunque, mi sono proposto di riscrivere per intero il CSS e anche i templates dai quali avrebbe potuto continuare da solo a ricodificare l’intero sito; era l’unico modo - fra l’altro - di far funzionare correttamente la gallery e rendere la grafica consistente in tutte le pagine. Oggi lo ha pubblicato e sono davvero contento di averlo aiutato a ricostruire questo suo sito, nel quale evidentemente ha investito ore di lavoro e voglia di imparare. Bravo Ken.

Confermo che se dovessi consigliare un hosting provider a qualcuno gli direi di affidarsi a (mt) MediaTemple, come ho fatto io nel ‘lontano’ 3 dicembre 2002 quando già si parlava di mt perché sembrava essere il provider de-facto per la maggior parte dei siti di designers di fama internazionale e Fortune-500 companies. E infatti da allora, zero problemi. Ieri ho ricevuto una mail da mt nella quale mi si chiedeva di passare (gratuitamente) al Grid-Service poichè il ‘vecchio’ Shared-Server sarebbe stato dismesso a partire dal prossimo 19 luglio. mt ha predisposto una ‘Migrate to the Grid’ web app dalla quale ho potuto - davvero con 3 click - registrare il nuovo DNS, backuppare, migrare e far funzionare il tutto in 12 ore! Una breve interruzione di servizio (5 minuti) e nessun problema di DB, connessioni o malfunzionamenti.

(gs) is a cluster-based, modern hosting service powered by hundreds of servers working in tandem to power your websites, applications and email with unrivaled power, burstability and reliability. The Grid system is designed for continuous operation 24/7/365.

Da oggi, sempre per soli 100 USD annuali (prezzo per una soluzione ‘lite’) ho 50GBs di spazio, 512GBs di network transfer mensile disponibile, antispam, rinnovato custom control panel, 100 databases.

The oil leak near the wellhead surface location (28.73756°, -88.36166°)
Image source: www.geoplatform.gov/gulfresponse/ - Mosaic Aerial Images

La falla, apertasi sul fondale sabbioso a 1700 metri per la rottura di un tubo é alimentata dal giacimento posto 1500 più in fondo. Il pozzo è finito fuori controllo a causa del mancato funzionamento dei sistemi automatici di interruzione del flusso (BOP) ed ha riversato in mare - fino ad oggi - 35/40 milioni di galloni di greggio (150 milioni di litri) al ritmo di 35/60 mila barili al giorno (sono in corso test per cercare di capire l’entità della perdita) causando uno tra i più gravi incidenti petroliferi che l’umanità abbia mai dovuto affrontare, e che abbia mai causato. Va detto che ci sono stati altri incidenti in passato (nel 1989 un’altra piattaforma off shore e sempre nel Golfo del Messico, (la Ixtoc I) riversò 150 milioni di barili di petrolio in acqua e ci vollero 10 mesi per fermare la perdita), mentre la Exxon Valdez sempre nell’89 riversò in mare il suo carico di circa 40 milioni di litri in seguito alla collisione con un reef sulla costa della Bligh Island in Alaska, ma mai si era verificata una falla a queste profondità, dove con 150 atmosfere di pressione, possono operare soltanto mezzi comandati dalla superficie. Se i dati sulla quantità di greggio che fuoriesce giornalmente dal pozzo fosse rivisto in positivo (probabile), cioè confermando una perdita di 60 mila barili al giorno, si avrebbe una quantià di greggio disperso che é pari a quello della Exxon Valdez, ogni 4-6 giorni. BP potrebbe trovarsi alla fine a dover pagare centinaia di milardi di dollari tra risarcimenti e costi di gestione della situazione (trivellazioni, nuovi sistemi di contenimento, ripulitura coste).

Ci sono buone possibilità che l’operazione ‘top-cap’ si concluda con un parziale successo ed in ogni caso se entro agosto i due pozzi attualmente in costruzione non riusciranno ad intercettare il condotto all’altezza del giacimento (operazione molto difficile da portare a termine con successo), potremmo veder sgorgare il petrolio per anni; il geologo Jill Schneiderman ha rinominato l’incidente il pozzo di Pandora; per allora potrebbero essersi riversati in mare altri 200-400 milioni di litri, se tutto va male, ed inoltre il grosso del greggio non sale in superficie ma resta sul fondale sotto forma di gigantesche chiazze spesse decine di metri, larghe kilometri. Sul sito di British Petroleum (che ad oggi ha speso 1 miliardo di dollari solo per le operazioni) si posso seguire in diretta le operazioni dalle telecamere montate sui 12 ROVs (remote operated vehicles); BP sta inoltre costruendo un enorme ‘barile’ di contenimento collegato ad una dozzina di superpompe che verrà posto sopra al blow out preventer (BOP) fallato ma non ho capito se verrà calato sul fondo.

June 2 2010, 12:43 pm CDT.
The oil spill as seen by the Skandi ROV2, holding its position at -1484m on top of the failed blow out preventer.

Ma quando la smetteremo di trivellare, di sporcare, di consumare, di distruggere, di mentire? Abbiamo un solo mare, un solo cielo, e facciamo finta che non sia così; da giorni seguo con grande apprensione, grazie ai vari live feeds, le operazioni di contenimento della falla ma più le guardo e più penso che siamo piccoli, presuntuosi, aggressivi e irresponsabili; guardo le ‘braccine’ di quei ROV, sballottati dalla corrente generata dal geyser di petrolio e gas mentre cercano di avvitare un bullone, o segare un tubo, e mi chiedo se riusciranno a porre fine al disastro prima di agosto e quali saranno le conseguenze se il petrolio dovesse essere trasportato dalle correnti atlantiche (di superficie) fino in Europa.

June 23, 2010 - 12:48 p.m. ET
La stima per eccesso (ma certamente vicina alla realtà) parla di 8.750.000 litri di petrolio riversati ogni giorno. BP ha dovuto momentaneamente rimuovere il lower marine riser package (LMRP) cap containment system (che almeno conteneva minimamente la perdita) per problemi tecnici dovuti alla collisione tra uno dei ROV ed il sistema di pompaggio di acqua calda, che serve ad evitare la formazione di cristalli di ghiaccio nel sistema di recupero parziale.

July 5, 2010.
Nel Golfo del Messico é iniziata la stagione degli uragani e per BP aumentano i ritardi e le difficoltà nella raccolta del greggio in superficie, mentre a -1500m il pozzo continua ad alimentare una marea nerissima - di Naomi Klein, l’Espresso.

July 13, 2010.
BP mostra un cauto ottimismo, e speriamo abbia ragione nonostante l’ormai obbligatoria premessa che “the sealing cap system never before has been deployed at these depths or under these conditions, and its efficiency and ability to contain the oil and gas cannot be assured”. Il nuovo sealing cap é incorso di assemblaggio; devono poi iniziare i test per vedere se davvero si riesce a bloccare la falla; durante le operazioni di assemblaggio di questo nuovo cap e nel rimuovere il ‘vecchio’ lower marine riser package (LMRP) containment cap si é reso necessario lasciare il pozzo completamente aperto mentre il geyser di gas e petrolio riversa nell’oceano 60.000 barili al giorno.

July 16, 2010.
La falla é chiusa.

July 15 2010, 6:00pm CDT, 12:43 pm CDT.
The well integrity test on the MC252 well commenced today; full closure of the choke valve occurred at approximately 2:25pm.

Per la prima volta, dopo 86 giorni di disastri la falla sembra essere chiusa. In realtà la chiusura delle valvole di questo nuovo ‘tappo’ da 75 tonnellate il cui risultato più evidente é la totale assenza di fuoriuscita di greggio in acqua, rappresenta l’inizio di una serie di test per verificare la tenuta del sistema di contenimento e la pressione nella falla. Se la pressione non sale agli 8-900 psi previsti significa che qualcosa non va come dovrebbe; mi spiego. Il petrolio è liquido e il liquido non è comprimibile. Se mettiamo un tappo su di un tubo, la pressione (se il tappo regge) si stabilizza quasi subito poichè l’acqua - o il liquido - non potendo essere ulteriormente compresso, resta bloccato stabilizzandosi ad una certa elevata pressione. Al momento, dai test in corso, la pressione sta salendo ma non ha raggiunto i livelli sperati. Questo potrebbe, ma non vuol dire di certo, che il condotto che porta petrolio dal giacimento posto a 1500 metri oltre il fondo marino al blow out preventer fallato, potrebbe dico potrebbe essersi rotto. Speriamo di no, è presto per dirlo e comunque finchè la pressione sale e non scende è buon segno. Incrociamo le dita.

August 4, 2010.
Ha funzionato. E continua a reggere. Ieri BP ha annunciato di aver iniettato nel pozzo, per otto ore, fanghi ad alta pressione. Questi fanghi ora esercitano una contro-pressione idrostatica mentre i due relief wells continuano a venir scavati e dovrebbero intercettare il pozzo per la metà del mese corrente.

Aiming System.
Made with Processing + jBullet.

Typo Mishap.
Applet and source code: http://www.openprocessing.org/visuals/?visualID=9333

Come anticipato, inizio a studiarmi jBullet - il Java port di Bullet Physics (open source collision detection, rigid and soft body dynamics library), visto che é proprio quello che serve per aggiungere convincenti effetti di fisica agli oggetti 3D disegnati in Processing; la lib é molto complessa ed espone centinaia di classi e metodi per calcolare collisioni, primitive, inierzia, posizioni, piani, velocità, accelerazioni, punti di contatto, shapes convesse e concave, eventi, algoritmi ecc… Si é reso necessario un decompiler per leggere le classi (.java) contenute nel .jar della demo Applet originale; questo é l’unico modo per poter affrontare le API di Bullet Physics almeno per identificare chi-fa-cosa. In questa situazione iniziale é chiaro che per comprendere, devo ricostruire la demo base trovando però un punto di contatto efficiente tra le funzionalità di disegno (rendering) in Processing e quelle di calcolo di forme e comportamenti in Bullet. Comunque - e questa é la parte che mi entusiasma - non ci sono limiti a ciò che si può realizzare, perché questa libreria é scelta come framework per le simulazioni da almeno 3 su 10 tra le Top Game Companies che sfornano videogames per Wii e PS3.

Kill ‘em all!
Posso creare forme e lanciarle nella direzione del lookAt point della camera partendo dalla posizione della stessa. Delle vere e proprie cannonate!

Nello sketch in cui ho tentato di usare per la prima volta Bullet, riprodotto nel video in alto, ad ogni key press la lettera o il numero corrispondente vengono creati e per effetto della gravità piombano sul piano sottostante; le forme sono dei veri e propri corpi rigidi che si fermano sui loro punti di contatto senza attraversarsi. La versione con cui si può ‘giocare’ sotto forma di Applet corredata di sorgente, è come al solito disponbile su OpenProcessing. Col mouse e tasto sx si ruota, col dx si fa zoom, e con la tastiera si creano i Characters.

Il poter simulare la matericità delle cose, ottenere reazioni in seguito ad azioni (come avviene nel mondo che ci circonda) suscita in me la stessa ‘frenesia creativa’ che potrebbe avere un pittore messo di fronte alla più grande tela bianca che potesse desiderare.

Come già visto in qualche post precedente, l’oggetto PGraphics permette di disegnare offscreen; è possibile poi analizzare pixel-per-pixel l’immagine PImage generata ed utilizzare le informazioni come colore e posizione dei pixel per inventarsi qualcos’altro. Da qualche giorno ho scoperto una tecnica per scrivere in 3D partendo da ‘pixel font’ originariamente renderizzati in 2D (i pixel font sono caratteri appositamente realizzati per poter risultare leggibili a dimensioni ridottissime, molto usati nei siti Flash, senza antialias) su di un PGraphics. Ho realizzato queste due Applet dalle quali potrete capire il funzionamento ma avrete la pazienza di studiarvele senza ulteriori indicazioni. Intanto sto indagando ulteriormente per applicare della fisica con jBullet, al fine di poter simulare la collisione tra le forme. Posterò gli sviluppi.

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.

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.

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.