Partendo da zero
● Realizzare un MVP videludico in pochi mesi○ Quali sfide tecniche?○ Vediamo qualche esempio
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
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
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)
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”
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
Comportamenti emergenti
Risultato finale:
● Difficile veder finire una partita senza almeno una parolaccia
○ Good job!
Resa estetica
● Effetti di post processo○ Fondamentali per la resa
estetica○ Molti sono inadatti alla VR
■ Avvengono in screen space
Resa estetica
● Necessari molti esperimenti:○ Esclusi
■ Nebbia volumetrica■ Ambient occlusion■ Tilt shift■ ...
○ Utilizzati■ Antialiasing■ Bloom
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
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
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
OverheadChiamata Update()
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
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)
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
Top Related