GIfB - Gestural Interface for Blender

GIf

Gestural Interface for Blender

UniversitĂ IUAV di Venezia FacoltĂ di Design e Arti

Corso di Laurea Specialistica in Comunicazioni Visive e Multimediali

Tesi di laurea di Alberto Granaiola Relatore professore Davide Rocchesso

Tesi di laurea Corso di laurea specialistica o magistrale in Comunicazioni Visive e Multimediali

Titolo tesi di laurea

GIfB - Gestural Interface for Blender

Cognome e nome

Granaiola Alberto

Matricola n.

262094

Anno accademico

2011/2012

Relatore

Rocchesso Davide

Correlatore Sessione di laurea

Firma Firma

Aprile 2013

INDICE

Abstract italiano

5

English abstract

7

Introduzione

9

Blender, Cinema 4D, 3D Studio Max

11

Errori modali nell’interfaccia di Blender

27

Valutazione dei motion controllers

35

GIfB: semplificare l’uso di Blender.

Proposte delle gestualità da adottare

45

Concezione del prototipo

53

Codici per il funzionamento di GIfB

61

Conclusioni

71

Bibliografia

75

Dichiarazione di consultabilità

ABSTRACT ITALIANO

Nella produzione di contenuti grafici, siano essi immagini statiche o video, qualora si dovesse passare attraverso l’utilizzo di elementi tridimensionali, esistono diversi software che aiutano il progettista a sviluppare le proprie idee.

La seguente tesi parte dal problema che la maggior parte di tali software sono a pagamento e costano cifre considerevoli. Esiste un programma open source molto completo per la gestione di oggetti e scene tridimensionali: Blender. Questo programma è abbastanza conosciuto negli ambienti di studio e progettazione, tuttavia il suo uso è parecchio limitato. La causa principale è la difficoltà di utilizzo: l’interfaccia è ostica, specialmente al primo approccio.

Blender è stato scelto come argomento di ricerca perché è open source. Questa sua caratteristica, che coincide con la possibilità di non avere vincoli nella modifica al codice sorgente, potrà permettere eventualmente ai programmatori di sviluppare al meglio i risultati di questa ricerca.

Per porre rimedio al problema dell’usabilità di Blender si è deciso, attraverso questa tesi sperimentale, di concepire un dispositivo di interazione gestuale. Questo dispositivo consentirebbe all’utente di emulare i gesti di creazione e modifica fisica di oggetti reali, traducendo i gesti compiuti in dati per la workstation. In questo modo i gesti dell’utente creerebbero e gestirebbero in Blender gli oggetti tridimensionali.

Nella tesi sono state comparate le interfacce di Blender, Autodesk 3D Studio Max e Maxon Cinema 4D. È stata effettuata un’approfondita l’analisi di Blender, per capire gli errori modali che può generare il programma in fase di utilizzo. Sono stati considerati i dispositivi di interazione gestuale più diffusi nel mercato e ne sono stati valutati sia i pro che i contro. Sono stati poi comparati gli atti che l’utente compie durante l’interazione con l’interfaccia di Blender con i gesti che esso compie per manipolare e gestire degli oggetti reali. È stato infine concepito il progetto di un controller ex-novo, partendo dai gesti dell’utente e valutando il suo funzionamento.

Sono state esposte le basi della sua programmazione, per il suo funzionamento e le relative problematiche.

5

ENGLISH ABSTRACT

When designers use three-dimensional elements to produce graphical content, whether still images or videos, there are several softwares to help in developing their ideas.

This thesis proceed from the problem that most of these softwares substantially cost.

A very complete open source software for the management of threedimensional objects and scenes exists and it is called Blender. This program is fairly well known in the design and research fields, but its use is quite restricted. The main reason is the difficulty in its usage, because of its tricky interface, especially at a first approach.

Blender was chosen as a topic for this research because it’s an open source software. This feature, that consists in the ability to freely change the source code, might allow programmers to develop the results of this research in an extensive way.

To solve the problem of Blender’s usability, it was decided, through this experimental thesis, to design a gestural interaction device.

This device should make the user emulating the acts of creation and physical modifications of real objects, translating them in workstation data. In practice, the user’s gestures should create and manage three-dimensional objects in Blender.

In this thesis different softwares (Blender, Autodesk 3D Studio Max and Maxon Cinema 4D) were compared through their respective interfaces. Blender was deeply analysed to understand the mode errors that can generate the program when used.

The more common types of gestural interaction devices in the market were compared to evaluate their pros and cons.

In this thesis were also considered all the acts that the user must to do when he interacts with the Blender’s interface. All these acts were compared to the gestures that the user does during the manipulation and the management of real objects.

Finally, a new controller was projected, starting from the user’s gestures and evaluating its operative mode.

The programming bases to make its prototype are her shown, as well as their relevant issues.

7

INTRODUZIONE

Negli ambiti lavorativi di progettazione architettonica e di design vengono usati diversi programmi per la gestione delle immagini.

Tali programmi consentono al progettista di sviluppare al meglio le proprie idee e di mantenere un alto livello di precisione nella realizzazione dei progetti.

Lo scopo di questa ricerca è il miglioramento dell’usabilità del programma più potente e versatile open source per la gestione di oggetti, ambienti ed immagini tridimensionali: Blender.

Con un’analisi anche superficiale si può appurare come Blender sia alla pari dei software proprietari più diffusi negli studi di progettazione. L’unico difetto di Blender, che ne impedisce un’ampia diffusione presso gli ambienti professionali, è l’usabilità, abbastanza ostica specie nei primi approcci dell’utente col programma.

Di seguito verranno descritte le peculiarità principali dei software per la progettazione 3d, verranno individuati i difetti principali che inficiano l’interazione tra l’utente ed il programma open source, infine verrà fatta una proposta progettuale per un dispositivo di interazione gestuale compatibile con Blender, al fine di rendere il flusso di lavoro del progettista grafico molto più veloce.

9

BLENDER, CINEMA 4D, 3D STUDIO MAX

Nella produzione di contenuti grafici, siano essi immagini statiche o video, l’utente che ritenga opportuno l’utilizzo della grafica tridimensionale deve considerare tutta una serie di software che gli consentono di creare oggetti e gestirne le proprietà.

Per quanto riguarda la progettazione 3d bisogna distinguere due macrocategorie di programmi: software parametrici e non parametrici.

I software parametrici si possono identificare nella famiglia dei programmi CAD (Computer-Aided Drafting) e affini. Questi software consentono di lavorare con estrema precisione, difatti da essi possono derivare le varie impostazioni per realizzare direttamente dei prodotti, anche in ambito CAM. Principalmente servono dunque a modellare oggetti 3d.

I software non parametrici possono essere altrettanto precisi, tuttavia la loro natura agevola principalmente la creazione di immagini statiche, di video e talvolta la grafica per videogiochi. Difatti essi sono stati creati per dare particolare attenzione alla parte di progettazione dei materiali e delle texture da assegnare ai vari oggetti 3d modellati, nonché alla gestione dell’illuminazione per impostare al meglio la fase di render di immagini o video. La parte di creazione e modellazione di oggetti tridimensionali rimane comunque ricca di opzioni e molto complessa.

Nel corso degli anni tra i principali software non parametrici si sono imposti 3d Studio Max, Maya, Cinema 4d.

Blender è cresciuto parallelamente a questi programmi proprietari, 11

esso è sempre stato riconosciuto come uno degli strumenti più potenti e versatili. Tuttavia non ha raccolto molto consenso nel corso degli anni e sono diverse le cause del suo insuccesso, le più evidenti sono due.

La prima consiste nel fatto che i professionisti preferiscono generalmente affidarsi a software proprietari per una questione di aggiornamenti e assistenza: sebbene la comunità di sviluppatori di Blender sia abbastanza ampia e Blender venga aggiornato ripetutamente (anche diverse volte nell’arco di un anno), il fatto stesso che sia un software open source lo fa percepire come meno “professionale” agli occhi degli utenti. Blender in fase di sviluppo comunque può presentare dei piccoli bug, i quali vengono prontamente corretti, ma anche questo fattore lo fa figurare come meno professionale, anche se tali bug non sono strettamente connessi all’authoring di contenuti 3d.

La seconda e non meno importante consiste nella presenza di un’interfaccia ostica al primo impatto. Questo fattore è valso soprattutto fino alla versione 2.49b (beta), la versione successiva 2.50a (alpha) ha rivoluzionato buona parte dell’interfaccia grafica. Nonostante le ultime migliorie, risulta difficile per un utente al primo approccio creare degli oggetti nell’immediato per poi poter proseguire nello sviluppo di scene tridimensionali con più elementi con facilità.

La combinazione di questi due fattori ha fatto sì che Blender sia rimasto sempre in sordina rispetto alle controparti di proprietà Autodesk e Maxon. L’utente inesperto preferisce poter produrre subito qualcosa, con un software pagato: in altre parole “il software è pagato, deve pertanto garantire dei risultati subito”.

In seguito verrà effettuata l’analisi dell’interfaccia di tre software: 3d Studio Max (2010), Cinema 4d (Release13) e Blender (versione 2.61). Tale analisi aiuterà a sottolineare le somiglianze e le differenze tra di essi ed infine a capire come l’utente inesperto può, con meno passaggi, creare immediatamente qualcosa: un feedback immediato nei risultati del proprio lavoro spinge l’utente a continuare a usare il medesimo programma.

I passaggi fondamentali per ottenere un’immagine o un video con questi software sono solitamente: la creazione di oggetti 3d, la modifica di essi, l’assegnazione di proprietà quali materiali e textures, il settaggio dell’ambiente che circonda gli oggetti con luci/sfondi etc., ed infine il render.

L’utente non avvezzo alla progettazione tridimensionale solitamente crea scene partendo dalle primitive: solidi predefiniti come parallelepipedi, coni, sfere, cilindri, toroidi, etc.

Quel che veramente conta per l’utente non esperto, in un’ottica di approccio e apprendimento del software, consiste nella possibilità di vedere immediatamente i risultati delle operazioni di creazione e modellazione dei solidi. L’assegnazione di materiali o textures agli oggetti e l’illuminazione di questi ultimi si possono vedere correttamente solo in seguito all’operazione di rendering.

I software di modellazione 3d consentono altresì di creare superfici nurbrs tramite l’utilizzo di splines, generatrici e direttrici (vengono chiamati modelli matematici, in quanto risultanti di operazioni matematiche tra dati), tuttavia è più facile per il principiante iniziare ad 12

1

1. Loghi dei programmi Autodesk 3D Studio Max, Maxon Cinema 4D, Blender

2

imparare un software utilizzando le primitive e rendendole superfici mesh, cioè insiemi di poligoni contigui tra loro (si possono definire modelli numerici, in quanto l’oggetto viene definito da un insieme di numeri correlati tra loro, ad esempio le coordinate degli otto vertici di un cubo).

La prima operazione che fa l’utente dopo aver avviato il software è orientarsi all’interno dell’interfaccia.

Le interfacce dei programmi analizzati sono personalizzabili, ma qui si considera l’utente inesperto, il quale accetta l’interfaccia per come appare e cerca di muoversi in essa in base a quello che vede.

Prima di proseguire è utile chiarire un punto. Svariate funzioni dei programmi vengono richiamate attraverso l’utilizzo dei bottoni. I vari bottoni presenti nei programmi si dividono (visivamente) in due categorie: bottoni con funzione descritta alfabeticamente e bottoni con funzione descritta da un simbolo grafico. Per rendere il testo più semplice si chiameranno i primi con il nome “bottoni”, i secondi come “icone”.

Cinema 4D e 3d Studio Max (i nomi verranno semplificati d’ora in avanti con C4d e 3ds) presentano un ambiente vuoto (anche questo per facilità verrà chiamato d’ora in avanti “limbo” al pari di quello degli studi/set fotografici) visto da quattro punti di vista predefiniti: tre viste corrispondono alle proiezioni ortogonali della scena (vista dall’alto, frontale e laterale), la quarta è in prospettiva e fa vedere gli oggetti disposti nel limbo “a tutto tondo”, cioè li fa percepire nel13

2. Interfaccia 3D Studio Max

la loro tridimensionalità; convenzionalmente queste “finestre nella finestra” del limbo vengono chiamate “viewport”. Oltre alle viste del limbo sono presenti dei pannelli di controllo vuoti, delle icone (C4d) o dei bottoni (3ds) i quali indicano all’utente che si possono creare dei solidi; ci sono delle icone che rimandano alle operazioni che l’utente può fare (modifica degli oggetti) e altre icone che rimandano alle opzioni dei programmi. Infine sono presenti i menu a comparsa in alto, partendo da sinistra.

Blender invece si presenta con un’unica vista in prospettiva; all’interno del limbo sono già presenti degli elementi: come un cubo, una piramide a base quadrangolare (la telecamera), un punto di controllo all’interno del cubo (il pivot, una sorta di baricentro del cubo) e il cursore 3d (il punto esatto dove vengono inseriti gli oggetti che l’utente crea). Il pannello laterale sinistro presenta dei bottoni che rimandano a delle operazioni di modifica degli oggetti.

Il pannello laterale a destra presenta delle cifre, l’utente può intuire che esse indichino le proprietà del cubo; si vedono poche icone e sono molto più piccole rispetto a 3ds e C4d. A destra si può notare comunque un elenco di elementi disposti gerarchicamente in una struttura ad albero, Blender in questo caso fa notare immediatamente qual è l’oggetto principale su cui si opera e le sue proprietà, ad esempio: nome oggetto(cubo)/tipologia di mesh(cubo)/materiale/texture. In alto, partendo da sinistra, ci sono i menù a scorrimento. Sotto il limbo ci sono altri menu a comparsa e altre icone, tra le quali lo switch di impostazione generica di Bender: object mode, edit mode, sculpt, vertex, texture, weight. In base al tipo di operazione che vuole fare, l’utente deve passare da un mode all’altro; purtroppo la posizione e la grandezza dello switch non aiutano l’utente neofita a capire una delle funzioni più importanti del programma. È comune a tutti e tre i software avere una timeline per animazioni sotto la vista del limbo. È comune altresì la presenza di una griglia di impaginazione all’interno del limbo, anche nelle viste prospettiche: la griglia nella visuale prospettica (o a seconda dei casi anche ortografica) in realtà aiuta l’utente più come piano di orientamento, che non per le operazioni di precisione, in sostanza aiuta a non percepire gli oggetti inseriti come totalmente fluttuanti nel vuoto.

Capire a cosa servono le icone.

I tre programmi aiutano l’utente a capire la funzione delle icone con una scritta che compare con la tecnica del mouse over (lasciare il cursore del mouse fermo sull’icona): in Blender e 3ds la scritta compare in popup appena al di sotto del cursore, in C4d la scritta appare sotto il limbo, a sinistra; la scelta adottata in C4d va a discapito dell’utente, il quale deve spostare lo sguardo dall’icona alla scritta, ammesso che si accorga della presenza di tale scritta.

L’aggiunta di un elemento al limbo viene recepito come la creazione vera e propria di un oggetto. L’uso delle primitive rispetto alle nurbs rende ancora più esplicito il feedback ed è per questo che l’utente alle prime armi usa principalmente le primitive. La creazione di una scena (e l’apprezzamento del software) passa dunque attraverso la rapida aggiunta di più elementi semplici nel vuoto.

14

3. Interfaccia Cinema 4D 4. Intefaccia Blender

3

4

15

5

6

In 3ds le primitive vengono inserite con un click, sui bottoni apposti immediatamente visualizzabili nel pannello a destra.

In C4d si visualizza una sola primitiva, immediatamente, quindi con un solo click possiamo inserire solamente un cubo; tuttavia il triangolo in basso a destra nell’icona “cubo” ci indica che esiste un sottoinsieme di icone1 (di altre primitive), quindi per aggiungere un solido semplice basterà fare due click.

3ds e C4d hanno in comune il fatto che, una volta inserita una primitiva, l’utente può dimensionare quest’ultima a piacimento attraverso l’uso del mouse. Il feedback del dimensionamento dell’oggetto avviene in tempo reale.

In Blender non esistono icone o bottoni che esplicitino l’inserimento delle primitive. L’inserimento si fa attraverso il menu a comparsa add/mesh/ e si sceglie il tipo di primitiva. Le primitive “create” non si possono dimensionare in fase di inserimento. Una volta inserite si possono modificare a piacimento, ma le operazioni per creare un oggetto come lo pensa l’utente diventano già due e ciascuna di esse comporta tutta una serie di passaggi: ad esempio per inserire un altro cubo bisogna per forza fare tre click; solo successivamente gli si possono assegnare dimensioni volute.

7

5. Inserimento primitive Cinema 4D 1. Questo sistema di sotto-icone è presente in diversi programmi, anche in quelli di uso più comune come le varie suite Office ad esempio; per questo anche l’utente inesperto può riconoscere questa funzione immediatamente 16

6. Inserimento primitive 3D Studio Max 7. Inserimento primitive Blender

Blender ha inoltre il problema di impostare il modo in cui si lavora.

Se in 3ds e C4d gli oggetti vengono prima creati separatamente e poi eventualmente correlati, in Blender bisogna sapere in quale modo è impostato il programma: object mode, edit mode, scuplt mode... Ad esempio l’aggiunta di una primitiva in “edit mode” legherà indissolubilmente l’oggetto inserito a quello che era già selezionato. Solo attraverso l’object mode l’utente può creare oggetti indipendenti tra loro. Questo è un problema di non poco conto, considerando il fatto che il principiante non bada subito alle impostazioni del programma: vuole solo usarlo, ottenere dei risultati e affinare le conoscenze in seguito. Se si inserisce un oggetto in edit mode, l’utente alle prime armi non può capire immediatamente perché non può modificare quello che ha appena inserito.

Una volta inserito l’oggetto in Blender l’utente vorrà dimensionarlo a piacimento. Ma dove?

In C4d e 3ds sono presenti in basso a destra del limbo i dati dell’oggetto, posizione, dimensioni, rotazione. In Blender non si capisce nemmeno se il cubo, già presente nel limbo, misura centinaia di metri o pochi centimetri.

Le prime operazioni elementari da fare con degli oggetti inseriti nel limbo sono: spostamento, rotazione, scalatura. Per rendere immediatamente fattibili queste operazioni tutti e tre i programmi usano delle icone, abbastanza chiare in 3ds e c4d, frecce per “sposta” cerchio-vettore per “rotea”, l’icona per “scala” è meno intuibile, ma il suo posizionamento di fianco alle altre due aiuta l’utente a dedurne la funzione. Le icone in 3ds e C4d sono posizionate sopra il limbo e le loro dimensioni sono molto maggiori rispetto a quelle di Blender; queste ultime vengono invece posizionate a fianco dello “switch mode”, il che porta un vantaggio: le operazioni che vengono eseguite maggiormente sono concentrate sotto il limbo. Purtroppo l’estrema semplificazione grafica di queste icone le rende meno riconoscibili rispetto alle controparti Maxon e Autodesk.

Per poter gestire al meglio l’inserimento e le modifiche degli oggetti nella scena l’utente ha bisogno di poter muoversi con la visuale, è fondamentale dunque che questi possa effettuare operazioni di spostamento della visuale (pan), operazioni di ingrandimento (zoom in/out) e possa roteare la scena (orbit: nello specifico è il punto di vista ad orbitare attorno alla scena, tuttavia la percezione dell’utente è quella di roteare la scena, come se egli roteasse un ipotetico piano lavoro reale dove poggiano gli oggetti).

Ogni programma qui analizzato ha le sue scorciatoie di tastiera oppure delle combinazioni mouse-tastiera, però l’utente inesperto sarà portato a cercare il bottone o l’icona specifica per eseguire le prime operazioni.

In C4d sono posizionate in alto a destra di ogni viewport (proiezioni ortogonali e vista prospettica) le specifiche icone, esse si distinguono dalle altre per essere più piccole, monocromatiche e più stilizzate. Fermandosi col mouse sopra di esse compare la descrizione alfabetica della loro funzione in basso a sinistra rispetto al limbo.

L’utente non deve fare altro che portarsi col cursore del mouse su tali icone, tenere premuto il tasto sinistro ed adoperare lo scorrimento del mouse per cambiare vista.

17

8

9

10

Dettagli delle modifiche elementari in: 8. Cinema 4D 9. 3D Studio Max 10. Blender

In 3ds le classiche icone sono posizionate in basso a destra e sono più piccole rispetto alle altre, poi in alto a destra di ogni viewport c’è il ViewCube, infine è stata introdotta da diversi anni la SteeringWheels2. Il posizionamento delle icone classiche di navigazione non è dei migliori, ma l’utente è aiutato a individuarle grazie a due fattori: il primo è l’icona di zoom, rappresentata con una lente d’ingrandimento stilizzata, questo porta a capire che in quella zona la toolbar è dedicata alle opzioni di navigazione della scena; il secondo è la comparsa delle funzioni in popup grazie all’utilizzo della tecnica del mouseover. Il ViewCube è un cubo con corona circolare alla base, il cubo ha descritto la tipologia di vista (top, front, rear, left, right, bottom) su ogni facciata, cliccando su di essa il punto di vista traslerà fino ad ottenere la visione voluta: cliccando su front, la visuale si sposterà fino alla vita generica front; la corona circolare alla base invece presenta in lettere i quattro punti cardinali (N,S,W,E) e anch’essa funziona con un semplice click; si possono cliccare anche gli spigoli del ViewCube per traslare verso punti di vista ortogonali. La SteeringWheels è un quadrante in semitrasparenza posto sul limbo, dove le opzioni di navigazione sono descritte alfabeticamente: questo sistema è più pratico e veloce delle icone classiche, l’unica difficoltà che comporta è la sua disattivazione, in quanto segue il cursore del mouse e finché accade questo l’utente non può selezionare alcun oggetto all’interno della scena3.

In Blender invece si può navigare solo tramite tastierino numerico con precisi tasti oppure con delle combinazioni tra tastiera e mouse. Questo lo rende ostico in quanto l’utente inesperto ignora quali siano i tasti specifici per navigare; inoltre l’utente non dispone sempre di una tastiera estesa, basti pensare a quando esso lavora con un laptop.

Elemento comune a tutti e tre i programmi consiste nel fatto che la rotella del mouse svolga la funzione di zoom in/out, essa è più immediata da scoprire e apprendere. Qualora l’utente fosse sprovvisto di rotella sul mouse (abbastanza comune oggi) in C4d e 3ds esistono sempre le icone, invece in Blender l’utente dovrà memorizzare combinazioni tastiera-mouse.

11

12

13

14

Gestione delle viewports.

Per ogni finestra rappresentativa di un punto di vista (viewport) in C4d esiste, accanto alle icone di zoom/pan/orbit, l’icona per passare da quattro ad un’unica viewport. Qualora l’utente volesse cambiare punto di vista (dall’alto al basso ad esempio) vero e proprio ed avere differenti tipologie di visualizzazione (shading, wireframe, etc.) ogni finestra contiene anche dei menu a comparsa appositi, situati nelle medesime viewport .

2. Introdotta per la prima volta in 3d Studio Max 2009 3. Per disattivarla basta premere il tasto “esc” o cliccare sula “x” di chiusura presente sulla steering wheels stessa; poiché la s.w. funziona principalmente attraverso il trascinamento del mouse, la difficoltà risiede principalmente nel fatto che la s.w. si sostituisca al cursore del mouse, l’utente potrebbe dunque essere disorientato dalla perdita di visione del cursore, inoltre dovrebbe staccare l’attenzione dal mouse per rivolgerla alla tastiera, al tasto “esc”.

18

11. Comandi navigazione scena in Cinema 4D 12. Comandi navigazione scena in 3D Studio Max 13. ViewCube 14. SteeringWheels

15

16

17

In 3ds queste opzioni sono posizionate in alto a sinistra di ogni singola viewport, ma non sono distinte graficamente dal limbo; restano comunque di facile fruizione, in quanto sono veri e propri bottoni con sfondo trasparente.

In BL l’utente si deve affidare ai menu a comparsa sottostanti il limbo: c’è lo specifico menu “view”. Attraverso questo si scelgono i punti di vista e il passaggio da una a quattro viewport contemporaneamente.

Altri pannelli, bottoni ed icone.

In 3ds l’utente che è riuscito ad inserire qualche primitiva comincia a capire che dovrà utilizzare il pannello alla destra del limbo per effettuare le operazioni con gli oggetti, difatti sono situate diverse tab per inserire altre tipologie di oggetti come le luci per modificare gli oggetti stessi, disporli in gerarchie etc., tuttavia all’utente alle prime armi saranno sufficienti le prime tre tab (tabelle).

Non meno importanti sono i materiali, visibili solo tramite il material editor; esso verrà visualizzato cliccando sulla specifica icona e apparirà come finestra pop-up a sé stante; questo passaggio non è immediato né tanto meno intuibile.

In C4d le icone per inserire altri oggetti o modificarne le proprietà sono accanto alle primitive. I pannelli posti alla destra del limbo (vedi fig.3) forniscono l’elenco degli oggetti inseriti e le caratteristiche assegnate agli oggetti stessi, il tutto seguendo una struttura 19

15-16-17. Da sinistra a destra, menu a comparsa per la gestione dei punti di vista in 3D Studio Max, Cinema 4D e Blender.

Notare come con il menu di Blender si possano gestire le viewport (le prime due voci)

18

19

20

gerarchica ad albero. L’elenco dei materiali è situato sotto il limbo, ogni pannello è contrassegnato con nome. Queste varie impostazioni rendono C4d il software con l’interfaccia meno ostica tra i tre.

In Blender la creazione e l’elaborazione dei materiali avviene attraverso il pannello laterale a destra. L’utente deve cercare l’apposita icona che richiamerà i materiali e da lì, sempre attraverso il medesimo pannello, modificherà i parametri interessati. Lo stesso avviene per le textures. Il posizionamento dei parametri di creazione e modifica dei materiali/textures è al di sotto dell’albero gerarchico degli oggetti posti in scena (oggetto/mesh/materiale/texture etc..), questa scelta di progettazione dell’interfaccia aiuta l’utente a capire a che livello opera (all’interno dell’albero gerarchico) e con quale elemento. L’elemento selezionato nell’albero gerarchico è solitamente evidenziato da un alone semitrasparente grigio o arancione.

Cancellazione degli oggetti.

In C4d e 3ds la cancellazione degli oggetti avviene attraverso il semplice tasto “canc” o “delete” della tastiera.

In Blender occorre selezionare l’oggetto all’interno del limbo e premere i tasti “delete” o “canc” ed infine dare conferma in un menu contestuale a comparsa nel limbo. Un altro modo consiste nel selezionare gli oggetti nell’albero gerarchico (pannello a destra), premere col tasto destro del mouse per visualizzare il menu contestuale e selezionare “delete”; queste molteplici operazioni per la semplice 20

18-19-20. Da sinistra a destra, pannelli per la modifica dell’oggetto, del materiale e della texture in Blender

21

22

23

cancellazione di un oggetto non aiutano il neofita a districarsi nel software.

Menu contestuali. È prerogativa dei sistemi operativi e di molti programmi avere dei menu contestuali che compaiono attraverso il click sul tasto destro del mouse (in Mac OS esiste la combinazione ctrl+click mouse).

Tali menu possono richiamare diverse funzioni che interessano gli oggetti selezionati. In C4d e 3ds i menu contestuali appaiono sia quando si selezionano gli oggetti all’interno della scena, sia quando sono elencati nei vari pannelli. In Blender il menu contestuale appare solo sugli oggetti elencati nel pannello specifico. E questo è un altro fattore che rende ostico il programma agli inesperti.

Gestione del pivot.

Ogni modifica fatta agli oggetti prende come punto base di riferimento il cosiddetto Pivot. Ad esempio, se si ingrandisce un cubo con il pivot posto al suo centro, questo si espanderà omogeneamente dal pivot verso l’esterno; se il pivot è posto su un vertice, il vertice stesso rimarrà immobile ed il cubo si ingrandirà partendo da quel vertice. Il pivot è posto di default al centro dell’oggetto, come un vero e proprio baricentro, tuttavia esso si può spostare. Il pivot è altresì l’origine di un sistema di coordinate ad oggetto, al quale fa 21

21-22-23. Da sinistra a destra, pannelli per le impostazioni della camera per il render, pannello per l’impostazione della scena, albero gerarchico degli elementi nel limbo.

Notare nell’albero gerarchico il rapporto parent-children tra oggetto, mesh, materiale, texture

riferimento il o gli oggetti selezionati.

In C4d il pivot si modifica grazie alla toolbar alla sinistra del limbo, l’icona è rappresentata da due vettori ortogonali, rappresentativi di un sistema di assi cartesiano. L’icona tuttavia può venire spesso confusa con quella che impone il sistema di coordinate assoluto (della scena): due vettori ortogonali e un triangolo. Può capitare dunque che, avendo selezionato il sistema di coordinate sbagliato (relative all’oggetto e non assolute), l’utente si ritrovi a voler spostare un oggetto che rimane immobile nella scena, mentre sta spostando il pivot appartenente all’oggetto stesso.

In 3ds si modifica il pivot andando nel pannello laterale destro, nella tabella delle gerarchie. Solo dopo aver premuto il bottone “Edit working pivot” si può iniziare a spostarlo a piacimento. I click diventano così tre e 3ds risulta meno immediato di C4d.

In Blender le problematiche della modifica del pivot iniziano dal capire se il programma è impostato in “object mode” oppure in “edit mode”, esattamente come descritto prima. Ipotizzando che l’utente inesperto abbia comunque risolto questo problema avendo già inserito e spostato una o più primitive, […] Per controllare la posizione del Centro dobbiamo attivare uno strumento chiamato Set Center. Per questo ci rivolgiamo ai pulsanti di controllo della barra degli strumenti nel Tool Shelf (ricorda che diventano visibili con il tasto [T]) e selezioniamo Add Tool (si può usare il motore di ricerca interno per accedere a questo strumento). [...] 4

24

25

Dalla citazione soprastante si evince quanto sia complicato imparare ad usare il pivot anche seguendo una guida di introduzione (dunque per principianti). Ciò che è complicato con un manuale diviene dunque impossibile per un utente neofita che miri ad un feedback immediato, in termini di risultati, da parte del programma.

Purtroppo le varie tipologie di pivot che BL offre all’utente verrebbero completamente ignorate dal modellatore 3d neofita, ammesso che quest’ultimo non abbia già abbandonato il programma in favore di altri più semplici.

Render.

Al principiante capace di inserire delle primitive nella scena, di modificarle, di navigare all’interno della scena, manca solo l’operazione finale, quella che gli consente di uscire dallo stato di preview ed ottenere il risultato finale. Ottenuto il risultato finale, il principiante sarà maggiormente incentivato a proseguire con la costruzione di scene più complesse e con l’apprendimento del programma. Il risultato finale si ottiene con il render. Un render base non ha bisogno dell’illuminazione, i punti luce possono venire inseriti anche

4. J. H. Goás, Guida d’introduzione a BLENDER 2.5, pdf distribuito online Licencia Creative Commons 2.5 España, novembre 2009, trad. it. a cura di A. Campagnol, F. Zoffoli, A. Labate, F. Martino, D. De Luca, distribuita in CC sul sito www.blender.it 22

26

24. Icona del pivot in Cinema 4D 25. Gestione del pivot in Blender 26. Gestione del pivot in 3D Studio Max

27

successivamente, attraverso le stesse modalità adottate per le primitive. Anche l’assegnazione dei materiali ai vari oggetti 3d non è indispensabile per ottenere quel risultato che stupirà il neofita dopo il primo render.

Sia in C4d che in 3ds esistono le apposite icone che fanno partire il calcolo di rendering con un solo click. In Blender si nota subito in alto a sinistra il menu a comparsa “render”, all’interno di esso si selezionerà “render image”, quindi due click.

C4d offre la possibilità di lanciare il render nella viewport sulla quale si sta lavorando o su una finestra a parte. Per ritornare alla preview basterà chiudere o ridurre a icona la finestra popup aperta, oppure fare un semplice click nella viewport renderizzata: il risultato scomparirà automaticamente.

In 3ds il render verrà elaborato in base alla viewport sulla quale si sta lavorando, si aprirà una finestra popup, dove si vedrà l’elaborazione grafica e il risultato finale; basterà chiudere o ridurre ad icona quest’ultima per tornare a lavorare alla scena.

In BL il render viene eseguito dal punto di vista della camera, per questo se ne trova inserita già una all’apertura del programma. Se l’utente ha già imparato ad impostare la viewport sulla telecamera, e al momento del lancio del render starà guardando la scena dalla stessa, avrà lo stesso feedback dei programmi 3ds e C4d.

Molto probabilmente però la viewport del principiante sarà impostata in semplice vista prospettica quindi il render sarà effettuato da un differente punto di vista rispetto all’anteprima in fase di edit23

27. Schermata di render di 3D Studio Max

ing. Questo è un fattore di disorientamento per l’inesperto. Inoltre il render non viene sviluppato in una finestra a parte o nella stessa viewport come per C4d. La visuale di rendering prenderà il posto della finestra dove avviene l’editing e non è per niente chiaro come si possa tornare indietro all’editing. Il comando per uscire dalla finestra di render è semplice ma non intuitivo (poiché sposta l’attenzione dell’utente dallo schermo): basta premere il tasto ESC della tastiera del computer. Se l’utente cercasse un comando da cliccare nell’interfaccia (come la chiusura delle finestre popup in C4d e 3ds) dovrebbe cercarselo in basso a sinistra, di fianco al menu a scomparsa view, in un’icona che apre un altro menu; tale icona, se ci soffermiamo col mouse over, verrà identificata come “Displays current editor type. Click for menu of available types”: l’esatto opposto del concetto “Less is more”5.

Considerazioni.

Attraverso una prima analisi - anche superficiale - delle interfacce di C4d, 3ds e BL, si evince comunque che ogni software abbia determinate peculiarità che, nascondendosi dietro l’interfaccia, fanno capire come i metodi di elaborazione di oggetti e scene 3d cambiano per ogni programma. C4d e 3ds sono già più simili tra loro, in quanto non vi è un’immediata distinzione tra varie metodologie di impostazione e di elaborazione del programma. Qualora un utente nuovo all’authoring 3d volesse approcciarsi a BL sarebbe corretto imparasse subito a distinguere le varie modalità di lavorazione precedentemente elencate: object mode, edit mode, sculpt mode, vertex paint, texture paint e weight paint. Queste ultime tre modalità sono presenti anche in C4d e 3ds, tuttavia esse si distinguono bene dall’interfaccia base e si aprono a parte: ad esempio in C4d se si vogliono elaborare i materiali e le textures si passa al modulo body paint.

Ecco qui l’ipotesi di aggiungere all’interfaccia grafica di Blender un dispositivo di interazione gestuale, al fine di rendere meno ostico il programma e rendere maggiormente veloce il flusso di lavoro.

Gestural Interface for Blender (per comodità verrà chiamato d’ora in poi con l’acronimo GIfB) deve rendere immediato l’uso del migliore software open source per la grafica tridimensionale.

Altra questione poi sono gli altri parametri come la gestione delle varie modalità di pivot; una volta apprese determinate funzioni il workflow di BL diventa fluido e veloce, tuttavia il neofita potrebbe sempre abbandonare il software prima di usarlo in tutta la sua potenzialità.

Differenze tra le schermate di render: 5. N. Negroponte, Essere digitali, Sperling & Kupfer, 2a ed., Milano, 1995, trad. it. F. e G. Filippazzi 24

28. Cinema 4D 29. Blender

28

29

25

ERRORI MODALI NELL’INTERFACCIA DI BLENDER

Durante l’analisi dell’interfaccia di Blender si è potuto appurare come questa sia ostica. Si sono tuttavia rivelati una serie di errori nella progettazione dell’interfaccia che possono indurre l’utente a commettere veri e propri sbagli durante la fase di disegno. Talvolta l’utente potrebbe accorgersene immediatamente ma nella peggiore delle ipotesi potrebbe proseguire con il proprio progetto e sbagliare quindi un’intera fase di avanzamento progettuale.

Questi errori sono dovuti alla modalità dell’interfaccia di Blender.

Una definizione completa di cosa sia una modalità deve includere anche il modo in cui un utente vede l’interfaccia: [...] un’interfaccia uomo - macchina è modale rispetto ad un dato atto quando (1) lo stato attuale dell’interfaccia non è il fuoco dell’attenzione dell’utente, e (2) l’interfaccia risponderà all’atto in uno fra più modi possibili , a seconda dello stato attuale del sistema[...] 6

Nel libro Humane interfaces Jef Raskin introduce le modalità con l’esempio della torcia. Si consideri una torcia con un solo bottone per accenderla e spegnerla; questo tasto tuttavia non rileva lo stato della torcia, cioè se è già accesa o spenta; in questo caso l’atto con-

6. Raskin Jef, Interfacce a misura d'uomo, Apogeo, Milano 2003, ed. or. Humane Interface,ACM Press, 2000, trad. it W. Vannini, pg 52, 54-55 27

siste nel premere il bottone, mentre l’operazione consiste nell’accendere/spegnere la torcia. Se la torcia è in fondo ad uno zaino e non sappiamo se è spenta o accidentalmente accesa, l’atto di premere il bottone non ci aiuta di certo a capire lo stato della torcia.

Qui si genera l’errore dovuto alla modalità del bottone.

L’esempio della torcia rientra nella seconda tipologia di modalità citata precedentemente, cioè lo stato di sistema (acceso/spento) non è noto e l’atto di premere il bottone cambia la torcia da un modo ad un altro (la accende o la spegne).

Nelle interfacce dei programmi i bottoni radio con a fianco la descrizione dello stato del programma possono sembrare adatte a non generare errori: l’atto di premere il bottone giusto coincide con lo stato del software (ed il fuoco dell’attenzione dell’utente è rivolto ad impostare lo stato del programma); tuttavia anche in questo caso la descrizione del bottone radio può essere ambigua in quanto l’utente a volte non può capire se la descrizione del bottone sia rivolta allo stato attuale del programma o alla sua impostazione futura (dopo l’atto di premere il bottone).

Anche i semplici bottoni radio possono rientrare nella seconda tipologia di modalità a causa dell’ambiguità appena descritta.

La modalità si verifica anche quando lo stesso identico atto può rimandare a differenti operazioni. Qui si può fare riferimento alle molteplici funzioni che possono essere assegnate allo stesso tasto; il tasto return (nella tastiera di un pc) può essere usato per mandare a capo quando si scrive un testo oppure per convalidare un’operazione che si sta ultimando.

Tuttavia l’atto di premere return quando si vuole mandare a capo riga o return quando si vuole convalidare un’operazione non rendono il tasto return (inteso come interfaccia) modale in quanto “l’atto specifico” e “il premere return” coincidono; l’esempio che fa Raskin riguarda l’utilizzo dell’interfaccia “bottone backspace” per cancellare differenti caratteri: l’atto è cancellare l’ultimo carattere non “quello specifico carattere”: se al posto di scrivere “ciao” si digita erronea-mente “ciap” oppure “cia0”, l’usare il tasto backspace riguarda non la cancellazione del carattere “p” oppure “0”, ma riguarda la cancellazione del carattere sbagliato; questo è l’atto che fa l’utente, questo è il caso dove atto (cancellare) ed interfaccia (backspace) coincidono.

Per capire la modalità (1) della spiegazione di Raskin possiamo elencare i casi in cui il tasto return esegue diverse operazioni all’interno della stessa interfaccia: l’atto dell’utente e lo stato attuale dell’interfaccia non coincidono, dunque lo stato attuale dell’interfaccia non è nel fuoco dell’attenzione.

Un esempio concreto ed odierno è l’interfaccia per scrivere mail all’interno di Facebook, dove di default premere return dà il comando per inviare la mail; per mandare a capo il testo, durante la scrittura, occorre mettere una spunta sulla casella sotto il campo di scrittura. Questo tipo di modalità genera anzitutto l’errore di invio testo quando si vuole andare a capo riga, senza tuttavia avere concluso la stesura della mail; per rimediare a questo errore l’utente sarà costretto a spostare il fuoco dell’attenzione dalla stesura del testo alla ricerca dell’impostazione desiderata all’interno dell’interfaccia 28

30

31

30-31. Vecchia e nuova mailbox di Facebook. Da notare il bottone radio per la funzione di invio con l'uso del Return della tastiera.

Nonostante l'interfaccia nuova offra un messaggio più chiaro questa opzione può sempre generare l'errore modale di invio involontario della mail

e all’atto di mettere la spunta sul bottone radio opportuno; l’utente d’ora in poi sarà costretto ad usare il bottone invia oppure a reimpostare l’interfaccia togliendo la spunta (spostando nuovamente il fuoco dell’attenzione e perdendo ulteriore tempo); da notare anche come il bottone radio per mandare a capo il testo sia affiancato dal simbolo (freccia a L rovesciata) di return, che per quanto universale possa essere, non è detto sia interpretabile sempre in maniera corretta e univoca7. Gli user experience designers di Facebook hanno posto una risoluzione parziale a questo tipo di modalità, rendendola temporanea: una volta impostato il bottone radio questo rimarrà in tale stato fino ad operazione contraria. Qualora l’utente non capisca come impostare l’interfaccia secondo le proprie esigenze, sarebbe costretto ad accettare il fatto di non avere il pieno controllo sulla formattazione del testo oppure a scrivere la mail su un editor di testo a parte (con la formattazione appropriata) per poi copiarlo ed incollarlo su Facebook. L’utente diverrebbe così prigioniero del computer8.

Secondo Raskin l’unica maniera per evitare totalmente l’insorgere di errori consiste nell’evitare qualsiasi tipo di modalità: ogni atto dell’utente deve rimandare ad un’unica e sola operazione nel programma - definizione non totalmente corretta, dice: Perché un’interfaccia possa essere classificata come non modale, essa deve essere non modale rispetto ad ogni atto 9

Rimane il dubbio se questo sia l’unico modo per sviluppare un’interfaccia a misura d’uomo, in quanto i programmi molto complessi quali Blender, 3ds Max e Cinema 4d contengono una moltitudine di operazioni difficilmente assimilabile in toto. L’assegnazione “un atto uguale un’operazione” sposterebbe il focus dell’attenzione dell’utente su un forbito “glossario degli atti”, distogliendolo dalla creazione dei contenuti veri e propri.

Modalità dei comandi in Blender.

Stupisce la scelta della Blender Foundation di basare l’interazione utente-contenuto principalmente attraverso sei modalità differenti:

7. Recentemente Facebook ha sostituito il simbolo Return con un avviso scritto: "Premi Invio per inviare". Nella vecchia interfaccia, la decisione di utilizzare il simbolo return per il bottone radio poteva essere motivata dal rendere riconoscibile universalmente l'operazione, esigenza più che giustificabile per l'interfaccia del social network più diffuso al mondo. Tuttavia non si capisce come mai il bottone invia (send) si sia sempre adeguato alla lingua impostata nel sistema operativo che usa l'utente: si poteva anche qui usare un'icona che rappresentasse l'atto di spedizione della mail.

8. Since humans are more pliable than computers, it can be easier to make a human fit the computer's limitations than to design the computer to fit the human's needs. When that happens, the human becomes a prisoner trapped by the computer rather than liberated by it. Karla Jennings in J. Raskin, Interfacce a misura d'uomo, p. 47. Traduzione: Finché le persone saranno più malleabili dei computer, risulterà più facile adattare una persona alle limitazioni del computer che progettare un computer che si adatti ai bisogni della persona. Quando questo avviene, le persone diventano prigioniere intrappolate dai computer piuttosto che liberate da essi.

9. ibid. p.47 29

Object mode (modalità riferita agli oggetti) Edit mode Sculpt mode Vertex paint (modalità riferita ai materiali) Texture paint Weight paint Come già spiegato precedentemente gli oggetti inseriti in object mode ed edit mode avranno delle caratteristiche completamente differenti. Uno sguardo all’albero gerarchico degli oggetti può tornare utile all’utente per capire a quale livello sta lavorando, tuttavia è per lui controproducente spostare continuamente il fuoco dell’attenzione dalla viewport ai pannelli solo per verificare lo stato attuale delle operazioni. Anche la gestione dei layer a disposizione spinge l’utente a spostare l’attenzione dal proprio progetto all’impostazione del programma.

I vari gradi di visualizzazione degli oggetti in c4d e 3ds sono legati agli oggetti e sono impostabili come proprietà degli oggetti medesimi. Di fatto gli elementi all’interno del limbo possono essere rispettivamente nascosti e/o congelati.

Poiché i designers di Maxon ed Autodesk hanno associato lo stato degli oggetti all’interno delle loro proprietà, il fuoco dell’attenzione per l’attivazione/disattivazione (operazione) coincide con la modifica delle proprietà degli oggetti stessi (atto per gestire l’albero gerarchico degli oggetti).

In Blender queste operazioni sono state divise con tre semplici icone (occhio, freccia, macchina fotografica: vedi figura 23) che ci spiegano immediatamente se un oggetto è visibile/modificabile/ renderizzabile oppure no. Il fuoco dell’attenzione viene ancora sospinto sull’albero gerarchico degli elementi, dunque gestito in modo corretto secondo i principi di Raskin.

Layers.

In Blender esiste anche l’attivazione/disattivazione di 20 layer, le loro icone sono state poste sotto la viewport ed esse appaiono come dei bottoni privi di etichetta con quattro stadi e corrispettive variazioni grafiche: layer visible/non-visibile lo si vede dal livello di grigio (chiaro invisibile, scuro visibile); qualora un layer avesse degli oggetti al suo interno appare un pallino arancione nel bottone (arancione vivo con layer attivato, desaturato con layer disattivato).

L’assegnazione di più elementi allo stesso layer e la facilità con la quale possono essere attivati/disattivati può generare errori inaspettati: accidentalmente l’utente potrebbe non vedere più diversi elementi della scena (layer disattivato per sbaglio).

Qui ci troveremo in presenza di una modalità che sposta il fuoco dell’attenzione dalla scena agli elementi di gestione della scena.

L’utente potrebbe vedere i propri oggetti attivi nella lista degli elementi, ma scomparsi all’interno del limbo.

Per capire a quale layer appartiene un elemento della scena occorre selezionarlo nell’apposito pannello, andare nel sottopannello object e vedere quale tra i venti bottoni radio corrispondenti ai vari layer è attivo. L’operazione può risultare abbastanza complessa.

30

32

33

34

35 Visualizzazione di due oggetti posti in differenti layers: il cubo selezionato appartiene al layer 1°, la sfera al 2°.

32. Visibili i layers 1° e 2°, l'utente sta lavorando nel primo layer. Il layer con l'oggetto selezionato ha il pallino arancione.

33. Visibile solo il layer 1°, il pallino grigio indica un oggetto nel layer 2° 34. Visibile solo il layer 2°, il pallino arancione desaturato indica l'oggetto selezionato nel layer 1° 35. Visibile il layer 3° senza oggetti

Ridondanze dei comandi in object mode.

All’interno dell’object mode sono ridondanti i comandi del pannello a sinistra e le proprietà del sottopannello object (vedi figure 4 e 18).

La ridondanza inoltre si ripete con i comandi per le modifiche basilari (sposta, rotea, scala) posti sotto la viewport. Nell’object mode non si possono verificare errori in quanto le modifiche apportate agli oggetti si ripetono sia che si operi nel pannello di sinistra, nel sottopannello object e nelle icone poste sotto la viewport.

Sono ridondanti anche il bottone origin (funziona come paletta adattativa) e il menu a comparsa di impostazione del pivot sotto la viewport.

Ridondanze comandi in edit mode e generazione di errori.

Il passaggio alla modifica degli oggetti, utilizzando l’edit mode, presenta di nuovo all’occhio dell’utente elementi grafici ridondanti; tra di essi vi sono i basilari operatori di trasformazione dell’oggetto: scala, rotea, sposta. La ridondanza si presenta sempre nel pannello a sinistra, nel sottopannello di proprietà dell’oggetto object a destra del limbo e nelle icone sotto la viewport. Tuttavia nell’edit mode i valori immessi/cambiati nei vari pannelli sono indipendenti tra loro: nel sottopannello object le misure non cambiano col passaggio da una modalità all’altra; nel pannello dell’edit mode i valori vengono resettati ogni qualvolta BL cambia modalità. Gli stessi comandi ma con peculiarità diverse possono indurre l’utente a sbagliare la modifica dell’oggetto e nei casi peggiori all’impossibilità di ripristino dei valori pre-modifica.

Si evince dunque che la ridondanza dei comandi nell’interfaccia genera errori modali, in quanto il sistema pone contemporaneamente più modi visibili e questi generano operazioni diverse che non sempre coincidono con l’atto univoco pensato dall’utente.

36

Ridondanza operazione delete.

Come già spiegato l’operazione di cancellazione degli oggetti può essere effettuata in diversi modi. Il primo tramite la selezione dell’oggetto nell’albero gerarchico; una volta selezionato l’oggetto si può anche spostare il cursore sull’oggetto nel limbo e premere DEL>enter. Il secondo selezionando l’oggetto direttamente nel limbo e cancellandolo tramite il menu contestuale. Il terzo è utilizzare l’apposito tasto Delete nel pannello a sinistra del limbo: una volta premuto, domanderà conferma della cancellazione esattamente come per i metodi appena descritti.

Sculpt mode: problematica del tool brush.

L’interfaccia diventa modale in quanto le proprietà dello strumento sono slegate dal feedback visivo (cerchio) fornito nella viewport.

L’area dove va ad agire il pennello sculpt interessa solo i vertici che rientrano all’interno di esso. Questo vale se il valore di raggio è sbloccato. Alla sinistra del campo di testo con il valore di raggio c’è un bottone che rimanda a due stadi differenti del tool bloccato/non bloccato attraverso l’uso dell’icona di un lucchetto.

31

36. Pannello laterale sinistro dell'edit mode, si possono notare le ridondanze dei comandi confrontando l'immagine con le figure 4 e 18

Una volta bloccato il valore di raggio si nota che: - il valore è cambiato - il cerchio del tool varia di dimensioni nella viewport in base al numero di vertici che può includere.

Dopo varie prove si capisce che lo sculpt unblocked funziona in base a quello che si vede nella viewport, dipende dal fattore di zoom; differentemente lo sculpt blocked varia a seconda dei vertici che può modificare. È presente un altro bottone a due stadi alla destra del valore dell’ampiezza del tool e non si capisce la differenza tra uno stadio e l’altro del bottone.

Anche in questi casi non è chiaro lo stato dell’interfaccia, la quale non coincide con l’atto dell’utente. Fortunatamente i valori del tool bloccato/non bloccato sono legati e dipendenti tra loro.

La tipologia di pennello è selezionabile attraverso paletta adattativa, cliccando sull’immagine del “tipo-pennello”, manca tuttavia il simbolo grafico (come il triangolo di c4d) atto a mostrare la presenza di opzioni nascoste.

Cambio automatico delle modalità.

In Blender l’object mode e l’edit mode possono venire richiamati semplicemente selezionando gli elementi all’interno dell’albero gerarchico degli oggetti. Rispettivamente Blender passerà automaticamente a object mode quando vengono selezionati i parents, e passerà a edit mode quando vengono selezionati i children che indicano la struttura poligonale degli oggetti.

Sebbene più sbrigativo rispetto al sottomenu di impostazione dei vari modi posto sotto al limbo, l’interfaccia si dimostra modale in quanto l’utente pone il fuoco dell’attenzione sugli oggetti (siano essi quelli appena selezionati nell’elenco degli elementi oppure evidenziati all’interno della viewport) e non sullo stato dell’interfaccia; il fuoco dell’attenzione si discosta dalla modalità nella quale si sta operando, se l’utente accidentalmente ha selezionato l’oggetto sbagliato può incappare successivamente in operazioni non volute.

In Blender non sempre tutte le modalità sono disponibili e di questo ci si accorge quando si selezionano gli oggetti singoli nell’albero gerarchico. Alla selezione di un punto luce o della telecamera potremo operare solo in object mode, alla selezione di una curva avremo disponibili solo object ed edit mode, alla selezione di una mesh, si aggiungeranno lo sculpt mode e le tre modalità vertex / texture / weight paint.

Appare evidente a questo punto come l’interfaccia di Blender si accosti al paradigma soggetto-azione in base al quale prima si seleziona l’oggetto su cui si vuole operare, poi il programma cambia automaticamente le modalità dell’interfaccia (offrendo gli strumenti consoni), infine l’utente svolge gli atti necessari a portare avanti il proprio progetto. Purtroppo il cambiamento automatico delle modalità, come appena visto, sposta il fuoco dell’attenzione sugli oggetti e non sullo stato dell’interfaccia.

32

37

37. Pannello laterale sinistro dello sculpt mode. Notare le icone per bloccare/sbloccare lo strumento Brush 38. Nella pagina a fianco: variazioni di visualizzazione di un oggetto selezionato e del cursore del mouse in base alla modalità corrente.

Dall'alto al basso: - object mode - edit mode - sculpt mode - wertex paint - texture paint - weight paint

Feedback visivi al cambio di modalità.

Per fare coincidere nel fuoco dell’attenzione dell’utente atto e stato dell’interfaccia i progettisti di Blender hanno posto attenzione ad altri elementi: oltre ai comandi che appaiono nel pannello laterale sinistro, la visualizzazione degli elementi selezionati all’interno del limbo cambia in base al mode corrente. In object mode l’oggetto viene evidenziato come unico ed inscindibile. Al contrario in edit e sculpt mode gli oggetti presentano evidenziati maggiormente sia gli edges tra i vari poligoni che i vertici. Sebbene meno notabili, queste ulteriori differenze possono aiutare l’utente a capire lo stato del sistema durante la modifica degli oggetti di scena. I progettisti di Blender hanno adottato un secondo escamotage per aiutare l’utente a capire lo stato dell’interfaccia: il puntatore del mouse cambia a seconda dello stato del programma; esso assume la forma di freccia in object mode, di croce in edit mode, di cerchio nelle restanti quattro modalità.

Bug rilevato in fase di analisi dell’interfaccia.

Durante l’uso di Blender è stato riscontrato un altro difetto, probabilmente dovuto ad un bug. Dopo otto ore lavorative e diversi salvataggi Blender non visualizza più le icone di tipo tool-brush e sculpt mode, sostituendole con un’icona a doppia freccia (come paletta adattativa); le opzioni vengono poi visualizzate su una paletta grigio semitrasparente. Per rimediare al problema ripresentatosi dopo il riavvio del programma, si è dovuto andare in object mode e ritornare nello sculpt per vedere l’interfaccia rigenerata.

Questi tipi di bug comunque vengono corretti con l’avanzare dello sviluppo di Blender.

38 33

VALUTAZIONE DEI MOTION CONTROLLERS ESISTENTI

Per la progettazione del dispositivo di interazione gestuale sono stati considerati diversi tipi di controllers, in particolare quelli delle consolle di gioco di ultima generazione.

La versatilità di questo tipo di dispositivi risiede principalmente nel background di programmi sviluppati per eseguirne l’hacking e l’adattamento dei controllers a più software e videogames.

Data la maggior complessità e il numero di gesti che device come il Wiimote Controller offrono, si può capire immediatamente come l’interazione utente-macchina possa andare ben oltre le semplici operazioni offerte dai più comuni Graphic Input Devices.

Il software più completo e compatibile con la maggior parte dei dispositivi di interazione gestuale si chiama Glove PIE, è stato sviluppato da Carl Kenner e l’ultima versione risale al 2010.

L’uso del suddetto kit di sviluppo offre una buona flessibilità. È vantaggioso in fase di programmazione, prototipazione e debugging, qualora si volessero ricreare dei codici per adattare i motion controller alle nostre esigenze. Una volta ultimato l’hacking tuttavia si nota l’insorgere di problemi concernenti l’usabilità, soprattutto per quanto riguarda l’uso ripetuto del dispositivo “personalizzato”.

I dispositivi di interazione gestuale che utilizzano Glove PIE per comunicare i dati alla workstation devono essere impostati ogni volta che vengono collegati al computer, questa condizione diventa improponibile nell’uso quotidiano e reiterato.

L’obbiettivo principale di questa ricerca è la semplificazione di tutti 35

39

40

gli atti che l’utente deve fare per compiere le operazioni di modellazione tridimensionale e il miglioramento del flusso di lavoro; risulta dunque dispersivo richiedere all’utente la ripetizione sistematica delle operazioni di impostazioni del dispositivo, giustificabili solo quando il device deve essere ricalibrato per questioni ergonomiche (cambio fra utenti con fisionomia differente).

L’utente, ogni volta che riavvia la propria workstation, deve attivare i dispositivi bluetooth, interfacciarli affinché si riconoscano tra loro, avviare il software Glove PIE ed infine ricalibrare sia il device interattivo per impostare lo spazio di interazione, sia la velocità dei movimenti (gesti).

Per quanto possa essere veloce l’utente nell’eseguire le operazioni suddette, queste rimangono estranee al processo di creazione dei veri e propri contenuti: in sostanza avremmo l’utente che lavora per la macchina, non viceversa.

Di seguito verranno elencati i dispositivi di interazione gestuale che sono stati considerati come alternativa a GIfB, i motivi per cui sono stati scelti e le problematiche che hanno portato al loro abbandono durante la fase di sviluppo del progetto.

Durante la fase di ricerca è stata posta particolare attenzione al Nintendo Wiimote Controller, considerato all’inizio per quattro fattori principali.

Esempi di motion tracker, 39. Microsoft Kinect 40. Due versioni del Sony Playstation Motion Controller

36

41

1) Interfaccia semplice, provvista di pochi tasti.

L’interfaccia del controller Wii ha otto tasti in totale, dei quali uno per l’accensione-spegnimento ed uno che assolve la multifunzione di direzionalità (tasto a croce: le quattro direzioni alto-basso destrasinistra).

Ad ogni singolo tasto può essere associata una singola operazione, otteniamo quindi almeno 6 tipi di operazioni ai quali vanno sommati i tasti di direzione. Il numero ridotto di tasti abbinato all’interazione gestuale renderebbe l’interfaccia non modale, ma solo in apparenza. Occorre fare una piccola digressione per spiegare il perché.

Si potrebbe pensare che difficilmente un hacking delle istruzioni di interazione possa creare errori modali, in quanto le due tipologie di atti (premere i tasti del controller e muoverlo nell’aria) sono profondamente diverse tra loro, tali differenze hanno anzitutto origine nelle parti diverse del corpo che si utilizzano: braccia ed avambracci per lo spostamento del controller da una parte, dita delle mani per premere i tasti dall’altra.

Sempre Raskin spiega come sia più difficile incorrere in errori modali quando gli atti di parti diverse del corpo si combinano per ottenere un’unica operazione. L’esempio lo fa confrontando, durante la digitazione di un testo, il feedback del Caps Lock e del premere costantemente il tasto Shift al fine di ottenere solo lettere maiuscole: usando il tasto Caps Lock un utente deve spostare il fuoco dell’attenzione dalla digitazione del testo allo stato attuale del tasto 37

41. Nintendo Wiimote Controller

stesso; tenendo con un dito premuto il tasto Shift, e digitando contemporaneamente le lettere con l’altra mano, l’utente non incorrerà in errori modali (lasciare erroneamente il Caps Lock in funzione) in quanto il costante feedback tattile e l’imposizione della posizione del dito sullo Shift coincidono con lo stato dell’interfaccia (l’interfaccia in questo caso è lo stesso tasto Shift). Tuttavia l’errore modale può essere eseguito anche in casi simili a quello ripostato da Raskin. Un esempio di errore modale lo si può individuare nell’utilizzo di un programma di creazione di livelli di videogiochi 3d come l’Unreal Editor all’interno del quale, per svolgere determinate operazioni, all’utente viene richiesto di combinare lo scorrimento del mouse e la costante pressione dei tasti del medesimo.

Nell’Unreal Editor sono presenti le viewport e per la navigazione all’interno della scena si usano: - tasto dx + scorrimento mouse: rotazione orizzontale e verticale del punto di vista nodale (dell’utente) - tasto sx + scorrimento mouse avanti/dietro: navigazione nella scena (avanti e indietro) - tasto sx + scorrimento laterale: rotazione orizzontale del punto di vista nodale Si può notare come l’errore modale corrisponde alla ripetizione della rotazione del punto di vista nodale. Questa scelta progettuale è giustificabile dal fatto che, il tenere premuto il tasto sx mouse abbinato allo scorrimento dello stesso, consente una navigazione all’interno della scena che richiama la navigazione del limbo sia in fase di test e sia in fase di gioco vero e proprio. Ma l’utente potrebbe comunque incappare nella modalità dell’interfaccia, e per risolvere l’errata interazione col programma dovrebbe spostare il fuoco dell’attenzione dalla navigazione nella scena al cambiamento del tasto del mouse spostando lo sguardo o ponendo più attenzione al feedback tattile.

Spiegato in passaggi: - l’utente cambia fov (field of view) orizzontale usando il tasto dx mouse - l’utente sta navigando all’interno della scena e il fuoco dell’attenzione è la navigazione nel limbo attraverso il trascinamento del mouse - l’utente pensa di potersi spostare all’interno della scena (crede di aver premuto il tasto sinistro del mouse) - l’utente trascina il mouse avanti/indietro, pensando di avanzare o arretrare nel limbo - a questo punto il fov rotea in senso verticale e si verifica l’errore modale: l’utente ha feedback negativo rispetto ai suoi gesti e perde il fuoco dell’attenzione dall’atto che voleva svolgere.

In altri programmi si è sempre parlato della combinazione tra tastiera e mouse, gli arti sono differenti.

Un controller gestuale come il Wii viene invece usato principalmente da solo e le parti del corpo interessate in fase di interazione con l’oggetto stesso appartengono al medesimo braccio. Il suo movimento, combinato all’uso delle dita, può generare errori modali.

Pertanto, sebbene le tipologie di atti siano profondamente diverse tra loro, la progettazione dell’interazione può comunque incappare in errori di tipo modale.

38

42

43

44

42-43-44. Dall'alto al basso: combinazioni per la navigazione nel limbo dell'Unreal Editor.

Vengono combinati lo scorrimento del mouse e la pressione continuata sul tasto del mouse.

L'errore modale avviene quando si confondono la prima e la seconda combinazione nonostante il feedback tattile, dato dalla pressione costante del tasto del mouse

Queste considerazioni sulla possibilità di incorrere in errori modali in fase di progettazione rimangono comunque un problema principalmente per il progettista, non per l’utente finale. La presenza dei pochi tasti nel Wiimote Controller rimane di facile apprendimento e utilizzo da parte dell’utente, offrendo comunque qualche opzione in più rispetto al mouse o alla tavoletta grafica.

2) Diffusa conoscenza dei metodi di interazione.

Questo fattore è dovuto principalmente al successo commerciale della consolle Wii e alla sua diffusione nel mercato. Il successo commerciale è avvenuto anche grazie a notevoli campagne pubblicitarie che mostrano l’utilizzo del dispositivo più che i contenuti veri e propri dei videogiochi, questo ha favorito l’apprendimento attraverso l’uso dell’imitazione dei gesti.

45

3) Vasta reperibilità sul mercato.

L’enorme successo della consolle della Nintendo ha ricreato anche un notevole mercato dei vari dispositivi che si interfacciano ad essa. Essi sono acquistabili anche separatamente, il più diffuso rimane comunque il controller base.

4) Costo relativamente basso.

Conseguenza diretta del terzo punto. Il costo del Wiimote, almeno per quanto riguarda il mercato europeo, oscilla tra il prezzo di un mouse laser con alto numero di dpi e le tavolette grafiche più economiche. Con il prezzo equiparabile ai più diffusi Graphic Input Devices utilizzati dai professionisti dell’authoring di contenuti grafici e multimediali il Wiimote Controller si può porre come un’alternativa equiparabile economicamente.

Sebbene siano numerosi i fattori pro-Wiimote sono stati riscontrati dei problemi che vanno ad annullare i punti suddetti.

1) Costruzione di un array di led infrarossi.

Per avere maggior precisione nel traking del Wiimote, è consigliabile costruire un array di Led IR ad hoc, piuttosto che non affidarsi al tracking della barra standard, dotata solamente di due led.

Per fare questo però occorre un minimo di competenza ed un po’ di pratica per costruire l’array e creare il circuito elettronico per alimentare l’array. Per uno studente oppure un haker non ci sono problemi a riguardo, ma è bene valutare che non tutte le tipologie di utenti rientrano in queste due categorie. Costruire l’array comporta una perdita di tempo. Qualora fosse già costruito e dato in dotazione con GIfB lieviterebbero i costi sia per quanto riguarda le materie prime che per l’assemblaggio. Quest’ultimo fattore va dunque contro la linea di principio secondo la quale è meglio fornire all’utente meno dispositivi possibili ad un costo ragionevole. Un’altra opzione potrebbe essere l’acquisto di un array precostruito, utilizzando una 39

45. Telecamera con array di led infrarossi Sony Chipset 20 LED Infrared Camera 480 TV Line. Fonte: www.security-camera-warehouse.com

camera ad infrarossi USB, ma anche in questo caso aumentano gli elementi hardware che l’utente deve gestire e il costo complessivo del sistema di interazione.

2) Aggiunta di dispositivi bluetooth terzi.

La comunicazione tra la workstation ed il Wiimote controller avviene attraverso bluetooth. Qualora il computer non fosse dotato già della periferica in questione occorrerebbe comprarne una, ritornando così alle problematiche descritte nel punto precedente: aumento del numero dei dispositivi e conseguentemente dei costi. Inoltre il collegamento tra il Wiimote e la workstation dovrebbe essere impostato ogni volta che si cominciano ad usare i dispositivi

3) Secondo wiimote.

Il Wiimote controller riesce a fare il tracciamento al massimo di quattro punti contemporaneamente. Rispetto all’idea iniziale di GIfB questo fattore si presenta come un limite alle funzioni che possono offrire sei punti di controllo (pollice-indice-medio di entrambe le mani) più il tracciamento delle mani. Una valida alternativa al Wiimote potrebbe essere il controller equivalente, Playstation 3 SixAxis. Il SixAxis riesce a fare il tracciamento di sei punti, ma rimane comunque un dispositivo progettato per essere usato prevalentemente con due mani.

Occorrerebbe quindi usare due controller Wiimote. Questo offrirebbe la garanzia di avere otto punti tracciabili in totale ed il tracciamento potrebbe essere non solo frontale, ma anche in profondità.

Tuttavia con questa soluzione si raddoppiano il numero dei dispositivi, così come i costi. E a queste condizioni GIfB avrebbe come concorrenti, a parità di prezzo, le tavolette grafiche professionali.

4) Postura del corpo dell’utente.

Poiché GIfB è rivolto ai chi deve produrre dei contenuti multimediali, usando principalmente un software di modellazione tridimensionale, occorre considerare anche la postura generica del corpo dell’utente durante la fase di produzione alla workstation. Tali considerazioni non partono solamente dalla necessità di rendere comodo l’utilizzo del GID da parte dell’utente, ma anche dal fatto che un motion controller come quello della Wii è stato progettato per essere usato adottando posture e movimenti corporei che sono ben diversi dalla normale postazione desktop. Bisogna quindi analizzare separatamente la “postura desktop” e la “postura Wii”.

Quando un utente interagisce con una workstation digitale l’utente è seduto davanti ad un tavolo/scrivania sul quale sono posti lo schermo e i vari GID. Lo schermo è posto frontalmente rispetto lo sguardo dell’utente. Tastiera e mouse (i più comuni GID) sono paralleli allo sguardo dell’utente, in linea teorica un utente dovrebbe porre il fuoco dell’attenzione solo sullo schermo ed utilizzare tastiera e mouse senza porvi lo sguardo. Qualora debba spostare lo sguardo su mouse e tastiera, una leggera inclinazione del capo e la rotazione dei bulbi oculari verso il basso risultano essere dei 40

movimenti talmente naturali da essere ignorati totalmente, in fase di esecuzione: quasi nessuno pensa di compiere questo tipo di atto, mentre lo esegue. Bisogna aggiungere che la postura generica che assume l’utente di fronte ad una workstation digitale può consentire a quest’ultimo di tenere una corretta posizione del proprio busto; inoltre gli arti superiori non subiscono un eccessivo stress in quanto poggiano con gomiti ed avambracci sullo stesso piano di appoggio dello schermo e dei GID. GIfB comporta il movimento nell’aria degli avambracci dell’utente, tuttavia questi si possono muovere usando sempre i gomiti come punti di appoggio; GIfB inoltre è pensato considerando anche l’utilizzo alternato tra controller gestuale e tastiera (per l’immissione di valori e campi alfa-numerici).

Durante l’utilizzo di un motion controller come il Wiimote la posizione dell’utente varia in base a diversi fattori: occorre considerare l’ampiezza schermo, il numero di utenze contemporanee, l’utilizzo di altri human interface devices. In questo frangente viene considerato soltanto l’interfacciamento di un singolo utente. Per quanto riguarda l’ampiezza dello schermo occorre sapere che i monitor utilizzati con le workstation differiscono per diversi fattori rispetto ai più comuni schermi televisivi, tali fattori sono la densità di pixel (dpi) la luminosità (cd/mq), la fedeltà cromatica e la copertura dello spazio colore (identificata di solito con il triangolo di Gamut). Genericamente i monitor per workstation sono di dimensioni inferiori rispetto alla maggior parte degli schermi lcd ad uso domestico. L’utilizzo alternato del motion controller e della tastiera (input alfa-numerici) è l’ultimo fattore che impone all’utente una posizione prossima al monitor della workstation. Come nella “postura desktop” il busto dell’utente è in posizione verticale e parallela alla superficie del monitor. L’alternanza tra controller e tastiera sposta il fuoco dell’attenzione nel momento stesso in cui l’utente si porta ad operare con entrambe le mani sulla tastiera: ciò avviene durante l’atto del posare il controller. Un ipotetico utilizzo dei Pinch Gloves (al posto del Wiimote) non comporterebbe alcuna perdita di attenzione in quanto i guanti sono indossati sulle mani stesse.

L’utilizzo del motion controller obbliga l’utente a puntare il dispositivo verso il tracker, sono tollerate le vari inclinazioni fintanto che il segnale a infrarossi viene visualizzato. Questo costringe l’utente a puntare il controller sempre in avanti e a mantenere mediamente una posizione orizzontale; considerando quindi la vicinanza con il monitor l’utente è obbligato a piegare i polsi in avanti ed un uso prolungato di tale postura può stressare gli atri superiori dell’utente e risultare fastidiosa.

Occorre infine considerare i fenomeni di occlusione: qualora l’utente copra erroneamente il segnale ad infrarossi, il sistema dovrebbe non fornire alcun tipo di input alla workstation.

Kinect, Leap, Natural User Interface.

Per quanto concerne altri tipi di motion controllers già in commercio, o con un forte sviluppo software alle spalle, si possono menzionare il Kinect di Microsoft, il Leap Gesture-based Computer Interaction System (comunemente chiamato Leap) di Leapmotion ed infine il Natural User Interface (NUI) di Intel.

41

Il primo vantaggio nell’utilizzo di questi sistemi è dovuto all’assenza di un’interfaccia a tasti come il Wiimote: in Kinect, Leap e NUI l’interfaccia è il corpo dell’utente.

Il Kinect, come il Wiimote, è diffuso nel mercato delle consolle dei videogiochi e risulta pertanto facilmente reperibile. Il Leap risulta attualmente il più preciso motion controller in commercio (si parla sempre di mercato mainstream).

Purtroppo anche questi tipi di device presentano dei fattori negativi, relativamente al progetto di GIfB. Un fattore negativo che riguarda questi tre motion controllers è il rischio di incappare in fenomeni di occlusione durante l’utilizzo. Il costo di Kinect e Leap è altresì elevato10 e, come già spiegato precedentemente, un professionista potrebbe rivolgersi per lo stesso prezzo ad altri GID. Infine il NUI di Intel, nonostante sia un progetto in forte fase di sviluppo, verrà presentato ufficialmente alla Game Developer Conference (san Francisco, 25-29 marzo 2013): si ritiene opportuno aspettare l’uscita ufficiale prima di valutare in maniera approfondita il dispositivo.

10. Rispettivamente 90$ e 70$, prezzi nei siti microsoftstore.com e leapmotion.com 42

46

46. Motion controller Leap.

Dal posizionamento sulla scrivania si capisce come il tracciamento dei gesti venga effettuato dal basso verso l'alto.

GIfB: SEMPLIFICARE L’USO DI BLENDER. PROPOSTE DELLE GESTUALITÀ DA ADOTTARE

Nel capitolo di analisi comparativa tra le interfacce di Blender, Cinema 4d e 3d Studio max sono state analizzate le varie operazioni che l’utente deve eseguire per creare le scene tridimensionali. Tali operazioni sono quelle elementari, occorre tuttavia fare un elenco che comprenda anche altre operazioni più complesse, occorre infatti definire attraverso quali azioni GIfB aiuta l’utente ad usare Blender e in quali azioni l’utilizzo di GIfB risulterebbe superfluo.

Si possono dunque definire operazioni elementari l’inserimento degli oggetti all’interno della scena, la selezione e deselezione degli oggetti stessi, le operazioni di modifica degli oggetti quali lo spostamento, la rotazione e il ridimensionamento degli oggetti, la cancellazione di essi, ed infine le operazioni per navigare all’interno della scena (spostare il punto di vista, orbitare attorno alla scena, e le operazioni di zoom).

Altre operazioni che si possono definire più complesse, in quanto spostano il fuoco dell’attenzione dell’utente dalla visualizzazione della scena, sono l’immissione di valori alfanumerici e l’interazione con i vari pannelli di Blender. Altre due operazioni complesse sono la gestione del pivot del cursore 3d per l’inserimento degli oggetti; sebbene quest’ultimo sia presente sempre all’interno della scena e l’utente lo utilizzi al pari degli altri oggetti inseriti si ritiene opportuno mantenere la sua gestione in un ambito non appartenente alle operazioni elementari in quanto non è un vero e proprio oggetto, infatti l’unica operazione che si può effettuare con esso è lo spostamento.

Esistono poi altre operazioni che non sono inerenti alla modifica della scena; tra queste si possono elencare la gestione delle viewport, 45

il passaggio tra le differenti modalità, il rendering e l’interazione con altri menu (ad esempio il menu File).

Un dispositivo di interfaccia gestuale che voglia semplificare l’uso di Blender deve emulare gli atti reali che una persona farebbe qualora si ritrovasse ad interagire con oggetti reali. L’esempio più esplicito che può venire in mente è il lavoro dell’artigiano o dello scultore: lavorano in uno spazio definito (ad esempio un tavolo da lavoro), aggiungono dei materiali modificabili (la creta, legno...), modellano e definiscono le forme dei loro oggetti con strumenti appropriati, ed infine li posizionano qualora gli oggetti stessi facessero parte di un insieme. In Blender le operazioni sono le stesse, tuttavia sono gli atti (che servono per compiere queste ultime) a risultare complessi, pertanto in questa sezione di ricerca verranno spiegati gli atti da adottare per emulare la realtà fisica (con oggetti fisici) al fine di rendere più semplici le operazioni che avvengono nella realtà virtuale di Blender. Pensando all’emulazione delle operazioni su oggetti reali occorre anche considerare l’impostazione fisiologica dell’utente (se è destro o mancino) e per facilitare gli esempi nella parte che segue della ricerca, verrà considerato solamente l’utente destro; naturalmente GIfB deve consentire l’inversione delle funzionalità assegnategli in modo da adattarsi dall’utente destro a quello mancino e viceversa.

Inserimento degli oggetti.

Sebbene l’interfaccia di Blender risulti meno intuitiva rispetto alle controparti commerciali analizzate si ritiene opportuno preservare l’attuale impostazione del programma in quanto l’inserimento degli oggetti è un’operazione appartenente alle più elementari, ma al contempo distoglie il fuoco dell’attenzione dell’utente da ciò che viene visualizzato nel limbo. Questo genere di operazione, seppur non immediata, risulta corretta in quanto l’utente vuole (e pensa) di inserire l’oggetto, è dunque concentrato sul nuovo oggetto e non su quelli già esistenti. L’unico elemento che influenza l’inserimento degli oggetti è il cursore 3d, che stabilisce il punto dove essi verranno aggiunti. Il cursore 3d si può spostare, tuttavia la gestione di tale cursore è da considerare separatamente come un’operazione complessa, come precedentemente spiegato, in quanto tutti gli aggiunti alla scena possono avere lo stesso punto di inserimento e possono venire spostati successivamente. La gestione del cursore 3d verrà comunque considerata più avanti.

Selezione e deselezione degli oggetti.

Come già visto precedentemente l’operazione di selezione degli oggetti avviene tramite l’interazione con l’albero gerarchico posto nel pannello a destra del limbo. Questa è un’operazione che si può semplificare. Gli atti che fa un utente per selezionare un oggetto sono: l’individuazione dell’oggetto con lo sguardo, il puntamento tramite il cursore del mouse, il singolo click sull’oggetto. Nella realtà fisica la selezione di un oggetto avviene tramite tre atti quasi uguali: oggetto individuato con la vista, focalizzazione dello sguardo su di esso oppure utilizzo degli arti per indicarlo, identificazione dell’og46

getto tramite un preciso responso che può essere tattile o di altro tipo (ad esempio vocalmente si può asserire “Questo oggetto”). In GIfB il puntamento dell’oggetto si dovrebbe effettuare attraverso il puntatore del mouse, la posizione di quest’ultimo deve essere quindi data dal tracciamento dei movimenti dell’utente; verrebbe naturale per l’utente usare il proprio indice per puntare l’elemento interessato. La selezione vera e propria dovrebbe avvenire tramite contatto tra due dita, in modo da ottenere un feedback tattile e rendere reale la presa dell’oggetto virtuale (emulazione della presa di un oggetto piccolo): questo lo si otterrebbe congiungendo il pollice all’indice che sta puntando l’elemento da selezionare; l’oggetto rimarrebbe selezionato fintanto che l’utente non disgiunga il pollice dall’indice (più semplicemente: lasciare la presa); in questo modo selezione e deselezione diventerebbero due atti che sfruttano la stessa parte del corpo e con un movimento opposto si otterrebbe (nel programma) l’operazione opposta.

Per rendere possibile la selezione degli oggetti si deduce che GIfB debba avere anche degli elementi che consentano di capire quando le dita della mano tracciata sono in contatto tra loro. Occorrerebbe un device simile ai Pinch Gloves, ma non è detto che sia necessario avere tutte le dieci dita delle mani adibite all’azione del contatto. Per l’operazione di selezione basta avere due dita con tale capacità: pollice e indice. In seguito, per ogni genere di operazione, verrà considerata l’adozione di nuove dita capaci di operazioni di contatto oppure la combinazione tra gli elementi di GIfB già a disposizione.

Spostamento, rotazione, ridimensionamento degli oggetti.

Attraverso la selezione dell’oggetto l’utente prende tra due dita l’oggetto virtuale nella scena di Blender. Così come si sposta un oggetto reale tenendolo in mano, GIfB determinerà la posizione dell’oggetto attraverso i dati forniti dal tracking della posizione della mano che “ha preso” l’oggetto.

La rotazione risulta più complessa da emulare: nella realtà la rotazione di un oggetto avviene attraverso la torsione della mano che tiene l’oggetto stesso oppure dal tentato spostamento di un punto sulla superficie dell’oggetto, sfruttando l’attrito per ottenere la rotazione. Il tracciamento della torsione della mano si potrebbe ottenere con un giroscopio; sarebbe preferibile tuttavia aggiungere nuovi punti di contatto tra le dita in quanto i dati forniti da essi sono semplicemente di tipologia true/false (più facili da gestire da GIfB) e un giroscopio aumenterebbe il costo di GIfB (le problematiche legate ai costi dei motion trackers sono state descritte nel precedente capitolo). Se si pensa che l’operazione di selezione e spostamento viene fatta con la mano destra, l’operazione di rotazione può essere effettuata nello stesso modo ma dalla mano sinistra. In questo modo si otterrebbe il feedback tattile, l’utente non sarebbe costretto a difficili torsioni degli arti, ed infine l’operazione di rotazione sarebbe ben distinta da quella di spostamento in quanto eseguita dall’arto opposto a quello principale (mano sinistra al posto della destra).

Occorre dunque aggiungere a GIfB altri due elementi che rilevino il contatto tra il pollice e l’indice della mano sinistra.

Il ridimensionamento di un oggetto (rimpicciolire o ingrandire) è 47

47

48

49

50

Proposte delle gestualità, dall’alto al basso: 47. Indicazione di un oggetto come puntamento del cursore del mouse 48. Selezione dell’oggetto 49. Spostamento dell’oggetto selezionato 50. Rotazione dell’oggetto selezionato

un’operazione diversa dallo spostamento o la rotazione in quanto è meno complessa con gli oggetti virtuali rispetto agli oggetti reali.

Per semplificare gli atti che l’utente deve fare si possono utilizzare gli elementi di GIfB già esistenti. Per spostare un oggetto basta tenere uniti pollice e indice della mano destra e muovere la mano stessa; per roteare occorre fare la stessa operazione ma con la mano sinistra; poiché l’elemento in comune a queste operazioni è il contatto tra pollice ed indice si ritiene opportuno combinare gli atti e sfruttare il tracking delle mani per ridimensionare gli oggetti: esattamente come avviene per l’operazione comune agli smartphone touchscreen per effettuare uno zoom (pinch-to-zoom) per rimpicciolire l’oggetto le mani si dovrebbero avvicinare tra loro e per ingrandirlo le mani si dovrebbero allontanare.

In definitiva le operazioni elementari identificate come sposta/rotea/ scala avrebbero in comune il contatto tra pollice e indice, il feedback tattile ed il feedback visivo dovuto al motion tracking delle mani in tempo reale.

51

52

Cancellazione degli oggetti.

L’eliminazione degli oggetti dalla scena è un’operazione della stessa tipologia dell’inserimento degli oggetti. Non occorre pertanto cambiare la tipologia degli atti già esistenti in Blender.

Navigazione nella scena: pan, orbit, zoom.

Le operazioni di navigazione all’interno della scena avvengono attraverso l’ausilio del tastierino numerico e, come già analizzato, non tutte le tastiere di computer ne sono dotate. Si possono notare come queste tre operazioni siano simili, come feedback visivo, alle operazioni precedentemente descritte come sposta, rotea, scala.

Infatti quando si sposta un oggetto lo si vede muoversi nella scena; così succede con l’operazione di pan: si vedono gli oggetti spostarsi dal lato opposto del movimento di spostamento della visuale, tuttavia l’utente è cosciente di muovere solo la visuale perché il fuoco dell’attenzione dell’utente è rivolto all’azione pan. Lo stesso si può dire per le operazioni di orbit (rotea) e zoom (scala). Per rendere più semplice l’utilizzo di Blender si può sfruttare questa similitudine impiegando gli stessi gesti che l’utente compie per gestire gli oggetti, in particolare il movimento delle mani ed il loro tracciamento.

Occorrerebbe però fornire GIfB di un differente approccio per l’attivazione delle operazioni di navigazione. Basandosi sempre sul principio di feedback tattile si possono aggiungere altri due punti di contatto, uno per ciascun dito medio delle mani. Per traslare il punto di vista basta creare il contatto tra pollice e medio della mano destra e muovere la mano stessa, per orbitare occorre fare la stessa operazione ma con le dita della mano sinistra e la stessa, per effettuare l’operazione di zoom pollice e indice di entrambe le mani devono essere in contatto e le mani si devono allontanare o avvicinare tra di loro.

Si possono generare degli errori modali in quanto l’utente potrebbe confondere il contatto pollice/indice con quello pollice/medio ma questa possibilità è abbastanza ridotta; la selezione dell’oggetto ed 48

53

Proposte delle gestualità, dall’alto al basso: 51. Esempio di movimento per effettuare il "pinch to zoom" in uno smartphone 52. "Pinch to zoom" adattato a GIfB 53. Contatto tra dito pollice e dito medio per effettuare le operazioni di pan, orbit e zoom utilizzando le stesse gestualità per le operazioni sposta, rotea, scala

il suo “impugnarlo” emulano la presa di un oggetto piccolo usando l’indice e il pollice: il pollice è il dito prensile più vicino all’indice e più naturale da usare; l’adozione del contatto tra pollice e medio è facile a livello fisiologico ma meno usata e spontanea in quanto il pollice deve piegarsi maggiormente verso il palmo della mano per raggiungere il dito medio.

Per il momento si è constatato che GIfB necessita di sei punti sensibili di contatto e le operazioni più semplici di gestione degli oggetti e navigazione nella scena possono essere gestite da sei combinazioni di contatto tra dita; bisogna constatare altresì che con sei punti sensibili le combinazioni di contatto (e le operazioni potenzialmente assegnabili) tra i punti aumentano a venti, se si considerano solo i contatti tra due dita.

In seguito verranno descritte le operazioni complesse, vale a dire quelle operazioni che modificano la scena o gli oggetti presenti in essa attraverso l’interazione con le parti dell’interfaccia diverse dalle viewports (i vari pannelli, bottoni, icone e menu) con conseguente spostamento del fuoco dell’attenzione dagli oggetti. Si potrebbe dire che con questo genere di operazioni l’utente non lavora sugli oggetti / nella scena ma per gli oggetti / per la scena.

Immissione di valori alfanumerici.

Per attivare le operazioni più semplici servono dunque dei contatti tra le dita, se l’utente non effettua nessuno di questi atti non può modificare gli oggetti all’interno della scena. Si può dunque dedurre che grazie a questo sistema l’utente è libero di muovere liberamente le mani e passare dall’uso attivo di GIfB all’uso della tastiera e del mouse senza conseguenza alcuna. GIfB non cambia la modalità di immissione di valori alfanumerici rispetto all’attuale impostazione di Blender. Sarebbe poi sbagliato cambiare la tipologia degli atti in quanto, quando un utente vuole immettere dei valori alfanumerici, il fuoco dell’attenzione si sposta all’atto di digitazione su tastiera.

Interazione con i vari pannelli.

Come per l’immissione di valori alfanumerici l’interazione con i vari pannelli di Blender presuppone che il fuoco dell’attenzione si sposti dall’interazione sugli oggetti. Non serve quindi apportare dei cambiamenti all’interfaccia esistente.

Si genera però una ridondanza tra l’operazione di selezione dell’oggetto tramite l’albero gerarchico degli elementi e la selezione dell’oggetto attraverso l’uso di GIfB. In Blender l’oggetto selezionato (usando l’elenco degli oggetti) rimane tale finché non si passa ad un altro oggetto oppure non si deseleziona lo stesso tramite l’uso del menu contestuale usato anche per cancellare gli oggetti (vedi secondo capitolo). Sarebbe un controsenso se un utente volesse selezionare un oggetto tramite i pannelli per poi modificarlo tramite GIfB in quanto rallenterebbe parecchio il suo flusso di lavoro. In tal caso GIfB riconoscerebbe l’oggetto come selezionato e l’utente dovrebbe comunque unire le dita secondo le combinazioni spe49

cifiche per richiamare l’operazione che vuole effettuare; una volta effettuata la modifica, staccando le dita, avverrebbe la deselezione dell’oggetto.

Qualora l’utente volesse selezionare un oggetto dall’elenco degli oggetti, e successivamente navigare nella scena usando GIfB, l’elemento non sarebbe comunque soggetto ad alcuna modifica in quanto pan/orbit/zoom sono operazioni che non modificano gli elementi della scena.

Gestione del pivot.

Anche durante la gestione del pivot l’utente sposta il fuoco dell’attenzione sullo stato di impostazione del programma. L’interazione per questa operazione rimane quella originale di Blender.

Gestione del cursore 3d.

Come precedentemente accennato l’unico elemento che influenza l’inserimento degli oggetti in Blender è il cursore 3d. Questo si può spostare liberamente nella scena e funziona solamente se si sta lavorando in object mode oppure edit mode. Per posizionare il cursore 3d l’utente muove il cursore del mouse all’interno del limbo ed esegue un click con il tasto sinistro: il cursore si posiziona dove è avvenuto il click. Poiché attraverso GIfB il cursore del mouse si muove in base al tracking della mano destra dell’utente, bisognerà pensare all’emulazione del click del mouse attraverso GIfB, potrebbe essere il contatto degli indici di entrambe le mani: l’utente punta la posizione del cursore indicandola con l’indice e fissa la nuova posizione con la combinazione suddetta.

Altre operazioni non inerenti la modifica della scena.

Il passaggio tra le differenti modalità, la gestione delle viewport e l’interazione con gli altri menu dovrebbero avvenire tramite secondo le funzioni di default di Blender, infatti non sono operazioni che modificano gli oggetti o la scena.

Interazione durante l’uso delle altre modalità.

Le altre modalità di Blender consentono una gamma di operazioni avanzate di modifica dei solidi, dei materiali e delle textures. L’utente che utilizza queste modalità è riuscito a superare la soglia del primo approccio a Blender, pertanto lo si può considerare possessore di una conoscenza avanzata del programma. Durante l’uso delle suddette modalità l’interazione con l’interfaccia avviene prevalentemente attraverso la modifica dei parametri nei vari pannelli e non all’interno della scena, come avviene per l’obect mode.

Nonostante non si lavori all’interno della scena GIfB può comunque tornare utile per migliorare il flusso di lavoro, ad esempio attraverso l’utilizzo delle gestualità per gestire la visualizzazione della scena (pan, zoom, orbit); occorre tuttavia escludere le gestualità per la selezione degli oggetti, in quanto l’utente sarà più portato ad interagire con l’albero gerarchico degli elementi, al fine di avere un 50

controllo più oculato del progetto.

Va posta particolare attenzione al tool brush, comune alle modalità sculpt, vertex, texture e weight.

In queste modalità il tool brush viene attivato combinando il trascinamento del mouse e la costante pressione del tasto sinistro, esattamente come avviene per lo strumento pennello presente nei più diffusi software di disegno grafico (Adobe Photoshop, Gimp, Microsoft Paint, etc.). In questo caso il click continuato del mouse può essere emulato sempre attraverso la giunzione tra pollice e indice della mano destra; il trascinamento del mouse, invece, può essere affidato ad un ulteriore sensore: un sensore di flessibilità, piegandosi, fornirà a Blender i dati al pari del trascinamento del mouse. Il bend sensor è stato adottato per rendere migliore il feedback visivo, soprattutto quando si lavora in sculpt mode. Piegare il dito emula l’atto di “grattare” la superficie dell’oggetto col quale si sta interagendo: se lo sculpt mode è impostato come sottrattivo (il tool brush “scava” l’oggetto) il feedback visivo corrisponde a quello che accadrebbe nella realtà, quando l’utente si modella un oggetto fatto di materiale malleabile come l’argilla; nel caso di tool brush impostato come additivo (l’oggetto viene “gonfiato”) il feedback visivo non disorienterebbe l’utente in quanto memore dell’impostazione sottrattiva.

51

CONCEZIONE DEL PROTOTIPO

Dopo l’analisi dei vantaggi e delle problematiche insite nell’adozione di dispositivi già presenti in commercio (o sulla soglia della commercializzazione come nel caso dell’Intel NUI) si è considerato di progettare GIfB partendo da semplici sensori, al fine di ottenere un dispositivo di tracciamento del movimento ex-novo.

Progettare GIfB basandosi sulle operazioni che l’utente vuole eseguire, e sugli atti che conseguentemente deve fare, impone immediatamente l’obiettivo di adattare GIfB all’utente sin dalla sua progettazione. Con l’adozione di motion controllers già esistenti il progetto tenderebbe a costringere l’utente ad adattarsi al dispositivo.

Per tradurre le gestualità negli input per la workstation grafica si è pensato di adottare e combinare diversi tipi di dispositivi.

Servirebbero dei Pinch Gloves, ossia dei guanti con sensori sui polpastrelli delle dita, tali sensori funzionano quando le dita vengono a contatto tra loro esattamente come se fossero interruttori elettrici; questo consentirebbe alla workstation di capire quando l’utente vuole selezionare gli oggetti in Blender e modificarli; si è già visto che sarebbero sufficienti solo tre punti sensibili per ogni mano: il pollice, l’indice ed il medio.

Si è visto inoltre che servirebbe un sensore di flessibilità (bend sensors) per fornire alla workstation lo stato di piegatura delle dita dell’utente, in questa maniera il computer tradurrebbe il movimento delle dita dell’utente in dati di modifica degli oggetti e sarebbe utile per le modalità, sculpt, vertex, texture e weight.

Per il tracciamento del movimento delle mani dell’utente è stato preso in considerazione il tracking ultrasonico: consentirebbe 53

a Blender di interpretare l’esatta posizione delle mani dell’utente all’interno del sistema di coordinate di Blender stesso, come se il progettista avesse le mani all’interno del limbo.

Tracking ultrasonico.

Uno dei vantaggi del traking ultrasonico è il basso costo. Per questo motivo è preferibile al tracking magnetico. Esistono specifici emettitori di suono che vanno oltre il range della percezione umana, reperibili in molti negozi online di prototipazione.

Esistono anche gli infrasuoni, ma essi sono da escludere a priori visto la loro lunghezza d’onda. Questa, sotto i 20Hz, è maggiore della distanza d’interazione tra l’utente e la macchina.

Esistono tracker ultrasonici già costruiti sul mercato con software in bundle ma costano eccessivamente, eccedendo di gran lunga i prezzi di mercato dei controller ad infrarossi già menzionati e degli altri dispositivi per l’input grafico, come le tavolette grafiche.

Come deve essere direzionata l’emissione dei suoni.

Più si alza la frequenza meno il segnale è omnidirezionale. La posizione degli emettitori era stata programmata all’altezza dei polsi.

Tuttavia si pone il problema dell’inclinazione dell’avambraccio.

Quando si abbassano le mani rispetto allo schermo il suono si propaga verso il basso, rimbalza sulla superficie di fonte allo schermo e poi viene recepita dal tracker. Per questo motivo nei progetti di tracker ultrasonici, l’emitter e il tracker sono posti uno di fronte all’altro11.

Non è detto che la propagazione del suono in altre direzioni, purché non opposte allo schermo della WS, sia un problema. Il tracking ultrasonico funziona come il sonar di un sottomarino, occorre decidere pertanto la quantità e la frequenza del numero di impulsi audio da emettere. Il difetto dell’emissione di impulsi audio sta nell’impossibilità di controllo dell’eco. Qui l’inquinamento acustico potrebbe influenzare i ricettori degli ultrasuoni ma, visto la bassa potenza di emissione (in decibel) degli impulsi, è un problema trascurabile.

Ricerche hanno dimostrato che la degradazione del segnale comincia a diventare problematica sotto la soglia dei 14 impulsi per secondo, i quali si tradurranno nella workstation in 14fps di refresh dell’immagine sullo schermo12.

Nel caso in cui il tracker e gli emitters fossero collegati direttamente ad un unico controller e quest’ultimo fosse connesso direttamente alla workstation, diminuirebbe la quantità di dati da gestire da GIfB: questo comporterebbe l’adozione di un controller non particolarmente potente.

Come esempio principale di tracker è stato preso in considerazione il Ping Ultrasonic Range Finder from Parallax. Esso determina con precisione al centimetro dove sono posti i transmitters ultrasonici.

11. G.C. Burdea, P. Collins, Virtual Reality Technology, John Wiley & Sons, 2003 12. Ibid.

54

90˚

90˚

Tuttavia questi hanno problematiche per quanto riguarda la direzionalità del suono. I ricevitori sonori possono venire posti di fronte allo schermo della nostra WS, tuttavia bisogna calcolare con precisione l’area utile di funzionamento. Osservando i coni di emissione sonora da parte dei trasmettitori (fonte i datasheet) si vede come a -6db l’angolo di emissione sia 55°. Questo significa che ad una distanza di 60 cm dallo schermo avremmo un’area di lavoro circolare di ~60 cm di diametro.

Servirebbe calcolare il giusto orientamento dei ricevitori di modo da consentire all’utente di avvicinarsi il più possibile allo schermo.

I ricevitori e gli emettitori di frequenze ultrasoniche vengono venduti con diverse frequenze di funzionamento: principalmente 40kHz e 32,768kHz. I ricevitori devono essere tre e ricevere alternativamente le frequenze, gli emitters devono lavorare in maniera asincrona.

Per ottenere un refresh minimo di 25fps a processo di elaborazione finito, bisogna avere da un minimo di 50ips all’atto dell’emissione (25ips per ogni frequenza ultrasonica). Per gestire gli impulsi, sia gli emettitori che i ricevitori, è sufficiente un solo microcontroller come Arduino.

Ping Ultrasonic Range Finder from Parallax opera come un sonar ed ha un range di misurazione della distanza che va da ~2cm a 3m. Poiché in GIfB sono separati, in quanto quest’ultimo non lavora come un sonar, occorre raddoppiare il range suddetto da ~4cm a 6m. Impostando un delay di 15ms tra un impulso e l’altro, si può arrivare ad ottenere 60ips abbondanti, 66,6 ips, per l’esattezza.

Rimane sempre l’incognita del lag per la trasmissione dei dati via wireless, ma per il prototipo si possono usare le linee RX/TX del microcontroller, ovviando al problema.

■ Directivity in Overall Sensitivity MA40S5 Beam Pattern 0° 30°

0(dB)

30°

-10(dB) 60°

60° -20(dB)

90°

54

Posizionamento degli emitters.

A livello anatomico l’utente lavorerà spontaneamente in tre posizioni principali (si parla solo di posizioni e orientamento delle mani): - palmi rivolti l’uno verso l’altro.

- palmi rivolti verso il basso, paralleli a tastiera-mouse (piano orizzontale).

- palmi paralleli allo schermo.

Sono stati considerati inoltre: palmi rivolti verso il volto dell’utente (l’utente porta verso di sé un oggetto ma lo può fare anche con palmi rivolti allo schermo, lavorando con l’intero braccio) e la posizione dei palmi paralleli alla tastiera ma rivolti verso l’alto (l’utente solleva un oggetto in Blender ma lo può fare anche con palmo rivolto verso il basso).

La posizione ideale degli emettitori a impulsi ultrasonici è dunque nella parte sottostante il polso, a livello dell’attaccatura delle ossa della mano, su radio e ulna.

Non si avrebbero problemi di errori dovuti a movimenti di rotazione del polso, il problema è il fastidio che si avrebbe nell’appoggiare i polsi sulla tastiera per scrivere.

Il rimedio pensato sarebbero dei cuscinetti che proteggano gli emitters e fungano anche da poggia-polsi.

Quando le mani scrivono sulla tastiera il receiver che riceverà il 55

54. Diagramma dell'area di lavoro di un ricevitore/emettitore ad ultrasuoni a 40kHz. Il pezzo in commercio è il Piezoelectric Ceramic Sensors (PIEZOTITE®), modello MA40B8R/S, prodotto dalla Murata Manufacturing Co.

90°

90˚

55

suono direttamente sarà quello posto nella parte bassa dello schermo, gli altri riceveranno il suono solo da eco sulla tastiera, questo comunque fornisce il posizionamento dei polsi nello spazio.

Nella calibrazione di GIfB dunque non soltanto vanno prese la flessione massima e minima del bend sensor, ma anche la posizione limite delle mani: quando GIfB riconosce la posizione dei polsi adiacenti alla tastiera del computer (l’utente sta scrivendo) il sistema comunica alla workstation di ignorare i dati ricevuti dagli emitters.

Posizionamento del tracker ultrasonico (receivers).

Visto le limitazioni dei ricevitori di ultrasuoni è meglio avere il triangolo con due vertici alla base dello schermo della workstation e il vertice superiore in cima allo schermo stesso, in modo da strutturare un triangolo isoscele. Il receiver in alto avrà la medesima posizione di una webcam (comune a molti computer portatili).

Movimento dello schermo.

Una volta costruito il tracker sullo schermo, in linea teorica quest’ultimo non dovrebbe muoversi; tuttavia ogni schermo è orientabile, ed esiste la possibilità che esso venga roteato durante la fase di lavoro. Questo succede con gli schermi commercializzati per il mercato consumer ma soprattutto coi laptop generici, dove spesso si aggiusta l’orientamento dello schermo sull’asse orizzontale a causa 56

55. Sistema di tracking ultrasonico, schema di posizionamento degli emitters e dei receivers.

A sinistra la prima versione pensata, a destra quella definitiva.

Legenda: Emitters: punti verdi Receivers: punti neri Pdx e Psx sono rispettivamente il polso destro ed il polso sinistro.

Le linee rosse sono le misurazioni fatte dai microcontrollers, derivanti dagli impulsi sonori. Conoscendo la posizione dei receivers si determina il triangolo nero, che sarà la base dei tetraedri. Il programma, risolvendo i tetraedri con i vertici Pdx e Psx, determinerà le coordinate degli emitters e dunque la posizione delle mani dell'utente.

Il prolungamento dal punto Psx è il bend sensor.

dei riflessi dell’ambiente esterno e della bassa fedeltà cromatica.

Pensare che l’utente bisognoso di aggiustare l’angolo di visuale dello schermo (laptop) debba in seguito ricalibrare GIfB (l’utente orienta lo schermo per non cambiare postura di fronte ad esso) pone seri interrogativi sulla possibilità che sia l’utente ad adattarsi a GIfB e non viceversa. Il monitor della workstation (ed il tracker ad esso applicato) dovrebbero essere sempre perpendicolari allo spazio interessato dai gesti dell’utente in fase di modellazione.

Considerazioni sulla gestione degli impulsi.

Il suono viene generato con precisa frequenza dagli emitters utilizzati, i quali basano la loro emissione su specifici oscillatori al quarzo, tarati per emettere 40kHz. Come già visto si presuppone ci siano 66,6 ips, a questi vanno aggiunti i tempi di impulso e delay nell’ordine di 10µs. Ad ogni insieme di 66 impulsi si devono aggiungere: 66 x 0,010 = 0,66 ms che sommati ai 66 * 15 = 990 ms fanno in totale 990,66 ms. Si otterrebbe così che un ciclo di 66 ips fornisce uno scarto di 9,34 ms al secondo.

Nel lasso di tempo di un secondo l’utente non noterà affatto la differenza.

Basta vedere i tempi di refresh di un qualsiasi schermo lcd, non necessariamente progettato per hardcore gamers (refresh da 2ms), anche gli schermi professionali usati per grafica bidimensionale hanno un refresh da 8ms, al limite da 14ms. Se l’utente non percepisce un refresh di 14ms sul monitor, non può dunque recepire lo scarto di circa 9,5ms dato dal funzionamento di GIfB.

Prototipo: componenti restanti e collegamenti.

Come già visto il prototipo non deve essere necessariamente wireless, anche se esistono i controller adatti.

Per capire l’interazione tra utente ed oggetti virtuali come selezione, orientamento e modifica degli oggetti, occorrono sei switch, da assegnare alle sei dita: pollice, indice e medio di entrambe le mani.

Quindi ciascuna delle tre dita delle mani deve dare la possibilità di contatto elettrico per fornire le condizioni true/false. Per comodità verranno chiamati d’ora in poi come Switch-Touch (ST).

Bisogna poi considerare il bend sensor, il quale serve a definire i dati per gli altri tipi di operazioni come l’utilizzo dello sculpt mode.

Per comodità il bend sensor verrà abbreviato in BND. Per fornire la posizione delle mani rispetto lo spazio si devono usare degli emettitori di ultrasuoni, come già precedentemente spiegato. Essi verranno posizionati sotto i polsi delle mani e verranno chiamati Ultra Sound Emitter (USE).

Dalla parte dell’utente vengono dunque forniti alla workstation (WS) 57

tre differenti flussi di dati, gli USE mandano il suono direttamente al computer. Gli ST ed il BND devono passare attraverso un microcontroller esterno, in tal caso basta anche un dispositivo non troppo complesso come Arduino (per comodità il controller posizionato sull’utente verrà nominato Micro Controller User (mcU)).

Gli ST devono essere gestiti attraverso i digital pins, il BND deve fornire la tensione elettrica ad un analog pin. La corrente per entrambe ST e BND può essere fornita attraverso il pin di erogazione a 5v.

56

Dunque si ottiene un cavo di erogazione energetica che si separa in 3 linee differenti: - 1 per fornire energia al BND della mano sinistra - 1 per fornire l’energia all’USE della mano destra - 1 per fornire l’energia all’USE della mano sinistra Per fornire l’energia costante agli ST basta un solo cavo proveniente da un pin digitale. Per riceve gli impulsi che generano le condizioni true/false servono quattro cavi; si ottengono così 5 linee elettriche: - 1 cavo per emettere il segnale agli ST dei pollici di entrambe le mani - 2 cavi provenienti dagli ST (indice e medio) della mano destra - 2 cavi provenienti dagli ST (indice e medio) della mano sinistra Occorrono altri cavi per fornire l’input elettrico agli USE al fine di trasmettere gli impulsi ultrasonici. Come USE sono stati adottati cinque sensori HC-SR04, in quanto più economici rispetto al sensore della Parallax; questi sensori adottano un pin per l’impulso e un pin per il ritorno dell’ultrasuono (eco), si hanno così 3 cavi: - 1 cavo per l’impulso dell’USE della mano destra - 1 cavo per l’impulso dell’USE della mano sinistra - 1 capo per il ritorno dell’eco (che verrà ignorato da GIfB ma serve per un corretto funzionamento di entrambi gli USE) Considerando il ritorno degli input dai sensori posti sulle mani dell’utente si hanno: - 3 cavi di rilevamento condizione true/false dagli ST della mano destra - 3 cavi di rilevamento condizione true/false dagli ST della mano sinistra - 1 cavo proveniente dal BND della mano sinistra (con tensione elettrica cambiata dalla flessione del BND e quindi valore analogico misurabile) Considerando anche la massa-terra si contano: - 1 cavo di massa-terra proveniente dal bend sensor - 1 cavo di massa-terra dall’ USE della mano destra - 1 cavo di massa-terra dall’ USE della mano sinistra Per quanto concerne il microcontroller occorre anche considerare i cavi di comunicazione con la workstation, RT/TX. Forse il prototipo si può avvalere direttamente di comunicazione RT/TX tramite semplice cavo usb, ma queste considerazioni verranno fatte in seguito.

58

56. Sensore ad ultrasuoni HC-SR04.

Lo speaker sinistro emette gli impulsi sonori, quello destro li riceve.

In fase di sperimentazione risulta necessario coprire lo speaker sinistro quando l'HC-SR04 funge da ricevitore e lo speaker destro quando l'HC-SR04 funge da emettitore

57

Dalla parte della workstation troveremo solamente i tre ricettori ultrasonici (per semplificare gli Ultra Sound Receiver verranno abbreviati a USR) per determinare la posizione dei polsi (dunque delle mani) dell’utente. Gli USR devono essere alimentati e fornire il dato dell’impulso ricevuto ad un altro microcontroller, in questo caso si hanno i seguenti cavi: -1 cavo di trasmissione energia ai tre USR -1 cavo di massa-terra dai tre USR -1 cavo per la trasmissione dell’impulso dagli USR (adottato per farli funzionare) -3 cavi per la trasmissione dell’impulso ricevuto Calcolando il numero di cavi e di segnali di input/output da gestire si può constatare come una sola scheda Arduino sia più che sufficiente per interpretare gli atti che l’utente compie durante l’utilizzo di GIfB. Basterà infine un cavo USB per fornire i dati dei vari sensori alla Workstation.

59

57. Schema di collegamento dei componenti di GIfB. I cavi rossi portano l'alimentazione elettrica a 5V. I cavi neri collegano i vari sensori alla massa terra.

I cavi blu forniscono ad Arduino l'attivazione degli ST. I cavi verdi forniscono gli impulsi ai sensori HC-SR04.

I cavi viola forniscono ad Arduino l'eco ricevuto dagli HC-SR04.

Il cavo arancione fornisce l'input analogico dal BND.

CODICI PER IL FUNZIONAMENTO DI GIfB

Come già visto il prototipo di GIfB ha bisogno di un solo microcontroller per funzionare. Questo deve trasformare gli input elettrici dei sensori in dati da poter inviare a Blender. È stato identificato il microcontroller Arduino come ideale in quanto risponde a tutte le esigenze di input, sia analogico che digitale; non di meno il suo basso costo e la facile reperibilità lo rendono adatto ad un progetto che di base non vuole risultare troppo costoso o difficile da costruire.

Arduino è programmabile, utilizza un linguaggio di derivazione Java, quindi risulta abbastanza semplice da gestire. La scheda non è dotata di molta memoria interna, i programmi che si possono caricare non possono essere particolarmente complessi, tuttavia questo non ha inficiato la compilazione degli sketch adatti al prototipo.

Blender, attraverso la sua interfaccia modale, offre agli utenti più esperti la possibilità di inserire dei programmi fatti con Python.

Python è molto più complesso come linguaggio di programmazione rispetto ad Arduino. In quanto tesi sperimentale di design si è deciso di non approfondire l’aspetto di programmazione in Python, prerogativa di un ingegnere informatico, bensì di rintracciare i giusti programmi che consentano l’interazione tra Arduino e Python.

In questa parte di testo verranno presentati gli sketch di base per fare funzionare GIfB.

61

Programma per il funzionamento del tracking ultrasonico.

Si è visto precedentemente come il tracking ultrasonico si ottenga attraverso la presenza di due emitter, posizionati sotto i polsi dell’utente, e di tre receivers posti sullo schermo della workstation.

L’esempio pratico di rilevazione di distanza di un oggetto fluttuante nello spazio, attraverso l’utilizzo di impulsi ultrasonici, è dato dal codice del Ping Ultrasonic Range Finder from Parallax: /* Ping))) Sensor

This sketch reads a PING))) ultrasonic rangefinder and returns the distance to the closest object in range. To do this, it sends a pulse to the sensor to initiate a reading, then listens for a pulse to return. The length of the returning pulse is proportional to the distance of the object from the sensor.

The circuit: * +V connection of the PING))) attached to +5V * GND connection of the PING))) attached to ground * SIG connection of the PING))) attached to digital pin 7 http://www.arduino.cc/en/Tutorial/Ping

created 3 Nov 2008

by David A. Mellis modified 30 Jun 2009

by Tom Igoe

This example code is in the public domain. */ // this constant won’t change. It’s the pin number // of the sensor’s output: const int pingPin = 7; void setup() { // initialize serial communication: Serial.begin(9600); } void loop() { // establish variables for duration of the ping, // and the distance result in inches and centimeters: long duration, inches, cm;

// The PING))) is triggered by a HIGH pulse of 2 or more microseconds. // Give a short LOW pulse beforehand to ensure a clean HIGH pulse: pinMode(pingPin, OUTPUT); digitalWrite(pingPin, LOW); delayMicroseconds(2); digitalWrite(pingPin, HIGH); delayMicroseconds(5); digitalWrite(pingPin, LOW);

// The same pin is used to read the signal from the PING))): a HIGH // pulse whose duration is the time (in microseconds) from the sending // of the ping to the reception of its echo off of an object. pinMode(pingPin, INPUT); duration = pulseIn(pingPin, HIGH);

}

// convert the time into a distance inches = microsecondsToInches(duration); cm = microsecondsToCentimeters(duration); Serial.print(inches); Serial.print(“in, “); Serial.print(cm); Serial.print(“cm”); Serial.println(); delay(100);

long microsecondsToInches(long microseconds)

62

{

}

// According to Parallax’s datasheet for the PING))), there are // 73.746 microseconds per inch (i.e. sound travels at 1130 feet per // second). This gives the distance travelled by the ping, outbound // and return, so we divide by 2 to get the distance of the obstacle. // See: http://www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf return microseconds / 74 / 2;

long microsecondsToCentimeters(long microseconds) { // The speed of sound is 340 m/s or 29 microseconds per centimeter. // The ping travels out and back, so to find the distance of the // object we take half of the distance travelled. return microseconds / 29 / 2; }

Il dispositivo qui citato funziona proprio come un sonar e grazie ad una sola coppia di USE-USR rileva la distanza dell’oggetto più vicino in movimento grazie al riflesso del suono. Il codice è stato adattato alle esigenze progettuali:

void setup() { pinMode(2,OUTPUT); //rec. pinMode(3,OUTPUT); //emitt_sx pinMode(4,OUTPUT); //emitt_dx pinMode(12,INPUT); //return emitt_dx pinMode(8,INPUT); //return emitt_sx pinMode(11,INPUT); //rec base_sx pinMode(10,INPUT); //rec alto pinMode(9,INPUT); //rec base_dx Serial.begin(9600); }

void loop(){ //si alternano gli impulsi receiver+emitter_sx e receiver+emitter_dx digitalWrite(2,LOW); digitalWrite(3,LOW); digitalWrite(2,HIGH); digitalWrite(3,HIGH); delayMicroseconds(10); digitalWrite(2,LOW); digitalWrite(3,LOW); long dur_sx_Uno = pulseIn(11,HIGH); int sx_Uno = 0.034 * dur_sx_Uno; if (sx_Uno < 14) sx_Uno = 14; // i valori dal 13 al 9 vengono male interpretati da Python delay(15); //consentire ad Arduino di calcolare long digitalWrite(2,LOW); digitalWrite(3,LOW); digitalWrite(2,HIGH); digitalWrite(3,HIGH); delayMicroseconds(10); digitalWrite(2,LOW); digitalWrite(3,LOW); long dur_sx_Due = pulseIn(10,HIGH); int sx_Due = 0.034 * dur_sx_Due; if (sx_Due < 14) sx_Due = 14; delay(15); //consentire ad Arduino di calcolare long digitalWrite(2,LOW); digitalWrite(3,LOW); digitalWrite(2,HIGH); digitalWrite(3,HIGH); delayMicroseconds(10); digitalWrite(2,LOW); digitalWrite(3,LOW); long dur_sx_Tre = pulseIn(9,HIGH); int sx_Tre = 0.034 * dur_sx_Tre; if (sx_Tre < 14) sx_Tre = 14; delay(15); //consentire ad Arduino di calcolare long

63

digitalWrite(2,LOW); digitalWrite(4,LOW); digitalWrite(2,HIGH); digitalWrite(4,HIGH); delayMicroseconds(10); digitalWrite(2,LOW); digitalWrite(4,LOW); long dur_dx_Uno = pulseIn(11,HIGH); int dx_Uno = 0.034 * dur_dx_Uno; if (dx_Uno < 14) dx_Uno = 14; // i valori dal 13 al 9 vengono male interpretati da Python delay(15); //consentire ad Arduino di calcolare long digitalWrite(2,LOW); digitalWrite(4,LOW); digitalWrite(2,HIGH); digitalWrite(4,HIGH); delayMicroseconds(10); digitalWrite(2,LOW); digitalWrite(4,LOW); long dur_dx_Due = pulseIn(12,HIGH); int dx_Due = 0.034 * dur_dx_Due; if (dx_Due < 14) dx_Due = 14; delay(15); //consentire ad Arduino di calcolare long digitalWrite(2,LOW); digitalWrite(4,LOW); digitalWrite(2,HIGH); digitalWrite(4,HIGH); delayMicroseconds(10); digitalWrite(2,LOW); digitalWrite(4,LOW); long dur_dx_Tre = pulseIn(9,HIGH); int dx_Tre = 0.034 * dur_dx_Tre; if (dx_Tre < 14) dx_Tre = 14; delay(15); //consentire ad Arduino di calcolare long Serial.write(sx_Uno); Serial.print(“ “); Serial.write(sx_Due); Serial.print(“ “); Serial.write(sx_Tre); Serial.print(“ “); Serial.write(dx_Uno); Serial.print(“ “); Serial.write(dx_Due); Serial.print(“ “); Serial.write(dx_Tre); Serial.print(“ “); Serial.println(); }

delay(10); // totale 100ms delay

Già precedentemente si è capito come l’esatta posizione di un punto fluttuante nello spazio può essere determinata dalla misura di tre distanze dell’oggetto fluttuante rispetto a tre punti fissi: basta immaginare una piramide a base triangolare, data la conoscenza della forma e della grandezza della base sono sufficienti le tre distanze dai vertici della base stessa per determinare la posizione del vertice della piramide.

In questo caso entrambe gli USE sono gli oggetti fluttuanti nello spazio, mentre i tre USR posti sulla workstation sono la base della piramide.

Visto le ridotte capacità di calcolo di Arduino, si è deciso di usare il microcontroller solamente per raccogliere i dati e mandarli alla workstation. Sarà compito di quest’ultima calcolare le coordinate degli ultrasound emitters al fine di ottenere il tracciamento della posizione delle mani dell’utente.

64

Programmi per l’interfacciamento tra Arduino e Blender.

Come base di partenza per programmare l’interazione tra Blender e Arduino attraverso Python è stato scelto il progetto “Tornio Digitale” sviluppato dal FabLab di Torino.

Nel “Tornio Digitale” si modifica un vaso disegnato con delle nurbs in Blender; attraverso dei potenziometri collegati ad Arduino è possibile cambiare in tempo reale le dimensioni del vaso, una volta ottenuta la forma desiderata questo verrà creato con una stampante 3d. Uno sketch di Arduino permette alla scheda di leggere gli input analogici ottenuti dai potenziometri e mandarli alla workstation tramite la porta seriale. In seguito viene riportato il programma di Python per il riconoscimento dei dati mandati da Arduino. import bpy import time import serial steps=0 #steps variable screw=0 #screw variable (in progress) #variables of each of the four knob dist1=1 dist2=1 dist3=1 dist4=1 val=0 #the value read from the serial port start=True #create a curve object path =bpy.data.curves.new(‘MyPath’,’CURVE’) pathOb=bpy.data.objects.new(‘Path’,path) pathOb.location=(0,0,0) scn=bpy.context.scene scn.objects.link(pathOb) path.dimensions=’3D’ spline=path.splines.new(‘NURBS’) scn.objects.active = pathOb #add a list of points to the curve pointList=[(0,0,0,6),(0,30,0,6),(0,30,0,6),(0,30,30,6),(0,30,60,6),(0,30,90,6)] nPoints=len(pointList) print (nPoints) spline.points.add(nPoints-1) for n in range(nPoints): spline.points[n].co=pointList[n] spline.use_endpoint_u=True #add the srew mofifier to the curve to make a vase screwMod=pathOb.modifiers.new(type=”SCREW”,name=”screw”) screwMod.steps=5 #solidify the mesh to make the object ready to be printed solidMod=pathOb.modifiers.new(type=”SOLIDIFY”,name=”Solidify”) solidMod.thickness=3 for i in range(len(spline.points)): print (“****”) print (spline.points[i].co) #spline.points[1].co=(-2.0,-1.0,-8.0,6)

65

#change “/dev/tty.usbmodemfa141” with the serial port wich Arduino is connected to ser = serial.Serial(“/dev/tty.usbmodemfa141”,9600) # open first serial port print (ser.portstr) # check which port was really used #create a modal timer to make possible to see the changes in real time class ModalTimerOperator(bpy.types.Operator): ‘’’Operator which runs its self from a timer.’’’ bl_idname = “wm.modal_timer_operator” bl_label = “Modal Timer Operator” _timer = None def modal(self, context, event): if event.type == ‘ESC’: #when clic esc button the script stops and close the serial port return self.cancel() ser.close() #cloese serial port if event.type == ‘TIMER’: line=ser.readline() #read a line from the serial port #print(line) l=len(line.split()) #check how many splitted values there are on the line read print(l) if(nPoints==l+1): #check if it is the correct number of values(this is needed to avoid out of bounds excemptions) for i in range(l-1): val=(float)(line.split()[i])#read each value of a line print(i) print(spline.points[i].co) spline.points[i+2].co=(spline.points[i+2].co[0],val,spline.points[i+2].co[2],6) #modify the y coord of each point of the curve except the first point val=(float)(line.split()[4])#read the value of the steps var=(int)(val/51.2) screwMod.steps=var+3#update the steps value # change theme color, silly! color = context.user_preferences.themes[0].view_3d.back color.s = 1.0 color.h +=0.01 #spline.points[1].co=(-2.0,spline.points[1].co[1]+0.1,-8.0,6) bpy.ops.transform.rotate(value=(0.01,),axis=(0,0,1)) return {‘PASS_THROUGH’} def execute(self, context): context.window_manager.modal_handler_add(self) self._timer = context.window_manager.event_timer_add(0.0001, context.window) return {‘RUNNING_MODAL’} def cancel(self, context): context.window_manager.event_timer_remove(self._timer) return {‘CANCELLED’} def register(): bpy.utils.register_class(ModalTimerOperator) def unregister(): bpy.utils.unregister_class(ModalTimerOperator) if __name__ == “__main__”: register() # test call bpy.ops.wm.modal_timer_operator()

Questo programma interpreta i valori ricevuti e cambia le dimensioni del vaso virtuale in Blender. Tuttavia, al momento di utilizzo di tale programma, si sono verificati degli errori di lettura dei dati provenienti da Arduino. Nonostante queste problematiche il codice del “Tornio Digitale” è risultato utile per la parte relativa ai cambiamenti 66

58. Come appare il "Tornio Digitale" in base al programma fatto dal FabLab. 59. Come appare il "Tornio Digitale" nelle prove effettuate per il prototipo di GIfB.

58

59

67

in tempo reale, più precisamente per la creazione del Modal Timer, (si veda il codice, righe “#Create a modal timer...” e seguenti).

Si è rivelato necessario usare separatamente Python per effettuare diverse prove di lettura dei dati forniti da Arduino. È stato sviluppato dunque il codice corretto per interpretare i bytes ricevuti, trasformarli in variabili int e float, ed infine calcolare le coordinate degli ultrasound emitters. Qui sotto il codice base Python: import serial import math porta = serial.Serial(‘com4’, 9600) #la porta deve essere impostata while True: #legge i dati sulla porta seriale e crea una lista di dati leggi = porta.readline().split() # i dati sx_Uno = sx_Due = sx_Tre = dx_Uno = dx_Due = dx_Tre =

vengono letti in base alla loro posizione nella lista leggi[0] leggi[1] leggi[2] leggi[3] leggi[4] leggi[5]

# i dati vengono trasformati in numeri interi, # emitter mano sinistra aS = int.from_bytes(sx_Uno, byteorder = ‘big’) bS = int.from_bytes(sx_Due, byteorder = ‘big’) cS = int.from_bytes(sx_Tre, byteorder = ‘big’) # i dati vengono trasformati in numeri interi, # emitter mano destra aD = int.from_bytes(dx_Uno, byteorder = ‘big’) bD = int.from_bytes(dx_Due, byteorder = ‘big’) cD = int.from_bytes(dx_Tre, byteorder = ‘big’) base = # immettere la distanza tra gli USR posti alla base del tracker ultrasonico # uso del teorema dei coseni, dei seni e di Pitagora per il calcolo delle coordinate # Emitter mano sinistra angoloS = math.degrees((math.acos((cS**2 + base**2 - aS**2)/(2*cS*aS)))) xS = round((cS * math.sin(angoloS)),2) yS = round((math.sqrt(cS**2 - xS**2)),2) zS = round((math.sqrt(bs**2 - xS**2)),2) # uso del teorema dei coseni, dei seni e di Pitagora per il calcolo delle coordinate # Emitter mano destra angoloD = math.degrees((math.acos((cD**2 + base**2 - aD**2)/(2*cD*aD)))) xD = round((cD * math.sin(angoloD)),2) yD = round((math.sqrt(cD**2 - xD**2)),2) zD = round((math.sqrt(bD**2 - xD**2)),2)

Lavorando sul codice nei vari passaggi si è notato che, all’aumentare del flusso dei dati, Python diviene esponenzialmente più lento nei calcoli per ottenere le coordinate.

L’utilizzo di Python all’interno di Blender si è rivelato ancora più esoso, rallentando così la fluidità dell’interazione. Nel codice riportato nella pagina a fianco vengono combinati il calcolo delle coordinate fatte solo per gli assi x-y degli oggetti ed il Modal Timer per vedere i cambiamenti in tempo reale.

Con questo sketch si è ottenuto un feedback visivo abbastanza fluido durante l’operazione di spostamento di un oggetto selezionato.

68

import bpy import serial import math porta = serial.Serial(‘COM4’, 9600) class ModalTimerOperator(bpy.types.Operator): ‘’’Operator which runs its self from a timer.’’’ bl_idname = “wm.modal_timer_operator” bl_label = “Modal Timer Operator” _timer = None def modal(self, context, event): if event.type == ‘ESC’: return self.cancel(context) porta.close() if event.type == ‘TIMER’: leggi = porta.readline().split() numUno = leggi[0] numDue = leggi[1] misUSRuno = int.from_bytes(numUno, byteorder = ‘big’) if misUSRuno < 14: misUSRuno = 13 misUSRdue = int.from_bytes(numDue, byteorder = ‘big’) if misUSRdue <14: misUSRdue = 13 base = 6 a= misUSRuno c= misUSRdue b = base angolo = math.acos(((c**2) + (b**2) - (a**2))/(2*c*a)) xCoord = c * math.sin(angolo) yCoord = math.sqrt((c**2) - (xCoord**2)) ang = math.degrees(angolo) print(ang) if ang > 90: yCoord =

0-yCoord

x = round(((xCoord-20)/100), 2) y = round(((yCoord/10), 2) print(x,y) bpy.ops.transform.translate(value=(x, y, 0)) return {‘PASS_THROUGH’} def execute(self, context): context.window_manager.modal_handler_add(self) self._timer = context.window_manager.event_timer_add(0.1, context.window) return {‘RUNNING_MODAL’} def cancel(self, context): context.window_manager.event_timer_remove(self._timer) return {‘CANCELLED’} def register(): bpy.utils.register_class(ModalTimerOperator) def unregister(): bpy.utils.unregister_class(ModalTimerOperator) if __name__ == “__main__”: register() # test call bpy.ops.wm.modal_timer_operator()

69

CONCLUSIONI

La presente ricerca si poneva come obiettivo il miglioramento dell’utilizzo di Blender. Questo programma open source è uno tra i più completi e versatili tool per l’authoring multimediale. È stato scelto perché, essendo a codice aperto, consentirebbe agli sviluppatori di modificare il codice sorgente senza i vincoli tipici degli altri software proprietari.

Sono stati analizzati altri due software insieme a Blender: Autodesk 3D Studio Max e Maxon Cinema 4d, in quanto tra i più diffusi negli studi professionali.

Dopo avere visto le differenze tra le interfacce e dopo avere capito quali sono le caratteristiche che rendono Blender un programma ostico all’uso, si è ritenuto opportuno creare un dispositivo di interazione gestuale. Sono stati valutati diversi dispositivi per il tracciamento dei gesti da parte dell’utente, valutando pro e contro dei controller già presenti nel mercato come il Wiimote della Nintendo, il Kinect di Microsoft e altri simili.

Dopo aver appurato che nessuno dei dispositivi valutati soddisfaceva pienamente gli obiettivi di questa ricerca, si è optato per la costruzione di un controller ex-novo, basandosi sulle gestualità che l’utente farebbe se interagisse con oggetti reali.

La facilitazione dell’uso di Blender passa attraverso l’interazione con gli oggetti virtuali come se fossero reali. Sono state altresì valutate le operazioni che Blender richiede all’utente e quando la Gesture Interface for Blender è veramente necessaria.

71

Mano a mano che sono stati valutati gli atti che l’utente deve fare durante la modellazione di oggetti tridimensionali virtuali (ed il loro corrispettivo nel mondo fisico, con oggetti reali) sono state trovate le soluzioni più adatte alla costruzione di GIfB: dalla tipologia dei sensori al loro numero, valutando i dati e le combinazioni che il dispositivo fornisce a Blender per migliorare il flusso di lavoro.

La ricerca, l’adozione e l’adattamento dei codici necessari a creare il prototipo di GIfB si sono rivelate le fasi più ostiche durante il periodo di sviluppo della tesi.

Come riportato nel capitolo di descrizione dei codici adottati, all’aumentare del flusso di dati fornito da Arduino, i programmi scritti in Python e inseriti in Blender diminuiscono in velocità di calcolo, fino a generare un pessimo feedback visivo durante l’uso del prototipo.

Il prototipo funziona in maniera fluida quando i dati da cambiare all’interno di Blender sono pochi, come ad esempio le sole coordinate di un solido primitivo. Nonostante le suddette limitazioni l’uso del prototipo dimostra che l’adozione delle gestualità considerate in fase di ricerca rendono più fluido l’uso di Blender.

Come già scritto, Blender è un programma a codice aperto ed esiste la possibilità di sviluppare ad hoc nel codice sorgente gli algoritmi giusti per rendere GIfB reattivo ed incrementare la velocità del flusso di lavoro durante l’uso di Blender. Purtroppo la programmazione a questi livelli va oltre l’ambito di studio nel quale è stata sviluppata questa tesi, essa è prerogativa di programmatori puri, di ingegneri informatici.

Si ritengono comunque raggiunti gli obiettivi prefissati: le gestualità adottate semplificano l’uso di Blender e l’esborso richiesto per la costruzione del prototipo è contenuto; si evince come una possibile produzione in serie di un dispositivo come GIfB comporterebbe bassi costi sia per i produttori che per i possibili acquirenti. GIfB diverrebbe così una valida alternativa ai Graphic Input Devices presenti già in commercio.

72

BIBLIOGRAFIA

Testi cartacei: AA. VV., MiMe 2008, Genova, 2008 (relazioni ed atti del simposio tenutosi a Genova nel 2008) G.C. Burdea, P. Coiffet, Virtual Reality Technology, John Wiley & Sons, 2003 P. Himanen, L'etica hacker e lo spirito dell'etĂ dell'informazione, Feltrinelli, Milano, 2001, trad. it F. Zucchella T. Igoe, Making things talk, Oâ&#x20AC;&#x2122;Reilly, California, 2007 K. A. Lambert, Programmazione in Python, Apogeo, Milano, 2012, trad. it. C. Giarratana B. Moggridge, Designing interactions, The MIT press, London, 2007 N. Negroponte, Essere digitali, Sperling & Kupfer, 2a ed., Milano, 1995, trad. it. F. e G. Filippazzi J. Raskin, Interfacce a misura d'uomo, Apogeo, Milano 2003, ed. or. Humane Interface,ACM Press, 2000, trad. it W. Vannini D. Saffer, Designing for Interaction: Creating Smart Applications and Clever Devices, New Riders, 2009

75

Manuali e tutorials reperiti in internet: W. Durfee, Arduino Microcontroller Guide, University of Minnesota, 2011 Reperibile su http://www.me.umn.edu/courses/me2011/arduino/ Fifth Dimension Technologies, 5DT Data Glove Ultra Series user's manual, 2004 Reperito su www.5DT.com J.H. GoĂĄs, Guida dâ&#x20AC;&#x2122;introduzione a Blender 2.5, 2008, trad it. A. Campagnol, F. Zoffoli, A. Labate, F. Martino, D. De Luca, Reperibile su www.blender.it C. Kenner, GlovePIE documentation, 2010 Reperibile su glovepie.org W. Reynish, The evolution of Blenders user interface, 2008 Reperibile su download.blender.org E. Rogers, Build Your Own Ultrasonic Rangefinder Reperibile su majolsurf.net G. van Rossum, Il tutorial di Python, Fred L. Drake, Jr., editor, 2004 Reperibile su docs.python.it/

Fonti web in ordine alfabetico: blenderscripting.blogspot.it docs.python.it docs.python.org en.wikibooks.org en.wikipedia.org it.wikipedia.org glovepie.org johnnylee.net processing.org pyserial.sourceforge.net searchco.de sourceforge.net stackoverflow.com www.arduino.cc www.blender.it www.blender.org www.blenderaddons.com www.fablabitalia.it www.python.it www.python.org www.tutorialspoint.com www.wiimoteproject.com www.zoo-logique.org

76

UNIVERSITÀ IUAV DI VENEZIA FACOLTA’ DI DESIGN E ARTI

DICHIARAZIONE DI CONSULTABILITA’ O NON CONSULTABILITA’ DELLA TESI DI LAUREA (da inserire come ultima pagina della tesi di laurea) Granaiola Alberto 262094 Il/La sottoscritto/a …………………… …………………….matr. n. ...…………….

Comunicazioni Visive e Multimediali

laureando/a in ………………………………………………...

Aprile 2013 2011 / 2012 sessione ………………………… dell’a.a. …………….………….

DICHIARA

che la tesi di laurea dal titolo: GIfB - Gestural Interface for Blender …………………………………………………………………………………………. ………………………………………………………………………………………….

è consultabile da subito 05 aprile 2013 X potrà essere consultata a partire dal giorno …………………..

non è consultabile (barrare la casella della opzione prescelta)

14 marzo 2013 data …………………..

Alberto Granaiola firma ………………………