mercoledì 2 settembre 2015

Soltanto una serie di tubi...


https://flic.kr/p/9tYsSH
Ipotizziamo di avere un bel motore grafico 3D in grado di visualizzare oggetti, avatar e quant'altro. Per poter "condividere" la simulazione con altri client avete la necessità di comunicare alcuni dati sugli oggetti presenti a video. E da questo nascono infiniti problemi che devono essere risolti: quale protocollo usare nella comunicazione? Ma soprattutto quali dati trasmettere? Cercando idee e suggerimenti in rete ho visto che pochi esperti trattano queste tematiche a livello tecnico e divulgativo. Per fortuna di chi vuole approfondire queste tematiche, uno sviluppatore, Glenn Fiedler, ha creato alcuni articoli introduttivi sulla programmazione via internet di giochi. Scopriamo quindi subito che è necessario abbandonare come protocollo TCP ed adottare UDP. Questo scelta è dettata dal fatto che il protocollo TCP è stato creato  per una comunicazione sicura nell'invio e ricezione del dato, situazione questa che non può essere adottata nei moderni MMO che hanno tempi di reazione dell'ordine dei millisecondi. Non è possibile in nessun modo attendere la verifica dell'avvenuta consegna del pacchetto e l'eventuale reinvio, questo creerebbe dei ritardi su una comunicazione che è già piena di ritardi. Il "lag" o ritardo è infatti intrinseco al funzionamento di internet che non può essere considerato come una "serie di tubi", ma come una rete di reti dove milioni di router, switch e computer dialogando ricevendo e ritrasmettendo pacchetti. Non dobbiamo poi dimenticare il limite fisico di propagazione della luce che comunque su lunghi tragitti inizia ad essere sensibile (se si parla di millisecondi). Ecco allora la strategia vincente:  trasferire piccole quantità di dati (quanto più possibile compresse ed in formato binario), su protocollo UDP (che è anche più snello del TCP), riscrivendo un semplice sistema per il sequenziamento dei diversi pacchetti e la conferma della ricezione. Nei tutorial e negli esempi tutto questo viene spiegato nel dettaglio, ma soprattutto vengono mostrate alcune strategie di "lag compensatio" ovvero compensazione del ritardo e di "prediction" ovvero di predizione ad esempio della posizione degli oggetti. Queste ultimi concetti sono molto utili soprattutto negli FPS in cui è essenziale una corretta gestione degli obiettivi colpiti e della posizione degli avversari. Non sono riuscito a capire se questi algoritmi siano utili nei Metaverse alla SecondLife e se ad esempio siano stati utilizzati proprio in SL per minimizzare l'onnipresente lag delle sim.

Sito principale: http://gafferongames.com/networking-for-game-programmers/
Codice di esempio: https://code.google.com/archive/p/netgame/

Studiare tutto questo non è certo uno scherzo, ma per fortuna esistono delle librerie che hanno già implementato queste logiche (o parte di esse). Soprattutto ENET sembra essere la soluzione ideale per l'ottima documentazione e per i numerosi esempi in rete. Riporto qui di seguito una breve lista di librerie:


Un bello studio che dimostra i problemi nell'utilizzo del TCP nei giochi:
Con questo secondo post credo ci sia tutto il materiale necessario per la creazione di una semplice demo. Uno spazio tridimensionale in cui inserire oggetti e magari spostarli, ruotarli e scalarli. Possiamo dire che ci potremmo trovare dinanzi ad un microscopico abbozzo di "Metaverse". Parlo di abbozzo perchè mancano ancora tantissime possibilità che che non sono state nemmeno indagate. Manca infatti l'utilizzo di un motore fisico, i sistemi per la gestione delle collisioni, l'uso di mesh animate e tantissimo altro. Questo a dimostrare l'estrema complessità di questi software che richiedono anni ed anni di pratica oltre a conoscenze che spaziano dalla matematica alla programmazione avanzata cross-platform.  Per non parlare poi della VR che aggiunge ulteriore complessità al sistema. Se infatti, secondo i consigli di Oculus, i motori grafici per avere un'ottima visualizzazione in VR devono girare a ben 75 FPS, allora tutte le latenze di rete devono essere attentamente valutate ed aggirate per creare l'illusione perfetta di un' ambiente virtuale tridimensionale condiviso.

martedì 1 settembre 2015

OK, abbiamo la data ed adesso?

Logo ufficiale Project Sansar da VRFocus.com
La notizia è rimbalzata sulla rete ovunque: l'Oculus Rift nella sua versione Consumer Version 1.0 sarà commercializzata a partire dal primo trimestre del 2016. Abbiamo finalmente la tanto attesa "data" che ha fatto così discutere sviluppatori, utenti ed appassionati. Eppure un misto di agitazione ed ansia pervade la mia mente: la VR è finalmente diventata una tecnologia consolidata e sopratutto utilizzata? Può un visore con l'attuale e più avanzata tecnologia essere lo scopo ultimo del mondo del gaming? Incomincio a pensare che l'arrivo dell'Oculus VR sia sicuramente una tappa molto importante nel cammino della Realtà Virtuale, siamo però ben lontani dall'avere una piattaforma che possa esprime tutte le potenzialità legate a questa tecnologia. Non si sono ancora visti protocolli e/o standard capaci di far "dialogare" i diversi dispositivi, ma sopratutto sono ancora pochi e di nicchia i sistemi che offrono la possibilità di condividere l'esperienza virtuale tra più utenti.  Non comprendo la foga e la rincorsa di singole avventure grafiche sicuramente ben realizzate grazie a motori grafici 3D come Unity ed Unreal Engine che tuttavia trascurano altri sistemi per l'interazione dell'utente con l'ambiente virtuale. Si é un po' troppo utenti passivi immobilizzati in una meravigliosa avventura quando invece potremmo essere i "demiurghi" in grado di creare un nuovo mondo. Va oltre tutto fatto notare che i Mondi Virtuali Immersivi in lavorazione stanno ancora implementando sistemi per offrire agli utenti la possibilità di inserire contenuti di vario tipo. La discussione è quanto mai accesa al riguardo: gli strumenti necessari devono essere inseriti nel mondo stesso oppure si devono utilizzare programmi appositi per la creazione?
La risposta è la più diversa (ma non troppo ;-): HighFidelity.io prevede per il momento la possibilità di importare mesh (e non solo) e di operare su di essi, in parte, anche attraverso gli strumenti in-world. Le operazioni base di traslazione, rotazione ed ingrandimento sono sempre possibili, come il rezzing di oggetti base, tuttavia creare oggetti complessi richiede l'utilizzo di modellatori avanzati come Maya o Blender. I problemi tecnici alla base di queste scelte non sono banali. Un oggetto potrebbe essere infatti composto di milioni di triangoli e quindi troppo oneroso nella sua ricostruzione a video ed anche nella sua trasmissione da client a server (o tra peer ;-) Ci sono quindi diversi trucchi sia nella visualizzazione come l'uso di diversi Livelli di Dettaglio (o LOD) della singola mesh, sia sistemi per rendere l'oggetto più semplice e quindi più facilmente visualizzabile. Il formato scelto per il salvataggio delle mesh nel caso ad esempio di HighFidelity, ma anche di altri motori grafici, è FBX. Si tratta di un formato proprietario di Autodesk molto utilizzato per via dei diversi modellatori della stessa casa che lo utilizzano per l'esportazione ed è quindi intuibile che i motori grafici 3D l'abbiano subito adottato da Unity ad Unreal Engine.
Il famoso e tanto atteso Project Sansar sta adottando, molto probabilmente, lo stesso sistema di caricamento delle mesh, tanto che viene dichiarato sul loro comunicato (libera mia traduzione) "..che un ristretto numero di persone potrà caricare modelli 3D creati con Maya(R)..":

The small group of initial creators invited to help test Project Sansar will create 3D content using Autodesk’s Maya® software and will export their creations to the new platform.
Vedi:http://www.lindenlab.com/releases/linden-lab-invites-first-virtual-experience-creators-to-project-sansar-testing

Per una più dettagliata disamina delle possibili caratteristiche di Project Sansar potete vedere qui. Dalle dichiarazioni fatte tuttavia si evince che saranno presenti successivamente anche strumenti direttamente in-world e l'importazione anche da altri modellatori 3D. 
Si procede quindi in ordine sparso, ma soprattutto in modalità diverse senza appoggiarsi a formati non proprietari od a protocolli open source e questo è un vero peccato per la diffusione di questi nuovi mondi virtuali. Sophia Elizabeth su medium.com ha scritto un bel articolo in due parti che mostra la vera e propria "battaglia" che sta iniziando tra le diverse piattaforme e che agli occhi di un programmatore sembra uno spreco di risorse e denaro incredibile. Dove sono protocolli e gli standard aperti e comuni su cui creare un Metaverso diffuso così come è successo per il Web. Se esiste HTTP, HTML e tanti altri standard e protocolli perchè non creare un "Metaverse Transfer Protocol"? I tentativi nel passato al riguardo ci sono e non hanno portato ahinoi a nulla di concreto. Perchè non utilizzare e rendere completamente open source/royalty free standard e protocolli di comunicazione e dare a tutti la possibilità di entrare in un "mercato" più vasto con regole comuni? Domande forse a cui mai potremo dare una risposta...

The fight for metaverse articolo:

  1. https://medium.com/@sophiaedm/the-fight-for-the-metaverse-811aef87d16a
  2. https://medium.com/@sophiaedm/the-fight-for-the-metaverse-part-ii-f68f91283a6d 
  3. http://recode.net/2015/07/31/in-the-shadow-of-second-life-virtual-reality-startups-say-this-time-itll-work-really/
Mi consola il fatto che il creatore di ConVRge abbia rilasciato dei bellissimi tutorial per creare un mini-metaverse basato su Unity 3D utilizzando la piattaforma di comunicazione Photon:
E non sarà certo un caso che molte delle "nuove" piattaforme siano basate sul motore 3D Unity per la sua estrema semplicità di integrazione. Rimane tuttavia il problema per me fondamentale di come queste piattaforme siano state realizzate. Quale gli algoritmi, le tecniche e le tecnologie, i protocolli utilizzati? Forse è meglio ripartire dalla base ed iniziare un bel corso sulle librerie grafiche OpenGL. Un primo e piccolo passo verso forse un Metaverse completamente Open Source basato su standard/protocolli quanto più possibili aperti e liberi. Un sogno o forse un' utopia, ma il MayaVerse non è forse questo?

Corsi OpenGL: