Assegni di ricerca FSE - IUAV - Nuove Tecnologie e Informazione Territorio Ambiente
 Skip Navigation Links sei in: > HOME > Assegnisti > Roberto Case - Nuvole 3D > Fasi di avanzamento
 pagina visitata 689 volte dal 25/03/2014  

Fasi di avanzamento

Stato dell’arte

In questa fase si è presa visione di ciò che è stato sviluppato nella versione precedente: la soluzione si compone di due parte, un cliente in linguaggio Actionscript (Flash) ed un server in linguaggio C++.

Scendendo in maggiore dettaglio si sono potute apprezzare le strutture delle due componenti. Il client presenta dei moduli per lo scambio di informazioni e dati con il server e per il rendering dei punti attenuti dallo streaming. Il server a sua volta presenta un modulo per le comunicazioni ed uno per la gestione dei dati delle nuove di punti 3D tramite una struttura octree.

 

Ricerca tecnologie alternative

In seguito alla presa visione dello stato dell’arte ci si è chiesti se, a distanza di tempo dall’inizio dello sviluppo, fossero emerse nuove tecnologie per l’implementazione o fossero considerabili delle variazioni nelle scelta fatte a riguardo.

Per la parte di visualizzazione delle nuvole 3D nel client questo studio ha portato al confronto di alcune tecnologie che fossero in grado di eseguire il rendering con buone prestazioni: le alternative al Flash, tecnologia proprietaria e che già in passato è sembrata sull’orlo di una dismissione da parte di Adobe,  si sono trovate in webGL, ovvero in una versione di openGL dedicata al web, ed in alcuni motori di gioco, anch’essi indirizzati a questo ambiente per il loro sviluppo. In un primo momento si erano considerate anche delle possibilità basate su HTML5 o CSS3, che quindi avrebbero permesso una totale portabilità dell’applicazione, salvo poi capire che le prestazioni in questi casi non sono ancora di buon livello, anche se si sta procedendo nella direzione giusta. Delle rimanenti, quella dei motori di gioco non è stata la tecnologia scelta in quanto per ottenere buone prestazioni ci si sarebbe dovuti orientare su dei software a pagamento. Quella di webGL è senza dubbio una soluzione, che in ottica futura, può portare a buoni risultati: in ottica futura perché le prestazioni sono già buone (utilizzando la scheda grafica della macchina), ma il supporto da parte dei browser non è ancora ottimale e ben diffuso. Considerando comunque l’ambito di ricerca nel quale si va ad operare, quest’ultima è sembrata l’alternativa più adatta: sono infatti molti i progetti basati su questa tecnologia che si possono trovare in rete.

Altro punto da valutare è stato quello legato alla comunicazione: nella versione precedente questa era svolta tramite una connessione TCP e l’invio dei singoli byte tramite essa; questa soluzione era possibile perché nativa in Actionscript e tramite una libreria in C++. Con il passaggio a webGL, la cui gestione viene fatta in JavaScript, non è stato più possibile mantenere questa configurazione e si è quindi ricercata una soluzione che potesse sostituire in modo efficiente la precedente. La scelta è ricaduta sui WebSocket, uno standard (quindi ben documentato e diffuso) che fornisce canili di comunicazione full-duplex attraverso una connessione TCP. Come webGL, anche i WebSocket sono gestiti in JavaScript lato client, mentre il server necessita di una libreria per la “conoscienza” del loro protocollo di comunicazione.

 

Approfondimenti sulla versione esistente della soluzione e Consolidamento conoscenza nuove tecnologie

Con l’identificazione delle nuove tecnologie da utilizzare, si è andati a cercare di capire se le strutture di client e server fosse idonee alla nuova versione; ecco quindi che si sono andati a studiare in maggiore dettaglio i moduli delle singole parti.

Una prima cosa che in prospettiva andrà modificata riguarderà la possibilità di interazione con la nuvola di punti, ovvero il risalire ad una terna (x,y,z) tramite il click del mouse: per fare ciò ci si deve affidare una tecnica denominata picking, per la quale però vi è la necessità di avere sempre a disposizione i valori delle coordinate dei punti disegnati sullo schermo, cosa che al momento non è disponibile in quanto tali valori vengono passati alla scheda video per il rendering e non vengono mantenuti nella memoria della macchina.

Un’altra cosa da modificare è il meccanismo di comunicazione delle richieste e risposte tra client e server in quanto le implementazioni dei websocket sono fondate su delle funzioni callback (analoghe a degli eventi) e non quindi sull’attesa dell’arrivo del singolo messaggio. Bisogna quindi andare ad identificare il tipo di richiesta e reagire nella maniera appropriata senza essere a conoscenza dello stato della comunicazione.

 

Creazione prototipo

(in corso)

La ricerca e scelta di tecnologie diverse da quelle della versione iniziale, ha portato alla creazione di un nuovo prototipo, inizialmente con struttura e caratteristiche uguali o simili alla versione precedente: questo per avere un primo confronto di prestazioni ed un punto dal quale continuare lo sviluppo sfruttando le soluzioni già individuate ed implementate.

Una delle modifiche maggiori apportate alla nuova versione è la gestione della frequenza di rendering, differente nel caso in cui vi sia una comunicazione in atto oppure no, in quanto quest’ultima viene rallentata notevolmente nei casi in cui vi sia una frequenza di refresh maggiore.

Una parte invece nuova dell’attuale versione è quella di interrogazione della nuvola: è stata implementata, lato client, la possibilità di selezionare un insieme di punti nell’intorno del doppio click del mouse. A questa funzionalità andrà unita la possibilità di ottenere informazioni da un database collegato alla nuvola di punti.

Parallelamente a queste modifiche si è testata l’applicazione anche su dispositivi mobile: inizialmente si sono presentati dei problemi relativi all’utilizzo della memoria, per i quali è stata sviluppata anche una versione che non memorizzi i dati in locale ma li richieda tutti ad ogni modifica della vista, con conseguente rallentamento dell’applicazione; in seguito si sono implementati i comandi per la navigazione tramite comandi passanti per il touchscreen del dispositivo; un aspetto difficilmente migliorabile è legato alla velocità di esecuzione del dispositivo per azioni come il caricamento dalla memoria dei punti già ottenuti dal server.