La seconda demo offre una riproduzione navigabile immersiva del Camposanto Monumentale di Pisa. Il Camposanto è l'ultimo dei monumenti a sorgere sulla Piazza del Duomo e la sua lunga parete marmorea ne delimita il confine settentrionale definendola compiutamente. Viene fondato nel 1277 per accogliere i sarcofagi di epoca romana, fino a quel momento disseminati attorno alla Cattedrale e reimpiegati come sepolture dei pisani illustri. Nelle intenzioni dell'Arcivescovo Federico Visconti l'edificio doveva essere un luogo "ampio e decoroso, appartato e chiuso". Nasce così una delle più antiche architetture medievali cristiane destinate al culto dei morti.
101
Quando il demo viene fruita in modalità immersiva, il movimento all’interno dello spazio virtuale è consentito attraverso il widget MovePad, mentre l’interazione con gli elementi artistici e architettonici sfrutta il widget Canvas. Grazie al primo ci si sposta avanti e indietro con le due frecce centrali, mentre la rotazione di visuale è affidata a quelle laterali. È proprio il nostro punto di vista ad attivare le finestre informative di Canvas: è sufficiente infatti centrare la visuale su un elemento interattivo
perché appaia un riquadro con il suo nome; manteniamoci su di esso per alcuni secondi e un riquadro di testo apparirà di fronte a noi, consentendo di apprendere elementi d’interesse sull’oggetto del nostro osservare. Possiamo vedere in Fig. 36 come appare il tooltip informativo.
35
Camposanto Monumentale: demo in XVR102
Il widget MovePad è attivato utilizzando i sensori del Polhemus Liberty, e sfruttando la collision detection tra i sensori e le quattro aree corrispondenti alle rotazioni e/o traslazioni disponibili.
La modalità desktop fa uso d’altro canto dei più tradizionali mouse e tastiera: quando il puntatore si trova sopra un elemento interattivo, il tooltip informa l’utente che sono disponibili informazioni e un doppio click attiva il widget Canvas che le contiene. La navigazione prevede anch’essa l’uso del mouse e sfrutta funzionalità interne del software XVR.
Sia in modalità desktop che immersiva infine, è stato utilizzato il widget Slider per consentire di passare da un periodo storico all’altro ed esplorare il Camposanto così come appariva nelle diverse epoche storiche. I periodi storici disponibili sono, in particolare:
1500-1706
1707-inizi sec. XIX prima metà sec. XIX fine sec. XIX-inizi sec. XX 1935-1944
103
1961/63-1976 1977-1986 ante 1990
38
Widget Slider controllato mediante sensore Polhemus in modalità immersiva.104
Test e risultati
Premessa
Motivazioni di carattere temporale hanno impedito di svolgere, al tempo in cui scrivo, i necessari test valutativi per quanto concerne la demo Camposanto Monumentale. In conseguenza di ciò, rimando la trattazione inerente ad una futura revisione del presente documento.
Struttura dell’user study
L’user study che concerne la demo Cappella Maggiore con Affreschi de Le Storie della Vera Croce è stato svolto prendendo in esame sei individui ambosessi equamente distribuiti, con diverse età anagrafiche ed esperienze in campo di Ambienti Virtuali eterogenee.
N SESSO ETÀ ESP.AV(anni)
1 F 44 >15 2 F 22 0 3 F 26 2 4 M 30 5 5 M 45 >15 6 M 35 0
A tutti i soggetti è stato chiesto di indossare l’HMD Oculus Rift e di usare due sensori offerti dal Polhemus Liberty, al fine di fruire della demo in modalità immersiva, utilizzando in particolare i Widget SensorSelect, SensorMove e Canvas.
105
I task che gli utenti hanno dovuto svolgere sono essenzialmente due, ovvero: esplorare la ricostruzione dell’ambiente virtuale,
visualizzare le informative collegate agli affreschi.
Prima dell’inizio di ciascuna prova gli utenti hanno ricevuto informazioni sulla modalità di interazione prevista dai widget summenzionati, ovvero
Navigazione mediante SensorMove, spostando il sensore per muoversi in avanti, a destra e sinistra, in alto e in basso. È possibile combinare diversi movimenti spostando il sensore in una qualsiasi direzione che combini quelle fondamentali testé elencate;
Selezione tramite SensorSelect, puntando l’asta virtuale nella direzione dell’affresco desiderato;
Visualizzazione di informazioni sull’affresco selezionato (v. punto precedente) tramite Canvas.
Ciascuna prova ha avuto durata diversa, in quanto si è atteso che l’utente familiarizzasse con le modalità di interazione per quanto gli fosse possibile; la durata media di ogni test è stata comunque non superiore a minuti 10. Al termine delle prove si è svolta una breve fase di intervista, nella quale è stato chiesto agli utenti di indicare la qualità dell’interazione riguardante i task a loro assegnati, nonché di suggerire come avrebbero migliorato o comunque diversificato l’esperienza per aumentarne l’usabilità.
Riportiamo di seguito i punti salienti delle interviste (i numeri fanno riferimento alla tabella riportata nella pagina precedente), corredati da una valutazione su scala 1-10 data dai partecipanti riguardo ai fattori chiave movimento, selezione e visualizzazione.
106
Risultati
Tester 1
Evidenzia la necessità di limitare il movimento all’interno dell’area di spazio in cui è presente la ricostruzione, evitando l’effetto “attraversamento dei muri”. In seguito alla richiesta di un sistema alternativo per migliorare l’usabilità della meccanica di movimento, suggerisce di rendere la velocità progressiva in relazione all’entità dello spostamento del sensore Polhemus. Inoltre considera controproducente il fatto che il sensore, normalmente raffigurato come sfera nell’ambiente virtuale, sparisca durante la navigazione.
Non riscontra difficoltà nell’uso del widget SensorSelect per selezionare i diversi affreschi, ma suggerisce spontaneamente di implementare un modo per attivare il widget Canvas su richiesta, anziché automaticamente quando un affresco viene puntato.
Movimento 6/10 Selezione 10/10 Visualizzazione 8/10
Tester 2
Riporta la tipica sensazione di mal di mare, che viene riscontrata da alcuni utenti durante l’uso di HMD, dopo pochi momenti di testing. Tuttavia prende confidenza velocemente con la meccanica di movimento, che definisce buona. Positive anche le valutazioni sui widget Canvas e SensorSelect: per il secondo in particolare riporta una difficoltà iniziale nel rapportare la posizione dell’asta di selezione nell’ambiente virtuale con quella della propria mano, difficoltà superata dopo le fasi iniziali di utilizzo.
Movimento 8/10 Selezione 7/10 Visualizzazione 8/10
Tester 3
Naviga senza difficoltà utilizzando sin da subito il widget SensorMove con buoni risultati, tuttavia trova impedimento nel ruotare la visuale a causa della posizione di SensorSelect, per la quale riferisce lo stesso problema di colocazione della
107
Tester 2 osservando come a volte l’asta di selezione si trovi involontariamente davanti agli occhi.
Ritiene la selezione migliorabile, in particolare suggerisce l’uso di un timer per far apparire il widget Canvas e di gestirne meglio la dimensione. La Tester tiene spesso il sensore assegnato al SensorSelect con il braccio quasi completamente esteso, e poiché la posizione di Canvas è solidale alla mano esso viene a trovarsi lontano al punto da degradarne la leggibilità. Riporta difficoltà nell’avvicinare il sensore al viso per ingrandire Canvas e al tempo stesso mantenere la selezione sull’affresco desiderato.
Movimento 9/10 Selezione 6/10 Visualizzazione 6/10
Tester 4
Naviga senza riportare difficoltà, ma evidenzia come nella sua esperienza d’uso il movimento offerto da SensorMove sia influenzato dallo spostarsi della persona nell’ambiente reale. Suggerisce, per facilitare la comprensione dell’area in cui SensorMove opera, una rappresentazione virtuale di quest’ultima sotto forma di sfera traslucida.
Riscontra nel puntamento una problematica simile a quella della navigazione, ovvero riscontra difficoltà a selezionare un affresco dopo aver ruotato la testa e conseguentemente il proprio sistema di assi rispetto a quelo del rilevatore dei sensori Polhemus. Dopo una prima difficoltà causata da quanto riscontrato, definisce buono il sistema di puntamento e di visualizzazione tramite widget Canvas. Suggerisce infine la possibilità di nascondere l’asta di SensorSelect tramite un qualche tipo di trigger.
Movimento 8/10 Selezione 7.5/10 Visualizzazione 8/10
Tester 5
Naviga senza riportare difficoltà all’interno della demo, e definisce buona anche l’esperienza d’uso di Canvas. Riguardo a SensorSelect riporta anch’egli il problema di colocazione della bacchetta, che definisce piuttosto grave. Avendo esperienza nell’uso in Ambienti Virtuali immersivi, suggerisce di risolvere tale problema grazie al motion tracking della testa dell’utente, in modo da avere un sistema di riferimento sempre aggiornato per il posizionamento dei widget.
108
Movimento 7/10 Selezione 6.5/10 Visualizzazione 7/10
Tester 6
Evidenzia come il movimento verso l’alto abbia sempre una componente di avanzamento, suggerisce come motivazione la difficoltà effettiva del Tester di muovere il sensore Polhemus lungo un asse perfettamente verticale. Per il resto si definisce positivamente impressionato dalla qualità e usabilità della navigazione, una volta compresa la necessità di compensare la problematica appena descritta.
Non riscontra difficoltà nell’uso di SensorSelect, ma come diversi altri Tester suggerisce di implementare un trigger di qualche tipo per le Canvas, dato che il loro continuo apparire di fronte agli affreschi può degradare l’esperienza di visione degli stessi.
109
6 CONCLUSIONI
RIEPILOGO
A chiusura di questo documento presentiamo alcune riflessioni di carattere riassuntivo sul lavoro svolto per la realizzazione di ImmerseTools. Lo strumento che ho realizzato ha raggiunto un buon livello di maturità sul piano funzionale e nella varietà dei widget offerti, come ho potuto confermare dai test svolti presso il laboratorio PerCro che ne hanno dimostrato l’efficacia in casi d’uso reali. Per quanto riguarda l’influenza dell’aspetto visivo sull’usabilità ho riscontrato come, coerentemente con le mie aspettative, siano presenti diversi margini di miglioramento. La scelta di un aspetto decisamente minimale e di basso impatto visivo ha certamente influenzato questo risultato, conseguenza anche di un focus in fase di sviluppo puntato fortemente sulla funzione prima che sulla forma. Inoltre l’assenza di un sistema di tracking per la testa dell’utente ha causato problematiche nell’uso del widget SensorSelect per diversi utenti, mentre l’impossibilità per l’utente di triggerare azioni, inerente alla natura dei sensori del Polhemus, è stata sottolineata anch’essa. Tuttavia quest’ultimo aspetto non ha influito in modo negativo sulla valutazione degli utenti, che hanno invece suggerito in modo costruttivo come ovviare al problema in futuro.
L’integrazione dei vari widget con i casi d’uso è risultata soddisfacente, salvo difficoltà riscontrate principalmente a causa della peculiarità della demo Camposanto Monumentale per quanto riguarda la gestione di camera, che non è stato possibile testare durante l’user study a causa delle summenzionate ristrettezze di tempistica. Questa demo infatti, così come la Cappella Maggiore, è nata per un utilizzo desktop e sono stati necessari adattamenti del codice preesistente per aggiungere il supporto alla modalità immersiva offerta da Oculus Rift.
Buona infine l’integrazione reciproca di widget multipli quando utilizzati all’interno della stessa demo, grazie alla possibilità di gestire il loro posizionamento nello spazio con i metodi offerti nativamente da XVR e sfruttati al meglio da ImmerseTools: l’uso di file di configurazione rende molto semplice
110
stabilire i parametri di posizionamento desiderati e una breve fase di testing preliminare consente di trovare velocemente una configurazione complessiva soddisfacente.
Concludo questo capitolo con una disamina dettagliata delle migliorie apportabili e degli sviluppi futuri previsti per ImmerseTools.
IL FUTURO
Si tratta di una constatazione ovvia, eppure serve farla: nessun software sarà mai perfetto, e ImmerseTools in particolare non ha certo la pretesa di essere tale. Pertanto occorre guardare avanti, riflettendo su quali sono i punti di forza del lavoro fin qui svolto e, soprattutto, dove ci sia margine di miglioramento.
L’estetica
ImmerseTools punta fortemente alla personalizzazione, offrendo diversi modi per rendere la propria interfaccia adattabile ai contesti più disparati; abbiamo visto, ad esempio, come il widget SlideMenu consenta di scegliere l’aspetto delle proprie voci – sia singolarmente che in blocco – tramite file di configurazione XML e testuali. Tuttavia l’aspetto predefinito di questo widget è alquanto minimale, o come si direbbe nella lingua di Sua Maestà, barebones: un miglioramento che certamente è possibile consisterà proprio nel dare un aspetto migliore a SlideMenu e agli altri widget, poiché l’usabilità di un elemento d’interfaccia è certamente influenzata anche dal fattore estetico.
Sarebbe ad esempio interessante e utile introdurre l’idea di una serie di temi, sia 2D che 3D, per uniformare i vari widget e conferire all’interfaccia un maggior senso di coesione.
111
Il codice
Buona pratica nella scrittura di codice, quale che sia la sua destinazione, è quella di commentare le scelte implementative salienti, lo scopo delle variabili fondamentali, ecc. Questo allo scopo di facilitare interventi successivi, da parte dell’autore originale e soprattutto di terze parti qualora il progetto incorpori nuovi collaboratori o sia ceduto in toto. Le fasi di sviluppo di ImmerseTools hanno visto cambiamenti, ripensamenti, inversioni di rotta più o meno radicali e pur in questo processo travagliato si è cercato di non rinunciare mai all’inserimento di commenti esplicativi ove necessario: ciononostante, la formattazione di questi ultimi non è uniformata e non è al momento possibile generare una documentazione tramite appositi strumenti automatizzati. Al fine di facilitare gli sviluppi futuri, un primo passo in avanti sarà certamente quello di provvedere ad una rielaborazione del corpus dei commenti, comprensiva di integrazione ove questi fossero scarni o del tutto assenti.
I widget
Al momento ImmerseTools è costituita da cinque widget: SlideMenu, PieMenu, CircularMenu
Canvas SensorSelect MovePad Slider
Ciascuno dei quali si adatta in diversi gradi all’uso desktop e immersivo. Oltre alle migliorie grafiche già citate, sono convinto che sia necessario in futuro una nuova analisi ancor più approfondita dei possibili casi d’uso: in questo modo certamente si individueranno nuovi widget e sarà possibile ottimizzare ancor di più quelli già esistenti. Alcune di queste migliorie sono già definibili, ad esempio:
112
PieMenu: al momento le voci di menu sono costituite da elementi 3D creati ad hoc, tuttavia degli oggetti procedurali
costituirebbero un approccio più leggero in termini computazionali. Il widget acquisterebbe inoltre maggiore dinamicità, in quanto ogni voce potrebbe variare il proprio arco di circonferenza. Il menu potrà così ospitare un numero variabile di voci, adattando l’ampiezza di ciascuna.
Canvas: attualmente supporta solamente la visualizzazione di immagini, in quanto le capacità di formattazione del testo in 3D offerte da XVR sono limitate. Per questo motivo il testo che si vuole eventualmente visualizzare viene rasterizzato assieme agli altri contenuti, mentre un approccio auspicabile prevede una migliore gestione di spaziature e paragrafi da affiancare all’offerta di XVR.
A potenziamento della suite di widget offerta da ImmerseTools sarebbe certamente opportuno aggiungere un elemento di interfaccia per i cosiddetti checkbox e radio button, facilitando così la gestione delle scelte multiple nonché di quelle mutuamente esclusive. Al momento tale funzionalità è presente in modo molto limitato nel widget PieMenu, che offre una voce arricchita con due radio button, per scelte binarie mutuamente esclusive: un miglioramento è quindi certamente auspicabile e previsto come sviluppo futuro.
Supporto hardware
Obiettivo di ImmerseTools è, l’abbiamo detto ormai diverse volte, fornire un’interfaccia usabile nella realtà virtuale immersiva. Ciò comporta necessariamente che si debbano supportare un insieme di periferiche hardware per input\output quali il già citato Oculus Rift, ma anche i suoi competitor principali – che esistono e di cui ancora non abbiamo avuto modo di parlare.
40 La freccia rappresenta l'arco di circonferenza che la voce occupa nel menu
113
Abbiamo accennato ad alcune di esse nel capitolo dedicato allo stato dell’arte, ed è opportuno riprendere il discorso in questa sede: la RV sta vivendo un periodo di grande espansione e sempre più attira investimenti anche da parte di grandi realtà come Microsoft, Razer, HTC, ecc. Se si vuole offrire un software veramente valido, occorre stare al passo con i tempi e far sì che le nuove periferiche si possano usare con ImmerseTools. È un compito laborioso e che dipende in buona parte dalla collaborazione dei produttori stessi, che in alcuni casi rilasciano piattaforme “chiuse” – è il caso di Nintendo con il suo WiiMote – costringendo noi sviluppatori al cosiddetto reverse engineering12. In questi casi si deve
lavorare a basso livello intercettando le comunicazioni tra la periferica e il computer, cercando di comprendere il suo protocollo di comunicazione, ecc. ma per fortuna non si tratta di un caso comune, in quanto sempre più periferiche prodotte sono mirate proprio allo sviluppo di software di terze parti come ImmerseTools.
È il caso dell’OSVR Hacker Kit, rilasciato recentemente da Razer. In conclusione, lavorare ad un più esteso supporto hardware è certamente un obiettivo futuro, anche al fine di individuare le periferiche che offrono le migliori performance in questo settore che si evolve di continuo.
12https://it.wikipedia.org/wiki/Ingegneria_inversa
114
Grazie al lavoro fin qui svolto e alle competenze acquisite nel processo, sono certo che ImmerseTools si evolverà in uno strumento dalla migliorata stabilità e dall’ampio supporto hardware\software, che possa essere utilizzato in numerosi progetti futuri con grande soddisfazione.
115
Bibliografia
1. Cabral, Marcio, et al. An experience using X3D for Virtual Cultural Heritage. Proceedings of the twelfth international conference on 3D web technology. 15 Aprile 2007, p. 161-164.
2. Serious Games in Cultural Heritage. Eike Falk, Anderson. 2009. International Symposium on Virtual Reality, Archaeology and Cultural Heritage VAST - State of the Art Reports.
3. Jacobson, Jeffrey, Gillam, Robyn e Hopkins, David. Virtual Egyptian Temple - PublicVr. [Online] PublicVR, Carnegie Mellon University (SFCI), Carnegie Museum of Natural History, The Art
Institutes, 2012. [Riportato: 15 10 2015.] http://publicvr.org/html/pro_egypt.html.
4. International Society for Presence Research. The Concept of Presence: Explication Statement. 2000.
5. Cruz-Neira, Carolina, et al. The CAVE: Audio Visual Experience Automatic Virtual Environment. Communications of the ACM, vol. 35(6). Giugno 1992, p. 64–72.
6. Poster: Evolution and Usability of Ubiquitous Immersive 3D Interfaces. Basu, Aryabrata, Johnsen, Kyle e Bogert, Kenneth. Orlando : s.n., 2013. 3D User Interfaces (3DUI), 2013 IEEE Symposium on. p. 131-132.
7. Lombard, M. e Ditton, T. At the heart of it all: the concept of presence. Journal of Computer- Mediated Communication. 1997, Vol. 3, 2.
8. Ozawa, K., et al. Psychological factors involved in auditory presence. Acoustical Science and Technology. 2003, Vol. 24, 1.
9. Designing auditory spaces to support sense of place: the role of expectation. Chueng, P. e Marsden, P. s.l. : Citeseer, 2002.
10. Sound design to enhance presence in photorealistic virtual reality. Serafin, S. e Serafin, G. s.l. : Citeseer, 2004.
11. HAMA device - Haptic display for Immersive vi rtua Environments. S.Kikuchi e Yamamoto, A. Lao : IEEE, 2008. Communications and Information Technologies, 2008. ISCIT 2008. International Symposium on. p. 453 - 458.
12. Hewett, et al. ACM SIGCHI Curricula for Human-Computer Interaction. s.l. : ACM, 1992. 13. Utility and usability: research issues and development contexts. Grudin, Jonathan. 2, 1992, Interacting with Computers, Vol. 4, p. 209–217.
14. Larsen, Larry. Channel 9. [Online] Microsoft, 6 January 2010. [Riportato: 6 June 2015.] https://channel9.msdn.com/blogs/larrylarsen/ces-2010-nui-with-bill-buxton.
15. Dam, Andries van. Post-WIMP User Interfaces. Communications of the ACM. February 1997, p. 63-67.
116
16. van Dokkuma, L.E.H., Ward, T. e Laffont, I. Brain computer interfaces for neurorehabilitation. Annals of Physical and Rehabilitation Medicine. February 2015, p. 3-8.
17. 3DM: A Three Dimensional Modeler Using a Head-Mounted Display. Butterworth, Jeff, et al. s.l. : ACM, 1992. 1992 symposium on Interactive 3D graphics. p. 135-138.
18. Towards usable VR: an empirical study of user interfaces for immersive virtual environments. Lindeman, Robert W., Sibert, John L. e Hahn, James K. s.l. : ACM, 1999.
19. An interaction tool for immersive environments using mobile devices. Medeiros, Daniel. s.l. : SVR, 2013.
20. Making VR work: building a real-world immersive modeling application in the virtual world. Mine, Mark, Yoganandan, Arun e Coffey, Dane. s.l. : ACM, 2014.
21. Fuchs, P. e Moreau, G. Le Traité de la réalité virtuelle. s.l. : Les Presses de l’Ecole des Mines de Paris, 2006.
22. Bowman, Doug A., et al. 3d User Interfaces: Theory and Practice. s.l. : Pearson Education, 2004.
23. Chu, Peter. VR Design: Transitioning from a 2D to 3D Design Paradigm. San Francisco : Samsung Developer Connection, 2014.
24. Mizell, David W., et al. Comparing immersive virtual reality with other display modes for visualizing complex 3D geometry. London : University College London, 2002.
25. Morville, Peter e Rosenfeld, Louis. Information Architecture for the World Wide Web. s.l. : O'Reilly Media, 1998.
26. Piero della Francesca On-line: Story of the True Cross, San Francesco, Arezzo (Italy). Lavin, M. A., et al. Toronto : Ediciones Cátedra, 2009.
27. Interactive Information System for the Camposanto Monumentale of Pisa. Baracchini, C., Brogi, A. e Merlitti, D. 1999.
28. S.r.l., VRMedia. XVR Home Italiano. [Online] VRMedia S.r.l. [Riportato: 01 09 2015.] http://www.vrmedia.it/it/xvr/specifications.html.