XNA3DGameEngine Bilag BILAG. Side 1/79

Transkript

1 BILAG Side 1/79

2 Table of Contents 1 Projektplan / dagbog XNA XNA Game Studio Express XNA Game Studio Proffesional Lagene i XNA Platformen Core framework Extended framework Applikations modellen Content pipeline en Games Overordnet design Test resultater og udsnit af kode Kald uden at gemme Kald uden at gemme Ekstra test Kald hvor data gemmes Besked system Collision Detection Konstruktion Test og Resultater Static Dynamic Konklusion Splitting - Verifikation Simple-Render BSP-Tree-Render Oct-Tree-Render Rendering Lavt antal Polygoner OctTreeRender BSPTreeRender PortalRender PortalRender og OctTreeRender PortalRender og BSPTreeRender Højt antal Polygoner SimpleRender OctTreeRender BSPTreeRender PortalRender PortalRender og OctTreeRender PortalRender og BSPTreeRender MultiThreading Enkelt Trådet design Engine-tråd og Render-tråd To trådet Collision ingen Rendering...61 Side 2/79

3 7.4 To trådet Collision m. to trådet Portal ingen Rendering M. to tråde pr. SceneNode ingen Rendering To tråde pr. SceneNode, forbederet ingen Rendering To tråde pr. SceneNode, hvor de ikke køre ingen Rendering En EngineX tråd, en RenderX tråd To tråde for Collsion og to for Portal To tråde pr. SceneNode To tråde pr. SceneNode, forbederet To tråde pr. SceneNode, hvor de ikke køre DGameEngine-testmiljøets klasser Litteraturliste Side 3/79

4 1 Projektplan / dagbog sep 26 ID okt 26 nov 26 dec 26 jan 27 feb 27 Task Name Finde informationer 2 Teori 3 Rapport skrivning 4 Overordnet design 5 XNA - Teori 6 XNA Praktisk viden 7 Kode Opstart og små tests 8 Kode Enginen 9 Kode Loaders (.3DS og.x) Kode Debug Renders 11 Kode Besked System 12 Modelere Modeller i 3DS Max 13 Kode Simple Renderen 14 BSP-Trees Renderes 15 OCT-Trees Renderes 16 Portal Renderen 17 AI Modul 18 Redesign af Portal 19 Kombination af Renderes 2 Kollisions modul 21 Debug render udvidelse 22 Trådning 23 Uddybende tests Side 4/79

5 2 XNA XNA frameworket er udviklet af Microsoft, med henblik på at få et helt managed udviklingsmiljø, der samtidig understøtter mulighed for udvikling af spil til både PC og Xbox36 samtidigt. Det har efterhånden taget Microsoft et godt stykke tid at udvikle frameworket, siden de første gang talte om XNA til Game Developer Conference i 24[XNA_BLOG]. Men i august 26 kom den første release, en beta1 udgave af XNA Game Studio Express(GSE), som er et udviklingskomponent til Visual C# Express. Senere i 26 kom også en beta2, før Microsoft i december 26 udgav en release candidate 1.. Testmiljøet i dette projekt er bygget på beta1 releasen af XNA GSE. Grunden til dette er, at Beta1 blev udgivet på samme tidspunkt, som vi startede projektet. Hvorfor vi ikke har skifter undervej er fordi, Microsoft har lavet grundlæggende ændringer fra beta1 og til de senere releases, hvilket villet krævet større ændringer af vores test miljø, hvilket så resulterer i, at vores tidligere tests ikke kan sammenlignes med de senere. 2.1 XNA Game Studio Express XNA GSE er den første udgave af XNA, og er den version som vi baserer vores test miljø på. XNA GSE er udviklet med henblik på hobbister, studerende og små spiludviklingsfirmaer. De små spilfirmaer kan bruge GSE til at udvikle PC spil. Hvis de vil udgive spil på XBox36 skal de bruge Game Studio proffesional(gsp). For studerende og hobbyisters vedkommende kan de både udvikle til PC og XBox36, da det her er udviklingen af spil der er målet, og ikke at udgive dem. For at udvikle spil til XBox36 skal man være medlem af XNA Creaters Club [ XNA_VERS], hvilket giver mulighed for at overføre spil til sin Xbox36 gennem XBox Live. Med XNA GSE har man adgang til både XNA frameworket og content pipelinen (dog kun XNA frameworket i Beta1), hvilket er to komponenter som Microsoft udtaler simplificerer spiludvikling [XNA_BLOG]. 2.2 XNA Game Studio Proffesional XNA GSP er en videreudvikling af XNA GSE, som udkommer på et tidspunkt i 27. Denne version af XNA har fokus på store spilfirmaer og vil komme til at indholde de samme features som Side 5/79

6 XNA GSE. Derudover indeholder den også nogle nye værktøjer til at kunne gøre spiludvikling nemmere for større hold af udviklere både grafikere og designere. XNA GSP vil også indeholde mulighed for at udvikle spil til Xbox36, med henblik på udgivelse. Nogle af de ekstra værktøjer, der følger med i denne version, er til at håndtere content-management, som i stigende grad er med til at øge kompleksiteten af spilprojekter. Det er Microsofts hensigt i større grad at lade modlers, designere o.lign. inkludere data direkte i miljøet, for at nedsætte muligheden for at compile spil med gammel eller ubrugbar data. Denne version har vi af naturlige årsager ikke kunnet prøve i praksis, så derfor vil vi fokusere mere på XNA frameworket og hvilke muligheder det har, da det ligger til grund for begge versionerne. 2.3 Lagene i XNA I dette afsnit beskriver vi hvilke lag og komponenter som er med i XNA. Det gør vi for, at vi bedre kan adskille, hvornår vi arbejder med ting, som påvirker begge versioner af XNA Game Studio, og hvornår tingene kan være forskellige fra version til version Platformen Platformen er det nederste lag i XNA hierarkiet, og er den del som selve XNA frameworket er bygget på. Koden der findes her, bygges oven på en del low-level platform specifik api er foruden Direct3D, XACT, Xinput og Xcontent. Disse komponenter og api er er unmanaged, og det er disse ting som Microsoft pakker ind i managed code, og simplificere for brugerene i de højere lag Core framework Core framework et er den nederste del af det samlede framework. Det er her unmanaged kode og platform specifikke kald bliver pakket ind, så det kan bruges som managed code for de højere lag. Adgangen til det nedre lag bliver grupperet, så funktionalitet som grafik, lyd og lignende bliver samlet i hver deres område, og kan dermed præsenteres fornuftigere til det ovenstående lag. Det er også her at Managede DirectX kommer på, for at give de ovenstående lag en managed platform at arbejde på. Microsoft har på dette lag også implementeret et matematik bibliotek, der indgår som en brugbar komponent for de øvre lag. Side 6/79

7 2.3.3 Extended framework Extended framework laget er udviklet for at indkapsle noget af funktionaliteten i core frameworket, og dermed simplifisere det for brugerene af frameworket. Det er her man finder applikationsmodellen og content pipelinen, der kan bruges til at sætte et spilmiljø op relativt hurtigt Applikations modellen Applikationsmodellen er den komponent i XNA der simplificerer spildesignet ved at have nogle prefabrikerede komponenter, som spillets kode kan arve fra. På denne måde kan man blandt andet arve fra en tegne -komponent, der får kaldt nogle predefinerede metoder, der giver mulighed for at eksekvere kode før, imens og efter, der bliver sendt informationer til grafikkortet. Andre komponenter i applikationsmodellen giver mulighed for at implementere funktionsorienterede komponenter, der kan indeholde updatede funktioner, som kaldes før en eventuel renderkomponent Content pipeline en Content pipelinen er en komponent i det extended framework, der håndterer indlæsning/inkludering af data som modeller, texturer, lyde/musik og shader programmer/effekter. Content pipelinen dækker primært unmanaged resourcer, og præsenterer dem for det spil der udvikles på en managed måde. Dette har tidligere været et problem, da kontrollen af disse ressourcer tidligere har været helt unmanaged eller liggende i små wrapper objecter til hver ting, hvilket har givet mange problemer med hvornår ting skal fjernes som ressource. Et eksempel kunne være en model, der skal unloades, skal alle dens texturer og shaders også fjernes?, eller deles de af flere modeller?. Det er dette problem microsoft forsøger at løse med Content pipelinen. Illustration 1:XNA Content Pipeline [XNA_BLOG] På Illustration 1 ses et overblik over Content pipelinen, den viser den samlede processering af data ressourcer, og hvordan data'ene bliver vist ensartet over for brugeren og content manageren. Side 7/79

8 Content pipelinen virker ved at der instantieres en content manager, der bruger content pipelinen til at loade data af typerne, som tidligere er beskrevet ind i system. Ved at bruge content manageren til at holde styr på modeller, texturer og lignendende, kan modellerne endda dele ressourcer såsom texture og shaders i hver content manager. Hvis der er flere modeller i hver deres content manager, der bruger samme texturer vil texturen loades to gange[hargreaves]. Når modellerne ikke skal bruges mere kaldes unload på manageren, og dermed unloades alle de ressourcer, som manageren har loaded [HARGREAVES] Games På Games-laget finder man selve spillogikken, det er her Microsofts mål om simplificering begynder at tage form, da man slipper for at tage sig af mange overvejelser og hardwarenær bekymringer. Man bygger oven på de lag, som tidligere er beskrevet og kan dermed fokusere mere på design og funktionalitet. 3 Overordnet design 3.1 Test resultater og udsnit af kode Kald uden at gemme Data er følgende int 2. 5 int's 3. 5 int's og 5 strings 4. 5 int's, 5 strings og 1 Vector int's, 5 strings og 5 Vector3 Eksempel på kode * Besked kald * public void TestLoopA() private MessageA ma = new MessageA(1); int rounds_tmp = rounds; while (rounds_tmp!= ) rounds_tmp--; _maintimer.reset(); for (int i = ; i < 1; i++) mr.retrivemessage(ma); * Funktions kald * public void TestLoopA() private int i1 = 1; int rounds_tmp = rounds; while (rounds_tmp!= ) rounds_tmp--; _maintimer.reset(); for (int i = ; i < 1; i++) mr.retrivemessage(ia); Side 8/79

9 System.Console.WriteLine("" + _maintimer.getelapsedtime()); // i en anden klasse public void retrivemessage(messagea message) System.Console.WriteLine("" + _maintimer.getelapsedtime()); // i en anden klasse public void retrivemessage(int intvar) FunktionsTest MessageTest Test 1 Test 2 Test 3 Test 4 Test 5 Test 1 Test 2 Test 3 Test 4 Test 5,148,125,187,1393,2627,146,125,147,125,147,125,125,187,1393,265,125,125,125,125,125,125,125,187,1385,2615,125,125,125,125,125,125,125,187,1382,2616,125,125,125,125,125,125,13,187,1383,2633,125,125,125,125,129,125,127,187,1382,2616,125,125,125,125,125,125,125,187,1394,2614,125,125,125,125,126,129,125,187,1397,2618,126,125,125,125,125,125,125,187,1383,2615,125,125,126,125,125,125,125,187,1382,2614,125,125,125,125,125,125,125,187,1382,2652,125,138,125,126,125,125,125,187,1382,2615,125,125,125,126,125,125,138,187,1382,2617,126,125,125,125,125,125,125,187,1382,2623,125,125,125,127,125,125,125,187,1393,2641,126,125,125,125,125,125,125,187,1431,2616,125,125,126,125,125,125,127,187,1383,2624,125,125,125,125,125,125,14,187,1384,2652,125,125,125,125,127,125,125,187,1383,2613,125,125,125,125,126,125,125,187,1382,2629,125,125,125,125,125,126,125,187,1383,2616,125,125,125,125,125,125,125,187,1382,2614,125,125,125,125,125,125,125,187,1383,2616,125,126,125,125,125,125,125,187,1396,2617,125,127,126,126,125,125,125,196,1384,2641,125,125,125,125,125,125,125,192,1383,2637,13,125,126,128,125,125,125,187,1382,2637,126,125,125,125,125,125,125,187,1384,2614,128,125,125,125,125,125,125,187,1382,2638,125,125,125,125,125,125,127,187,1383,2622,125,125,125,125,125,125,125,187,1382,262,125,126,125,125,128,125,125,187,1385,265,125,125,126,125,125,127,125,189,1383,2629,125,125,125,125,125,125,125,187,1382,2652,125,125,135,125,125,125,125,187,1388,2639,125,125,125,125,125,125,125,187,1382,2615,125,125,126,125,125,125,125,187,1382,2618,126,125,125,125,125,125,125,187,1382,2614,125,125,128,125,125,125,125,187,1386,2615,127,125,126,125,125,125,125,187,1384,2618,127,125,125,125,125,125,125,24,1382,2639,125,125,125,125,125 Side 9/79

10 3.1.2 Kald uden at gemme Ekstra test Data er følgende Matrice 2. 1 BoundingSphere 3. 1 Vector Vector3 Eksempel på kode * Besked kald * public void TestLoopA() private MessageA ma = new MessageA(new Matrix(1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f)); while (rounds_tmp!= ) rounds_tmp--; _maintimer.reset(); for (int i = ; i < 1; i++) mr.retrivemessage(ma); System.Console.WriteLine("" + _maintimer.getelapsedtime()); // i en anden klasse public void retrivemessage(messagea message) * Funktions kald * public void TestLoopA() private Matrix mat1 = new Matrix(1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f, 1.f); int rounds_tmp = rounds; while (rounds_tmp!= ) rounds_tmp--; _maintimer.reset(); for (int i = ; i < 1; i++) mr.retrivemessage(mat1); System.Console.WriteLine("" + _maintimer.getelapsedtime()); // i en anden klasse public void retrivemessage(matrix mat) Side 1/79

11 FunktionsTest MessageTest Test 1 Test 2 Test 3 Test 4 Test 1 Test 2 Test 3 Test 4,1877,644,566,197,147,125,148,125,1843,65,56,112,129,125,125,125,1838,638,56,192,125,125,131,125,1839,638,562,196,125,126,125,125,1843,631,56,189,125,128,125,125,1875,592,56,189,125,125,126,125,1837,638,56,189,125,125,125,125,1837,592,56,19,125,125,126,125,1837,592,562,189,125,125,126,129,1837,627,56,189,127,136,125,125,1839,638,56,189,125,129,125,126,1839,631,572,19,125,125,126,125,1954,638,56,189,125,125,126,125,1841,638,56,112,125,125,126,125,1838,62,589,19,129,125,126,125,1847,638,564,189,125,126,129,125,1843,622,562,19,125,125,125,125,1837,638,56,19,125,125,125,125,1838,638,56,1113,125,125,125,125,1837,596,56,189,125,125,125,125,1837,638,56,191,125,125,125,125,1837,619,56,189,127,125,125,125,1847,592,562,189,125,125,125,125,1839,592,56,191,128,129,126,127,1841,61,56,189,125,125,125,125,1845,638,56,191,125,125,125,125,1839,64,56,189,125,125,125,125,1839,592,56,19,128,127,128,125,1839,651,563,189,125,125,127,125,1838,638,56,189,125,126,126,125,1839,592,561,189,125,125,125,125,1839,636,56,19,125,125,126,125,1839,638,56,189,125,125,125,125,1836,592,56,192,165,125,125,125,1839,69,56,189,125,125,126,125,1837,591,56,191,125,125,125,125,1836,641,561,189,125,127,126,126,1837,638,56,189,125,125,125,125,1836,638,56,19,125,125,126,125,1996,649,56,189,129,125,125,125,1837,638,56,191,125,125,125, Kald hvor data gemmes Data er følgende int 2. 5 int's 3. 5 int's og 5 strings 4. 5 int's, 5 strings og 1 Vector int's, 5 strings og 5 Vector3 Eksempel på kode Side 11/79

12 * Besked kald gemme besked * public void TestLoopA() private MessageA ma = new MessageA(1); int rounds_tmp = rounds; while (rounds_tmp!= ) rounds_tmp--; _maintimer.reset(); for (int i = ; i < 1; i++) mr.retrivemessage(ma); System.Console.WriteLine("" + _maintimer.getelapsedtime()); // i en anden klasse MessageA ma; public void retrivemessage(messagea message) ma = message; * Funktions kald gemme variable* public void TestLoopA() private int i1 = 1; int rounds_tmp = rounds; while (rounds_tmp!= ) rounds_tmp--; _maintimer.reset(); for (int i = ; i < 1; i++) mr.retrivemessage(ia); System.Console.WriteLine("" + _maintimer.getelapsedtime()); // i en anden klasse private int testint = ; public void retrivemessage(int i) testint = i; * Besked kald - gemme variable* public void TestLoopA() private MessageA ma = new MessageA(1); int rounds_tmp = rounds; while (rounds_tmp!= ) rounds_tmp--; _maintimer.reset(); for (int i = ; i < 1; i++) mr.retrivemessage(ma); System.Console.WriteLine("" + _maintimer.getelapsedtime()); // i en anden klasse private int testint = ; public void retrivemessage(messagea message) testint = message.testvalue1; Side 12/79

13 FunktionsTest MessageTest_ message gemmes Test 1 Test 2 Test 3 Test 4 Test 5 Test 1 Test 2 Test 3 Test 4 Test 5,29,628,328,4263,6559,1194,499,51,498,498,187,562,3274,4234,6523,779,498,498,498,499,187,56,3244,4232,6555,56,498,498,5,498,187,564,3243,5142,6599,569,498,52,498,498,187,561,326,4232,6522,56,498,498,498,5,187,56,3241,4235,6497,564,498,498,498,498,188,564,3239,4233,6542,562,498,527,499,498,187,56,329,4231,6528,56,59,498,498,498,187,56,3258,5147,6514,661,498,498,499,498,187,563,3242,4234,6622,56,498,499,498,498,187,56,3241,4233,648,56,498,498,498,499,187,623,3242,4234,731,561,498,498,498,498,187,562,3242,4237,6558,56,498,498,498,498,194,575,3239,5353,648,56,499,498,498,498,188,564,3244,4236,6513,563,498,498,51,498,187,56,347,425,6522,56,498,499,498,498,189,56,3242,4233,665,56,498,498,498,499,187,562,3243,4233,6514,56,498,498,498,498,189,56,324,4234,6525,56,498,498,498,498,187,56,3237,4236,6527,562,57,498,498,498,187,589,3236,4288,726,561,498,498,5,498,188,56,3252,4266,661,56,498,514,498,498,187,56,3238,4233,6554,561,498,498,498,498,187,562,3236,4391,6525,56,498,498,531,498,187,56,3249,4235,6522,56,498,499,498,498,192,56,324,4233,655,56,499,498,498,498,187,586,3236,4247,725,56,498,498,498,51,187,56,3239,4234,663,56,498,498,498,498,187,562,3254,4233,6519,561,498,498,498,498,189,562,3237,4234,6556,56,498,498,52,498,187,56,3237,4233,6541,562,498,499,498,498,187,563,3237,4236,6551,56,499,498,498,498,187,562,3236,4231,6493,572,498,498,498,499,191,56,3238,4249,7333,56,498,498,51,498,187,562,3245,4235,6476,56,498,498,498,498,187,562,3249,5173,6496,56,498,498,498,498,187,569,324,4234,6517,564,498,498,499,498,187,56,3237,4238,6574,56,499,498,5,498,187,624,3281,4235,6552,56,498,498,498,51,187,6,3238,4234,651,562,498,498,498,498,187,56,3238,429,6519,56,498,499,498,498 Side 13/79

14 MessageTest_ variabler gemmes Test 1 Test 2 Test 3 Test 4 Test 5,312,698,2387,2923,4538,281,686,2366,2869,4551,28,685,2366,2865,4517,285,711,2366,2864,4518,28,685,2369,2884,4546,28,687,2365,2913,4517,281,685,2367,2881,4566,28,685,2366,2864,4511,28,695,2366,2865,4522,28,685,241,2868,4515,28,689,2367,2866,4513,283,685,2365,2882,4539,281,685,2367,289,4518,28,685,2366,2873,466,28,685,2367,2867,4517,28,688,2365,2865,4515,28,685,237,2868,4615,283,687,2365,2867,458,28,685,2365,288,4497,28,687,2369,2882,4517,28,685,2365,2895,4518,28,685,2367,2884,4567,28,685,2365,2885,4487,281,685,2366,2863,4544,28,685,2365,2878,449,28,685,2388,2923,456,28,685,2366,2866,4521,28,685,2365,3488,4487,282,685,2365,2899,4539,282,685,2365,2884,4493,28,685,2367,2863,4595,28,685,2365,3559,4484,28,685,2365,2924,4516,28,685,2365,2866,4512,281,685,2366,2863,4517,291,687,2369,2865,468,28,685,2369,2882,4512,28,685,2367,2873,448,282,685,2366,2863,4514,281,685,2379,2886,4512,28,685,2365,2892, Besked system Data er følgende int 2. 5 int's 3. 5 int's og 5 strings 4. 5 int's, 5 strings og 1 Vector int's, 5 strings og 5 Vector3 Side 14/79

15 Eksempel på kode * Besked kald gemme besked * public void TestLoopA() private MessageA ma = new MessageA(1); int rounds_tmp = rounds; while (rounds_tmp!= ) rounds_tmp--; _maintimer.reset(); for (int i = ; i < 1; i++) ms.addmessageandupdate(ma); System.Console.WriteLine("" + _maintimer.getelapsedtime()); // i besked system klassen private ArrayList messages = new ArrayList(); public void addmessageandupdate(messagea message) messages.add(message); switch (message.testvalue1) case 1: break; case 2: break; case 3: break; case 4: break; case 5: break; case 6: break; case 7: break; case 8: break; case 9: break; case 1: mr.retrivemessage((messagea)messages[]); break; default: mr.retrivemessage((messagea)messages[]); break; messages.removeat(); // i en anden klasse MessageA ma; public void retrivemessage(messagea message) ma = message; * Besked kald gemme besked * public void TestLoopA() private MessageA ma = new MessageA(1); int rounds_tmp = rounds; while (rounds_tmp!= ) rounds_tmp--; _maintimer.reset(); for (int i = ; i < 1; i++) ms.addmessageandupdate(ma); System.Console.WriteLine("" + _maintimer.getelapsedtime()); // i besked system klassen public void addmessageandupdate(messagea message) switch (message.testvalue1) case 1: break; case 2: break; case 3: break; case 4: break; case 5: break; case 6: break; case 7: break; case 8: break; case 9: break; case 1: mr.retrivemessage(message); break; default: mr.retrivemessage(message); break; // i en anden klasse MessageA ma; public void retrivemessage(messagea message) ma = message; Side 15/79

16 Besked system_med at gemme i array Besked system_med at gemme i klassen Test 1 Test 2 Test 3 Test 4 Test 5 Test 1 Test 2 Test 3 Test 4 Test 5,5538,5541,552,5523,5531,1113,117,118,179,116,5425,557,5476,5479,5479,162,111,999,158,996,5435,548,5481,5484,5481,158,998,998,158,997,5443,5497,5482,5477,552,16,998,998,158,996,542,548,5612,5479,5481,161,1,998,161,996,5419,5481,5638,5491,5476,158,996,998,158,996,5423,5481,5478,5483,5481,188,999,996,161,998,5422,5477,5479,5481,548,185,996,996,158,996,5438,5479,5477,5523,5479,159,998,997,158,997,542,5519,5481,5482,5479,164,998,996,158,996,542,5481,5494,5488,5478,159,996,996,16,996,5418,548,548,5491,5479,161,998,996,158,996,5419,5476,5492,5481,5493,162,998,996,158,19,5423,5486,5577,5478,548,159,998,999,159,129,5455,5478,5478,5479,5488,161,999,996,158,997,5418,5492,5476,5477,5497,159,996,999,159,996,5419,5478,5492,548,5479,173,1,996,159,998,5417,553,5478,549,548,163,996,996,158,12,5417,5492,5481,5484,5476,16,13,996,159,996,5418,548,5479,548,5494,158,999,998,158,997,5431,5481,5488,5479,5479,16,997,996,159,996,5417,5492,5476,5478,5497,158,998,125,158,996,5448,5478,557,548,5496,161,996,997,159,996,5419,5478,5476,5491,5478,16,999,996,158,996,5417,5479,5484,5487,5481,158,1,997,158,996,5416,5483,548,5478,549,16,997,997,158,997,5429,5479,548,5514,5478,165,998,996,162,996,5417,557,5479,5479,5496,158,996,997,158,996,5415,5479,5496,5479,5479,161,998,996,159,997,5414,5481,5481,5496,5477,16,999,999,158,996,5418,5476,5479,5478,5479,159,996,996,158,997,5414,5489,5529,5481,551,16,999,996,158,1,5452,548,5478,5476,5481,16,996,996,16,996,5416,5492,5479,5482,5497,16,998,997,158,997,6254,5481,5492,5478,5478,161,12,996,159,996,5415,552,5486,548,5483,158,14,998,158,996,5448,5496,5479,5476,5489,162,998,998,158,123,5414,5478,5476,5482,5494,162,997,996,159,997,5464,548,5479,5478,5478,158,998,997,158,996,5414,5492,548,5493,5485,161,12,996,158,11,5451,5489,557,5476,5519,16,996,996,158,997 Side 16/79

17 4 Collision Detection Collision Detection og Control, har vi valgt som en af de moduler, vi mener er vigtig for vores 3DGameEngine. Grunden til dette er, at en 3DGameEngine som skal kunne understøtte et FPS spil, skal kunne fortælle og håndtere, når en spiller eller et andet 3D objekter støder ind i selve verdenen eller andre objekter. Den anden grunden er, at vi gerne vil bruge dette modul til at kunne give en god indikation omkring hvordan andre komponenter vil komme til at reagere med de teknikker, vi har tænkt os vil kunne give en performance forbedring. Vi finder disse komponenter typisk i den forstand, at ligesom AI, Physics, Lyd osv kan og er meget CPU tunge opgaver. Alle har det tilfælles at der er X-antal arbejdsopgaver, der skal løses som typisk er proportionel med antallet at enheder, som skal styres/beregnes, ligesom Collision Control har. X-antal bevægelige objekter skal kontrolleres op imod x-antal stationært geometri og evt. x-antal bevægeligt objekter. 4.1 Konstruktion For at vi får realistiske tests så bliver vores Collision Detection / Control nødt til at være så tæt på det vi ser i kommercielle 3DGameEngines. Her er det vigtigste at vores Collision Detection har samme hastighed som de kommercielle Engines, i hvert fald set asymptotisk. Vi vil aldrig kunne ramme den samme hastighed af den simple årsag, at der findes mange nuancer på, hvordan den Collision Detection kan laves. Men ifølge litteraturen så findes der en fælles asymptotisk hastighed. Grunden til, at der findes en fælles asymptotisk hastighed, er, hvis vi ser på problemet med at finde ud af om to objekter optager fælles sted i et dertil hørende tid. Dvs. to objekter bevæger sig og i en given tid støder de sammen. Der hvis vi tager det første problem, optager det samme sted. Dvs. har det ene objekt geometri som skærer det andets geometri? Hvis vi simplicerer dette problem til, at en kugle støder ind i noget geometri (objekt). Der findes, hvis vi er lidt firkantede, to måder at finde ud af dette. Denne ene er brute force teste alle polygonerne op i mod kuglen og finde dem som skærer denne, hvis vi antager, at det er en boundingsphere der skal testes op imod et objektet med 2millioner polygoner. Denne naive algoritme tester alle polygoner i objektet for at se, om der er en kollision, dvs.: 2 16 tests dvs. running time er : (#polygons)= n Skal udføres inden man kan se om der er en kollision eller ej, dette bliver endnu værre, hvis det er et Side 17/79

18 helt objekt, der kolliderer med objektet, f.eks. et objekt på 1polygoner: =2 19 tests dvs. running time er : (#polygons1 * #polygon2)= n m n2 Begge af disse asymptotiske running time's er helt udelukket i et real tid sceneri, som et 3D First Person Shooter er. Selvom vi siger at en 1GHz processor er i stand til at udføre 1 test per clock cycle, vil det stadigvæk betyde, at den vil bruge 2 sekunder for at gennemfører den sidste test. Det er næsten unødvendigt at sige, at det ikke er denne metode, som bliver brugt. Den hurtigste måde vi kan finde ud af, om en kugle deler plads med et objekt er ved at have sorteret objektets geometri på en sådan måde, at vi hurtigt kan bestemme hvilke dele af geometrien, der ikke er interessant, og hvilke der er. En sådan måde kan være et binært søgetræ som har den egenskab at være asymptotisk meget hurtigt log n [CORMEN] for en søgning. Objekt Binært søge træ Objekt Del objekt 1 Del objekt 2 Del objekt Del objekt Del objekt Del objekt Illustration 2: Collision Detection, Binært søge træ Ideen er som vist på Illustration 17: Collision mellem dynamske og statiske objekter - Normale er, at et objekt bliver delt op i mindre og mindre dele eftersom man går ned igennem træet. Dvs. man kan meget hurtigt bestemme, om der er en kollision mellem to objekter ved at teste på root-nodens boundingsphere, hvis der er en kollision her, vil man fortsætte ned igennem træet, indtil der ingen kollision mellem en underliggende boudningsphere er, eller vi når bunden, hvorefter vi bliver nødt til at teste på den/de polygoner, der er tilknyttet den sidste node. For hver gang vi går ned igennem træet så halverer vi vores problem. Højden/dybden af vores Side 18/79

19 binært træ for objektet med de 2mill polygoner er: 2 16 polygoner=log højde Højde af binært træ er : O log 2 n hvis vi antager at leaf-noderne alle indeholder 1 og kun 1 polygon. Det vil betyde, at når algoritmen når bunden af træet, og der stadigvæk er kollision mellem den sub-boundingsphere i træet/noden og den kolliderende boundingsphere, at vi kun behøver at lave en intersecetion test mellem boundingsphere og en polygon for at teste, om der reelt findes en kollision. Alt i alt vil vi højest have udført 21 2=42 interscetion tests mellem boundingsphere og boundsphere (to for hvert level i træet) og kun en test mellem boudingsphere og polygon. Test mellem to boundingspheres er væsentlig hurtigere end boudingsphere og polygon, fordi to boudingspheres kun har en intersection hvis deres afstand mellem deres center er mindre en deres fælles radius. Mens BoudingSphere og polygon har en intersection hvis, det plan polygonen laver har en intersection med boundingsphere'en, og at polygons punkter ligge således at bare et at intersection punkterne for planet er inde i polygon. Start kollision test Første sub-sphere kollision test Objekt Objekt Coll. sphere Coll. sphere Anden sub-sphere kollision test Polygon & sphere kollision test Objekt Objekt Coll. sphere Coll. sphere Illustration 3: Kollision test mellem objekt og coll. sphere Hvis vi igen har kollision mellem to objekter, hvor det ene har 2mill polygoner og det andet har 1 polygoner, kan det gøres ved først at traversere det ene objekts kollision binær søgetræ, hvorefter det andet bliver traverseret med det førstes sidste sub-boundingsphere. Vi får derfor: 1 ' st obj : log =21 dvs. 42 tests 2 ' nd obj: log =1 dvs. 2 tests total antal tests=42 2=62 tests dvs. running time : O log 2 obj1 O log 2 obj2 = O log 2 obj1 obj2 Med andre ord en væsentlig forbedering af algoritmen. Vi er gået fra at have 2milliarder tests til kun Side 19/79

20 at have 62 tests for om to objekter har en kollision. Desuden skal det nævnes, at det er worst case running time for den sidste algoritme, vi viser. I langt de fleste tilfælde vil der ikke være nogen kollision, og derfor vil den returnere allerede efter første test mellem de to overordnede BoundingSpheres. Igen, hvis vi siger en 1GHz processor er i stand til at udføre en test per clock cycle, vil denne forbedrede Collision Detection være i stand til at udføre samme test, som den forrige gjorde på 1 sekund, på: 62 tests =.62 ms ticks / sec Hvilket er en 2ms/.62ms ~ 32 gange hurtigere (asymptotisk). Litteraturen fortæller os at den hurtigste måde vi kan lave en søgning via sammenligning er log n hvilket vi har nået. Dvs. umiddelbart kan den ikke gøres hurtigere. Dog findes der specielle tilfælde, f.eks. hvor de to objekter ikke har bevæget sig, hvor en caching af sidste resultat kan bruges, hvilket tager 1 tid. I vores algoritme hvis ingen af objekterne har bevæget sig, forsørgelsen ignoreret, da det antages at en evt. collision er blevet håndteret. Det samme gør sig gældende, når vi får tid ind i billedet. En 3DGameEngine og derfor også spillet er helt generelt, ikke en flydende kontinuert hændelse. For hver gang vi kører en update på 3DGameEngine'en så er der gået x-antal tid. Dvs. ligesom med film, så er hver frame i spillet en discret sampling af, hvordan verdenen ser ud på et givent tidspunkt. Hvilket fører til, at vi skal have en måde vi kan finde ud af, hvornår hændelser sker, så som collisioner mellem objekter i en kontinuert kontekst (se ). Start Objekt Slut Stationært objekt Objekt Illustration 4: Collision, bevægeligt obj over tid Igen har vi to måder en brute force, som vi allerede har set ikke virker, hvilket vil tage O n tid, hvor n er det interval vi sætter op mellem samplingerne (de røde cirkler). Side 2/79

21 Objekt Stationært objekt Objekt Illustration 5: Collision, bevægeligt obj over tid, "brute force" Mens en søgning som bygger på at halvere problemet for hver iteration vil tage O log n tid, hvor n er antallet af halveringer, se Illustration 21: Collision mellem dynamske og dynamiske & statiske objekter - Normal [ERICSON]. Start Objekt End Stationært objekt Objekt Illustration 6: Collision, bevægeligt obj over tid, Binær søgning Hvorfor vi er nødt til at lave denne overlap mellem disse BoundingSpheres? Kan ses i Illustration 23: Simple-Render & No rendering Low polygon. Her bliver en kollision mellem en kugle og et meget spidst objekt overset. Side 21/79

22 Objekt Objekt Illustration 7: Binær søgning fejl Ligesom andre 3DGameEngines skelner vi mellem stationært geometri og bevægelige objekter af den simple årsag, at hvis vi allerede ved, når vi indlæser modellerne ind, hvilke som ikke vil komme til at bevæge sig, kan vi allerede komme uden om at skulle teste disse op imod andre ikke bevægelige objekter, da disse aldrig vil kunne støde ind i hinanden. Et Collision Detection system er ikke specielt anvendeligt, hvis vi ikke brugte det til noget. Vi har derfor lavet to Collision Handlers, som bliver håndteret af Physics komponenter i vores Engine. Den ene handler er Bouncer-Handler som navnet antyder gør, at objekter kan reflektere af vægge, objekter osv. hvor den røde pil er retningsvectoren for objektet, mens den sorte pil er afstanden, det vil tilbagelægge mellem 2 efter hinanden følgende frames, den stiplede pil er den nye udregnede placering. Illustration 8: Bouncer-Handler Mens den anden er en Push'er-handler som vi bruger til, at vores kamera ikke kan gå igennem væggene, gulv osv. dvs. det vil f.eks. glide henover gulvet, hvis vi ramte ind i det. Illustration 9: Push'er-handler Side 22/79

23 Ideen er så, om vi kan forbedre denne model. Vi benytter allerede vores Collision Detection komponent til at bestemme, hvornår objekter bevæger sig igennem en portal. Det foregår ved det princip, at vi laver en Collision Ray, som i bund og grund er et linie stykke. I dette tilfælde som har startpunkt i den gamle position for objektet og slutpunkt i den nye position for objektet. Der sker så det, at hvis denne Collision Ray krydser en given portal, så ved vi, at objektet, som denne Ray hører til, har krydset den på gældende portal. Tanken er så, at denne portal graf også skal kunne bruges til Space Partitionering for vores Collision Detection komponent, frem for at skulle til at vedligeholde en ny SP-graf såsom et OctTree, for vi har allerede denne portal graf gratis i den forstand, at for at vores Portal-Render kan fungere korrekt, så skal den vedligeholdes for hver iteration, med alle de objekter som skal renderes Test og Resultater For at teste korrektheden og hvilken forbedering vores Portal-Graf kan have på vores Collision Detection, benytter vi vores verden fra før med de 6 rum. Vi generer x-antal objekter (spheres), som alle bevæger sig med samme hastighed, retningen bliver bestemt ud fra kameraets retning. Når de rammer andre objekter vil de blive reflekteret med uændret hastighed. Illustration 1: Verden delt ind i BSP-Tree Illustration 11: Kugler rammer verdenen Ovenover ses verderen, hvor vi for testens skyld tegner BSP-tree'et, som bliver brugt til søgningen for kollisioner. I Illustration 18: Collision mellem dynamske og statiske objekter - Portal ser vi nogle kugler, hvor nogen af dem rammer verdens geometri. For at kunne se hvilke dele af verden som bliver ramt, tegner vi BSP-Tree noderens boundingsphere, som ses som en wireframed sphere. Side 23/79

24 Illustration 12: Kugler i rum 6 Illustration 13: Kugler rammer verdenen Ovenover ses rum 6 med nogle kugler og til venstre ses BSP-Tree'et med de boundingsphere for noderne, hvor der sker en kollision. Illustration 14: Bounding Volumes Ovenover ses udelukkende objekternes boundingboxe og portalernes boundingspheres. De bevægelige objekter har linier for deres up-, right- op direction-vectors Static Vi starter med at teste, hvor objekterne udelukkende kan kollidere med den stationære geometri. Den første test er den normale, hvor vi ikke benytter nogen form for Space Partitionering. Mens i den anden test benytter vi portal-grafen til at bestemme, hvilke objekter og geometri kan kollidere med hinanden. Side 24/79

25 Normal - Static Portal - Static Illustration 15: Static Collision - Normal Illustration 16: Static Collision - Portal Den første blå søjle er reference, dvs. Frame Raten vi har ved kugler. De efterfølgende stiger antallet af kugler, 1, 2, 4, 8 og 16 kugler. Som det kan ses, så er vores portal graf næsten 1% hurtigere, end den test hvor vi ikke benytter nogen form for SP. Det skal også nævnes at i den normale test har vi fjernet portal grafen helt, således den ikke bliver opdateret, men vi får et mere realistisk resultat. Side 25/79

26 Collision Dection / Handling - Static - Normal ,5 5 7,5 1 12, ,5 2 22,5 25 Illustration 17: Collision mellem dynamske og statiske objekter - Normale Øverst = kugle, næste = 1 kugler, næsten igen = 2 kugler, osv nederst = 16 kugler Illustration 17: Collision mellem dynamske og statiske objekter - Normale ses Frame Rate'en for hele tests forløbet. Collision Dection / Handling - Static - Portal ,5 5 7,5 1 12, ,5 2 22,5 25 Illustration 18: Collision mellem dynamske og statiske objekter - Portal Side 26/79

27 Øverst = kugle, næste = 1 kugler, næsten igen = 2 kugler, osv nederst = 16 kugler Illustration 18: Collision mellem dynamske og statiske objekter - Portal ses Frame Rate'en for hele tests forløbet Dynamic I denne test kan kuglerne kolliderer med hinanden Normal - Dynamic Portal - Dynamic Illustration 19: Dynamisk Collision - Normal Illustration 2: Dynamisk Collision - Portal Igen er den første blå søjle reference, dvs. Frame Raten vi har ved kugler. I de efterfølgende stiger antallet af kugler, 1, 2, 4 og 8 kugler. Pga. at testen for om kuglerne støder ind i den dynamiske geometrien dvs. andre kugler stiger i orden af n2, ser vi en endnu større hastighedsforøgelse, når vi benytter os af Portal-Grafen til SP. Her er hastighedsforøgelse over 2% nogen steder. Side 27/79

28 Collision Dection / Handling - Dynamic - Normal ,5 5 7,5 1 12, ,5 2 22,5 25 Illustration 21: Collision mellem dynamske og dynamiske & statiske objekter - Normal Øverst = kugle, næste = 1 kugler, næsten igen = 2 kugler, osv nederst = 8 kugler Illustration 21: Collision mellem dynamske og dynamiske & statiske objekter - Normal ses Frame Rate'en for hele tests forløbet. Collision Dection / Handling - Dynamic - Portal ,5 5 7,5 1 12, ,5 2 22,5 25 Illustration 22: Collision mellem dynamske og dynamiske & statiske objekter - Portal Øverst = kugle, næste = 1 kugler, næsten igen = 2 kugler, osv nederst = 8 kugler Side 28/79

29 Illustration 22: Collision mellem dynamske og dynamiske & statiske objekter - Portal ses Frame Rate'en for hele tests forløbet. 4.2 Konklusion Det siger sig selv, at vi fremover vil benytte Portal-Grafen til Space Partitionering for både Collision Detection, men også hvis der skulle komme andre komponenter, som kan drage nytte af hurtigt at kunne bestemme relationer mellem objekter. Yderligere får vi Portal-Grafen gratis i den forstand, at Portal-Renderen skal bruge den og PortalRenderen er uden lige den hurtigste Render vi har, hvilket gør, at vi ikke kommer uden om PortalRenderen og derved Portal-Grafen. Vores løsning er i stand til at finde kollisioner mellem to objekter på O log n tid. Hvis en eller begge bevæger sig, er vi i stand til at finde kollisionspunktet på O log m log n hvor m er tiden hvor kollisionene finder sted og n er tiden, det tager at finde hvor i objektet kollisionen er. Dog skal det nævnes, at i langt de fleste tests for at finde kollisionspunktet for en given tid er kompleksiteten O log m 1. Da vi i de fleste tilfælde hurtigt kan se, at en kollision er mulig. Dvs. vi får typisk en søgning som total set tager O log m log n. Vores argument er, at det er den hurtigste måde at finde kollisioner på asymptotisk. Dvs. der findes metoder, som vil være i stand til at kunne gøre dette hurtigere, men ikke asymptotisk, det betyder at vores algoritme vil udvise samme hastighedskarakteristika som andre Collision Detection algoritmer, når vi tilføjer objekter til den [CORMEN] [ERICSON]. For at denne algoritme skal helt op og konkurrere med andre hurtigere algoritmer så burde vi som andre skifte fra BoundingSpheres (OBS) til ObjektOrienteretBoundingBox'e (OBB), da disse har mindre overlap mellem de enkelte noder og derved minimerer, at vi tester på noder, som kunne have været undgået [ERICSON]. Til vores test er denne algoritme mere end god nok. Testene med denne algoritme vil fortælle os korrekt, om de optimeringer, vi afprøver, i virkeligheden vil være en forbedring eller ej, da vores algoritme asymptotiske har samme hastighed som alle andre Collision Detection algoritmer, hvilket har været vores mål med denne. Yderligere mener vi, at denne algoritme eller rettere sagt komponent, vil være god nok til at simulere tilstedeværelsen af andre komponenter i vores Engine. Vi er i stand til at kunne ændre på, hvor meget den vil beregne per update (antallet af objekter der skal testes på). Side 29/79

30 5 Splitting - Verifikation Dette er ganske enkelt for at visuelt verificerer, at opdelingen er korrekt. Når selve testen kører er der ingen måde at være sikker på at vores algoritme er i stand til at udføre opdeling og kun tegne de dele, som kan ses. Derfor har vi lavet dette kapitel. Testen er udført således, at vi har 2 kameraer. Det ene er det vi ser igennem, det er statisk og overser hele geometrien. Det andet er bevægeligt, det er ud fra dette at vores algoritme bestemmer, hvad der kan ses. Vi tegner selve geometrien (selve objektet med texture) plus datastrukturen (Oct eller BSP), som blev brugt til at dele geometrien op med. Hver node i datastrukturen har fået tildelt sin egen farve, hvilket betyder, at en Wireframe geometri har forskellige farver (farvetildeling er tilfældigt, hvilket betyder at der kan forkomme noder som næsten har samme farve). Den lilla box er hele geometriens BoundingBox. Dybden af træet, der er vist, er sat til minimum 125 polygoner i hver node. 5.1 Simple-Render Simple-Render har i sig selv ikke nogen spændende datastruktur. Den bestemmer udelukkende på basis af objektets BoundingVolume, om det skal renders eller ej. Nedenunder ses det objekt, vi har testet med occucity fra Microsoft DirectX SDK. På første billede kan vi se objektet, da det befinder sig inden i ViewFrustum'et. Men på det andet kigger kameraet forbi objektet. Side 3/79

31 Som det kan ses, så virker den som den skal (Der er gennemført flere tests, hvor ekstremer i forhold til algoritmen også er blevet testet for korrekthed). 5.2 BSP-Tree-Render BSP - Split med geometrien Split med geometrien er den opdelingsmetode vi benytter med det for øje at benytte så meget af geometrien til at bestemme splitning planerne. Det betyder at splitting planerne stort set udelukkende bliver bestemt ud fra den allerede eksisterende geometri, hvilket er med til at minimere antal af polygon split, vi laver. Dog skal det nævnes at faktorer så som faktuelle splilts og tree-balance også spiller ind i bestemmelsen af splitting planer, men igen splitting planer kan du generere ud fra geometrien. Her kan hele geometrien ses, læg mærke til den lilla BoundingBox hvor siderne er synlige. Side 31/79

32 Her er halvdelen synlig, læg mærke til den lilla linie igennem midten af objektet gående vertikalt, hvilket igen er objektets BoundingBox. Som det kan ses, bliver der tegnet geometri, som delvist ikke kan ses pga. inddelingen. Husk på, at objektet skulle, hvis det var rigtigt, have være drejet med, således at kun halvdelen var synlig lige nu, og det ville have befundet sig i den venstre halvdel. Her er der endnu mindre af objektet, som befinder sig inden i kameraets ViewFustrum. Side 32/79

33 Her ses objektet, når vi har bevæget kameraet ned og til venstre. I det sidste billede er geometrien tegnet op i WireFrame inde i objectes BoundingBox. Billederne taler for sig selv, at opdelingen/splittingen og cullingen med ViewFustrum'et fungerer korrekt. Endvidere er det tydeligt at se, at pga., at opdelingen helst vil benytte sig af geometrien, vil opdelingen foregå langs strukturerne i objektet. I dette tilfælde er det bygningerne i objektet, således at vi får splitting planer som går ca. fra midten og langs med bygning indlingen og ud til kanten af objektet. Dette bevirker, at vi får nogle relativ lange sub-objekter ud af opdelingen. BSP - Bedste split Bedste split virker ved, at som udgangspunkt at vælge en vertex som center punkt for splitting planet, hvorefter vi regner ud, hvor mange split vi skal lave, og hvordan tree-balancen kommer til at se ud. Dette bliver gentaget nok gange, indtil vi har fundet et splitting plan som laver færrest split og balancerer træet bedst muligt. Side 33/79

34 Her kan hele geometrien ses, læg mærke til den lilla BoundingBox hvor siderne er synlige. Her er halvdelen synlig, læg mærke til den lilla linie igennem midten af objektet gående vertikalt, hvilket igen er objektets BoundingBox. Som det kan ses bliver der tegnet geometri som delvist ikke kan ses pga. inddelingen. Husk på at objektet skulle, hvis det var rigtigt, have være drejet med således at kun halvdelen var synlig lige nu og det ville have befundet sig i den venstre halvdel. Side 34/79

35 Her er der endnu mindre af objektet, som befinder sig inden i kameraets ViewFustrum. Her ses objektet når vi har bevæget kameratet ned og til venstre. I det sidste billede er geometrien tegnet op i WireFrame inde i objectes BoundingBox. Billederne taler for sig selv, at opdelingen/splittingen og cullingen med ViewFustrum'et fungere korrekt. Endvidere er det tydeligt at se, at denne opdelingsmetode generer sub-objekter som er væsentligt mere kompakte end split med geometrien gør. 5.3 Oct-Tree-Render Splitting Side 35/79

36 Her splitter Oct-Tree'et geometrien med Sub-noderens BoundingBox (de grønne kasser). Det skal give os sub-noder, som er helt kvadratiske. Hvilket kan ses tydeligt på efterfølgende illustrationer. Her kan hele geometrien ses, læg mærke til den lilla BoundingBox hvor siderne er synlige. Her er halvdelen synlig, læg mærke til den lilla linie igennem midten af objektet gående vertikalt, det er igen objektets BoundingBox. Som det kan ses bliver der tegnet geometri, som delvist ikke kan ses pga. inddelingen. Husk på, at objektet skulle, hvis det var rigtigt, have være drejet med, således at kun halvdelen var synlig lige nu, og det ville have befundet sig i den venstre halvdel. Side 36/79

37 Her er der endnu mindre af objektet, som befinder sig inden i kameraets ViewFustrum. Her ses objektet, når vi har bevæget kameraet ned og til venstre. I det sidste billede er geometrien tegnet op i WireFrame inde i objectes BoundingBox. Billederne taler for sig selv, at opdelingen/splittingen og cullingen med ViewFustrum'et fungerer korrekt. Non-splitting Vil ikke splitte geometrien. Geometrien vil derimod blive tildelt en node i forhold til, hvor mange procent af den pågældende polygon, der befinder sig inden i en given sub-node. Dvs. den sub-node med højest procenttal for en given polygon vinder den. Side 37/79

38 Her kan hele geometrien ses, læg mærke til den lilla BoundingBox, hvor siderne er synlige. Her er halvdelen synlig, læg mærke til den lilla linie igennem midten af objektet gående vertikalt, det er igen objektets BoundingBox. Som det kan ses, bliver der tegnet geometri, som delvist ikke kan ses pga. inddelingen. Husk på, at objektet skulle, hvis det var rigtigt, have være drejet med, således at kun halvdelen var synlig lige nu, og det ville have befundet sig i den venstre halvdel. Side 38/79

39 Her er der endnu mindre af objektet, som befinder sig inden i kameraets ViewFustrum. Her ses objektet, når vi har bevæget kameraet ned og til venstre. I det sidste billede er geometrien tegnet op i WireFrame inde i objectes BoundingBox. Billederne taler for sig selv, at opdelingen og cullingen med ViewFustrum'et fungerer korrekt. Og tildelingen af polygoner til de enkelte noder i OctTree'et fungerer korrekt, nu hvor ingen polygonsplitting finder sted. Side 39/79

40 6 Rendering I dette afsnit kommer testforløbene for de forskellige Renders vi har og kombinationerne mellem Portal-Render og Oct- / BSP-Tree-Render. Testene hører til det test scenario, hvor vi har lavet en reel verden hvori kameraet følger den bestemt rute igennem verdenen. 6.1 Lavt antal Polygoner Her kommer testene for verden med et lavt antal polygoner. Overskrifterne på graferne forstæller hvilken test der blev udført. None and SimpleRenderX - Low Polygon Illustration 23: Simple-Render & No rendering Low polygon Side 4/79

41 SimpleRenderX - Low Polygon Illustration 24: Simple-Render - Low polygon OctTreeRender OctTreeRenderX 1Polygon - Low Polygon Illustration 25: OctTree-Render 1 polygon pr. node - Low polygon Oct-Tree-Renderen (1 polygoner pr. node) med Simple-Render testen som reference. Side 41/79

42 OctTreeRenderX 25Polygon - Low Polygon Illustration 26: OctTree-Render 25 polygon pr. node - Low polygon Oct-Tree-Renderen (25 polygoner pr. node) med Simple-Render testen som reference. OctTreeRenderX 1Polygon - Low Polygon Illustration 27: OctTree-Render 1' polygon pr. node - Low polygon Oct-Tree-Renderen (1' polygoner pr. node) med Simple-Render testen som reference. Side 42/79

43 6.1.2 BSPTreeRender BSPTreeRenderX 1Polygon - Low Polygon Illustration 28: BSPTree-Render 1 polygon pr. node - Low polygon BSP-Tree-Renderen (1 polygoner pr. node) med Simple-Render testen som reference. BSPTreeRenderX 25Polygon - Low Polygon Illustration 29: BSPTree-Render 25 polygon pr. node - Low polygon BSP-Tree-Renderen (25 polygoner pr. node) med Simple-Render testen som reference. Side 43/79

44 BSPTreeRenderX 1Polygon - Low Polygon Illustration 3: BSPTree-Render 1' polygon pr. node - Low polygon BSP-Tree-Renderen (1' polygoner pr. node) med Simple-Render testen som reference PortalRender PortalRenderX - Low Polygon Illustration 31: Portal-Render - Low polygon Brun = Simple-Render, Guk = Portal-Render, Blå = Portal-Render forbederet. Side 44/79

45 Testforløbet for to typer af Portal-Render med Simple-Render som reference PortalRender og OctTreeRender PortalOctRenderX 1Polygon - Low Polygon Illustration 32: Portal- & OctTree-Render, 1 polygoner pr. node - Low polygon Oct-Tree-Render (gul) (1 polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (brun) som reference. Side 45/79

46 PortalOctRenderX 25Polygon - Low Polygon Illustration 33: Portal- & OctTree-Render, 25 polygoner pr. node - Low polygon Oct-Tree-Render (gul) (25 polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (brun) som reference. PortalOctRenderX 1Polygon - Low Polygon Illustration 34: Portal- & OctTree-Render, 1' polygoner pr. node - Low polygon Oct-Tree-Render (gul) (1' polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (brun) som reference. Side 46/79

47 6.1.5 PortalRender og BSPTreeRender PortalBSPRenderX 1Polygon - Low Polygon Illustration 35: Portal- & BSPTree-Render, 1 polygoner pr. node - Low polygon BSP-Tree-Render (gul) (1 polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (brun) som reference. PortalBSPRenderX 25Polygon - Low Polygon Illustration 36: Portal- & BSPTree-Render, 25 polygoner pr. node - Low polygon Side 47/79

48 BSP-Tree-Render (gul) (25 polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (brun) som reference. PortalBSPRenderX 1Polygon - Low Polygon Illustration 37: Portal- & BSPTree-Render, 1' polygoner pr. node - Low polygon BSP-Tree-Render (gul) (1' polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (brun) som reference. 6.2 Højt antal Polygoner Her kommer testene for verden med et lavt antal polygoner. Overskrifterne på graferne forstæller hvilken test der blev udført SimpleRender Side 48/79

49 SimpleRenderX - High Polygon Illustration 38: Simple-Render - High polygon OctTreeRender OctTreeRenderX - 25Polygoner Illustration 39: OctTree-Render, 25 polygoner pr. Node High polygon Oct-Tree-Renderen (25 polygoner pr. node) med Simple-Render testen som reference. Side 49/79

50 OctTreeRenderX - 1Polygoner Illustration 4: OctTree-Render, 1' polygoner pr. node High polygon Oct-Tree-Renderen (1' polygoner pr. node) med Simple-Render testen som reference. OctTreeRenderX - 1Polygoner Illustration 41: OctTree-Render, 1' polygoner pr. node Oct-Tree-Renderen (1' polygoner pr. node) med Simple-Render testen som reference BSPTreeRender Side 5/79

51 BSPTreeRenderX - 25Polygoner Illustration 42: BSPTree-Render, 25 polygoner pr. node BSP-Tree-Renderen (25 polygoner pr. node) med Simple-Render testen som reference. BSPTreeRenderX - 1Polygoner Illustration 43: BSPTree-Render, 1' polygoner pr. node BSP-Tree-Renderen (1' polygoner pr. node) med Simple-Render testen som reference. Side 51/79

52 BSPTreeRenderX - 1Polygoner Illustration 44: BSPTree-Render, 1' polygoner pr. node BSP-Tree-Renderen (1' polygoner pr. node) med Simple-Render testen som reference PortalRender Side 52/79

53 Portal-RenderX - High Polygon Illustration 45: Portal-Render - High polygon Brun = Simple-Render, Sort = Portal, Blå = Portal-Render forbederet. SimplePortalRenderX - High Polygon Column I Column J Column AM Column AZ Illustration 46: Portal-Render, Polygons Render'ed J = Total antal polygoner. I = Simple-Render antal polygoner. Side 53/79

54 AM = Portal-Render antal polygoner. AZ = Portal-Render forbederet antal polygoner. SimplePortalRenderX - High Polygon Column F Column AJ Column AW Illustration 47: Portal-Render, Objects render'ed - High polygon F = Simple-Render antal af objekter renderet. AJ = Portal-Render antal af objekter renderet. AW = Portal-Render forbederet antal af objekter renderet PortalRender og OctTreeRender Side 54/79

55 PortalRenderX and OctTreeRenderX 25Polygon - High Polygon Column B Column AS Column BV Illustration 48: Portal- & OctTree-Render 25 polygoner pr node - High polygon Oct-Tree-Render (blå) (25 polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (sort) og Simple-Render (brun) som reference. PortalRenderX and OctTreeRenderX 1Polygon - High Polygon Column B Column AS Column CJ Illustration 49: Portal- & OctTree-Render 1' polygoner pr node - High polygon Oct-Tree-Render (blå) (1' polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (gul) og Simple-Render (brun) som reference. Side 55/79

56 PortalRenderX and OctTreeRenderX 1Polygon - High Polygon Column B Column AS Column CX Illustration 5: Portal- & OctTree-Render 1' polygoner pr node - High polygon Oct-Tree-Render (blå) (1' polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (sort) og Simple-Render (brun) som reference PortalRender og BSPTreeRender PortalRenderX and BSPTreeRenderX 25Polygon - High Polygon Column B Column AS Column EB Illustration 51: Portal- & BSPTree-Render 25 polygoner pr node - High polygon BSP-Tree-Render (blå) (25 polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (sort) og Simple-Render (brun) som reference. Side 56/79

57 PortalRenderX and BSPTreeRenderX 1Polygon - High Polygon Column B Column AS Column EO Illustration 52: Portal- & BSPTree-Render 1' polygoner pr node - High polygon BSP-Tree-Render (blå) (1' polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (sort) og Simple-Render (brun) som reference. PortalRenderX and BSPTreeRenderX 1Polygon - High Polygon Column B Column AS Column FB Illustration 53: Portal- & BSPTree-Render 1' polygoner pr node - High polygon BSP-Tree-Render (blå) (1' polygoner pr. node) kombineret med Portal-Renderen med PotalRenderen (sort) og Simple-Render (brun) som reference. Side 57/79

58 7 MultiThreading I dette afsnit er alle test resultaterne for trådnings testene. Side 58/79

59 7.1 Enkelt Trådet design Test resultater for enkelt trådet design. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 484,87,,, 48,89,,, 43,32,,, 278,97,,, 168,7,,, 76,34,,, 32,88,,, Balls FPS σ Thread1 σ Thread1 σ 8,298,14, 1 3,215,, 2 17,1825,1,1 4 9,4229,, 8 6,8849,4, 16 4,2145,, 32 1,3424,, Reference FPS Reference FPS w. σ Wait times std. Deviation (σ) wait times,15,,14,13,12,11,1,9,8,7,6,5,,,,,,,4,3,2,1,,,, Side 59/79

60 7.2 Engine-tråd og Render-tråd Test resultater for det to trådet design. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 129,52,5,,5 125,2,2,1,3 181,61,,8,8 576,91,,16,16 363,43,,26,27 168,57,,58,58 7,32,,139,139 Balls FPS σ Thread1 σ Thread1 σ 4,193,99, ,5662,81, ,221,18, ,576,28, ,32,23, ,1789,1, ,331,5,156 FPS FPS w. σ Wait times std. Deviation (σ) wait times,14,275,13,25,12,11,225,1,2,9,175,8,15,7,6,125,5,1,4,75,3,5,2,25,1,, Side 6/79

61 7.3 To trådet Collision ingen Rendering Test resultater for at tråde Collision med to tråde. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 1173,54,5,,5 1191,48,2,1,3 1111,28,,5,6 653,91,,14,15 323,43,,3,3 167,16,,58,58 72,87,,135,135 Balls FPS σ Thread1 σ Thread1 σ 9,9637,58, ,4381,67, ,1335,85, ,2464,9,31 8 1,2923,4, ,3931,22, ,3458,13,125 FPS FPS w. σ Wait times std. Deviation (σ) wait times,14,25,13,225,12,11,2,1,175,9,8,15,7,125,6,1,5,4,75,3,5,2,25,1,, Side 61/79

62 7.4 To trådet Collision m. to trådet Portal ingen Rendering Test resultater for at tråde både Collision og Portal med hver to tråde. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 1167,25,,2,3 955,6,,9,1 693,25,1,12,12 58,97,,19,19 343,53,,28,28 183,86,,53,53 82,6,,119,119 Balls FPS σ Thread1 σ Thread1 σ 75,2475,71, ,8486,16, ,6498,25, ,997,16, ,2594,6, ,9125,2, ,8614,6,15 FPS FPS w. σ Wait times std. Deviation (σ) wait times,12,225,11,2,1,9,175,8,15,7,125,6,5,1,4,75,3,5,2,25,1,, Side 62/79

63 7.5 2 M. to tråde pr. SceneNode ingen Rendering Test resultater for at tråde både Collision og Portal med hver to tråde, yderligere er der to tråde pr scenenode. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 633,19,,14,14 415,79,,2,21 286,55,,33,33 187,83,,46,46 95,64,,99,99 5,34,,19,19 21,37,,465,465 Balls FPS σ Thread1 σ Thread1 σ 4,8521,9, ,7952,12, ,3982,7, ,46,3,93 8 4,9945,3, ,384,3, ,93,4,168 FPS FPS w. σ Wait times std. Deviation (σ) wait times,5,18,45,16,4,14,35,12,3,1,25,8,2,6,15,1,4,5,2,, Side 63/79

64 7.6 2 To tråde pr. SceneNode, forbederet ingen Rendering Test resultater for at tråde både Collision og Portal med hver to tråde, hver scenenode tråd får hver 1 noder. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 1147,79,,3,3 781,38,,11,12 653,89,,14,14 44,44,,2,21 255,5,,34,34 132,26,,63,63 48,88,,173,173 Balls FPS σ Thread1 σ Thread1 σ 62,5489,58, ,2779,16,5 2 35,5294,29, ,211,8, ,3966,2, ,7783,3, ,6863,2,28 FPS FPS w. σ Wait times std. Deviation (σ) wait times,18,3,16,275,25,14,225,12,2,1,175,15,8,125,6,1,4,75,5,2,25,, Side 64/79

65 7.7 2 To tråde pr. SceneNode, hvor de ikke køre ingen Rendering Test resultater for at tråde både Collision og Portal med hver to tråde, hver scenenode tråd får hver 1 noder. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 1112,51,,5,6 781,45,,11,11 64,9,,14,14 417,99,,23,23 261,62,,37,37 14,15,,69,69 49,25,,199,199 Balls FPS σ Thread1 σ Thread1 σ 81,391,91, ,8192,31, ,9244,26, ,9693,16, ,819,5, ,2162,47, ,8539,13,167 FPS FPS w. σ Wait times std. Deviation (σ) wait times,2,2,18,18,16,16,14,14,12,12,1,1,8,8,6,6,4,4,2,2,, Side 65/79

66 7.8 2 En EngineX tråd, en RenderX tråd Test resultater for at tråde Enginen og Renderen. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 573,74,15,,15 488,7,12,,12 474,33,6,1,6 381,78,,16,16 18,51,,42,42 79,18,,112,112 29,81,,316,317 Balls FPS σ Thread1 σ Thread1 σ 19,5718,245, ,7299,98,35 2 5,9972,126, ,2454,9,13 8 6,5499,9, ,6466,4, ,331,,12 FPS FPS w. σ Wait times std. Deviation (σ) wait times,325,25,3,225,275,25,2,225,175,2,15,175,125,15,125,1,1,75,75,5,5,25,25,, Side 66/79

67 7.9 2 To tråde for Collsion og to for Portal Test resultater for at tråde både Collision og Portal med hver to tråde. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 481,22,12,,12 455,14,11,1,11 463,57,6,1,6 361,9,3,3,6 259,81,3,8,11 137,83,2,22,25 68,91,6,17,23 Balls FPS σ Thread1 σ Thread1 σ 14,138,134, ,9594,74, ,2735,97, ,7747,65, ,4112,7, ,179,31, ,7244,44,192 FPS FPS w. σ Wait times std. Deviation (σ) wait times,25,2,23,18,2,16,18,14,15,12,13,1,1,8,8,6,5,4,3,2,, Side 67/79

68 7.1 To tråde pr. SceneNode Test resultater for at tråde både Collision og Portal med hver to tråde og hver SceneNode har to tråde. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 467,16,4,1,5 338,6,3,4,7 255,66,2,1,12 158,68,1,23,24 89,6,,65,66 45,9,,142,143 2,53,,428,429 Balls FPS σ Thread1 σ Thread1 σ 28,2817,11, ,1791,59, ,3985,34, ,5421,18,18 8 7,4344,12, ,1313,5, ,865,1,25 FPS FPS w. σ Wait times std. Deviation (σ) wait times,45,3,4,275,25,35,225,3,2,25,175,15,2,125,15,1,1,75,5,5,25,, Side 68/79

69 7.11 To tråde pr. SceneNode, forbederet Test resultater for at tråde både Collision og Portal med hver to tråde og 1 SceneNoder har to tråde. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 48,41,12,,12 464,58,9,,9 467,68,5,1,6 339,86,3,6,9 226,79,2,13,15 111,26,4,27,32 44,71,4,57,6 Balls FPS σ Thread1 σ Thread1 σ 9,5664,15, ,238,79, ,9478,78, ,6651,17, ,448,3, ,7866,6, ,3285,24,299 FPS FPS w. σ Wait times std. Deviation (σ) wait times,65,3,6,275,55,25,5,225,45,2,4,175,35,15,3,125,25,2,1,15,75,1,5,5,25,, Side 69/79

70 To tråde pr. SceneNode, hvor de ikke køre Test resultater for at tråde både Collision og Portal med hver½ to tråde og SceneNoder trådene køre ikke. Tabellen nedenunder til venstre viser vente tiderne mellem Enginen og Renderen og til højre viser den standardafvigelserne. De 4 andre grafer på denne side viser grafisk de forskellige aspekter som tabellen viser. Balls FPS Thread1 wait Thread2 wait Total wait (ms) 476,41,11,1,12 472,75,8,1,9 468,53,4,2,6 346,8,2,8,1 211,43,3,11,15 111,39,4,25,29 44,49,8,49,57 Balls FPS σ Thread1 σ Thread1 σ 12,437,198, ,829,128, ,2747,65, ,4186,37, ,15,65, ,689,34, ,852,68,292 FPS FPS w. σ Wait times std. Deviation (σ) wait times,6,3,55,275,5,25,45,225,4,2,35,175,3,15,25,125,2,1,15,75,1,5,5,25,, Side 7/79

71 8 3DGameEngine-testmiljøets klasser Her er de klasser som vores testmiljø består af, detvil være udelukkende klasser som vi selv har udarbejdet under speciale forløbet. Side 71/79

72 Side 72/79

73 Side 73/79

74 Side 74/79

75 Side 75/79

76 Side 76/79