Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

358 vues

Publié le

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.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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!

×