Gian Carlo Mingati. Design and development for interactive media.

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

Ebbene si, il giorno 4 settembre 2009, ore 18.00; mancano 23 giorni da oggi. Dopo 9 anni insieme e tre di convivenza io e Alessandra (Lallo) ‘convoliamo’ a nozze.

Checklist: organizzata la cerimonia, il party, il viaggio, fatto fare gli abiti, le fedi, le torte, stampate le partecipazioni - hanno la grafica che vedete nell’immagine qui sopra, che ci sembrava più originale invece di spedire le solite partecipazioni in cartoncino standard con font graziato dorato, - musica, location ok… ora una certa ansia personalmente mi pervade, ma sono molto molto felice. E poi, lunedi 7 settembre partiamo per un viaggio on the road degli USA.

Oggi abbiamo pubblicato questo minisito con tutti i dettagli e i riferimenti per partecipare alla lista.

Ma quanto costa questo network transfer?
Ho scoperto che la popolarità - passatemi il termine - di alcune pagine di questo sito è talmente elevata (e mi fà piacere, ovviamente) che mi si bruciano più di 30 Gigabytes di network transfer ogni mese; stando alle statistiche della mia (mt) hosting solution, questo sito ha più di 80.000 hits al giorno e circa 4000 visite totali alle singole pagine dei miei plugins jQuery (slideViewer in testa). Google Analytics lo conferma.

Cosa sono le hits e cosa sono le page views? In pratica ogni hit rappresenta la richiesta da parte di un browser di ogni singolo elemento di una pagina - per esempio una pagina con 1 file esterno css, 1 file immagine e la pagina stessa sono 3 hits e 1 page view. E questo, se si supera un certo limite ha un costo: essendo cliente di MediaTemple (mt) dal 2002 ed essendo rimasto sullo shared server, pago poco meno di 120 euro l’anno; oggi, usare (mt) come hosting provider costa almeno 20$ al mese (240 l’anno) … quindi mi tengo il mio servizio base con i suoi limiti di network transfer.
Fino a pochi mesi fa non avevo mai dato uno sguardo a questa faccenda del consumo mensile di banda, ma queste due pagine su jQuery sono a loro volta linkate dalla lista di plugin del sito jQuery (sulla quale chiunque sviluppi un plugin può linkare il suo lavoro) ed è da lì che arriva tutto questo traffico. Inoltre, slideViewer è spesso linkato da quei post sulle “migliori 10, 100, 1000 javascript galleries e/o ajax solutions per il tuo sito” e da lì parte altro traffico.

Ho potuto verificare che se una pagina è molto linkata ed il testo in essa contenuto (ma anche i tags H1, H2 e in genere i tags di intestazione) corrisponde ad un certo tipo di keywords (come per esempio slider, viewer, jquery), ecco che cercandole con Google il primo link è sempre quello alla pagina di slideViewer servita dal mio account su (mt). Insomma sale il PageRank, il famoso algoritmo col quale Google indicizza il world wide web… e diminuisce il network transfer disponibile per il mese.

Ma… a proposito di PageRank:

Insomma, sforare i 30 Giga di network transfer mensili si traduce in un sovraprezzo di $.50 per Giga in più e - ad oggi - siamo già a 4 in più. Non mi resta che diminuire la qualità delle immagini dei miei sliders (peccato) perchè ogni giorno tutte le immagini di quelle pagine vengono servite a 2-3000 utenti e così si fà presto a raggiungere i 30 Giga prima della fine del mese.

Durante la fase iniziale dello sviluppo di un widget jQuery un bel pò più articolato, mi sono ritrovato al punto in cui offset().left e top, ed il loro utilizzo erano chiari; ho quindi deciso di condividere con voi questi ‘effettini’ trasformandoli in un piccolo plugin con funzionalità di Zoom e Pan (ingrandimento e scroll in base alla X e Y del puntatore del mouse).

Si chiama miniZoomPan e funziona così: si prepara il markup composto da una DIV con un ID e dentro ci si mette un’immagine; la classica immagine in un post, per esempio.

<div id="zoom01">
<img src="leaf_s.jpg" />
</div>


Si instanzia il plugin (scaricabile qui) in questo modo:

$(function() {
$("#zoom01").miniZoomPan({
sW: 200, //small image width and height
sH: 250,
lW: 370, //large image width and height
lH: 462
// other options
/*
frameColor: "#cecece",
frameWidth: 1,
loaderContent: "loading..." // text or image tag eg.: "<img src='spinner.gif' />"
*/
})
});


Fatto. Come potete notare sW e sH sono le dimensioni dell’immagine piccola, mentre lW e lH sono quelle dell’ingrandimento. Obbligatoriamente le vs. immagini dovranno avere la parte finale del nome file modificato ad hoc (mycat_s.jpg per la piccola, mycat_l.jpg per la grande).
A questo punto quando vi posizionate sull’immagine, ne viene caricata una di dimensioni maggiori (grande quanto volete) che scrollerà in base alla posizione del mouse. Un preload customizzabile con testo o con una gif informa l’utente del caricamento in corso.

Qui trovate la pagina d’esempio, dove con un minimo di pazienza potrete recuperare il CSS e lo script che comunque per comodità potete prelevare rispettivamente qui e qui. Si tratta di piccolo plugin senza pretese, che però può servire su un online store per visualizzare al volo l’ingrandimento di una maglietta o di un oggetto senza dover cambiare pagina o usare finestre modali.

miniZoomPan plugin. Enjoy.

Image credits: Alien Blob - J. Bumgardner
In questi giorni ho potuto rimettere le mani su un ‘vecchio’ progetto, dopo che per caso mi sono dovuto cimentare nella realizzazione di qualcosa di simile, che poi mi è servito - con le opportune modifiche - per proseguire nella realizzazione di questo plugin per jQuery: slideViewerPro.

Devo dire che sono soddisfatto del risultato finale visto che tra le richieste di updates per il suo predecessore c’erano la possibilità di far avanzare le slides in modo automatico e di poter avere delle thumbnails da selezionare, in alternativa ai numeri; slideViewerPro ha tutto questo, e altre opzioni. Ho anche scritto un tutorial in inglese grazie al quale - forse - si capisce come costruire uno slider per immagini da mettere nel proprio blog, o da usare come base per uno slideshow di progetti; per questo non riporto porzioni di codice o istruzioni su questo post.
Inoltre è nata una collaborazione a ‘due mani’ di cui però non darò ulteriori dettagli se non che con questo mio ‘asiatico’ collaboratore stiamo lavorando ad un merge tra le due versioni di slideviewer (1.1 e Pro); in pratica alla fine dovremmo arrivare alla realizzazione di una complete-gallery-solution cioè un unico script che con un paio di settings proponga una UI con numeri o thumbnails.

Come da ‘tradizione’ slideViewerPro si lo si può usare in modo molto semplice, a partire da una lista non ordinata di immagini.

Altro giretto a bordo del mio Logo 500. Il mio amico Daniele è venuto a trovarmi da Edimburgo, ed ha portato con se questa bellissima microcamera, una Helmet HERO Wide. Ottima scusa per un voletto pomeridiano on-board.

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.