Il meraviglioso TiltBrush by Google

Come costruire un Metaverse (od almeno provarci ;-)

Quando ho dato avvio, nella mia mente, al Progetto MayaVerse ho iniziato immediatamente a pensare come poterlo realizzare. L’idea base era quella di sviluppare, come dimostratore iniziale, qualcosa di simile al compianto Social VR Convrge. In sintesi: uno spazio virtuale tridimensionale interattivo multiutente. Qualcosa di apparentemente semplice, ma che in realtà richiede diverse scelte tecniche non banali e soprattutto conoscenze informatiche non di facile reperimento. Non esiste, infatti, un Metaverse How-To che guidi uno sviluppatore alla costruzione di una piattaforma di questo tipo, ma sono disponibili invece numerosi strumenti, oggetti programmabili e librerie che opportunamente armonizzate possono creare un’unica piattaforma.

Il compianto SocialVR Convrge: antesignano (e di molto) di Facebook Spaces

Si tratta quindi di saper scegliere e soprattutto fare in modo che tutti questi componenti “parlino tra di loro” ed interagiscano in maniera corretta. Quali scelte fare e soprattutto cosa mettere nella propria cassetta degli attrezzi?

Come primo ingrediente è necessario avere un motore grafico tridimensionale che ci permetta di rappresentare gli oggetti ed agenti. Esistono moltissimi motori grafici, ma la scelta è caduta ben presto su Unity. Unity 3D è uno dei motori piu’ utilizzato e soprattutto supportato da una comunità molto vasta. La quantità di codice per modificare, aggiungere funzionalità o moduli è enorme e moltissimo materiale è sotto licenza Open Source. Unity ha inoltre l’indubbio vantaggio di avere diversi tutorial e guide per iniziare, oltre una curva di apprendimento molto poco ripida all’inizio: in summa un candidato ideale. Certamente non tutti pensano che Unity sia, su progetti molto grandi, un valida possibilità, ma è pur vero che la disponibilità di aiuti e di codice per gli altri motori non è altrettanto ricca.

Connaturale con la scelta di Unity è stata la preferenza della libreria VRTK (Virtual Reality Toolkit). Possiamo dire che VRTK è attualmente il punto di riferimento per i quanto riguarda gli “Interactive System”, ovvero l’insieme di codice che permette uno sviluppo efficace ed efficiente di tutti le funzionalità tipiche in VR come l’afferrare oggetti (grabbing), il movimento (Teleporting ed altri tipi di locomotion), l’interazione con interfacce grafiche in VR, etc... L’unica vera accortezza, a livello tecnico, è di utilizzare l’ultima versione presente su Github poiché il codice si sta evolvendo molto rapidamente. E’ necessario poi seguire molto bene la community su Slack che offre un’ottima assistenza: https://vrtoolkit.slack.com/messages

L’elemento forse più delicato di un SocialVR è sicuramente la scelta del sistema di networking. Quasi tutte le altre piattaforme (AltVR, Anyland, Rec Room, etc…) si affidano all’ottimo servizio Photon Network (https://www.photonengine.com/en-US/PUN). E’ tale la popolarità di Photon che ben due demo hanno cercato di armonizzarla con la libreria VRTK ottenendo degli ottimi risultati:

Per non parlare di un esempio molto ben fatto rilasciato direttamente sull’ Asset Store di Unity dagli sviluppatori di Photon:

Tale abbondanza non può certo passare inosservata anche se due problematiche mi dicono di non cadere in questa “tentazione”. La prima motivazione è commerciale: Photon Network è gratuita fino a 20 utenti, ma soprattuto basato su servizi in cloud di cui abbiamo pochissimo controllo. Ci affidiamo insomma ad un’azienda esterna per una parte che idealmente dovrebbe essere sotto il nostro completo controllo. Oltre tutto il modello che ho in mente si ispira molto a quello che è il progetto OpenSim e che HighFidelity già fanno. Diamo l’opportunità a tutti di poter mettere su il proprio Server ed avere così il proprio piccolo Metaverse. La parte server dovrebbe essere una sorta di Server Apache facilmente configurabile creando così molteplici istanze da poter poi visitare navigando da una all’altra. Da ultimo anche una componente tecnica mi ha spinto a questa scelta: il protocollo utilizzato nella versione 1.4.4 è estremamente semplice e snello, favorisce così un’ottima integrazione ed anche performance notevoli così importanti in VR. Jamster, lo sviluppatore di DarkRift, ha inoltre annunciato un importante aggiornamento: la nuova versione 2 è stata migliorata, completamente re-ingegnerizzata e aggiunta del protocollo RUDP. Quest’ultimo è veramente essenziale perchè molto più veloce del TCP, ma con tutte le caratteristiche necessarie per essere affidabile come quest’ultimo. L’importanza del protocollo UDP/RUDP nei sistemi di rete dei “Giochi” è stato ampiamente disquisito su questo sito:

La nostra scelta comprende quindi:

Ho già provveduto a creare un piccolo abbozzo che spero diventi la base di qualcosa di molto più grande e soprattutto ho scritto una piccola guida su come il Server DarkRift debba essere configurato su un server VPS Linux (in questo caso un Server Ubuntu 14.04 su DigitalOcean):

L’interazione tra utenti è molto importante e Facebook Spaces ne è la dimostrazione vivente. E’ fondamentale che tutti gli avatars possano parlare tra di loro attivando il microfono senza dover premere pulsanti (a meno di non voler scegliere appositamente l’opzione PTT — Push To Talk, premi per parlare). L’audio dovrebbe essere inoltre “spazializzato”, ovvero appositamente modificato per essere collocato da un utente nello spazio tridimensionale, ma anche essere opportunamente modificato dall’ambiente stesso. Se la fonte sonora è dietro uno schermo il relativo suono sarà attenuato, se l’ambiente è molto grande ci saranno particolari fenomeni di riverbero del suono. Tutto questo aumenta l’immersività e la sensazione di presenza e può essere ottenuta integrando questa meravigliosa libreria audio:

Per quanto riguarda invece la possibilità di far comunicare gli utenti, quasi tutte le piattaforme scelgono il servizio sempre offerto da Photon Network chiamato Photon Voice. Anche in questa circostanza è preferibile una soluzione svincolata da servizi cloud di terze parti. In particolare TeamSpeak offre un buon compromesso con un sistema facilmente integrabile in Unity:

Cosa ci riserva il futuro di MayaVerse 2.0?

Le idee e le tecnologie per sviluppare ulteriormente questa possibile Demo non mancano e soprattutto si basano su solide scelte tecnologiche già esistenti da verificare, integrare ed armonizzare con il resto del software:

  1. Utilizzare la rete IPFS: l’idea di avvalersi di una piattaforma così avanzata e distribuita garantisce che tutti i modelli, livelli, etc sia sempre reperibile e soprattutto veloci da scaricare. L’idea non è nuova e già Tim Sweeney, nel suo intervento al SteamVR Dev Days 2016, ha parlato ampiamente del sistema decentralizzato IPFS. JanusVR già fa ampio uso di IPFS caricando direttamente le varie ambientazione. Sfortunatamente il tutto passa attraverso il gateway predefinito che converte le chiamate IPFS in HTTP. Questo, a mio parere, vanifica un po’ la vera potenza di IPFS che essendo un sistema decentralizzato e ridondate non viene sfruttato a dovere. Con l’avvento di Unity 2017.1 sarà possibile utilizzare un runtime più recente di .NET e si potranno integrare direttamente il porting del client IPFS in Unity. Servendosi dell’AssetBundle di Unity e di IPFS si potrà fare il rez (creare) praticamente ogni assets dinamicamente.

2. Un framework di Networking dovrà essere DarkRift2, ma nessuno ci impedisce di utilizzare la base di questo sistema (Hazel) che è stata rilasciata sotto licenza Open Source. Alcuni esperimenti da me effettuati hanno portato ad ottimi risultati. L’overhead è minimo, stiamo parlando di 4 byte ed utilizzando sistemi di serializzazione ottimizzata dei dati come Flatbuffer (http://exiin.com/blog/flatbuffers-for-unity-sample-code/) è possibile trasmettere qualunque tipo di informazione risparmiando spazio. Certamente manca tutta la parte di crittografia dei dati, ma agendo direttamente sui dati con libreria come libsodium è possibile sopperire a questa mancanza.

3. Aggiungere un linguaggio interno per offrire all’utente finale la possibilità in-game di aggiungere e modificare il comportamento dell’ambiente 3D e non solo. Unity 3D è già un ambiente ampiamente configurabile, non manca ovviamente l’opportunità di dare agli utenti un linguaggio interno simile al LSL di SecondLife o l’attuale Javascript di HighFidelity. Si potrebbe persino ipotizzare un client con interfaccia classica (UI 2D) dedicato solo e soltanto alla configurazione e programmazione dell’ambiente virtuale. Oppure un apposito SDK come è stato già fatto per VRChat. Le opzioni sono molte, una mi ha particolarmente colpito:

http://www.moonsharp.org/

4. Voice System migliorato: TeamSpeak è soltanto l’inizio, DiscordApp mette a disposizione un sistema molto più avanzato che però è attualmente in Beta: https://discordapp.com/gamebridge

5. Ottimizzazioni: con l’uscita del nuovo Unity 2017, Nvida ha messo a disposizione un suo sistema di ottimizzazione per sfruttare meglio la propria GPU guadagnando moltissimo in velocità. Esistono poi numerose altre configurazioni da controllare:

6. Integrazione Bitcoin/Ethereum: ogni Mondo Virtuale Immersivo possiede la propria economia. Ognuno ha la propria “valuta” perchè allora non utilizzare una crypto-valuta come Bitcoin o Ethereum:

E perchè non fare un passaggio di denaro tramite Bitcoin/Ethereum con una semplice stretta di mano virtuale?

7. Avatars ed identificazione tramite OTP: Ho pensato di utilizzare il sistema di autenticazione SRP per l’autenticazione degli utenti. Tuttavia questo è un dettaglio che ha (ahinoi) molta meno importanza della rappresentazione grafica degli avatar. Sicuramente integrare la soluzione di Morph3D è necessario per fare in modo che gli utenti si identifichino maggiormente nel proprio Avatar.

8. Interazione con BOT e sistemi avanzati di AI: Machine Learning e VR sono da sempre due mondi che dovrebbero parlarsi maggiormente. Integrare IBM Watson in un Mondo Virtuale Immersivo potrebbe fare meraviglie:

https://www.ibm.com/innovation/milab/watson-speech-virtual-reality-unity/