Univerza v Ljubljani
Fakulteta za raˇ cunalniˇ stvo in informatiko
Danijel Filipovi´c
Interaktivna vizualizacija
arheoloˇ skega najdiˇ sˇ ca v navidezni resniˇ cnosti
DIPLOMSKO DELO
VISOKOˇSOLSKI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : izr. prof. dr. Matija Marolt Somentor : as. mag. ˇ Ziga Lesar
Ljubljana, 2022
besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.
Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita program- ska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/
licenses/.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Kandidat: Danijel Filipovi´c
Naslov: Interaktivna vizualizacija arheoloˇskega najdiˇsˇca v navidezni re- sniˇcnosti
Vrsta naloge: Diplomska naloga na visokoˇsolskem programu prve stopnje Raˇcunalniˇstvo in informatika
Mentor: izr. prof. dr. Matija Marolt Somentor: as. mag. ˇZiga Lesar Opis:
V sodelovanju z Narodnim Muzejem Slovenije (NMS) boste razvili (VR) vi- zualizacijo arheoloˇskega najdiˇsˇca in arheoloˇskih predmetov. Cilj vizualizacije je javnosti pribliˇzati slovensko zgodovino prek interaktivne aplikacije, v kateri bodo uporabniki lahko izkusili ˇzivljenje v ˇzelezni dobi. Interaktivnih scena- rijev je na voljo veˇc, od prikaza kovanja oroˇzja do vizualizacije ˇzeleznodobne vojske. Poleg interaktivne vizualizacije bo diplomska naloga lahko obsegala tudi 3D modeliranje predmetov in navideznega prostora v tesnem sodelova- nju z NMS. Tehnologija je stvar dogovora, na voljo so igralni pogoni (Unity, Unreal, Godot), spletne tehnologije (Three.js, Babylon.js, WebGL, WebXR) ali kaj drugega. Dober izdelek bo na ogled obiskovalcem razstave, ki jo pri- pravlja NMS.
Title: Interactive visualization of an archeological site in virtual reality Description:
In collaboration with The National Museum of Slovenia (NMS), we will de- velop a VR visualization of an archeological site and its findings. The goal of the visualization is to bring awareness about the Slovenian history to the general public through an interactive application, where users will experience life from the iron age. There are multiple interactive scenarios available, from portraying the forging of a weapon to portraying an iron age army. Including
Hvala mami Sladjani Filipovi´c, oˇcetu Rafotu Filipovi´cu in bratu Aleˇsu Fili- povi´cu za brezpogojno in neomejeno podporo med ˇcasom ˇstudija; Narodnemu muzeju Slovenije, predvsem Juretu Kusetiˇcu in Saˇsi Rudolf, za prijetno so- delovanje, gostoljubje na sestankih in pomoˇc pri izdelavi izdelka; Igorju Doli- narju za 3D modele in pomoˇc pri uvaˇzanju le-teh; Laboratoriju za raˇcunalniˇsko grafiko in multimedije Fakultete za raˇcunalniˇstvo in informatiko Univerze v Ljubljani za izposojo strojne opreme v namen razvoja; ter mentorju in so- mentorju za podporo, pomoˇc in napotke.
Kazalo
Povzetek Abstract
1 Uvod 1
1.1 O projektu . . . 1
1.2 O diplomskem delu . . . 2
2 Arheoloˇsko najdiˇsˇce in zgodovinsko obdobje 3 3 Uporabljene tehnologije 7 3.1 Navidezna resniˇcnost . . . 7
3.2 Oculus Quest 2 . . . 10
3.3 Unity . . . 11
3.4 C# . . . 14
4 Izdelava vizualizacije 15 4.1 Atmosfera, ki jo ˇzelimo upodobiti . . . 15
4.2 Skybox . . . 16
4.3 Viˇsinska slika . . . 18
4.4 Izdelava terena . . . 19
4.5 Postavitev igralca . . . 20
4.6 Oblikovanje terena . . . 21
4.7 Uˇcinki delcev . . . 25
4.8 Dodajanje ptic . . . 26
4.11 Zvok . . . 32
5 Dodajanje interakcije 35 5.1 XR Interaction Toolkit . . . 35
5.2 Zasnova interakcije . . . 38
5.3 Kontroler stanja . . . 39
5.4 Kontroler za procesiranje uporabniˇskega vnosa . . . 40
5.5 Kontroler sulice . . . 43
5.6 Kontroler tarˇce . . . 55
5.7 Zaslon, ki prikazuje let sulice . . . 58
6 Konfiguracijska datoteka 61
7 Uporabniˇski vmesnik 63
8 Zaledni del 69
9 Zakljuˇcek 73
Seznam uporabljenih kratic
kratica angleˇsko slovensko
VR virtual reality navidezna resniˇcnost AR augmented reality obogatena resniˇcnost NMS The National Museum of Slo-
venia
Narodni Muzej Slovenije DAeL Danube’s Archeological eLan-
dscapes
Arheoloˇske eKrajine Podo- navja
NPC Non-playable character lik, ki ga ni mogoˇce igrati
Povzetek
Naslov: Interaktivna vizualizacija arheoloˇskega najdiˇsˇca v navidezni re- sniˇcnosti
Avtor: Danijel Filipovi´c
Arheoloˇska najdiˇsˇca lahko prinesejo odkritja, ki nas fascinirajo in nam po- nudijo vpogled v nekaj, kar je ˇze dolgo pozabljeno in zapuˇsˇceno. Najdbe zah- tevajo veliko pazljivosti in skrbi, saj je njihova ohranjenost zelo pomembna.
V tem delu se tega problema lotimo s pomoˇcjo digitalne rekonstrukcije naj- denih ostankov v obliki 3D modelov. Ta pristop nam omogoˇca laˇzjo preno- sljivost, shrambo in vzdrˇzevanje ohranjenosti arheoloˇske dediˇsˇcine.
Medtem ko nam ostanki in najdiˇsˇca ponujajo dober vpogled v preteklost, nam ne morejo omogoˇciti izkuˇsnje, ki bi nas postavila v takratni svet. To bomo zapolnili s tehnologijo navidezne resniˇcnosti.
Rezultat diplomskega dela je interaktivna vizualizacija arheoloˇskega najdiˇsˇca, ki s pomoˇcjo igrifikacije in tekmovalnosti uporabniku ponuja potopitveno, a tudi zabavno izkuˇsnjo.
Kljuˇcne besede: Navidezna resniˇcnost, vizualizacija, VR, arheoloˇsko najdiˇsˇce, interaktivna vizualizacija.
Abstract
Title: Interactive visualization of an archeological site in virtual reality Author: Danijel Filipovi´c
Archeological sites can uncover secrets, which fascinate us and offer an insight into the long forgotten and abandoned. Preservation of the quality of the relics requires a substantial amount of care. In this thesis, we tackle this problem with the help of digital reconstruction in the shape of 3D models.
This approach allows us to transfer, store and maintain the archeological heritage with ease.
While relics and archeological sites offer us a good insight into the past, they can’t deliver an experience which would truly place us in a world from which they were used. We will fill this gap with the help of virtual reality.
The product of my diploma is an interactive visualization of an archeolog- ical site, which offers an immersive, but also – with the help of gamification and competitiveness – fun experience.
Keywords: Virtual reality, visualization, VR, archeological site, interactive visualization.
Poglavje 1 Uvod
1.1 O projektu
Narodni Muzej Slovenije (v nadaljevanju NMS) je julija 2020 skupaj z 22 par- tnerji iz 10 drˇzav, med katerimi je tudi Zavod za varstvo kulturne dediˇsˇcine Slovenije (ZVKDS), zaˇcel izvajati evropski projekt Arheoloˇske eKrajine Po- donavja (Danube’s Archeological eLandscapes, v nadaljevanju DAeL) [5]
pod vodstvom avstrijskega muzeja Universalmuseum Joanneum. To je veˇcji projekt, katerega namen je poveˇcati prepoznavnost arheoloˇske dediˇsˇcine, digitalizirati evropsko arheoloˇsko dediˇsˇcino ter jo narediti privlaˇcnejˇso za vkljuˇcevanje v trajnostni kulturni turizem.
V okviru projekta bomo projektni partnerji izdelali veˇc vizualizacij, ki bodo upodobile doloˇcene scenarije iz zgodovine. Nastali izdelki bodo nato del mednarodnih razstav. Uporabljene bodo VR in AR tehnologije, s katerimi bomo ustvarili kakovostne, resniˇcnosti zelo podobne vizualizacije in izkuˇsnje v upanju, da bo to obiskovalce motiviralo k nadaljnjemu spoznavanju bogate arheoloˇske dediˇsˇcine. Pri upodobitvi se bomo osredotoˇcili predvsem na Podo- navje [39]. Verjamemo, da bo vpeljava sodobnih tehnologij moˇcno popestrila izkuˇsnjo ogleda razstav.
1
1.2 O diplomskem delu
Kot sodelujoˇci na projektu smo izdelali eno od predhodno omenjenih vizu- alizacij, ki bodo nastale v okviru projekta. Dodani so elementi igrifikacije, ki vizualizaciji dodajo obˇcutek videoigre in naredijo celotno izkuˇsnjo bolj zabavno.
Predmet obdelave je ˇzeleznodobna naselbina, odkrita na danaˇsnji Ulaki nad Starim trgom pri Loˇzu. Izdelali smo interaktivno vizualizacijo, ki upo- rabnika postavi v vlogo Kelta, ki se pripravlja na obrambo. Vizualizacija je postavljena v ˇcas sredine 1. st. n. ˇst., ko je naselbino oblegala rimska vojska, zato se protagonist na namenskem terenu uri in poskuˇsa izboljˇsati svojo veˇsˇcino metanja sulice. Na terenu je postavljena tarˇca, uporabnik pa lahko pobere sulico, ki jo nato s pomoˇcjo kontrolerja vrˇze proti tarˇci.
Igra poteka tako, da ima igralec doloˇceno ˇstevilo metov. Vsak met je vreden doloˇceno ˇstevilo toˇck, ki je odvisno od oddaljenosti srediˇsˇca tarˇce do toˇcke zadetka. Ko igralec doseˇze najveˇcje dovoljeno ˇstevilo metov, lahko svoj doseˇzek (vsota doseˇzenih toˇck vseh metov) vnese na lestvico dosegov in se tako primerja z ostalimi igralci.
Za izdelavo izdelka smo uporabili sodobne metode, strojno in program- sko opremo. Glavni izdelek diplomskega dela je torej opisana interaktivna vizualizacija, katere razvojni proces bomo podrobno dokumentirali v tem be- sedilu. Za vsako implementirano funkcionalnost bomo bralcu tudi opisali in predstavili tehnologijo oz. koncepte, ki implementacijo omogoˇcajo.
Poglavje 2
Arheoloˇ sko najdiˇ sˇ ce in zgodovinsko obdobje
Arheoloˇsko najdiˇsˇce, ki smo ga upodobili v vizualizaciji, se nahaja na Ulaki – 683 metrov visoki vzpetini nad Starim trgom pri Loˇzu v jugozahodni Slo- veniji. Njen vrh je poloˇzen in obsega povrˇsino 5 ha, na njem pa leˇzijo sledovi prazgodovinskega gradiˇsˇca in rimskega naselja. Arheologi so odkrili tudi dva rimska oblegovalna tabora: enega na vzpetini severovzhodno od Ulake (670 m), drugega na Nadleˇskem hribu (642 m) juˇzno od Ulake.
Obmoˇcje je bilo skenirano s tehnologijo LIDAR [15], katere rezultati so bili analizirani in arheoloˇsko interpretirani. To je razkrilo tlorisno zasnovo najdiˇsˇca in potek obzidja.
3
Slika 2.1: Ulaka in dolina pod njo. Vrh Ulake je na spodnjem delu na levi strani. Na desni strani je vrh Nadleˇskega hriba, kjer so bili najdeni ostanki oblegovalnega rimskega tabora (avtor: Toni Konrad).
Slika 2.2: LIDAR posnetek obmoˇcja in njegova arheoloˇska interpretacija (iz- delava: Narodni muzej Slovenije).
Diplomska naloga 5 Rimska vojaˇska tabora blizu naselja Ulaka arheologi razumejo kot oblego- valni gradnji in ocenjujejo, da sta nastala v obdobju delovanja Julija Cezarja v Iliriku (59–49 pr. n. ˇs.) ali pa najkasneje med Oktavijanovo vojno v Ili- riku (35–33 pr. Kr.). Odkritja rimskega oroˇzja in vojaˇske opreme kaˇzejo na spopad med rimsko vojsko in domaˇcini, branilci gradiˇsˇca. Obleganje Ulake oznaˇcuje prehod iz ˇzelezne v rimsko dobo na Notranjskem. Naselbina je cve- tela tudi v obdobju antike, saj rimski novci, najdeni na Ulaki, dokazujejo poselitev do zaˇcetka 5. stoletja. Poleg oroˇzja in orodja so iz rimske dobe naˇsli ˇse fibule in drug nakit. Veˇcina najdenih rekvizitov je iz mlajˇse ˇzelezne dobe. Hiˇse v kompleksu so bile vkopane v skalno osnovo, kar je znaˇcilno za ˇzeleznodobno gradnjo. V veˇcini objektov naj bi bila tla poklesana in izrav- nana z glino, kritje pa je bilo narejeno s skodlami ali s slamo. V naselju je bilo najdenih tudi veliko sledi, ki namigujejo, da je bilo predelovanje kovine pogosta dejavnost. Med te najdbe sodijo kovaˇska orodja, ognjiˇsˇca, talilniki, strjevalne posode itd. Te najdbe nakazujejo na razvito kovinarstvo in pod- pirajo tezo, da je bila Ulaka trˇsko srediˇsˇce lokalne skupnosti [10, 14, 2].
Slika 2.3: Orodje iz kovaˇcnice na Ulaki. 1. st. n. ˇst. (avtor: Tomaˇz Lauko, Narodni muzej Slovenije).
Slika 2.4: Rimska vojaˇska oprema z Ulake. 1 st. pr. n. ˇst. in 1. st. n. ˇst.
(avtor: Tomaˇz Lauko, Narodni muzej Slovenije). Primerjava z modelom, ki je bil uporabljen v vizualizaciji.
Poglavje 3
Uporabljene tehnologije
V tem poglavju bomo opisali predvsem strojno in programsko opremo, ki jo smo jo uporabili za izdelavo interaktivne vizualizacije. Vse ostale tehnologije, ki so del zalednega dela, bomo opisali v 8, ko bomo govorili o izdelavi in delovanju zalednega dela.
3.1 Navidezna resniˇ cnost
Navidezna resniˇcnost (angl. Virtual Reality – VR) je raˇcunalniˇsko generirano okolje s scenami in objekti, ki izgledajo zelo resniˇcni, kar da uporabniku obˇcutek, kot da je potopljen v pravo okolje. To izkuˇsnjo doseˇzemo s pomoˇcjo naprave, imenovane VR oˇcala (angl. VR headset) [40]. Uporabnik si na glavo da oˇcala, skozi katera vidi virtualen svet. Oˇcala sledijo premikom uporabnikove glave s pomoˇcjo senzorjev za premikanje in simulirajo pogled na enak naˇcin, kot vidimo resniˇcen svet skozi oˇci.
Pogosto ima uporabnik v rokah tudi kontrolerje, ki imajo prav tako sen- zorje za zaznavanje premika. Ti kontrolerji nam omogoˇcajo interakcijo zno- traj navidezne resniˇcnosti.
Danes najpogosteje opazimo uporabo te tehnologije v podroˇcjih:
1. videoiger, kjer je uporabljena primarno za zabavo in potopitvene digi- talne izkuˇsnje;
7
2. medicine, kjer je veˇcinoma uporabljena v izobraˇzevalne namene;
3. kulture, kjer je veˇcinoma uporabljena v raznih muzejih in galerijah;
4. izobrazbe, kjer je veˇcinoma uporabljena v namene demonstracije in uˇcenja obvladovanja raznih situacij, ki jih je teˇzko ali drago uresniˇciti izven navidezne resniˇcnosti in
5. arheologije, kjer je veˇcinoma uporabljena v interaktivnih vizualizacijah in simulacijah.
Velik del motivacije pri razvoju te tehnologije je vedno predstavljala moˇznost priprave za aktivnosti, ki jih bomo poˇceli oziroma se z njimi sooˇcili v resniˇcnem ˇzivljenju. Kakovostne simulacije omogoˇcajo izkusiti enako ozi- roma skoraj enako situacijo kot v resniˇcnem ˇzivljenju, le da pogosto pri niˇzjih stroˇskih in viˇsji varnosti, kar ˇse posebej velja za podroˇcje medicine in vojaˇski trening. Dober primer tega so simulatorji letenja z letalom ali simulatorji izvajanja medicinskega posega na ˇcloveˇskem telesu [16].
Ceprav se opisano zdi izjemno tehnoloˇsko napredno, najdemo prve po-ˇ skuse implementacije te ideje ˇze v 50. letih 20. stoletja. Obstajala je namreˇc naprava z imenom Sensorama, ki je omogoˇcala ogled 3D filmov, hkrati pa generirala vonje in oddajala vibracije, kar je naredilo izkuˇsnjo kar se da re- sniˇcno. Napravo je leta 1962 patentiral kinematograf Morton Heilig, ki je bil navduˇsen nad idejo 3D filmov [24].
Diplomska naloga 9
Slika 3.1: Naprava Sensorama. Vir: [4].
Eden od pionirjev navidezne resniˇcnosti je bil Ivan Sutherland, ki je delal v agenciji DARPA (Defense Advanced Research Projects Agency) [6], ka- sneje pa na Harvardski univerzi. Sutherland je leta 1966 zaˇcel delati na 3D raˇcunalniˇskem zaslonu, ki naj bi bil privezan na glavo. Naprava je imela oˇcala, ki so prikazovala raˇcunalniˇsko generirano grafiˇcno vsebino s pomoˇcjo dveh manjˇsih zaslonov, ki sta delovala na tehnologiji katodne cevi [13]. Za- slona sta bila nameˇsˇcena pri uporabnikovih uˇsesih, njihova vsebina pa je bila s pomoˇcjo ogledal odbita na oˇci uporabnika. Naprava je sledila premikom glave uporabnika in tako prilagajala vsebino, ki jo izrisuje.
Slika 3.2: Naprava, ki jo je razvil Ivan Sutherland. Posneto leta 1967 na Harvardski Univerzi. Vir: [1].
3.2 Oculus Quest 2
Oculus Quest 2 so VR oˇcala. Izdelal jih je Oculus, podjetje, ki je v lastniˇstvu podjetja Meta Platforms. Na police je izdelek priˇsel leta 2020.
Oˇcala so sposobna delovati kot samostojna s pomoˇcjo vgrajenega opera- cijskega sistema, ki je osnovan na operacijskem sistemu Android, ali pa preko raˇcunalnika, ˇce so nanj povezane prek USB ali Wi-Fi tehnologije [20].
Diplomska naloga 11
Slika 3.3: Oculus Quest 2. Vir: Oculus.
3.3 Unity
Unity je programska oprema, natanˇcneje igralni pogon, ki ga je razvilo podje- tje Unity Technologies. Prva razliˇcica tega orodja je izˇsla junija 2005, ko je bil pogon izdan ekskluzivno za sisteme Mac OS X. Od tedaj se je moˇcno razˇsiril in je danes sposoben razvijati izdelke, ki delujejo na mnogih platformah, med katerimi so tudi Windows, Linux, Mac OS, Android, iOS, igralne konzole, spletni brskalniki (vmesnik WebGL), razne platforme navidezne resniˇcnosti itd. Orodje se pogosto uporablja za razvoj videoiger ter raznih vizualizacij in digitalnih izkuˇsenj. Omogoˇca ustvarjanje raznih grafiˇcnih vsebin, ki se izri- sujejo v realnem ˇcasu, ima pa tudi simulacijo fizike (fizikalni pogon NVIDIA PhysX). Najpogosteje se uporablja za razvoj videoiger, a njegova uporaba seˇze tudi v podroˇcja arhitekture, gradbeniˇstva, strojniˇstva, filmske industrije in ˇse veliko ostalih [27].
Unity je ogromna platforma, ki ima veliko funkcionalnosti in konceptov, ki jih potrebujemo v doloˇcenih scenarijih in primerih uporabe. Na tem mestu bomo opisali nekaj bistvenih konceptov te programske opreme. Pri tem se bomo omejili predvsem na koncepte, ki so uporabljeni v naˇsem izdelku.
• Scena
Scena je kljuˇcni del Unity projekta. Je neko okolje, kjer lahko delamo z vsebino. V sceno postavimo objekte, ki so nato del nje in lahko z njimi manipuliramo. V izdelku imamo aktivno eno sceno hkrati in med raznimi scenami se lahko tudi premikamo. Ko naredimo nov Unity projekt, dobimo privzeto prazno sceno, na kateri lahko nato zaˇcnemo delati [37].
• GameObject
GameObject je najbolj osnoven koncept v pogonu. Vsak objekt v sceni je GameObject, kar pomeni, da je vse, kar je v projektu in nekoˇc zaˇzivi oziroma nastopi, GameObject ali del nekega GameObjecta. Odvisno od nadaljnjih podrobnosti naˇsega objekta se narejenemu GameObjectu dodaja potrebne lastnosti, ki mu omogoˇcajo doloˇceno vedenje oz. vlogo.
To naredimo s pomoˇcjo komponent. Vsak GameObject ima obvezno komponento Transform, ki vsebuje njegovo lokacijo v sceni in trans- formacije, poleg tega pa omogoˇca manipuliranje s transformacijami in doloˇcanje nadrejenih (starˇs) ali podrejenih (otrok) GameObjectov ter hrani osnovne podatke o GameObjectu, npr. njegovo ime. [31]
• Komponente
Komponente so omenjene lastnosti, ki jih dodamo na GameObject. So programska koda, ki se izvaja v kontekstu objekta. GameObject ima lahko kombinacije komponent, ki ga skupaj pretvorijo v nekaj smisel- nega in mu dajo neko obnaˇsanje. Vsaka komponenta ima svoje metode in lastnosti, ki GameObjectu dodajo funkcionalnost.
• Skripte
Diplomska naloga 13 Skripte so ene izmed mnogih komponent v pogonu. Skripta nam omogoˇca, da naredimo nek kos programske kode, natanˇcneje razred, ki bo ob in- stanciranju objekt, nato pa ga pripnemo na poljuben GameObject ali veˇc GameObjectov. V skriptah lahko dostopamo in manipuliramo z ostalimi komponentami tega GameObjecta, z ostalimi GameObjecti, s samo sceno in ˇse veliko veˇc. Imajo doloˇcene funkcije, ki se pokliˇcejo ob doloˇcenih dogodkih, npr.:
– Start
Funkcija se pokliˇce v prvem okvirju (angl. frame), ko je GameO- bject aktiven v sceni)
– Update
Funkcija se pokliˇce na zaˇcetku vsakega okvirja.
– OnEnable
Funkcija se pokliˇce, ko se GameObject vklopi. Prav tako ob- staja funkcija OnDisable, ki se pokliˇce, ko se GameObject izklopi.
GameObjecte lahko v ˇcasu izvajanja poljubno preko skript vkla- pljamo ali izklapljamo.
– Destroy
Funkcija se pokliˇce, ko se GameObject uniˇci.
• Kamere
V pogonu uporabljamo kamere, da uporabniku izriˇsemo svet. V sceni moramo vedno imeti vsaj eno kamero, lahko jih je pa tudi veˇc. S kame- rami lahko, tako kot tudi z vsemi ostalimi GameObjecti, popolnoma manipuliramo. Lahko jih premikamo po svetu, dodamo fiziko, jim do- damo zaznavanje trkov, na njih pripnemo skripte in ostale komponente, lahko pa tudi dodamo komponente, ki so specifiˇcne za kamere, kot so npr. post-procesiranje [29].
• Rigidbody
Rigidbody je komponenta, ki GameObjectu omogoˇci, da nanj deluje fi- zika. Omogoˇceno je dodajanje mase na objekt, manipuliranje s pomoˇcjo sil in navorov, zaznavanje trkov in interakcija z drugimi Rigidbody objekti [36].
• Material
Medtem ko 3D model definira obliko objekta, komponenta Material doloˇca videz 3D modela. Pri tem obstaja tesna povezava s senˇcilniki – vsak Material ima namreˇc senˇcilnik, ki definira prikaz. Material si s senˇcilnikom, ki ga uporablja, deli lastnosti in podprte parametre [34].
Pogon Unity ima izmed vseh uporabljenih tehnologij najveˇcjo zaslugo pri izdelavi naˇsega izdelka. Omogoˇcil nam je kreiranje terena, uvaˇzanje 3D modelov, kreiranje atmosfere, kreiranje raznih scen, dodajanje interakcije, zaznavanje vnosa prek vhodnih naprav, povezavo z VR kontrolerjem in ˇse mnogo veˇc.
3.4 C#
C# je sploˇsno namenski, strogo tipiziran in objektno usmerjen programski jezik. Razvilo ga je podjetje Microsoft kot del svoje .NET platforme [3].
Poglavje 4
Izdelava vizualizacije
4.1 Atmosfera, ki jo ˇ zelimo upodobiti
V svetu videoiger obstaja veliko razliˇcnih umetniˇskih slogov, ki definirajo videz izdelka. Da bi bil produkt zanimiv uporabnikom, je zelo pomembno, da je vizualno privlaˇcen.
Ker je v naˇsem izdelku velik poudarek na zgodovinski natanˇcnosti in resniˇcnem okolju, smo se odloˇcili, da bomo kot umetniˇski stil izbrali realizem.
Uporabniku ˇzelimo ponuditi izkuˇsnjo, ki je karseda podobna resniˇcnosti.
Na podroˇcju ustvarjalnosti nismo imeli nobenih bistvenih omejitev, zato smo imeli proste roke. Odloˇcili smo se, da bomo okolje postavili v obdobje pozne jeseni in da ˇzelimo narediti sonˇcni zahod. Toˇcno takˇsno je namreˇc bilo stanje tistega popoldneva, ko smo zaˇceli z delom.
15
Slika 4.1: Sonˇcni zahod, ki ga ˇzelimo upodobiti.
4.2 Skybox
V videoigri lahko sceno vidimo kot neko neskonˇcno praznino, po kateri se lahko premikamo. Znotraj te scene so nato postavljeni objekti, ki predsta- vljajo okolje in “svet” videoigre.
Metoda skybox omogoˇca kreiranje ozadij, ki igri dodajo globino. Celotno okolje, v katerem bo igra potekala, se zavije v ogromno kocko. Okolje je torej znotraj kocke. Na notranje ploˇsˇce kocke se nato prilepi teksturo, ki ima 6 med seboj povezanih delov. Ta tekstura lahko vsebuje seveda kar koli, pogosto je to nebo, ki ima vˇcasih tudi kakˇsne oddaljene zgradbe ali objekte, ki so zelo daleˇc od igralca in v resnici ne obstajajo kot dejanski 3D modeli v sceni, saj so del slike. Igralcu, ki se premika po terenu, to da obˇcutek, da
Diplomska naloga 17 je okolje veliko, saj se mu predmeti, ki so v njegovi bliˇzini (in so del scene kot 3D modeli), pribliˇzujejo ali oddaljujejo z njegovim premikanjem, objekti daleˇc stran pa ostanejo na istem mestu [26].
Slika 4.2: Primer teksture za skybox. Vir: [25].
Za uporabo v naˇsi vizualizaciji smo si izbrali enega izmed skyboxov, ki so bili kupljeni v Unity spletni trgovini [28]. Pogon nam omogoˇca zelo enostavno menjavo skyboxa v sceni. Do moˇznosti dostopamo prek menijev Rendering / Ligthning / Environment / Skybox Material.
Slika 4.3: Meni za nastavljanje skybox scene.
Slika 4.4: Naˇsa scena v Unity z nastavljenim skyboxom.
4.3 Viˇ sinska slika
V naˇsi igri smo ˇzeleli narediti repliko Ulake in njene oˇzje okolice. ˇCe bi se tega lotili roˇcno, bi to bilo seveda zelo poˇcasno, naporno in zagotovo ne najbolj natanˇcno. Odloˇcili smo se, da bomo naredili viˇsinsko sliko.
Viˇsinska slika (angl. heightmap) je slika, v kateri vsak piksel vsebuje podatke o viˇsini povrˇsine na njegovi toˇcki. Takˇsno sliko lahko uporabimo pri izdelavi terenov, kjer se viˇsina v neki toˇcki na terenu nastavi na enako viˇsino, kot jo predstavlja ista toˇcka na sliki. V viˇsinski sliki predstavlja ˇcrna barva najmanjˇso in bela barva najveˇcjo viˇsino. ˇCe je takˇsna slika shranjena v sliki in ne specializiranem formatu (obstaja jih veˇc), mora ta slika biti v sivinskih odtenkih. [8]
Za naˇs izdelek smo viˇsinsko sliko ustvarili s pomoˇcjo spletne aplikacije Tangram Heightmapper [9].
Diplomska naloga 19
Slika 4.5: Ustvarjena viˇsinska slika Ulake in njene okolice.
4.4 Izdelava terena
Po izdelavi viˇsinske slike sledi uvaˇzanje le-te v Unity, ki ima nekaj pogojev, ki jih moramo izpolniti, da bi bilo uvaˇzanje uspeˇsno. Slika mora biti namreˇc ob- vezno v formatu RAW in v sivinskih odtenkih. Poleg tega ima pogon mnoˇzico predefiniranih loˇcljivosti, ki jih sprejme kot veljavne loˇcljivosti viˇsinske slike za uvaˇzanje. Priporoˇceno je tudi, da naj bo teren, na katerega bo viˇsinska slika uvoˇzena, enake velikosti (ˇsirina in viˇsina v metrih) kot loˇcljivost slike (v pikslih) z namenom, da se viˇsinske razlike na terenu v pogonu uveljavijo po enako veliki povrˇsini, kot so na sliki.
Z izjemo teh pogojev je uvaˇzanje viˇsinske slike zelo enostavno. V sceni je potrebno narediti nov teren (desni klik v Inspector / 3D Objects / Terrain), kar ustvari nov GameObject s komponento Terrain. V tej komponenti je nato meni “Terrain settings”, ki vsebuje podmeni za viˇsinske slike.
Slika 4.6: Meni za uvaˇzanje viˇsinske slike v Unity.
Slika 4.7: Teren, generiran prek viˇsinske slike.
4.5 Postavitev igralca
Po uspeˇsno narejenem terenu smo se lotili naˇcrtovanja postavitve okolja in igralca. V Unity urejevalniku smo se s kamero sprehajali po terenu in po- skuˇsali doloˇciti najboljˇso pozicijo za igralca. Igralec je v igri statiˇcen in nima moˇznosti premikanja, zato je pozicija zelo pomembna. Po razmisleku smo ugotovili, da je najbolje, da ima igralec sonˇcni zahod za seboj in gleda v
Diplomska naloga 21 smeri nasprotno od sonca, tako bo imel pred oˇcmi lepo osvetljeno sceno in sence. Poleg tega bi bilo verjetno zelo moteˇce, ˇce bi imel igralec ob zaˇcetku v vidnem spektru sonce, ki je moˇcan vir svetlobe. Odloˇcili smo se tudi, da ˇzelimo igralca postaviti v dolino in ne na visoko toˇcko.
Slika 4.8: Izbrana pozicija igralca – zgoraj je pogled naprej, spodaj pa pogled nazaj.
4.6 Oblikovanje terena
Teren je v Unity v resnici le velika 3D povrˇsina, s katero lahko manipuliramo.
Ta ravnina ima svoje lastnosti, med katerimi so npr. ˇsirina in viˇsina terena.
Pogon ponuja paket, ki se imenuje Terrain tools in nam ponuja veliko oro- dij za prilagajanje terena, med katerimi so npr. viˇsanje, niˇzanje, glajenje,
izdelava mostov, barvanje tekstur in ˇse mnoga druga. Ko si izberemo ˇzeleno orodje, si moramo izbrati ˇse ˇcopiˇc. ˇCopiˇc je lahko razliˇcne oblike, privzeto je pa navaden krog. ˇCopiˇce lahko uvaˇzamo tudi prek viˇsinskih slik. Po kliku na teren bo izbrano orodje znotraj obmoˇcja ˇcopiˇca ustrezno manipuliralo s povrˇsino.
Slika 4.9: Primer izbire orodja za manipulacijo viˇsine terena in enega izmed ˇcopiˇcev.
Diplomska naloga 23 Izbrali smo si orodje za barvanje terena s teksturami in celoten teren naredili skalnat.
Slika 4.10: Teren s teksturo skalnate povrˇsine.
Zatem smo dolino pobarvali s teksturo travnate povrˇsine. Pri tem smo opazili, da je na doloˇcenih lokacijah teren preveˇc naguban. Izbrali smo si orodje za glajenje terena, privzet okrogel ˇcopiˇc in teren zgladili. Poleg tega smo tudi vrhove hribov pobarvali s teksturo snega.
Slika 4.11: Pobarvan teren in primerjava pred in po glajenju.
Sledilo je dodajanje dreves. Unityjev paket Terrain tools vsebuje orodje
“Paint trees”. To orodje nam omogoˇca, da vnesemo seznam 3D modelov dreves, ki jih ˇzelimo postaviti na teren. V nastavitvah izberemo velikost ˇcopiˇca, gostoto poraˇsˇcenosti dreves, viˇsino dreves (ki je lahko tudi nakljuˇcna) in ˇsirino dreves (ki se lahko spreminja skladno z viˇsino). Ob kliku na teren pogon v obmoˇcju ˇcopiˇca postavi drevesa na doloˇcene toˇcke in viˇsino, ki je skladna s terenom – torej so drevesa pri tleh in ne nad ali pod terenom. V dolino smo postavili razna drevesa, ker smo ˇzeleli raznolik gozd, na vrhove
Diplomska naloga 25 hribov pa smo postavili iglavce, ki so zasneˇzeni.
Slika 4.12: Teren z gozdom.
4.7 Uˇ cinki delcev
Sistem delcev (angl. particle system) je tehnologija, ki izriˇse veliko majhnih slik ali 3D objektov – delcev (angl. particles) in s tem ustvari nek vizu- alni uˇcinek. Vsak delec v sistemu predstavlja nek posamezen del celotnega uˇcinka. Veˇcinoma se uporabljajo pri izdelovanju dinamiˇcnih objektov, kot je npr. dim, saj je takˇsne objekte teˇzko uˇcinkovito prikazati s pomoˇcjo slike ali 3D objekta [35]. Pogon ponuja ogromno nastavitev za sisteme delcev, med katerimi so npr. trajanje uˇcinka, moˇznost neskonˇcnega predvajanja v zanki, najveˇcje ˇstevilo delcev, ki lahko hkrati obstajajo znotraj sistema, hitrost kre- iranja delcev, koliko ˇcasa naj nek delec obstaja, preden se odstrani, hitrost premika delcev, osvetljava delcev itd.
V naˇsem izdelku smo to tehnologijo uporabili v veˇc primerih. Eden izmed njih je izdelava uˇcinka padanja listja, kar je znaˇcilno za jesen. Sistem za
delce uporablja veˇc slik listov, ki jih med seboj meˇsa. Sistemu delcev lahko nastavimo tudi velikost, ki je v tem primeru skoraj ˇcez celotno povrˇsino gozda.
Slika 4.13: Padajoˇce listje.
4.8 Dodajanje ptic
Da bi bilo okolje kakovostno, se je treba posvetiti podrobnostim. Odloˇcili smo se, da bomo vizualizacijo oˇziveli s tem, da v okolje dodamo ptice. V Unity spletni trgovini smo kupili paket 3D modelov ptic vkljuˇcno z animacijami.
Ptice in njihov nadzor smo implementirali v dveh skriptah. Najprej smo na GameObjectu “Environment” (okolje) naredili novo komponento tipa skripta, v kateri je razred BirdSpawner. V njem teˇce neskonˇcna zanka, ki instancira ptico, nato pa poˇcaka X sekund in instancira novo. Spremen- ljivka X je nakljuˇcno ˇstevilo v intervalu [4,10]. Instanciranje ptice poteka po sledeˇcih korakih:
Diplomska naloga 27
• Izberi nakljuˇcnega izmed predefinirane mnoˇzice 3D modelov ptic.
• Izberi nakljuˇcno ˇstevilo A v intervalu [5,10].
• Ce jeˇ A veˇcji od 5, instanciraj novo ptico na xosi terena, kjer je koor- dinataxnakljuˇcno ˇstevilo med 0 in ˇsirino terena, koordinatay(viˇsina, na kateri se bo ptica instancirala) nakljuˇcno ˇstevilo v intervalu [41,80], koordinata z pa je 0.
• Sicer instanciraj novo ptico na z osi terena, kjer je koordinata xenaka 0, koordinata y nakljuˇcno ˇstevilo v intervalu [41,80], koordinata z pa je nakljuˇcno ˇstevilo med 0 in dolˇzino terena.
Odloˇcili smo se, da bomo ptice instancirali na eni izmed osi, ker smo ˇzeleli prepreˇciti, da bi se ptica kdaj instancirala v igralˇcevem vidnem polju, saj bi bilo to zelo nenavadno. Vsaka instancirana ptica ima takˇsno rotacijo, da gleda iz osi proti terenu in ne stran.
Pri tem seveda delo ˇse ni konˇcano, saj je urejeno le instanciranje ptic in ne letenje oz. premikanje.
GameObject vsake instancirane ptice ima pripeto komponento tipa skripta z razredom BirdMover. Ta razred ob instanciranju dostopa do komponente Rigidbody in ji nastavi vektor hitrosti na produkt vektorja Transform.forward (ki kaˇze naprej od ptice relativno na njeno rotacijo) s spremenljivko hitro- sti premikanja in tako simulira letenje. Poleg tega razred periodiˇcno vsako sekundo zamenja vrednost spremenljivke hitrosti premikanja, da letenje ni videti preveˇc monotono, saj ptice ne letijo vedno z enako hitrostjo. Animacija letenja ptice se neskonˇcno predvaja celoten ˇzivljenjski cikel ptice.
Razred ima tudi neskonˇcno zanko, ki periodiˇcno (enkrat na sekundo) preverja, ˇce je ptica ˇze preletela celoten teren (celotno ˇsirino ali dolˇzino, odvisno od tega, kje je bila instancirana). Ce ugotovi, da je ptica terenˇ ˇze preletela, jo obrne za 180◦. Ko ptica osemkrat preleti teren, jo razred BirdMover odstrani. To zagotovi, da ni v sceni preveˇc ptic, saj BirdSpawner ˇse vedno instancira nove. Lahko bi tudi naredili, da BirdSpawner instancira
omejeno ˇstevilo ptic, a smo ˇzeleli veˇcjo raznolikost med vrstami ptic, torej da bi igralec videl kar se da veliko razliˇcnih 3D modelov. Vse spremenljivke in vsi intervali, ki smo jih v tem poglavju omenili, so nastavljivi v Unity urejevalniku in po testiranju smo izbrali subjektivno najbolj ustrezne.
Periodiˇcno izvajanje programske kode smo implementirali s pomoˇcjo Unity Coroutines – tehnologija, ki omogoˇca, da se neka metoda preneha izvajati za doloˇceno ˇcasovno enoto in nato nadaljuje tam, kjer je bilo izvajanje preki- njeno [30].
Slika 4.14: Primerek ptice (orel) med izvajanjem igre.
4.9 Osvetlitev
Unity za osvetlitev uporablja implementacijo globalne osvetlitve (angl. global illumination) [32]. V pogonu imamo na voljo veˇc virov svetlobe:
• komponenta luˇci na GameObjectu;
• razni materiali, ki oddajajo svetlobo in
• ambientna svetloba.
Komponenta luˇci ponuja veˇc razliˇcnih luˇci, ki so primerne za razliˇcne primere uporabe:
Diplomska naloga 29
• toˇckovna luˇc (angl. point light)
Je enostavna luˇc, ki se nahaja nekje v prostoru in v vse smeri okoli sebe oddaja enako moˇcne svetlobne ˇzarke. Takˇsna luˇc je uporabna v primerih, ko imamo neke objekte, ki se svetijo, kot je npr. uliˇcna svetilka.
• reflektorska luˇc (angl. spot light)
Je enaka kot point light, le da oddaja svetlobne ˇzarke znotraj nekega kota namesto povsod naokoli sebe. Dober primer uporabe za takˇsno luˇc je npr. baterijska svetilka.
• usmerjena luˇc (angl. directional light)
Je luˇc, katere pozicija ni pomembna. Svetlobni ˇzarki, ki jih oddaja, bodo osvetlili celotno sceno pod doloˇcenim kotom. Dobra je za simuli- ranje npr. sonˇcne svetlobe.
• ploskovna luˇc (angl. area light)
Je luˇc, ki na podlagi nastavitev in parametrov ustvari obmoˇcje v obliki pravokotnika, znotraj katerega osvetli obmoˇcje s pomoˇcjo izraˇcunanih odbojev svetlobe od stranic pravokotnega obmoˇcja.
V naˇsem izdelku smo uporabili predvsem usmerjene luˇci. Naredili smo dve luˇci, ki sta obrnjeni v takˇsnem kotu, da so njuni svetlobni ˇzarki pribliˇzno vzporedni smeri sonca na skyboxu – tako ima igralec obˇcutek, kot da svetloba dejansko prihaja iz sonca na nebu, kar pa seveda ni res, saj je tisto sonce le del slike (skybox). Ena luˇc oddaja svetlobne ˇzarke oranˇzne barve, saj je to pogosto pri sonˇcnih zahodih, druga luˇc pa ima le poloviˇcno intenzivnost svetlobe in oddaja ˇzarke svetlo roˇznate barve, saj smo ˇzeleli, da bi bil sonˇcni zahod oranˇzen in roˇznat.
Uporabili smo sicer tudi toˇckovne luˇci. Rezultat tega bo viden kasneje v delu, ko bomo pokazali konˇcni zaslonski posnetek okolja, na katerem so tudi bakle, ki imajo tovrstno luˇc.
Slika 4.15: Primerjava scene pred in po osvetlitvi.
Ko smo vse to zakljuˇcili, smo v okolje dodali ˇse nekaj podrobnosti. Na doloˇcene pozicije smo poloˇzili veˇc veˇcjih skal, polomljene veje dreves, gobe, razno grmiˇcevje, bakle (dodatna osvetlitev) in roˇze.
Diplomska naloga 31
4.10 Post-procesiranje
Post-procesiranje je izraz za mnoˇzico metod, ki jih uporabljamo za doda- janje vizualnih uˇcinkov ˇcez slike. V videoigrah takˇsni uˇcinki delujejo na senˇcilnikih, ki izrisujejo grafiˇcno vsebino. Uˇcinki post-procesiranja vplivajo na celotno sliko in ne na posamezne elemente [21]. Primer uˇcinkov, ki jih post-procesiranje omogoˇca:
• svetla obmoˇcja v sliki, ki se bleˇsˇcijo (uˇcinek “bloom”);
• spreminjanje barvnega tona, temperature, nasiˇcenosti celotne slike (uˇcinek
“color adjustments”);
• zatemnitev robov slike (uˇcinek “vignette”)
in ˇse mnogi drugi. Uˇcinki, ki jih Unity podpira v svojem paketu Post- processing, so naˇsteti v [22]. V svojem izdelku smo uporabili kombinacijo veˇc uˇcinkov in testirali razne vrednosti, dokler nismo priˇsli do zadovoljivega rezultata.
Slika 4.16: Primer uˇcinka “bloom”.
Slika 4.17: Primerjava scene pred in po uveljavljenem post-procesiranju. Raz- lika je najbolj vidna v barvah jesenskih listov in robovih slike. Prav tako se vidi temnejˇse nebo.
4.11 Zvok
Za delovanje zvoka v sceni moramo imeti en GameObject, na katerem bo komponenta Audio Listener. Ta komponenta simulira posluˇsalca oziroma prejemnika zvoka in omogoˇca, da igralec sliˇsi zvoke iz okolja. Unity priporoˇca, da naj bo v sceni le en Audio Listener. To komponento se najpogosteje pripne na tisti GameObject, kjer je kamera, saj je tam tudi igralec.
Ce ˇˇ zelimo, da nek GameObject oddaja zvok, mu moramo pripeti kom-
Diplomska naloga 33 ponento Audio Source, ki kot enega od vhodnih parametrov sprejme zvoˇcno datoteko, ki naj jo predvaja. Moˇzno je predvajanje ob inicializaciji kom- ponente, neskonˇcno ponavljajoˇce predvajanje in predvajanje s pomoˇcjo pro- gramske kode.
V naˇsi sceni je en Audio Listener, ki je pripet na GameObject, ki pred- stavlja igralca. Za predvajanje zvoka smo uporabil veˇc Audio Source kom- ponent:
• Audio Source na GameObjectu “okolje”. Ta GameObject ima med svojimi otroki glavni teren in vse njegove dekoracije, tarˇco, sulico in vse ptice, ki se instancirajo med tekom igre. Ta komponenta v zanki predvaja zvoke narave, gozda in vetra, kar igralca bolj potopi v okolje.
• Audio Source na GameObjectu tarˇce, ki ob zadetku sulice v tarˇco pred- vaja zvok zadetka nekega projektila v les.
• Audio Source na GameObjectu sulice, ki ob metu predvaja zvok objekta, ki se hitro premika skozi prostor.
Zvok lahko na komponenti Audio Source zlahka predvajamo ob poljub- nem ˇcasu. To naredimo tako, da v neki skripti dostopamo do komponente AudioSource, kar nam omogoˇca vgrajena Unity metoda GetComponent, ki nam vrne instanco iskane komponente. Ko to instanco imamo, pokliˇcemo metodo PlayOneShot.
Poglavje 5
Dodajanje interakcije
5.1 XR Interaction Toolkit
Med mnogimi paketi, ki jih ponuja pogon Unity, je tudi XR Interaction Toolkit [38]. Ta paket vsebuje ogrodje, ki omogoˇca interakcijo kontrolerjev z raznimi elementi uporabniˇskega vmesnika v sceni in raznimi GameObjecti.
Sestavljen je iz treh temeljnih elementov:
• Interactor komponenta
Je komponenta na GameObjectu, ki bo v interakciji z ostalimi Ga- meObjecti, ki to interakcijo podpirajo. Interactor je najpogosteje na VR rokah igralca. Ta komponenta poskrbi za zaznavanje dotikov ali prijemov objektov.
• Interactable komponenta
Je komponenta na GameObjectu, ki podpira interakcijo z Interactorji.
Ponuja metode, katerih izvajanje se sproˇzi ob doloˇcenem dogodku – npr. ob dotiku ali prijemu objekta, na katerem je ta komponenta.
• Interaction manager
Sluˇzi kot posrednik med dvema pravkar omenjenima komponentama in ima vlogo upravljalca. V sceni je lahko veˇc upravljalcev in vsak
35
ima lahko svojo mnoˇzico Interactor in Interactable objektov, a obvezno mora biti v sceni vsaj en upravljalec, da sistem lahko deluje.
Ogrodje vsebuje svojo mnoˇzico konceptov, ki predstavljajo posamezen dogodek, kateri je posledica nekega uporabnikovega dejanja:
• Hover
Stanje, ko je Interactorju omogoˇceno, da naredi interakcijo z Interac- table objektom. Primer: v sceni imamo oroˇzje, npr. roˇcno piˇstolo (Interactable), in uporabnik z rokami (Interactor) pride v njeno bliˇzino oz. se je dotika. To je stanje, ko mu je interakcija (npr. prijem) omogoˇcena.
• Select
Stanje, ko Interactor pravkar vzajemno deluje z Interactable objektom.
Primer: uporabnik drˇzi piˇstolo v rokah.
• Activate
Dejanje, ko uporabnik sproˇzi nek dogodek na Interactable objektu, s katerim vzajemno deluje. Da se lahko sproˇzi dogodek Activate, mora biti objekt Interactable v stanju Select. Primer: uporabnik sproˇzi strel.
Ogrodje za VR in AR omogoˇca nadzor veˇcje mnoˇzice interakcij. Ker je naˇs projekt v VR, bomo naˇsteli le tiste, ki veljajo za VR:
• zaznava uporabniˇskega vnosa na raznih VR platformah;
• zaznava predhodno opisanih dogodkov;
• povratne informacije uporabniku v obliki haptiˇcnih operacij, npr. vi- briranje kontrolerja;
• povratne informacije uporabniku v obliki vizualnih elementov – risanje ˇcrt in ˇzarkov, ki izhajajo iz rok uporabnika;
• interakcija z raznimi elementi uporabniˇskega vmesnika in
Diplomska naloga 37
• VR kamera, ki podpira statiˇcne (uporabnik med izkuˇsnjo sedi) in pro- storske (uporabnik se sprehaja po prostoru, kar se posreduje v izkuˇsnjo kot premikanje po prostoru znotraj VR) izkuˇsnje.
V svojem projektu smo najprej prek orodja Package Manager namestili ogrodje XR Interaction Toolkit in konfigurirali projekt, da bo primeren za VR. Zatem smo naredili GameObject z imenom VR Controller, na katerem je komponenta Interaction manager. Med otroci tega GameObjecta je ˇse objekt XR Rig, ki ga ponuja Unity kot predlogo. Vzpostavitev je enostavna – le desni klik v Inspector / XR / XR Rig (Action based). S tem se ustvari GameObject, ki ima predkonfigurirano VR kamero in kontrolerje (kompo- nente, ki skrbijo za zaznavanje uporabniˇskega vnosa in preslikanje le-tega v dejavnosti, ki jih ogrodje podpira) za levo in desno roko. Prav tako po- gon konfigurira delujoˇce Interactor komponente in pri tem ponuja ogromno moˇznosti, ki jih lahko konfiguriramo po ˇzelji.
Morali smo namestiti ˇse vtiˇcnik za Oculus naprave, ki ga je izdalo podjetje Oculus v sodelovanju z Unityjem, da bi lahko interakcija delovala na oˇcalih Quest 2.
Ostalo je le ˇse to, da smo komponentam XR Controller (Action-based) povedali, kateri so modeli igralˇcevih VR rok. Slednje smo kupili v spletni trgovini Unity Asset Store [28].
Slika 5.1: Zaslonski posnetek iz VR oˇcal, ki prikazuje delujoˇce roke v igri.
5.2 Zasnova interakcije
Interakcijo smo zasnovali tako, da smo programsko logiko razdelili v razne kontrolerje. Kontrolerji so programski razredi, ki skrbijo vsak za svoj doloˇcen del igre, tako npr. kontroler za sulico SpearController skrbi za prijemanje, spuˇsˇcanje in metanje sulice, zaznavanje zadetkov in zgreˇsenih metov, pozicio- niranje sulice in vse ostalo, kar se tiˇce sulice. Kontrolerji imajo razne metode, ki jih lahko kliˇcejo med seboj (npr. kontroler za nadzor stanja kliˇce javne
Diplomska naloga 39 metode kontrolerja za sulico), ˇce je po tem potreba.
V sledeˇcih poglavjih bomo obravnavali vsakega od kontrolerjev posebej in opisali njihov namen, glavne naloge in delovanje. Pri tem se bomo omejili na tiste kontrolerje, ki so bistveni za delovanje igre.
5.3 Kontroler stanja
Kontroler stanja je implementiran v razredu StateController. Je glavni kon- troler vizualizacije, vsebuje reference do vseh ostalih kontrolerjev ter nadzo- ruje celotno delovanje igre. Prav tako skoraj vsi ostali kontrolerji vsebujejo referenco do tega kontrolerja.
Odgovoren je za shranjevanje pomembnih spremenljivk, ki nadzorujejo sploˇsen potek in stanje igre:
• dominantna roka igralca;
• ˇstevilo izvedenih metov;
• ˇstevilo doseˇzenih toˇck in
• ˇstevilo dovoljenih metov v spremenljivkiTHROW COUNT.
Glavna naloga tega kontrolerja je, da se v svojih metodah ustrezno odzove na dogodke, o katerih ga obveˇsˇcajo (prek klicev teh metod) ostali kontrolerji.
Primer: kontroler sulice je ugotovil, da je sulica zadela tarˇco. Uspeˇsno je izraˇcunal vrednost tega zadetka v toˇckah in nato sporoˇcil kontrolerju Sta- teController, da je priˇslo do zadetka ter mu povedal, koliko toˇck je bilo doseˇzenih. StateController poveˇca ˇstevilo izvedenih metov in vsoto doseˇzenih toˇck, nato pa sporoˇci kontrolerju za grafiˇcni uporabniˇski vmesnik, naj poso- dobi prikaz teh dveh ˇstevil. Zatem preveri, ali je bilo izvedenih toliko metov, kot jih je najveˇc dovoljeno. V primeru, da to drˇzi, zakljuˇci igro in naroˇci kontrolerju za procesiranje uporabniˇskega vnosa, naj ne sprejema veˇc akcij, sicer pa sporoˇci kontrolerju za nadzor sulic, da je omogoˇceno instanciranje nove sulice.
Zivljenjski cikel tega kontrolerja je takˇsen, da je v sceni vedno delujoˇˇ ca natanko ena instanca in ne obstaja moˇznost, da bi se ob delovanju instanciral ˇse kak primerek ali pa da bi se obstojeˇci odstranil.
5.4 Kontroler za procesiranje uporabniˇ skega vnosa
Je kontroler, ki je implementiran v programskem razredu InputController.
Odgovoren je za procesiranje uporabniˇskega vnosa prek VR kontrolerjev.
Njegova glavna naloga je zaznavati klike raznih gumbov in o njih obve- stiti kontroler stanja. Prav tako nadzoruje, ali je trenutno VR kontroler- jem omogoˇcena interakcija z elementi uporabniˇskega vmesnika in ali jim je omogoˇcen prijem sulice. ˇZivljenjski cikel tega kontrolerja je enak tistemu, ki ga ima kontroler stanja.
Igra zaznava uporabniˇske vnose s pomoˇcjo Unityjevega sistema za vnose, ki je imenovan Input System in je del enako poimenovanega paketa [33].
Ta sistem je zasnovan modularno in uporabniˇski vnos procesira tako, da se sistem odzove na izvedene akcije in ne neposredno na uporabniˇski vnos.
Sistem nam omogoˇci, da se programska koda loˇci od uporabniˇskega vnosa in deluje tako, da dejanski vnos sproˇzi akcijo, katera nato sproˇzi programsko kodo (metodo).
Primer: ˇZelimo implementacijo, da klik miˇske sproˇzi strel piˇstole. V sistemu vnosa je potrebno definirati akcijo, ki predstavlja strel. Pogon tedaj v pripravljenosti ˇcaka na izvedbo te akcije in, ˇce do tega pride, o tem obvesti vse posluˇsalce – metode. Pri tem je kljuˇcno dejstvo, da te metode niso vezane na klik miˇske, ampak na izvedbo akcije. ˇCe bi se v programski kodi npr. ob kliku miˇske odzvali z izvedbo metode, ki implementira odziv na strel, bi to popolnoma delovalo – a bi priˇsli do teˇzav, ˇce bi npr. uporabnik ˇzelel spremeniti kontrole in si nastaviti igro tako, da mu neka druga tipka ali gumb na miˇski sproˇzi strel. Prav tako bi priˇsli do teˇzav, ˇce bi ˇzeleli spremeniti platformo, na kateri igra deluje, saj se kontrolerji moˇcno razlikujejo. Ceˇ
Diplomska naloga 41 uporabljamo sistem vnosov, po tem ni potrebe – potrebno je le prilagoditi vnos, ki sproˇzi to akcijo, programska koda pa ostane popolnoma enaka.
Kljuˇcni koncepti, ki sestavljajo sistem vnosov:
• sredstva akcij (Input Actions Assets)
vsebujejo mnoˇzico kontrolnih shem, preslikave akcij, akcije in njihove vezi.
• kontrolne sheme (Control Schemes)
definirajo kombinacije naprav, ki jih igralec lahko uporablja (npr. miˇska in tipkovnica, igralni ploˇsˇcek itd.).
• preslikave akcij (Action Maps),
mnoˇzice, ki med seboj loˇcijo razne aktivnosti (npr. kontrole za premi- kanje, kontrole za streljanje, kontrole za voˇznjo itd.).
• akcije (Actions),
dogodki, ki bodo sproˇzili doloˇceno reakcijo. Primer: dogodek strel sproˇzi klic metode ReagirajObStrelu.
• vezi (Bindings)
fiziˇcne kontrole (ki so del kontrolne sheme), ki bodo sproˇzile dogodek neke akcije (npr. klik miˇske je vezan na akcijo strel, pozicija VR kon- trolerja je vezana na pozicijo roke v igri itd.).
• komponenta Player Input,
ki za igralca uveljavi nastavitve vnosa. Ta komponenta kot vhodni parameter sprejme sredstva akcij, katera naj uveljavi.
Unity kot del predhodno opisanega paketa XR Interaction Toolkit ponuja tudi privzeta sredstva akcij (Default Input Actions), ki imajo ˇze nastavljene vse akcije, preslikave, sheme in vezi, da bi XR kontroler uspeˇsno deloval. Ta sredstva smo uporabili tudi sami, saj smo po testiranju ugotovili, da delujejo
brezhibno in zadovoljijo vse naˇse potrebe glede zaznavanja uporabniˇskega vnosa.
Kontroler za procesiranje uporabniˇskega vnosa predvsem skrbi za dve dejavnosti uporabnika:
• uporabnik ˇzeli instancirati novo sulico;
• uporabnik ˇzeli zamenjati dominantno roko.
To smo implementirali tako, da programski razred sprejme ˇstiri vhodne parametre, ki so tipa InputActionReference – referenca na akcijo. Parametri so ˇstirje, saj imata obe dejavnosti moˇznost, da se jih sproˇzi iz leve ali de- sne roke – torej dve referenci za instanciranje sulice (klik gumba na levi ali desni roki) in dve za menjavo roke. Kontroler se ob instanciranju doda kot posluˇsalec na izvedene akcije, ki jih je dobil kot vhodne parametre, in doloˇci metode, ki jih ˇzeli sproˇziti ob klicu.
Slika 5.2: Koda, kjer kontroler prejme vhodne parametre in se doda kot posluˇsalec na izvedene akcije.
Diplomska naloga 43
5.5 Kontroler sulice
Implementacija nadzora nad instanciranimi sulicami in nadzora nad obnaˇsanjem posamezne sulice je narejena s pomoˇcjo dveh kontrolerjev.
5.5.1 Kontroler za nadziranje sulic
Ta kontroler je implementiran v programskem razredu SpearOverseeker in ima enak ˇzivljenjski cikel kot kontroler stanja. Njegova glavna in edina naloga je obdrˇzati nadzor nad instanciranimi sulicami. Ko igralec igro zaˇcne, ima pred seboj ˇze instancirano sulico. Po izvedenem metu sulica ostane tam, kjer je pristala – v tarˇci ali na tleh. Igralec nato na kontrolerju klikne gumb, ki sproˇzi instanciranje nove sulice, katera se pojavi v njegovi bliˇzini – na predefinirani zaˇcetni lokaciji, ki je odvisna od igralˇceve dominantne roke. Za instanciranje nove sulice poskrbi prav ta kontroler.
Programski razred ima spremenljivko KEEP SPEARS, ki mu doloˇci, koliko sulic naj obdrˇzi v sceni. Ideja je namreˇc takˇsna, da sulice po metu ostanejo zapiˇcene v tarˇci, ob kliku na gumb pa se instancira nova. Pri tem nas je skrbelo, da bo ob velikem ˇstevilu sulic v tarˇci vidljivost tarˇce in njenega srediˇsˇca bistveno poslabˇsana. Po pogovoru smo priˇsli do zakljuˇcka, da bomo ta problem reˇsili s konfigurabilno spremenljivko, ki bo doloˇcila, koliko sulic naj bo najveˇc hkrati v sceni.
Instanciranje nove sulice poteka po sledeˇcem postopku:
1. Kontroler za procesiranje uporabniˇskega vnosa zazna dogodek akcije za instanciranje nove sulice in o tem obvesti kontroler za nadzor stanja.
2. Kontroler za nadzor stanja preveri, ali je dovoljeno instanciranje nove sulice (Ali je stanje igre v zakljuˇcku? Ali je bilo izvedeno najveˇcje dovoljeno ˇstevilo metov?).
3. ˇCe je instanciranje dovoljeno, kontroler stanja naroˇci razredu SpearO- verseeker, naj instancira novo sulico.
4. SpearOverseeker trenutno sulico (ki je v tem trenutku ali v tarˇci ali pa na tleh) doda v polje predhodno instanciranih sulic.
5. SpearOverseeker trenutni sulici odstrani sledeˇce komponente:
• XR Grab Interactable, saj s to sulico veˇc ne bodo mogoˇce interak- cije;
• Kontoler SpearController, ki bo opisan kmalu;
• BoxCollider, saj ta sulica veˇc ne potrebuje zaznavanja trkov;
• AudioSource, saj ta sulica veˇc ne bo predvajala zvokov (zvok meta, zadetka ali instanciranja – sulica ob instanciranju predvaja prije- ten zelo kratek zvok, ki igralca obvesti, da se je nekaj zgodilo);
6. SpearOverseeker preveri, ˇce je trenutno ˇstevilo sulic v sceni enako KEEP SPEARS. ˇCe je, odstrani najstarejˇso obstojeˇco sulico.
7. SpearOverseeker instancira novo sulico in si jo shrani kot trenutno.
5.5.2 Kontroler za nadzor posamezne sulice
Je kontroler, ki je implementiran v razredu SpearController. Vsak Game- Object sulice ima ob instanciranju na sebi pripeto to komponento. Njen ˇzivljenjski cikel poteka od instanciranja sulice do trenutka, ko ˇzeli uporabnik instancirati novo (naslednjo) sulico, kar lahko naredi ˇsele po izvedenem metu trenutno aktivne sulice.
Ta kontroler implementira obnaˇsanje posamezne sulice. Njegove najpo- membnejˇse naloge so:
• Implementacija indikatorja za prijem sulice
GameObject sulice ima na sebi komponento XR Grab Interactable.
To sulici doda podporo za XR interakcije (opisano v section 5.1). Ko se uporabnik z VR rokami dotakne sulice (stanje Hover), se sproˇzi metoda razreda SpearController OnHandHoverEnter. Izvede se sledeˇci postopek:
Diplomska naloga 45 – Preveri, kako je ime Interactorja, ki se je dotaknil sulice. Ugotovi,
ali je to desna ali leva roka.
– Ce se uporabnik sulice ni dotaknil z dominantno roko, prekliˇˇ ce izvajanje tega postopka.
– Sicer prek vgrajene Unity metode GetComponent pridobi kompo- nento Material in na njej nastavi emisijo rumene barve.
To bo povzroˇcilo, da se sulica zasveti, na podlagi ˇcesar uporabnik zazna, da sulica omogoˇca interakcijo in jo lahko zagrabi. ˇCe uporabnik zapusti stanje Hover, se emisija odstrani.
Slika 5.3: Indikator, da je omogoˇcena interakcija s sulico
Slika 5.4: Uporabnik drˇzi sulico v rokah in je pripravljen na met. Sulica je v stanju Select.
Diplomska naloga 47
• Nadzor nad dominantno roko igralca
Uporabnik lahko prek klika na gumb spremeni dominantno roko. Potek spremembe dominantne roke je takˇsen:
– Kontroler za procesiranje uporabniˇskega vnosa zazna klik na gumb.
– Kontroler za procesiranje uporabniˇskega vnosa preveri, ali je klik izvedla trenutno dominantna roka. Namreˇc, ˇce je trenutna domi- nantna roka npr. desna in uporabnik klikne gumb za spremembo dominantne roke na levem kontrolerju, to ni veljavna operacija.
Operacije so dovoljene samo na trenutno dominantni roki – samo ta roka lahko sulico zagrabi, se je dotakne (preide v stanje Hover) in sproˇzi zamenjavo dominantne roke. Torej, ˇce imamo trenutno dominantno roko npr. desno in jo ˇzelimo zamenjati z levo, moramo gumb za menjavo dominantne roke klikniti na desnem kontrolerju.
Ce kontroler za procesiranje uporabniˇskega vnosa ugotovi, da jeˇ operacija veljavna, o tem obvesti StateController.
– Kontroler StateController spremeni trenutno dominantno roko, prilagodi grafiˇcni uporabniˇski vmesnik (ki bo opisan kasneje v delu) in sporoˇci trenutni sulici, naj zamenja dominantno roko.
– Kontroler SpearController na trenutno aktivni sulici premakne po- zicijo levo od igralca, saj jo bo zagrabil z levo roko. Vsa bodoˇca instanciranja sulice bodo sulico postavila na enako pozicijo levo od igralca, razen ˇce pride zopet do menjave. Po privzetih nastavitvah je dominantna roka desna.
Slika 5.5: Pozicija sulice glede na dominantno roko
• Zaznavanje trkov
Zaznavanje trkov (Collision detection) je del funkcionalnosti Unity- jeve implementacije fizike. ˇCe ˇzelimo, da zaznavanje trkov med dvema objektoma deluje, mora imeti vsaj eden od teh objektov na sebi kom- ponento Rigidbody, oba pa morata imeti na sebi eno izmed mnoˇzice Collider komponent.
Diplomska naloga 49 Collider komponente na GameObjectu doloˇcijo meje, znotraj katerih bo trk z drugim objektom zaznan. Unity ponuja veˇc raznih Collider komponent:
– Collider v obliki ˇskatle (Box Collider);
– Collider v obliki kapsule (Capsule Collider);
– Collider v obliki poljubnega 3D modela (Mesh Collider);
– Collider v obliki kroga (Sphere Collider);
– Collider v obliki kolesa (Wheel Collider), ki je zasnovan predvsem za uporabo na kolesih avtomobilov in ima za to tudi implementi- rano fiziko;
– Collider v obliki poljubnega terena.
Unity ob zaznavi trka sproˇzi metodo OnCollisionEnter, ki je imple- mentirana v kontrolerju suliceSpearController. Metoda se odzove ob zaznavi trka sulice s katerim koli drugim Colliderjem. Kot argument prejme podatke o trku, kjer lahko vidi, s kom je trˇcila in kateri Collider je priˇsel do trka. Na sulici imamo dve Box Collider komponenti – eno na kovinski ˇspici in eno na palici. Razlog za to je:
– Metoda ob sproˇzitvi v primeru zadetka tarˇce preveri, kateri Colli- der je zadel tarˇco. ˇCe je to Collider na kovinski ˇspici, metoda ta trk obravnava kot veljaven zadetek.
– Ce je tarˇˇ co zadel Collider palice, to pomeni, da je bila sulica ob trku obrnjena tako, da se ni mogla zapiˇciti v tarˇco. V tem pri- meru metoda ne obravnava trka kot veljaven met in ne izraˇcuna doseˇzenih toˇck, a ˇse vedno ˇzelimo, da se sulica od tarˇce odbije, kot bi se tudi v resniˇcnem ˇzivljenju – za to pa potrebujem Collider, sicer bi sulica ˇsla skozi tarˇco.
Slika 5.6: Colliderji v obliki ˇskatle na sulici – obmoˇcja znotraj zelenih kva- dratov.
• Met sulice
Kot smo ˇze omenili ima GameObject sulice na sebi komponento XR Grab Interactable. Ta komponenta omogoˇca nadzor nad VR interak- cijo z GameObjectom, na katerem je pripeta. Med drugim omogoˇca tudi moˇznost “throw on detach”, ki ob spustu sulice (izhod iz stanja Select) na njo doda silo, enako pospeˇsku kontrolerja v trenutku, ko je bila sulica spuˇsˇcena – torej, ˇce uporabnik s kontrolerjem izvede met in spusti sulico, bo pospeˇsek tega meta dodan na sulico znotraj igre.
Komponenta XR Grab Interactable nam ob tem omogoˇca ˇse dodatne moˇznosti, kot so npr:
– skliranje hitrosti meta;
– skliranje kotne hitrosti meta;
– ob metu prisilno vklopi gravitacijo na vrˇzenem objektu in – zglajevanje hitrosti meta.
Diplomska naloga 51 Poleg tega ponuja ˇse sproˇzitev metod ob dogodkih interakcije:
– ob vhodu v stanje Hover;
– ob izhodu iz stanja Hover;
– ob vhodu v stanje Select;
– ob izhodu iz stanja Select;
– ob vhodu v stanje Activate;
– ob izhodu iz stanja Activate.
Slika 5.7: Lastnosti, ki smo jih nastavili na komponenti XR Grab Interactable (ki je pripeta na GameObject sulice)
Postopek meta je implementiran tako:
1. Ob spustu sulice kontroler SpearController vklopi zaznavanje trkov (ko uporabnik sulico drˇzi v rokah ne ˇzelimo zaznavati trkov
z npr. terenom, saj bi v tem primeru ob trku kontroler mislil, da je bil met izveden).
2. KontrolerSpearControllerprek komponente AudioSource pred- vaja zvok meta sulice s pomoˇcjo metodePlayOneShot(opisano v section 4.11).
3. Ko pogon zazna trk, sproˇzi metodo OnCollisionEnter, ki je im- plementirana v razredu SpearController. V tej metodi kontro- ler:
– Preveri, ali je bil zaznan trk s tarˇco ali terenom, v naspro- tnem primeru (npr. trk z rokami uporabnika) ne naredi niˇc in prekliˇce izvajanje metode.
– Izklopi nadaljnje trke (sulica lahko npr. prileti v tarˇco in nato pade na tla – to je ˇse vedno bil zadetek, kontroler pa bi lahko ob trku s tlemi sklepal, da je bila tarˇca zgreˇsena).
– Prebere lokacijo prve toˇcke v trku (tam, kjer sta se meji Col- liderjev prviˇc dotaknili).
– Preveri, ali je trk sproˇzil Collider na konici (in ne na palici) sulice in ali je zadel Collider na tarˇci (in ne na stojalu tarˇce).
∗ Ce to drˇˇ zi, kontroler met obravnava kot zadetek.
∗ Sicer met ni obravnavan kot zadetek, saj je ali zadel teren (torej zgreˇsil tarˇco), ali pa zadel tarˇco bodisi v stojalo bodisi v dejansko tarˇco, ampak s palico – torej tarˇce ni zadela konica.
Ce je kontroler ugotovil, da je izveden met uspeˇsno zadel tarˇˇ co, naredi slednje:
1. Kot starˇsa svojega GameObjecta nastavi tarˇco. To naredi z na- menom, da se bo ob premikanju tarˇce premikala tudi sulica, na kateri je kontroler pripet. Veˇc o premikanju tarˇce kasneje.
Diplomska naloga 53 2. Prek komponente AudioSource predvaja zvok zadetka tarˇce (zvok
nekega projektila, ki zadene leseno ploˇsˇco).
3. Izraˇcuna, koliko toˇck je zadetek vreden:
– V dvodimenzinalnem okolju (osz zanemari) izraˇcuna razdaljo med srediˇsˇcem Colliderja tarˇce in toˇcko na robu Colliderja tarˇce (torej polmer kroga). Recimo, da je to spremenljivka B.
– Prav tako v dvodimenzionalnem okolju izraˇcuna razdaljo med srediˇsˇcem Colliderja in toˇcko zadetka. Recimo, da je to spre- menljivka A.
– Izraˇcuna razmerje med A in B. Veˇcje, kot je razmerje med tema dvema spremenljivkama, bliˇzje je zadetek srediˇsˇcu tarˇce.
– Ko dobi razmerje (ki je vedno med 0 in 1, saj razdalja od srediˇsˇca tarˇce do toˇcke zadetka ne bo nikoli veˇcja kot od srediˇsˇca tarˇce do roba tarˇce – v tem primeru do zadetka sploh ni priˇslo), ga pomnoˇzi s 100, da bi dobil ˇstevilo med 0 in 100.
Recimo, da je to spremenljivka C.
– Od najveˇcjega moˇznega ˇstevila toˇck, ki ga lahko posame- zen met doseˇze (kar je 100), odˇsteje C. Namreˇc, ˇce je C npr. 10 toˇck, to pomeni, da je sulica zadela tarˇco na razdalji 10 % najveˇcje moˇzne razdalje, torej je bil zadetek zelo blizu srediˇsˇcu. V tem primeru uporabnik mora dobiti 90 toˇck in ne 10. V nasprotnem primeru, ˇce je C npr. 90 toˇck, to pomeni, da je tarˇco zadel na oddaljenosti, ki je enaka 90 % najveˇcje moˇzne oddaljenosti od srediˇsˇca do roba tarˇce – ta met ni bil blizu srediˇsˇca. Uporabnik v tem primeru ne sme dobiti 90 toˇck, ampak 10.
tocke= 100−(AB ×100)
– Kontroler ˇstevilo doseˇzenih toˇck zaokroˇzi navzgor na najbliˇzje ˇstevilo, ki je deljivo s 5.
– Kontroler o zadetku obvesti kontroler tarˇce TargetController, ki se ustrezno odzove (kar bo opisano kasneje v delu). To izvede tako, da na njem pokliˇce javno metodo InsertScore, ki kot argument sprejme ˇstevilo doseˇzenih toˇck.
– Kontroler o zadetku obvesti kontroler stanja StateController, ki:
∗ poveˇca ˇstevilo izvedenih metov;
∗ poveˇca ˇstevilo doseˇzenih toˇck;
∗ naroˇci kontrolerju za upravljanje grafiˇcnega uporabniˇskega vmesnika, naj posodobi podatke, ki jih prikazuje uporab- niku.
Slika 5.8: Zadetek tarˇce
Diplomska naloga 55 Ce je kontroler ugotovil, da met ni zadel tarˇˇ ce:
1. Izraˇcuna, ali je bila oddaljenost od toˇcke trka s terenom (ali stojali tarˇce) in pozicije igralca veˇcja od 3m.
2. ˇCe to ne drˇzi, se met ne ˇsteje kot veljaven met, saj to pomeni, da je lahko uporabniku sulica ponesreˇci padla ali pa jo je spustil preveˇc ˇsibko, saj ni ˇse dobro poznal kontrol igre. V tem primeru se ne zgodi niˇc, sulica pa ostane na tleh. Uporabnik nato klikne gumb, kateri instancira novo sulico.
To je v resnici dokaj pogost primer. V poskusni skupini smo na- mreˇc opazili, da je bil prvi met navadno zelo ˇsibek, saj ˇse niso poznali kontrol in obnaˇsanja igre, skrbelo pa jih tudi, da jim bo kontroler padel iz roke ali da bodo poˇskodovali opremo okrog sebe.
To ˇse posebej velja, ˇce igralec ˇse nikoli ni poskusil nobene VR izkuˇsnje.
3. ˇCe to drˇzi, kontroler pokliˇce enako metodoInsertScore razreda TargetController, kot argument pa ji poda ˇstevilo 0. Poleg tega obvesti tudi kontroler stanja StateController, da je bil izveden met, ki je zgreˇsil tarˇco.
5.6 Kontroler tarˇ ce
Ta kontroler je odgovoren za nadzor obnaˇsanja tarˇce, predvsem za dinamiˇcno prilagajanje pozicije tarˇce. Ideja je namreˇc takˇsna, da se po doloˇcenem ˇstevilu metov preveri vsota doseˇzenih toˇck v prejˇsnjih metih in ˇce je ta vsota veˇcja od nekega doloˇcenega ˇstevila, se tarˇca premakne naprej in je tedaj dlje od igralca, kar pomeni, da bodo naslednji meti veˇcji izziv. V nasprotnem primeru, ˇce je ta vsota manjˇsa od tega ˇstevila, to pomeni, da igralcu ne gre najbolje – takrat se mu tarˇca pribliˇza z namenom, da bodo naslednji meti laˇzji. Implementacija je takˇsna:
1. Kontroler ima spremenljivkoTHROW CYCLES, ki mu pove, po koliko me-
tih naj preveri vsoto doseˇzenih toˇck v prejˇsnjih THROW CYCLES metih.
Po privzetih nastavitvah je ta spremenljivka enaka 3, kar pomeni, da bo kontroler po tretjem metu preveril vsoto doseˇzenih toˇck pri prvem, drugem in tretjem metu. Naslednjiˇc bo to ponovil po ˇsestem metu, ko bo izraˇcunal vsoto toˇck za ˇcetrti, peti in ˇsesti met.
vsotaM etov=
T M
X
n=T M−T HROW CY CLE+1
dosezeneT ockeP riM etih[n]
, kjer jeT Mˇstevec nazadnje izvedenega meta. T M se po vsakem metu poveˇca, za kar skrbi kontroler StateController.
2. Po izraˇcunani vsoti doseˇzenih toˇck kontroler preveri spremenljivkoPOINTS THRESHOLD.
Ta spremenljivka predstavlja prej omenjeno ˇstevilo, ki doloˇca mejo za premik tarˇce bliˇzje ali dlje od igralca. Pri tem je pomembna ˇse ena spremenljivka, ki se imenuje POINTS THRESHOLD WINDOW. Ta spremen- ljivka obstaja z namenom, da ustvari zaprt interval, znotraj katerega se tarˇca ne premakne.
Ce ima spremenljivkaˇ POINTS THRESHOLD vrednost npr. 100, bi ob dosegu 99 toˇck tarˇca priˇsla bliˇzje k igralcu, ob dosegu 101. toˇcke pa bi se premaknila dlje, kar nam ni vˇseˇc. Natanˇcneje moti to, da obstaja le eno ˇstevilo, ki odloˇca o premikanju tarˇce in po naˇsem mnenju bi bilo bolje, ˇce bi bil to interval. Tako bi lahko uredili, da se ob dosegu npr.
95 toˇck ali 107 toˇck tarˇca ne premakne, saj sta obe ˇstevili zelo blizu meji.
Po privzetih nastavitvah ima POINTS THRESHOLD vrednost 150, POINTS THRESHOLD WINDOW pa 25, kar ustvari interval [125,175]. To pomeni, da:
• ˇce je vsota toˇck v prejˇsnjih THROW CYCLESmetih npr. 120 toˇck, se tarˇca premakne bliˇzje k igralcu;
Diplomska naloga 57
• ˇce je vsota toˇck v prejˇsnjih THROW CYCLES metih npr. 157 toˇck, kar je znotraj ustvarjenega intervala, se tarˇca ne premakne;
• ˇce je vsota toˇck v prejˇsnjih THROW CYCLESmetih npr. 181 toˇck, se tarˇca premakne dlje od igralca;
3. Ko je kontroler ugotovil, kaj mora narediti s pozicijo tarˇce, pride v poˇstev spremenljivkaTARGET LOCATION STEP. Ta spremenljivka doloˇci, za koliko mnaj se tarˇca premakne, ˇce se mora premakniti. Vrednost te spremenljivke velja za premik tarˇce v obe smeri. Po podrobnem testiranju z veˇc razliˇcnimi vrednostmi smo se odloˇcili, da bomo nastavili privzeto vrednost na ˇstevilo 2,5.
Slika 5.9: Primerjava pozicije tarˇce na zaˇcetku igre in po veˇc uspeˇsnih metih
5.7 Zaslon, ki prikazuje let sulice
V prejˇsnjem poglavju smo opisali dinamiˇcno premikanje tarˇce. ˇCe je igralec zelo dober v igri, se lahko zgodi, da bo tarˇca od njega v nekem trenutku zelo oddaljena, mogoˇce celo toliko oddaljena, da sulica po doloˇceni preleteni razdalji skoraj ne bo veˇc vidna. V ta namen smo implementirali zaslon, ki prikazuje let sulice. Zaslon je navdihnjen po tistemu, ki ga lahko vidimo na tekmovanjih v smuˇcarskih skokih. Ko je skakalec visoko v zraku, ga je zelo teˇzko videti, kar velja ˇse posebej za gledalce, ki so od skakalnice bolj oddaljeni. Gledalci imajo zato na voljo manjˇse zaslone, na katerih lahko spremljajo dogajanje.
Prikaz in skrivanje zaslona nadzira kontroler za tarˇco TargetController.
Ob vsakem premiku tarˇce preveri, ali je tarˇca dovolj oddaljena, da bi moral pokazati zaslon. To naredi tako:
• Kontroler shranjuje premike tarˇce s pomoˇcjo indeksa oddaljenosti tarˇce, ki je hranjen v spremenljivki razreda TargetController. Tarˇca ima ob zaˇcetku igre indeks 0, saj je to njena prvotna pozicija. ˇCe se tarˇca premakne dlje od igralca, znaˇsa indeks 1. Za vsak premik dlje se tarˇci poveˇca indeks za 1, za vsak premik bliˇzje pa se pomanjˇsa za 1.
• Preden kontroler izvede premik, vedno preveri indeks oddaljenosti. ˇCe je tarˇca na indeksu 0 in mora kontroler premakniti tarˇco bliˇzje do igralca, tega ne bo naredil, sicer bi lahko igralec npr. vseh 10 metov zgreˇsil in priˇsel do stanja, ko bi se tarˇca tolikokrat premaknila bliˇzje, da bi bila za samim igralcem, kar se seveda ne sme zgoditi.
• Spremenljivka CAMERA FROM INDEX hrani ˇstevilo, ki pove indeks odda- ljenosti, od katerega naprej je zaslon viden.
V glavni sceni imamo GameObject z imenom ThrowScreen, ki vsebuje zaslon za prikazovanje leta sulice. Privzeto je ta objekt izklopljen. Kontroler TargetController ima referenco nanj in ga lahko s pomoˇcjo metodeSetActive vklopi ali izklopi.
Diplomska naloga 59 Zaslon za prikazovanje meta sulice je implementiran tako:
• Vsaka instancirana sulica ima na zaˇcetku palice kamero, ki je usmerjena proti konici sulice
• Vsaka instancirana sulica ob instanciranju preveri, ali je v sceni tre- nutno vklopljen zaslon. ˇCe je, sproˇzi metodo BindToSpearCamera, ki je implementirana na kontrolerju za zaslon ThrowScreenController. Ta metoda kot argument sprejme komponento kamere, kateri nastavi pa- rameterrenderTexture.
• GameObject zaslona ima komponento Canvas (platno), ki prikazuje eno samo sliko – komponenta RawImage.
• Komponenta RawImage ima vhodni parameter, ki sprejme teksturo.
Naredili smo teksturo tipa RenderTexture, ki je tekstura, katero Unity posodablja med delovanjem igre.
• Platno na zaslonu torej prikazuje teksturo. Vsaka na novo instancirana sulica poveˇze svojo kamero na RenderTexture – tako doseˇzemo, da se vidno polje kamere izrisuje v teksturo, ki jo generira pogon med delovanjem igre.
