Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Lo sviluppo di Edge Guardian VR - Maurizio Tatafiore - Codemotion Milan 2016

342 views

Published on

Cosa significa sviluppare un videogioco in VR partendo da zero? Cosa è andato dritto e cosa è andato storto durante questi mesi di crunch. Un talk informativo con approfondimenti tecnici dal punto di vista sia del Grafico che del Programmatore.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Lo sviluppo di Edge Guardian VR - Maurizio Tatafiore - Codemotion Milan 2016

  1. 1. Lo sviluppo di Edge Guardian Alcune note tecniche
  2. 2. Partendo da zero ● Realizzare un MVP videludico in pochi mesi ○ Quali sfide tecniche? ○ Vediamo qualche esempio
  3. 3. Partendo da zero ● Rendering stereoscopico ○ Low level rendering ○ Setup della telecamera ■ Distanza interoculare ■ Convergenza ● Tracking ○ Librerie di basso livello per l’acquisizione ○ Interpolazione e smoothing dei dati di tracking ○ Gestione dei tracked device
  4. 4. Integrazione con Unity3D Uso di Unity con HTC Vive: ● SteamVR (architettura open source) ○ OpenVR (libreria open source) ● VRTK (VR Tool Kit) ○ Nato dalla community ○ Grezzo all’inizio ■ Alcune integrazioni sono state necessarie ○ Evoluto moltissimo in pochi mesi
  5. 5. Le vere sfide Iterazioni brevi: ● Mercato nuovo ed in fermento ○ Necessità di essere disponibili al pubblico il prima possibile Ottimizzazione: ● Vive richiede(va) 90fps obbligatori ○ Ogni hiccup risulta estremamente fastidioso ○ Cali prolungati di framerate portano nausea ○ Problema parzialmente superato di recente con ATW (Asynchronous reprojection)
  6. 6. Comportamenti emergenti All’inizio erano le sfere: ● Non erano troppo interessanti
  7. 7. Comportamenti emergenti Rendere i nemici più “intelligenti”: ● Avvicinamento convincente ● Capacità di evitare gli attacchi ● Non rimanere bloccati dietro ostacoli o nel paesaggio ● Movimento fluido ● Evitare comportamenti “robotici”
  8. 8. Comportamenti emergenti Soluzioni: ● Behaviour trees? ● Flocking behaviours? ● Reti neurali? ● Forse meglio partire da un approccio semplice… ○ Physics based ○ Un unico movimento base: reach point ○ Guidato da una FSM ○ Meccanismo di evitamento
  9. 9. Comportamenti emergenti Risultato finale: ● Difficile veder finire una partita senza almeno una parolaccia ○ Good job!
  10. 10. Resa estetica ● Effetti di post processo ○ Fondamentali per la resa estetica ○ Molti sono inadatti alla VR ■ Avvengono in screen space
  11. 11. Resa estetica ● Stereoscopia: I post processi avvengono qui
  12. 12. Resa estetica ● Necessari molti esperimenti: ○ Esclusi ■ Nebbia volumetrica ■ Ambient occlusion ■ Tilt shift ■ ... ○ Utilizzati ■ Antialiasing ■ Bloom
  13. 13. Resa estetica
  14. 14. Ottimizzazioni ● Questione di applicare fin dall’inizio alcune best practices ○ Pooling per evitare instanziazione ○ Paradigma 90/10 ■ Problema “a thousand updates” ■ Gestione dei cicli ○ I test, anche su macchine relativamente low end, hanno dato risultati incoraggianti “Debolezze” di Unity da conoscere ed aggirare
  15. 15. Ottimizzazioni ● Pooling degli oggetti ○ Istanziazione di un nuovo oggetto: operazione dispendiosa ○ Ondate di centinaia di nemici in contemporanea ○ Pool di nemici istanziati in startup ■ Offscreen ■ Diverse categorie ■ Configurabili ■ Un manager che ne gestisce il ciclo di vita
  16. 16. Ottimizzazioni ● “A thousand updates” (https://blogs.unity3d.com/2015/12/23/1k-update-calls/) ○ Unity si basa sul paradigma entità/componenti ○ Ogni componente possiede vari “hook” ■ Alcuni, come Update(), vengono richiamati ad ogni ciclo Overhead Chiamata Update()
  17. 17. Ottimizzazioni ● “A thousand updates” ○ Con molti oggetti interattivi in contemporanea, l’overhead può essere un grosso problema ○ Soluzione: ■ Di nuovo il manager pattern ● Un solo oggetto che abbia i riferimenti a tutti gli oggetti di una categoria ● Una chiamata ad Update()... ● ...che aggiorna tutti gli oggetti in un ciclo
  18. 18. Ottimizzazioni ● Garbage collection e gestione dei cicli ○ Unity scripting backend: Mono 2.6.5 (circa .NET 2.0) ○ Gestione automatica della memoria e GC ■ GC non generazionale ■ Ogni passaggio del GC causa fps hiccups ○ .NET possiede classi collection generiche molto utili ■ List<>, Queue<>, Stack<>, Dictionary<>, … ■ MA ■ L’utilizzo del pratico costrutto foreach su di essi genera garbage ● (bug di Mono 2.6.5)
  19. 19. Ottimizzazioni ● Garbage collection e gestione dei cicli ○ Rimanendo nel paradigma 90/10 esistono due soluzioni ■ Utilizzare for al posto di foreach ■ Riscrivere l’enumeratore per le classi interessate
  20. 20. Grazie a tutti per l’attenzione!

×