Metodbeskrivning

Algoritmerna testades med ramverket som Serpa & Rodrigues (2019b) presenterade. Beslutet togs att använda deras ramverk då det var ett gediget och flexibelt testramverk för bredkollisionsdetektion. Det erbjöd även tre testscenarier, totalt trettio inbyggda algoritmer (se Figur 12), samt att ramverket mätte det som önskades mätas i denna undersökning. Det bör dock noteras att deras ramverk var relativt nytt. Förutom i artikeln där Serpa & Rodrigues (2019b) presenterade ramverket, så hade ingen annan använt det än. Båda skribenterna är dock väl citerade och det fanns ingen anledning att misstro ramverket de presenterade. Men för att försäkra sig om ramverkets validitet utfördes dock ett mindre test. En egen utloggning av tiden det tar för algoritmerna att detektera alla kollisioner gjordes och jämfördes med resultatet Broadmark uppmätte.

3.1.1 Prestanda för olika scenarier

För att få en bild av hur bredkollisionsdetektionsalgoritmerna presterade under olika scenarion så kördes testscenarierna flera gånger med varierande antal objekt. Optimalt borde alla möjliga kvantiteter av objekt ha testats men denna studie utfördes under en begränsad tidsperiod, så antalet tester behövde begränsas. För att få en bra representation av algoritmernas förmågor med hänsyn till tiden som fanns så delades testerna upp i tre intervaller: lilla som testade tio till hundra objekt med steglängd fem, mellan som testade tusen till tiotusen med steglängd femhundra, stora som testade hundratusen till tvåhundratusen med steglängd tiotusen. Notera att steglängd syftar till skillnaden mellan objektmängderna för två på varandra följande tester. De tre intervallerna valdes för att undersökningen skulle bli så bred som möjligt utan att ta för lång tid. Att testa bredkollisionsdetektionsalgoritmer med varierande antal objekt för att utvärdera hur algoritmerna skalar gentemot olika mängder objekt är något som är vanligt förekommande.

Metoden användes av Luque m.fl. (2005), Capannini & Larsson (2018) och Serpa & Rodrigues (2019a, 2019b) för att bara nämna några. Att köra alla tre intervaller på ett testscenario definierades som ett set, så att utföra lilla, mellan och stora intervallet på scenen Slumpvandring är att göra ett set på Slumpvandring.

Dock notera att scenariot Gravitation utelämnades från tester med det stora intervallet. Denna undersökning gjordes nämligen på sämre hårdvara jämfört med vad Serpa & Rodrigues (2019b, s. 10) använde. Detta, i kombination med resultatet som Serpa & Rodrigues (2019b, s. 11) presenterade för scenariot Gravitation, gör att det bedömdes ta för lång tid att testa scenariot Gravitation på det stora intervallet.

24

Av samma anledning som scenariot Gravitation utelämnades från testning av det stora intervallet så testades inte alla algoritmer som fanns tillgängliga i Broadmark mot det. De algoritmer som bedömdes prestera för dåligt i mellanintervallet togs bort från testningen av det stora intervallet. Utöver det så ströks även algoritmer som presterade allt för dåligt under testningen med det stora intervallet vilket definierades som att de i genomsnitt tog över 1,5 sekunder att utföra en genomsökning.

3.1.2 Prestanda beroende på förhållandet mellan statiska och dynamiska objekt

Hur bredkollisionsdetektionsalgoritmerna hanterar olika distributioner mellan dynamiska och statiska objekt testades. Hur fördelningen mellan dynamiska och statiska objekt påverkar algoritmerna är något som både Luque m.fl. (2005) och Serpa & Rodrigues (2019a, 2019b) testade. De testade dock endast med scenarier där alla objekt släpps och får falla till marken där de till sist blir vilande, d.v.s. statiska. Denna undersökning testade mot DLS:er vilka består av ett stort antal varierade scenarier, dock brukar majoriteten av objekt i dem vara statiska (Serpa & Rodrigues, 2019a s.261). Att endast testa med det enkla scenario som Luque m.fl.

(2005) och Serpa & Rodrigues (2019a, 2019b) gjorde ansågs därför inte vara tillräckligt.

Istället testades alla scenarier med olika andelar statiska objekt. Dock utifrån samma argumentation som den för variation av antalet objekt så begränsades variationer av andelen statiska objekt. För att få ut maximalt med testdata utifrån tidsramen som tilldelats så testades varje set med sex olika andelar statiska objekt: 0 %, 20 %, 40 %, 60 %, 80 % och 100 %. Att testa ett set med alla sex fördelningar av statiska objekt definierades som en omgång.

Notera dock att även här gjordes ett undantag för det stora intervallet. Till följd av antalet tester som utfördes så utelämnades tester med 0% statiska objekt från det stora intervallet.

Det gjordes då det uppskattas att det skulle ta för lång tid att testa dem. Detta antogs däremot inte vara någon större förlust för arbetet då det var inriktat mot datorspelsbranschen, och i scenarierna som spelbranschen använder kollisionsdetektionsalgoritmerna för är oftast majoriteten av objekten statiska (Serpa & Rodrigues, 2019a s.261). Testningen med 0%

statiska objekt behölls dock för lilla intervallet och mellanintervallet för att få en större bredd på hur algoritmerna presterar, och eftersom det bedöms att det kunde utföras inom tidsramen för projektet.

3.1.3 Hur slumpens inverkan ska minimeras

Simuleringsgeneratorn spelar upp simuleringarna och sparar ner alla objektens AABB:er för varje bild i exekveringen, och Broadmark använder detta för att testa bredkollisions-detektionsalgoritmerna. Testningen gjordes genom att Broadmark tog information som sparades ner för varje bild och körde bredkollisionsdetektionsalgoritmerna över dem och kontrollerade hur lång tid det tog för algoritmen att hitta alla överlappningar. Eftersom testscenarierna utförs exakt likadant varje gång Broadmark använder dem, ansågs det därför inte vara nödvändigt att testa varje simulering mer än en gång, vilket låste upp tid för att testa flera instanser av varje simulering. Att endast köra varje simulering en gång är även något som Serpa & Rodrigues (2019b) gjorde.

Även om simuleringarna exekverar på exakt samma sätt varje gång de körs så innehåller fortfarande skapandet av dem slumpbaserade variabler som objektens startposition, deras utgångshastighet samt vilka objekt som är statiska. Slumpningen av dessa parametrar gav ett mer verklighetsliknande testscenario, eftersom det i verkligheten inte går att garantera en

25

optimal situation. Det gjorde dock att en situation som missgynnar en specifik algoritm skulle kunnat uppstå. För att minimera risken att en algoritm stjälps av slumpen testades flera instanser av varje simulering utifrån vilket ett medelvärde beräknades. Att utvärdera en algoritm med medelvärdet från flertalet körningar av en simulering är vanligt förekommande.

Det användes exempelvis av Schmidtke & Erleben (2018) och Weller, Debowski & Zachmann (2017) när de utvärderade sina algoritmer. Just för detta arbete duplicerades varje scen mer specifikt tjugo gånger. Det beslutades göras tjugo dubbletter för att eliminera slumpens inverkan så mycket som möjligt. Att inte fler tester gjordes beror på arbetets tidsbegränsning.

3.1.4 Objekt som används i testningen

Broadmark hade ursprungligen stöd för tre typer av objekt: kuber, sfärer och olikformade rektanglar. När Serpa & Rodrigues (2019b) utförde sina tester använde de endast kuber. Serpa

& Rodrigues (2019b, s.9) motiverade detta med att de sedan tidigare kunde påvisa att testning med olikformade rektanglar och sfärer påverkar alla algoritmerna likartat. Det skulle därmed inte tillfört några nya insikter om de testades. Utifrån detta, och den begränsade tiden som fanns till förfogande, så begränsades undersökningen till att endast använda kuber.

3.1.5 Testernas längd

Då det utfördes ett stort antal tester i denna undersökning var det av stor vikt att testerna inte var längre än nödvändigt. Av de tre scenarierna har Fritt fall egenskapen att den stabiliserar sig när alla objekt har blivit vilande på marken. Testning visade att det tar runt 300 bilduppdateringar för detta stabiliserade läge att infinna sig. Utifrån detta drogs slutsatsen att 300 bilduppdateringar var det minsta antalet uppdateringar som kunde användas. Om ett mindre antal användes fanns risken att spikar i data skulle fått allt för stor effekt på resultatet.

Däremot om ett mycket större antal användes fanns risken att det inte skulle funnits tid att utföra alla test inom den givna tidsramen. Med 300 bilduppdateringar som absolut minimum för att garantera att Fritt fall hinner stabilisera sig beslutades att alla tester skulle köras i 400 bilduppdateringar.

3.1.6 Hur resultatet skulle presenteras

Under testningen av algoritmerna sparades exekveringstiden, mätt i sekunder, det tog för algoritmerna att lokalisera alla potentiella kollisioner för varje enskild bilduppdatering. Detta var samma prestandamått som Zhang & Liu (2015) och Serpa & Rodrigues (2019a, 2019b) använde sig av. Denna data användes för att utvärdera hur en algoritm presterade överlag samt hur dess prestanda förändras beroende på antal objekt och andelen statiska objekt som testades.

Data som samlades in under testningen redovisades med linjediagram vilket gav en bra bild av hur algoritmernas prestanda förändras i förhållande till antalet objekt samt andelen statiska objekt i scenarierna. Resultaten presenterades även med ett violindiagram vilket gav en nyanserad bild av hur stabila algoritmerna var i sina prestanda. Detta ansågs vara extra intressant för spelutvecklare eftersom om en algoritm har stor variation i hur den presterar skulle den vara ett dåligt alternativ. Om prestanda ofta faller kommer den nämligen ha negativ inverkan på interaktivitet.

3.1.7 Metoddiskussion

Metoden som valdes för detta arbete var inte perfekt då den inte testade mot exakta datorspel-scenarier. Metoden använde snarare mer abstrakta generaliseringar av de situationer som kan

26

uppstå i datorspel. Detta var en svaghet då testningen blev mindre specifik för spelmiljöer, dock var det till fördel då en större andel av spelgenrer potentiellt kan använda sig av informationen från testerna. Mer generella tester gör nämligen, som namnet antyder, testdata mer generell. Exempelvis skulle scenariot Gravitation kunna representera hundratals datorstyrda karaktärer som kolliderar med varandra i ett strategispel eller ett massivt antal objekt som flyttas omkring i ett fysikpusselspel. Största svagheten för nuvarande metod var dock att det inte gick att testa övriga användningsområden som bredkollisionsdetektionsalgoritmer används för i dataspel. Dock fanns det inte tillräckligt med tid för att implementera det som en del i detta arbete.

Ett alternativ till den metod som presenteras här skulle vara att för varje algoritm utföra en algoritmanalys, vilken går ut på att utvärdera algoritmerna och komma fram till dess tidskomplexitet (sämsta exekveringstid). Det positiva med det är att tidskomplexitet används just för att jämföra algoritmer, vilket samstämmer med ett av målen för arbetet. Däremot säger tidskomplexitet ingenting om hur algoritmen presterar i ett specifikt scenario. Det är även värt att notera att majoriteten av undersökningar som gjorts på bredkollisionsdetektion använder sig av testning snarare än algoritmanalys, som Capannini & Larsson (2018), Wang m.fl. (2018a), Serpa & Rodrigues (2019a), Li m.fl. (2018) och Avril m.fl. (2014) gör, för att bara nämna ett fåtal. Även de som använde sig av algoritmanalys, som Weller m.fl. (2017, s.136), utför ändå oftast experimentet för att konkretisera algoritmens förmågor.

Arbetet var tänkt att vara riktat mot spelbranschen, så ett relevant alternativt sätt som arbetet skulle kunna ha gjorts på vore genom att implementera faktiska spelscenarier eller testa gentemot redan existerande spel. Detta skulle gett mer precisa data om specifika spelscenarier vilket skulle avgränsat andelen personer som skulle ha nytta av studien. Ett exempel vore om testet utformades för att simulera ett första-persons-skjutar-spel, ur vilket data som skulle vara av stort intresse för endast utvecklare av just denna genre skulle fåtts. Problemet med avgränsad nytta skulle kunna ha motverkats genom att utveckla simuleringar av flera olika genrer. Datorspel använder inte endast bredkollisionsdetektionsalgoritmerna för kollisionsdetektion utan även för att snabba på andra arbetsuppgifter, och Broadmark kunde inte testa hur algoritmerna presterade för dessa arbeten. Optimalt hade därmed varit att antingen expandera funktionalitet för Broadmark så att den kunde testa denna typ av funktionalitet, eller att utveckla ett eget testramverk som inriktar sig specifikt på att testa detektionsalgoritmerna gentemot datorspel. Största nackdelen med att göra något av detta hade varit att det skulle tagit tid att utveckla både testsimuleringar av spelen och nya testverktyg, vilket var något som det helt enkelt inte fanns tid för. Testning gentemot genuina datorspelscenarier som skulle spelas av riktiga spelare hade också introducerat en stor slumpfaktor i testerna, i form av den mänskliga faktorn, så att en mycket större kvantitet av data skulle behövt samlas in. Möjligen skulle detta kunnat underlättas genom att testa med hjälp av artificiell intelligens, dock skulle även detta alternativ krävt mycket med tid för

27

 Simuleringsgeneratorns uppsättningsapplikation vidareutvecklades så det gick att ställa in andelen statiska objekt i scenariona samt att det automatisk gick att skapa testserier.

 Hjälpskriptet run modifierades för att ta hänsyn till DLS:ernas egenskaper samt för att automatisera testningen som utfördes.

28

4 Implementation

Implementation av testramverket delades upp i fyra delar. Första delen var uppsättningen och valideringen av Broadmark. Den andra delen var anpassningen av simuleringsgeneratorn för att den skulle kunna skapa scenarier med statiska objekt i samt för att effektivisera simuleringsgenereringen. Tredje delen bestod av att anpassa hjälpskripten som ramverket använde för att automatisera testningen och visualisera resultaten. Fjärde och sista steget var implementationen och integrationen av BVH-SR i Broadmark.