XNA3DGameEngine. XNA 3DGameEngine. Test af performance forbederne teknikker til 3DGameEngines. Speciale. Afleveret den 28/

Transkript

1 XNA 3DGameEngine Test af performance forbederne teknikker til 3DGameEngines Speciale Adrian Peter Togeskov Cpr-Nr: Vejleder: Peter Rahlff Friis Cpr-Nr: Ken Friis Larsen Afleveret den 28/2-27 Side /4

2 Indholdsfortegnelse Sammenfatning Indledning Problemformulering Læsevejledning Krav til 3D Game Engine Krav Afgrænsninger Test platformerne Test maskine Acer Travelmate Test maskine 2 HP Pavilion dv228ea Validitet af testplatformene Test Maskine Test Maskine Vurdering Støj og fejlkilder Eksterne fejlkilder Interne fejlkilder Minimering af fejlkilder Timer præcision Overordnet struktur Overordnet Design Den klassiske model Vores model Sammenligning af designs Test og evaluering Eksperimenter vurdering Del konklusion Rendering Lille eksperiment Test resultater Vurdering af resultater Generelle optimeringer Fjernelse af redundante vertices Del konklusion Renders Teori og Analyse Simple-Render BSP-Tree-Render Oct-Tree-Render Test og Resultater Test scenario Resultater og vurdering Del konklusion Sortering af geometri Test...53 Side 2/4

3 .4.2 Resultater Del konklusion Portal render Teori og Analyse Analyse af PVS og Portals Test og evaluering Del konklusion Kombinering af optimeringerne Tests Yderligere evaluering Del konklusion Collision Detection / Control Kompleksitet Simulering Portal-Graf Test og evaluering Del konklusion Multi threading Teori og Analyse Grov opdeling teori Fin opdeling teori Meget fin opdeling teori Test og evaluering Grov inddeling Fin inddeling Meget fin inddeling Yderligere evaluering Del konklusion XNA Håndtering af unmanaged entiteter Brugen af XNA Del konklusion Konklusion Fremtidigt arbejde... 6 Litteraturliste... 2 Side 3/4

4 Sammenfatning Denne rapport beskriver et speciale forløb, der omhandler design, test og udvikling af vores egen 3D Game Engine med multi-core understøttelse, bygget på Microsofts XNA Beta Framework. Formålet med dette projekt er at belyse mulighederne og brugbarheden af XNA frameworket, sammen med udviklingen af et testmiljø, der udnytter mulighederne i ressourcerne, der findes i både moderne PC'er og Xbox36, som begge er understøttet af det nye XNA framework. For at opnå en god performance i testmiljøet, har vi gennemført en række tests, omhandlende optimering af grafik og renderingsteknikker med BSP-tree, Oct-tree og Portaler, samt forskellige måder en GameEngine kan trådes. På baggrund af vores erfaringer med XNA mener vi, at denne platform er mest egnet til at lære spiludvikling på, og udviklingen af mindre spil. Vi mener ikke, at den endnu er brugbar til at udvikle store kommercielle spil. Vores tests viser en stor fordel i at benytte portaler som renderingsteknik, der samtidig giver adgang til en portal graf, som vi har set er en udmærket Space Partitionerings metod. Hvis Enginen er bygget med det formål, at den skal være trådet, ser vi her, at der er rigtig meget performance at hente. Side 4/4

5 2 Indledning Denne rapport beskriver et speciale omhandlende tests af performance forbedrende teknikker til 3DGameEngines. Vi har valgt dette emne, fordi vi syntes, at det er et utrolig spændende område at arbejde med og kan se muligheder i det. Fordi dette emne er så stort, har vi valgt at fokusere dels på, om ældre renderingsteknikker kan modificeres til at køre på dedikeret 3D Hardware, og dels på nogle muligheder indenfor trådning af en 3DGameEngine. Vi har valgt at kigge på renderings teknikker, der har været brugt i nogle af de mest populære ældre spil, som Doom2 og Quake, fordi vi syntes, det kunne være spændende at se, om de stadig,den dag i dag, er ligeså brugbare, når vi arbejder med dedikeret 3D hardware. Grunden til, at vi har valgt at kigge på mulighederne for trådning af 3DGameEngines, er, at det bliver mere og mere almindeligt at have dual-core og multi-core processorer i normale hjemme PC'er eller i spillekonsoller. Derfor vil vi undersøge, hvor stor en fordel, det kan være at udnytte de flere ressourcer, der findes i processorerne i dag. Samtidig er dette område også spændende, fordi der ikke er udgivet nogle kommercielle spil, der benytter en fuldt trådet 3DGameEngine. Udover disse to emner vurderer vi også XNA Game Studio Express Beta, som er et interessant nyt Managed spiludviklingsmiljø, fra Microsoft. Vi vurderer dette på baggrund af erfaringer, som vi har fået under udviklingen af vores testmiljø, i form af en 3DGameEngine baseret på XNA. For at belyse disse emner har vi udviklet et 3DGameEngine testmiljø og har set på hvilke krav vi mener der er for et sådan testmiljø. Side 5/4

6 3 Problemformulering Vi har implementeret et testmiljø i form af en 3DGameEngine i XNA Game Studio Express Beta, og denne bruger vi som testmiljø og grundlag for en række tests og problemstillinger, som vi gerne vil analysere. Testmiljøet er ikke en komplet 3DGameEngine med alle de finesser og moduler, som man vil finde i kommercielle Engines. Det er meningen, at den indeholder nok til at fungere som en platform for de tests, som vi gerne vil gennemføre. Via vores brug af XNA vil vi bruge det indblik, vi får i XNA til at vurdere brugbarheden af det i forhold til både amatører og professionelle spiludviklere, og dermed om XNA kan bruges til morgendagens nye kommercielle spil, eller om det er mere brugbart for amatør spil? Vi forventer at XNA frameworket åbner nogle nye døre i forhold til udvikling i et managed miljø, og dermed muligheden for udvikling af større spil. Med vores testmiljø vil vi teste, hvilke af de mest interessante renderingsteknikker, fra før der var dedikerede 3D hardware, der kan modificeres til stadigvæk at være brugbare i dag? Vi forventer, at det vil være muligt at kunne modificere disse tekniker til at kunne køre på en moderne GPU, yderligere forventer vi, at disse tekniker måske kan kombineres for at forbedre performancen. Gennem test af vores testmiljø vil vi se på muligheder for at kunne tråde en 3DGameEngine. Vi vil undersøge, hvilken indvirkning forskellige trådningsmodeller har på testmiljøet, og hvor stor performance forbedring der kan opnås ved at benytte et multi-trådet miljø frem for en single-trådet. Vi forventer, at der vil være stor performance fordel i et mult-trådet miljø, på en dual cored platform. Vi forventer at se en relativ stor forøgelse af hastigheden, men selvom vi har % mere processorkraft, forventer vi ikke en fordobling af hastigheden, da der vil være elementer, som skal udføres sekventielt, f.eks. Renderingen. En performanceforøgelse vil afhænge af, hvor meget der skal udføres sekventielt. Side 6/4

7 4 Læsevejledning Denne rapport består af sider inklusiv forside og indholdsfortegnelse. Dertil hører et bilag på 7 sider og et program der er udviklet under dette speciale forløb på ca. 22' linier. For at belyse de problemstillinger som er beskrevet i problemformulering, har vi gennemført en række tests, og præsentere resultaterne i denne rapport. Først i rapporten beskriver vi de ydre påvirkninger for de gennemførte tests Dette indebærer hvilke krav og afgrænsninger, vi har til design og udviklingen af 3DGameEngine-testmiljø'et, som vi har implementeret, som vi bruger som baggrund for vores tests. Her beskriver vi også, hvilke påvirkninger, der kunne være på resultaterne i form af støj og forurening. Efter disse beskriver vi udførelsen af Render testene. Først med henblik på at se, hvordan grafik håndteres af miljøet, hvorefter vi beskriver testene og resultaterne fra renderingerne med BSP- og OCT-trees. Disse giver anledning til nogle flere tests, der leder os hen til brugen af Portaler til rendering, og kombinationer med BSP- og OCT-Trees. Efter at have kigget på Renderingsteknikker, fokuserer vi på en udvidelelse af vores testmiljø med kollision detektering, for bedre at kunne benytte testmiljøet til at teste indvirkningen af multitrådning. Under tests af multi-trådning har vi kigget på flere forskellige trådningsmodeller, lige fra 2 trådning til mange trådning, hvor vi beskriver deres indvirkning og præsenterer forskellige trådmodellers resultater. Til sidst gennemgår vi nogle af de erfaringer vi har fået under udviklingen af vores testmiljø. Her lægger vi hovedsagelig fokus, på nogle oplevelser vi har haft med XNA Game Studio Express og selve XNA frameworket. På baggrund af disse vurdere vi, hvad vi mener XNA på nuværende tidspunkt egner sig bedst til. Side 7/4

8 5 Krav til 3D Game Engine For at vi mener, at vores testmiljø er godt nok til at kunne benyttes som platform for de tests, vi gerne vil udføre, har vi udformet nogle krav, som testmiljøet skal leve op til. I dette kapitel beskrives hvilke krav vi har udformet til testmiljøet, og hvilke afgrænsninger vi har til det. 5. Krav Kravene til vores testemiljø er stillet op omkring de problemstillinger og spørgsmål, som vi gerne vil have svar på. Vi har derfor inddelt kravene i følgende kategorier. Krav for overordnet system og design: ) Testmiljøet skal implementeres på en version af XNA, for at få praktisk erfaring med hvilke muligheder der ligger i XNA frameworket. 2) Testmiljøet skal implementeres på et design, hvor de interne moduler har et minimum af afhængigheder til resten af systemet, for at nedsætte påvirkningen fra udskiftende moduler. Krav til moduler 3) Testmiljøet skal indeholde flere Renders for at kunne teste forskellige grafiske optimeringsteknikker. 4) Testmiljøet skal indeholde et realistisk beregnings-tungt modul, der kan bruges til at øge CPU forbruget, og dermed gøre det muligt at teste, hvilke fordele trådning har på en 3DGameEngine. 5) Testmiljøet skal kunne funktionere, selv om flere moduler ikke er tilsluttet systemet, dog kan en nedsat funktionalitet ikke undgås. Krav til renderings teknikker 6) Testmiljøet skal indeholde en render, der benytter en reference renderings teknik. Krav til testmiljøet og moduler i forbindelse med multi-threading 7) Testmiljøet skal kunne køre hele systemet på en tråd for at fastsætte en reference hastighed. 8) Hvert modul skal implementeres, så det er muligt at det køre på en eller flere tråde internt. Side 8/4

9 5.2 Afgrænsninger Udvikling af en komplet 3DGameEngine og gennemteste den vil kræve mere tid, end vi har haft mulighed for i dette projektforløb, og vi er derfor blevet nød til at afgrænse os. I den forbindelse har vi foretaget følgende valg: ) Vi afgrænser os fra at implementere en komplet 3DGameEngine, det er derimod et mål at implementere en testsplatform, hvori vi kan gennemføre vores tests. 2) Vi afgrænser os fra at håndtere alle typer 3D spil, men fokuserer kun på indendørs spil. 3) Vi afgrænser os til udelukkende at fokusere på 3DGameEngines til multi-core'ed PC'er. 4) Vi afgrænser fra at super optimere vores teknikker, således at en direkte sammenligning er mulig med kommercielle Engines teknikker. Det er derimod for os interessant, hvilke teknikker, der kan give en general forbedering. Side 9/4

10 6 Test platformerne I dette afsnit beskriver vi, hvilke testplatforme vi har kørt vores implementerede system og vores tests på. Udover beskrivelserne af maskinerne vurderer vi deres validitet i forhold til den hardware, man normalt finder på PC'er, der kører spil. 6. Test maskine Acer Travelmate 824 Dette er den kraftigste testmaskine, som vi testet på, med 2 cores på hver 2 Ghz og et dedikeret grafikkort(dvs. har ikke indbygget en GPU i chipsættet). Specifikationer: Processor: Intel Core Duo 2, Ghz Ram: 2 Gb PC DDR2 Grafik: ATI Mobility Radeon X6 med 256 MB DDR3 ram - Shader Model 3.. Operativsystem: Windows XP Professional SP2 6.2 Test maskine 2 HP Pavilion dv228ea Denne test maskine er den langsommeste af testmaskinerne, som vi tester vores miljø på. Den har 2 cores af,6 Ghz og et onboard grafik kort, der er en del af motherboard'ets chipsæt og bruger shared ram(dvs. benytter system ram). Processor: AMD Turion 64X2 TL-52 (,6Ghz) Ram: Gb PC DDR2 Grafik(onboard): Nvidia GeForce Go65 med optil 256 MB ram(shared) - Shader Model 3.. Operativsystem: Windows XP Home 6.3 Validitet af testplatformene I dette afsnit kigger vi på, hvor valide vores testmaskiner er i forhold til de PC'er, som bruges til at Side /4

11 spille spil på rundt om i verdenen. Dette gør vi for at kunne bestemme, om vores testplatformer lever op til standarden for de computere, der bruges til 3D Spil og ad den vej kunne bekræfte, at de tests, vi udfører, vil være udført på standard hardware og derfor vil være valide. Dette gør vi ved at benytte Valves' undersøgelse af PC hardware og drivers, der benyttes til spil[survey]. Undersøgelsen startede den 5 november og er på nuværende tidspunkt stadig i gang. I skrivende stund er der '3'96 unikke systemer med i undersøgelsen, hvilket gør den til den største undersøgelse, vi har kunnet finde og få adgang til Test Maskine Denne maskine er den kraftigste af de to testmaskiner, som vi benytter i vores test. Processoren er en 2 GHz Core Duo, som hastighedsmæssigt i følge Valves undersøgelse for CPU'er, er samlet omkring de 2.GHz, hvilket gør vores 2GHz Core Dou til lidt under gennemsnittet, men dog stadigvæk så tæt, at vi ikke mener, at det kan have nogen nævnværdig indflydelse. Hvilket ikke var tilfældet, hvis vores var f.eks. 3GHz. Med hensyn til system ram har denne maskine 2GB til rådighed, hvilket er meget i forhold til gennemsnittet fra Valve undersøgelsen, da vi sammenlagt (Windows, Visual Studio, Engine osv) ikke har brugt over 52MB har størrelsen af ram'en lidt at sige. Grafikkortet er et ATI X6 som hastighedsmæssigt ligger omkring samme niveau[graphic_chart], som størstedelen af de grafikkort, der findes i en gennemsnitlig PC ifølge Valve. Vi mener derfor, at denne maskine repræsenterer ganske godt et gennemsnitligt system, hvilket gør den god som testplatform, da vores tests i den henseende vil have ca. samme hastighed på gennemsnittet af PC'er. Det gør, at vi bedre kan sige noget generelt om en evt. performance forbedring Test Maskine 2 Denne maskine er den langsommeste af vores testmaskiner med en processor på,6 Ghz, hvilket er lidt under gennemsnittet for AMD processorerne i Valves undersøgelse. Med ca. GB system ram ligger denne maskine på gennemsnittet, og i en kategori sammen med næsten 5% af de systemer der er med i undersøgelsen. Grafikortet er et Geforce65, der performancemæssigt ligger i den lave ende. Med den lidt langsomme CPU, gennemsnitlige system ram og langsomme grafikkort, må vi sige, at denne maskine ligger et godt stykke under gennemsnittet for hastigheden på normale PC'er. Side /4

12 6.3.3 Vurdering Af disse to testmaskiner er det klart, at testmaskine repræsenterer den mest gennemsnitlige af de to, hvilket ligger til grundlag for, at de fleste testresultater i denne rapport er fra tests udført på denne maskine. Vi mener derfor at kunne stå inde for, at vores resultater, fra denne maskine, vil være forholdsvis ens med en gennemsnitlig PC. Test Maskine 2 er langsom i forhold til gennemsnittet i undersøgelsen, denne er derfor mindre god at udføre vores store tests på, da den ikke vil give de samme resultater som en gennemsnitlig PC. Dermed er denne mest egnet til indledende tests, hvor resultater blot skal sammenlignes med andre resultater fra samme maskine, eller til tests hvor resultaterne blot skal give en indikation af en fordel eller ulempe. De resultater, vi præsenterer i denne rapport, kommer derfor fra tests udført på Test Maskine, med mindre andet er angivet i afsnittet. Side 2/4

13 7 Støj og fejlkilder I dette afsnit kigger vi nærmere på de forskellige støj og fejlkilder, som vores tests kan have været og har været udsat for. 7. Eksterne fejlkilder Helt generelt igennem de forskellige test har vi forsøgt at minimere forstyrrende kilder, som f.eks. andre programmer der kører samtidigt, ved at lukke alle andre programmer ned, som ikke skal bruges af enten vores test eller af operativsystemet. Det betyder ikke, at vi helt har udelukket muligheden for støj fra andre programmer, hvilket kan strække sig lige fra GUI-Programmer til Drivers. Et aktivt trådløst netkort kan med jævne mellemrum søge efter nye netværk og, hvis driveren ikke er skrevet specielt godt, have en stor negativ indflydelse på vores test. Et GUI- (Graphic User Interface) Program kan også med jævne mellemrum opdatere det grafiske interface, som dermed vil beskæftige grafikkortet med opdateringen. Eller lidt mere bizart, opdagede vi, at et lille GUI-Program med semi-transperant vindue gjorde, at XNA tilsyneladende helt mistede 3D acceleration fra grafikkortet og endte med en hastighed på ca.. Mange af de støj/fejlkilder, vi har fundet, har været nemme at se/finde, da de har givet et forholdsvis stort udslag på vores test. Enten er de fundet ved at hastigheden er væsentligt lavere, end hvad den burde være, eller at hastigheden ikke er den, vi forventede i forhold til en række af test, vi har udført. Side 3/4

14 Støj Illustration : Fejlkilde påvirkning i Busy-wait På Illustration ses et eksempel på, hvordan et af vores testresultater var blevet påvirket af støj. Testen er fra vores Threading tests, hvor vi har to tråde, som hver benytter sig af Busy-waiting. Det er tydeligt, at der er et program, der med jævne mellemrum bruger forholdsvis meget CPU kraft. Fordi begge tråde hele tiden laver noget pga. Busy-wating, ses denne type støj meget tydeligt. Intervallet er på nøjagtigt 25ms, hvilket ikke kan være tilfældigt. Vi fandt desværre aldrig ud af, hvor denne støj kom fra, men det skal siges, at vi heller ikke har set den i de andre tests. Det kan tænkes, at grunden til, at vi først i de senere test, rigtigt har kunnet se effekten af støj er, at de testplatforme vi benytter er dual core'ed og alle de første tests har udelukkende være single threaded. Det betyder, at vi under alle de tidligere test har haft en buffer i form af en ekstra core, som derfor er i stand til at tage sige af andre programmer, der ellers ville kunne have påvirket vores tests direkte. Windows er fundamentalt en ustabil platform at udføre tests på. Dens premeptive multitasking og mange system-servicer, der ikke kan lukkes ned, gør, at vi ikke kan være sikre på, at andre systemer vil køre på samme tid eller periodisk under vores tests. Den nemmeste og bedste måde at komme uden om dette problem er ved at foretage mange målinger og heraf tage gennemsnittet af dem, evt. fjerne store udsving eller køre den pågældene test om, hvis der er for meget støj. En anden god ide er at se, om testene kan gennemføres med samme resultat på et andet tidspunkt, for at se om en evt. konstant påvirkning var til stede under den forudgående test. Grunden til, at vi har valgt at lave de primære test på intel platformen, er, fordi dens cores har fælles level2 cache, mens AMD platformen har dedikeret level2 cache til hver af core'ene. Grunden til, at dette er en vigtig observation, er, at vi ikke kan være sikre på hvilken core vores tråd vil køre på, henover forløbet. Tråden skifter ofte core. Ved det dedikerede level2 cache design hos AMD vil det betyde, at ofte når tråden skifter core, vil dens cache være tom dvs., den ikke indeholder data, Side 4/4

15 som er nødvendig for vores tråd, mens det ligger i den anden. Det medfører ekstra trafik, som igen koster performance. På Illustration 2 ses hvordan en enkelt tråd, som arbejder %, bliver fordelt mellem de to cores. Illustration 2: En tråd på dual core CPU Umiddelbart kan vi godt bede operativsystemet om at lægge denne tråd kun på den ene CPU, hvilket vil løse problemet i vores Single tråd design, men i vores multi trådet design har vi ikke denne mulighed for at låse trådene til en given core, hvor så samme problem opstår. Problemet vil endda være større her, da vi kan være sikre på, at et tråd swap vil trashe cachen for den sidste tråd. 7.2 Interne fejlkilder Man skal være påpasselig med, at de enkelte tests udføres under samme betingelser. Vi får f.eks. en hel anden Frame Rate, hvis vi ændrer opløsningen af FrameBufferen, eller hvis vi vælger at slå antialiasing til. Vores Engine udvikler sig igennem de forskellige tests. Vi får løbende tilføjet mere funktionalitet for hver runde af tests, hvilket er gjort for at give vores test et mere realistisk miljø at køre i og dermed et bedre billede af, hvordan de forskellige teknikker vil opføre sig, i en endnu mere realistisk Engine. Dette betyder, at vi ikke er i stand til at gå tilbage og re-teste teknikkerne og regne med, at vi får det samme resultat igen, med mindre vi tager en ældre version af Enginen frem, som oprindeligt var brugt under testene. Det er selvfølgelig ikke en direkte fejlkilde, men det betyder, at vi skal være varsomme med at re-teste, og at alle vores tests kun er valide i forhold til andre test udført på samme tid og platform. Forhåbentligt skulle der gerne være en tendens til, at det ene stadigvæk er hurtigere end det andet på de nyere generationer af vores Engine, så i det lys skulle det ikke have nogen betydning for validiteten af testene. 7.3 Minimering af fejlkilder For at minimere indflydelsen af fejlkilder har vi fulgt forskellige forholdsregler. Yderligere har vi, Side 5/4

16 hvor det var muligt, udført testene gentagene gange, og herefter taget gennemsnittet af dem for at få elimineret udsving. Hvor det er muligt, har vi derfor også vedlagt standardafvigelse for at vise troværdigheden af testene. En meget stor standardafvigelse vil indikere en test, hvor vi ikke kan sige noget reelt fornuftigt om resultatet (evt. pga. støj), hvor testen måske i sig selv er forkert opstillet, eller fordi det er en indikation af, at den teknik, som vi tester, er meget ustabil. 7.4 Timer præcision En oplagt mulighed for stor til mindre unøjagtighed ved enhver måling, hvor tid er en faktor, er præcisionen af tids tageren (Timer). Vi fandt hurtigt ud af, at den umiddelbare indbyggede timer i XNA ikke kunne give os den nøjagtighed, vi gerne ville have. Der var simpelthen en vis variation mellem, hvornår den sendte sine ticks. Ideen er, at man kan bede XNA med jævne mellemrum at køre en given funktion, men det interval man sætter, skal ses mere som et ønske og ikke som en reelt krav om at køre funktionen, hvilket gør, at der vil komme variationer. For at slippe for disse unøjagtigheder som software timers er udsat for, da operativsystemet fundamentelt ikke kan garantere for, hvornår en eksekvering af programmerne vil foregå, har vi valgt at benytte de meget mere præcise hardware timere. Den hardware timer vi har valgt virker ved for hvert CPU tick, at CPU'en tæller et bestemt register op med en. Det er et 64Bit register for at kunne holde nok værdier til at CPU'en kan køre meget længe, inden den overflower og starter forfra. På en 2GHz CPU betyder det at: GHz=2 9 updates/ sek = sek 292 år 2 9 updates/sek der vil gå 292 år før at timeren overflow'er, det er meget længere tid end vores test, så sandsynligheden for, at vi har genstartete computeren inden da, er ganske overhængende. Præcisionen ifølge [DUNLOP] er på ca. μsek og kan aflæses ned til <μsek. Denne præcision gør, at vi for at opnå et drift på sek, skal lade den køre i 6 sek =.6 dage. Vi har naturligvis valgt at bruge denne hardware timer, som dermed ligger til grundlag for alle tidstagninger, vi har foretaget i dette projekt. Side 6/4

17 8 Overordnet struktur I dette kapitel beskriver vi hvordan et klassisk 3DGameEngine design kan se ud, og hvordan vi har valgt at designe vores testmiljø, for at leve op til de krav vi har fastsat i kapitel 5 (KRAV og afgrænsninger). Herefter sammenligner vi de to designs for at vurdere, hvilke forskelle, fordele og ulemper der er med dem. Til sidst i kapitlet gennemfører vi nogle tests af det overordnede design, og vurderer resultaterne, for at få en ide om performance påvirkningen af vores overordnede design er. 8. Overordnet Design Det overordnede design for en 3D GameEngine er en meget kompleks opgave, fordi det på et tidligt tidspunkt i projektet giver eller begrænser muligheder senere i projektet. Påvirkningerne kan være alt lige fra GameEnginens hastighed til om GameEnginen kan køre, hvis et modul ikke er tilgængeligt. 8.. Den klassiske model På Illustration 8 ses hvordan et 3D GameEngine design kan se ud ifølge Intel[INTEL]. Denne Engine indeholder hvad der menes at være et minimum fra Intel's side, for hvilke komponenter der skal være, og hvordan de skal sættes sammen. Illustration 3: Klassisk 3D Game Engine design[intel2] Side 7/4

18 Strukturen er, selvom den i bund og grund er logisk, kompliceret at få et overblik over, da mange af komponenterne har forbindelse til hinanden, og en ændring i blot en enkelt komponent kan hurtigt påvirke andre på en måde, som man først havde overset. En anden problematik kan være, at der vil være meget, der skal implementeres i de forskellige komponenter, for at få Enginen til at compile, hvilket kan resultere i længere og dyr udviklingstid pga. evt. fejl. I denne struktur er det heller ikke nemt at udskifte et modul, fordi det nye modul skal implementere flere forskellige interfaces og overholde mindst ligeså mange retningslinjer for, hvordan ting skal processeres, hvis et modul helt mangler vil intet sandsynligvis fungere/compile. Disse problemer prøver vi at løse med et andet og i vores øjne mere strømlignet design. Det er tanken, at det, om muligt, ikke vil bruge flere ressourcer, end dem man støder på under komplekse løsninger som vist på Illustration Vores model På Illustration 4 ses en model over vores overordnede design. Engine Initilization Schedular The Game 5. Input Libraries Math Loaders Structures Audio Collision Physics Network Scene-Manager/Graph Message System Render Animation Render #2... Illustration 4: Vores model Vi har valgt at basere vores design på et besked system, der fungerer ved, at moduler kan registrere sig med en prioritet og en type, der bestemmer, hvilke beskeder modulet skal modtage. Beskedsystemet er vist på Illustration 4 ved de blå streger, der viser kommunikationen mellem beskedsystemet (Message System), og de registrerede moduler i GameEnginen. Modulerne kan ikke kun modtage data, men også sende beskeder tilbage til beskedsystemet. Der er altid kun Side 8/4

19 kommunikation mellem systemet og modulerne, aldrig mellem modulerne hver især for at holde afhængigheder på et minimum. De sorte streger, der findes i højre side af illustrationen, viser modulernes adgang til en fælles scene-manager/space Partition-graf. Denne kommunikation er direkte og sker uden brug af beskeder Beskedsystemet Fordelen ved et beskedsystem, der står for kommunikationen mellem modulerne, er, at modulerne ikke kender til hinanden, og dermed heller ikke kan påvirke hinanden gennem afhængigheder. Dette gør det muligt at opfylde flere af de krav, som vi har sat til testmiljøet, primært dem med afhængigheder. Ulempen ved beskedsystemet er, at det sandsynligvis vil blive en smule langsommere end direkte funktionskald mellem modulerne. Som sagt giver beskedsystemet os et minimum af afhængigheder og af den vej lav påvirkning ved udskiftning af moduler, da ethvert modul kun har scenegrafen og beskedsystemet som afhængigheder. Dette mener vi er det minimum af afhængigheder, vi kan have, mens der stadig er mulighed for en performance, som vi mener, er brugbar. Med hensyn til udskiftning af moduler, vil det ikke påvirke resten af systemet, fordi det nye modul kun vil modtage og afsende de samme type beskeder som det gamle modul, derfor vil resten af systemet ikke opdage denne udskiftning. For at have endnu færre afhængigheder, kunne vi have tilgangen til scenegrafen gennem beskedsystemet, det vil sandsynligvis påvirke hastigheden væsentligt, fordi SceneGrafen er en datastruktur som stort set alle modulerne konstant benytter og derfor ville genere uhensigtsmæssigt megen trafik/beskeder. Systemet skal også kunne fungere med et eller flere moduler, der mangler, hvilket er muligt med beskedsystemet, fordi der igen ikke er nogen direkte kobling mellem modulerne. De andre moduler vil udføre deres arbejde dog evt. med nedsat funktionalitet. Et eksempel kan være, at der enten ikke er nogle Renders eller kollisionsmoduler, hvilket påvirker systemet ved, at vi ikke kan se, hvad der sker i testmiljøet, eller ved at man kan bevæge sig igennem væggene. Men de andre moduler som fysik, AI o.s.v. vil stadig arbejde videre under de forhold der er, så AI modulet vil stadig fortælle dens modeller, hvad de skal gøre, og fysik modulet vil fortsat bevæge alle de modeller, der har flyttet sig. Med besked systemet er det også muligt at have flere forskellige Rendere i testmiljøet på samme Side 9/4

20 tid, fordi alle Renderne er moduler, som kobler sig på Besked System og blot modtager samme beskeder. Resultatet vil være, at de alle sammen Renderer deres data oven i hinanden Scheduleren Scheduleren er placeret sammen med beskedsystemet og er den enhed, der bestemmer, hvornår modulerne får CPU tid. Prioriteten af denne eksekvering er bestemt ud fra, hvilken prioritet modulerne har registreret sig med. Hvis man kigger på Illustration 4, betyder tallet i hvert modul den prioritet, som de er blevet registreret med. Scheduleren giver CPU tid efter højest først princippet, hvilket betyder oppefra og ned på illustrationen. Med vores scheduler i designet, er det muligt at køre systemet på en eller flere tråde, fordi scheduleren med en enkelt tråd kan køre alle modulerne sekventielt, og med flere kan give nogle moduler CPU tid parallelt. Den kontrol, som scheduleren har ved at kontrollere eksekveringen af modulerne, vil også gøre det nemmere at udvide testmiljøet til at køre på flere tråde, fordi vi har kontrollen af modulerne samlet et sted Sammenligning af designs De to designs har vidt forskellige fokus Intel's fokuserer på en hurtig og komplet GameEngine, imens vores fokuserer på at kunne bruges til forskellige tests. Fokus området har dermed en kraftig indvirkning på det endelige design. Vores design giver mulighed for, at vi tidligt i implementeringen kan se, om testmiljøet kører og dermed begynde at kigge efter fejl tidligt i forløbet. Det er en klar fordel i forhold til Intel's design, der sandsynligvis kræver mere implementation på grund af alle de afhængigheder komponenterne har til hinanden. Hvis vi havde brugt Intel's design, ville der være en sandsynlighed for, at fejl først opdages senere i projekt forløbet, og dermed en større risiko for at deres indflydelse vil være større. En anden fordel ved vores design er muligheden for at køre flere moduler parallelt, samtidig med at man kan overskue konsekvenserne, og dermed bedre udnytte ressourcerne i moderne multi-core CPU'er. Her vil Intel's design have problemer, fordi komponenterne har mange afhængigheder til hinanden, og hvis flere af dem skulle køre parallelt, er det meget svært at overskue konsekvenserne af det. En tredje ting som vores design gør muligt for os, er at kunne udskifte moduler nemt, fordi modulerne ikke har afhængigheder til hinanden. Designet gør samtidig, at vi kan køre vores Side 2/4

21 testmiljø, hvor et eller flere moduler mangler i systemet. Disse ting er noget som Intel's design vil have problemer med, fordi komponenterne er så tæt knyttet, at hvis de ændrer sig eller helt mangler, vil det påvirke alle de komponenter, som har afhængigheder til dem. Hvis nogle komponenter helt mangler vil GameEnginen måske slet ikke kunne køre. Vores design understøtter også flere moduler af samme type. Det kan være flere rendere, som skrevet tidligere eller f.eks. flere forskellige AI moduler, der hver håndterer forskellige typer af modeller. Dette er igen heller ikke muligt i Intel's design, med mindre man restrukturerer designet for at få plads, hvilket igen giver flere afhængigheder i systemet. Vores design er desværre ikke helt perfekt. De ting som vi har valgt at lægge fokus på i designet kommer med en pris. Vores beskedsystem har et overhead i forhold til de direkte kald som Intel's design har, så i en ren sekventiel kørsel med alle moduler, burde vores design være det langsomste. For at få en ide om hvor langsomt vores besked system er i forhold til de direkte kald, har vi udført nogle tests. 8.2 Test og evaluering I dette afsnit udfører vi nogle tests, som viser hvor stor tidsforskel der er på at bruge direkte funktionskald, beskeder og et simpelt beskedsystem Eksperimenter Følgende tests er udført for at se, hvilken indvirkning det har at bruge beskeder og et beskedsystem i forhold til direkte funktionskald, som man bruger i det klassiske design. Alle de følgende tests er udført på Test Maskine 2. Første test fokuserer på hastighedsforskellen på et funktionskald med et forskelligt antal variable mod et funktionskald med en besked, der indeholder en række variable. Herefter fokuserer vi på en situation hvor dataerne, der sendes med funktionskaldet, gemmes i den pågældende klasse til senere brug, noget som sandsynligvis vil blive aktuelt, når et modul skal gemme sine arbejdsopgaver, indtil modulet får CPU tid til at processere dem. Sidste test fokuserer på, hvor meget tid der bruges, hvis beskederne skal gennem et beskedsystem for at blive sendt videre til et modul, der kan processere beskeden. Resultaterne og kode udsnit for disse tests, findes i bilagsrapporten under overordnet design. Side 2/4

22 8.2.. Det overordnede scenarie Disse tests er alle udført med '' kald, som er gentaget 4 gange for at se, om dataerne er forholdsvis ens. Tidstagningen er over alle '' kald og ikke for hvert kald, for at minimere støjen. Med mindre andet er angivet, er det følgende data, som vi benytter i disse tests.. int's 2. 5 int's 3. 5 int's og 5 strings 4. 5 int's, 5 strings og Vector3 struktur fra XNA 5. 5 int's, 5 strings og 5 Vector3 strukturer fra XNA Disse typer er valgt, fordi vi mener, at de med stor sandsynlighed vil blive brugt i det færdige system. Int's er med, fordi det er en simpel valuetype, som bruges meget ofte. Strings er med, fordi det i C# er en reference type, som dermed overføres pr. reference og ikke pr. value, og Vector3 er en struktur i XNA, som benyttes meget i forbindelse med 3D og er desuden en value type Hastighedsforskel mellem parameter kald og besked kald Scenariet for denne test er: funktions kald udføres fra en klasse til en anden, den afsendende klasse har instantieret variabl(erne) med data før testen starter, og den modtagne klasse processerer ikke dataerne på nogen måde. Dette resulterer i, at vi udelukkende måler tiden, det tager at foretage et funktions kald. Side 22/4

23 27,5 26,258 25, 22,5 Tid i msec 2, 7,5 5, 3,855 2,5, 7,5 5, 2,5,,249,8,257,32 F F2,878,3,85,32,252,,252,2,253,7,249,7,249,7 F3 F4 F5 M M2 M3 M4 M5 Illustration 5: Funktionskald med parameter og beskeder Illustration 5 viser gennemsnitstiden for '' funktionskald med hhv parametre F# og beskeder M#, samt dataerne fra punkt til 5 i (det overordnede scenarie). Prikkerne og tallene i bunden af hver søjle viser standardafvigelserne for de pågældende tests. Kaldene M til M5 (en besked) ligger alle meget stabilt, hvilket er forventet, fordi de alle overfører en refernce til en besked. Ved kaldene F til F5 (individuelle parametre) ses en stigning i forhold til mængden af data, som funktionen overfører ved parametre. Overførslen af int's (Fog F2) er hurtige og ligger på en hastighed, der minder om reference overførslen af beskederne. Dette er fordi int's har samme størelse som referencerne til beskederne, hvilket ikke giver os nogen stor forskel. F3 begynder at være langsommere, fordi funktionen nu skal overføre 5 int's og 5 referencer til strings, i modsætning til en reference i M3. Ved F4 og F5 er tiden steget drastisk, i forhold til F-F3, imens M4 og M5 holder sig på samme hastighed som M og M2. Denne forøgelse i tidsforbrug, er på grund af Vector3 strukturen fra XNA frameworket. Fordi Vector3 er en struktur der indeholder 3 floats og en del funktioner, er det kompleks data type, men i stedet for at være en reference type har Microsoft valgt at gøre den til en value type. Dette indebærer at Vector3 strukturerne kopieres, når de bruges som parameter i et funktions kald, hvilket er grunden til at F4 og F5 bruger markant mere tid end F-F3. Vi kan konkludere, at Vector3 strukturen bruger meget tid, når de overføres som en parameter i et funktionskald. Sprøgsmålet er så, hvordan ser det så ud for nogle af de andre meget benyttede strukturer i XNA, og hvordan vil en sammenligning se ud, hvis det kun er Vector3 strukturer uden ints og strings, vi skal overføre? Side 23/4

24 Uddybende forsøg af XNA strukturer Her udfører vi samme test igen, blot med ny data, som er følgende:. Matrix 2. BoundingSphere 3. Vector Vector3 2, 8,468 8, 6, Tid i msec 4, 2,,9, 8, 6,223 6, 5,67 4, 2,,,263,255,257,25,38,29,49,46,63,2,3,9 F F2 F3 F4 M M2 M3 M4 Illustration 6: Funktionskald med parameter og beskeder m. XNA data På Illustration 6 ses samme tests som tidligere med hhv parametre (F) og beskeder (M), men med de nye data. Kald M til M4 ligger, med de nye data, igen stabilt. Kald F(Matrice) er som forventet den data, der tager længst tid, fordi den indeholder 6 float's samt funktioner til at manipulere matricer. Ved sammenligning er M derfor mere end 6 gange hurtigere end F. F2 er en BoundingSphere, der indeholder i bund og grund en vector3 struktur, samt en float til radius, hvilket gør den en smule langsommere end F3, der kun indeholder en enkelt Vector3. F4, der indeholder tre Vector3 strukturer, er derfor langsommere end både F2 og F3. Hvis vi sammenligner F til F4 med M til M4,er det igen klart, at funktionskald med referencer til beskeder er markant hurtigere end funktions kald med XNA strukturer som parametre. Side 24/4

25 Ud fra resultaterne fra Illustration 5 og Illustration 6 må vi konkludere, at det kan være en fordel at sende beskeder med data, i stedet for normale parameterkald især i forbindelse XNA's egne strukturer. Når det med disse data, kan være en fordel at sende beskeder, hvilken effekt er så mulig at opnå, hvis modulerne der modtager data'erne/beskederne, skal lagre dem til senere processering, såsom et beskedsystem, der vil fungere med postkasser til hvert modul? Hastighedsforskel når data beholdes af modtager klassen Dette scenario er en udvidelse af (hastighedsforksle mellem funktionskald og beskeder), hvor data'erne gemmes i modtager klassen, til senere processering (postkasse). Dette testes på 3 måder:. Parameterkald hvor parametrene gemmes i modtager klassen som variable (F). 2. Besked kald, hvor beskedens data gemmes i modtager klassen som variable (MV). Dvs. data udtrækkes fra beskeden. 3. Besked kald, hvor beskedens reference gemmes i modtager klassen som en variable (MM). Først sammenligner vi resultaterne (F) med (MV), og herefter sammenligner vi (F) med (MM). Illustration 7 Og Illustration 8 viser gennemsnits tiden '' funktions kald med hhv parametre F# og beskeder MV#, samt dataene fra punkt til 5 i (det overordnede scenarie). Prikkerne og talene i bunden af hver søjle, viser standard afvigelserne for de pågældende tests. Side 25/4

26 7, 66,56 65, 6, 55, 5, Tid i msec 45, 45,293 43,395 4, 35, 32,49 29,3 3, 25, 23,68 2, 5,, 5,, 6,862 5,672 2,943,876,6,56,284 F F2 F3 F4 2,67 2,8,9,45,8 F5 MV MV2 MV3,435,36 MV4 MV5 Illustration 7: Funktions Kald med data opbevaring F og F2 klarer sig godt ved at være lidt hurtigere end MV og MV2, hvilket viser, at det ikke er en fordel at overføre en besked med int's, blot for at gemme værdierne i kaldet. Dette ændre sig i F3, hvor det ses, at MV3 er næsten en tredjedel hurtigere end F3, hvilket også gør sig gældende for både MV4/F4 og MV5/F5. På Illustration 8 ses sammenligningen mellem parameterkaldet F# fra før, og beskedkald MM# hvor referencen til beskeden gemmes i den modtagne klasse. 7, 66,56 65, 6, 55, tid i msec 5, 45, 43,395 4, 35, 32,49 3, 25, 2, 5,, 5,, 5,672 2,943,876,6,56,284 F F2 F3 F4 2,67 F5 5,692 4,986 4,994 4,993 4,983,375,22,52,53,7 MM MM2 MM3 MM4 MM5 Illustration 8: Funktions Kald med data opbevaring 2 Det er tydeligt og ikke overraskende at det er en fordel at gemme referencen til beskeden ved større Side 26/4

27 mængder af data. Hvis der kun sendes én int, kan det ikke betale sig, men ved 5 int's er hastigheden omkring den samme, og når der sendes en Vector3 struktur (F4/MM4), er det 9 gange hurtigere at opbevare data'erne med beskeden. Vi kan, som forventet konkludere at med større mængder af data, er det meget hurtigere at bruge en besked i funktionskaldet og gemme referencen, til når klassen eller modulet får CPU tid. Da vi har set, at det ikke nødvendigvis er meget langsommere at bruge beskeder til at sende data rundt med, hvilken indvirkning vil det så have, hvis beskeden skal igennem et simpelt besked system, der skal teste, hvilken modtagerklasse, en besked skal ud til? Hastighedsforskel med simpelt besked system Scenariet for denne test er: En klasse sender en besked til et simpelt beskedsystem, der kigger på en variable i beskeden for at vurdere, hvor den skal sendes hen. Beskedsystemet kalder derefter den modtagende klasse med beskeden, der afslutter med at gemme en reference til beskeden i en member variable. Denne test giver os derfor en idé om, hvor meget hastighed vi vil miste ved at bruge et beskedsystem. 7, 66,56 65, 6, 55, Tid i msec 5, 45, 43,395 4, 35, 32,49 3, 25, 2, 5,, 5,,,68 9,993 9,974,586 9,986,62,55,46,9,7 BS BS2 BS3 BS4 BS5 5,672 2,943,876,6,56,284 F F2 F3 F4 2,67 F5 Illustration 9: Parameter kald i forhold til et simpelt besked system På Illustration 9 ses parameterkaldet F# fra kapitel (hastighedsforskel når data beholdes af modtager klassen) og resultaterne fra det simple beskedsystem BS#. Side 27/4

28 Det ses her, at beskedsystemet(bs og BS2) er betydeligt langsommere end parameterkaldet(f og F2), hvilket viser, at der tabes performance, hvis beskederne indeholder få simple datatyper. Men når der skal sendes større mængder af data(f3/bs3, eller hvis dataene er strukturer fra XNA(F4/M4 og F5/M5), er der meget at spare, selv om beskederne skal igennem et beskedsystem vurdering Vi kan ud fra disse tests konkludere at data'erne, der skal være i beskederne, er en vigtig faktor for hvornår, og hvor meget performance der mistes ved at benytte beskeder og et beskedsystem. Vi kan samtidig konkludere, at XNAs strukturer er tunge at bruge som parametre i et funktions kald. For at minimere indvirkningen fra at oprette og nedlægge beskeder, kan det være en fordel med en besked pool med tomme beskeder, så der ikke bruges for meget processor kraft på at oprette og slette beskederne, hvilket hurtigt vil kunne forbruge en evt. forbedring. Beskederne i denne pool skal så indeholde variabler som kan bruges til at overføre data mellem modulerne. Det betyder dog ikke, at vi skal have utrolige store beskeder, men derimod at vi skal have en overordnet besked, der bliver arvet fra, hvor der så findes x-antal specifikke beskedtyper ud fra denne. Dette kan være Collision beskeder, AI beskeder osv. Beskedpool'en vil komme med ekstra overhead til at håndtere og vedligeholde pool'en. Som vi så i de forgående tests, kan og vil det hurtigt blive en fordel at sende et samlet objekt, i dette tilfælde en besked i stedet for at sende x-antal parametre. Med den ekstra overhead fra besked-pool'en vil det derfor betyde, at vores beskeder helst skal være forholdsvis store. I vores testmiljø er det Collision modulet der sender flest beskeder, og disse beskeder er forholdsvis store. I korte træk indeholder de 5 referencer, 5 Vector3, matrix, plus en liste over kolliderende polygoner. Målet med besked systemet er at være i stand til at afkoble modulerne fra hinanden. Hvis dette resulterede i en alt for stor hastighedsstraf, kunne vi være nødt til at ændre dette design. Udfra vores tests og vores beskeders størrelse mener vi, at det er rimeligt at antage, at beskedsystemet enten ikke vil være langsommere eller kun have et lille overhead i forhold til funktionskald. Denne anskuelse giver os derfor ikke nogen grund til at ændre det design, vi har valgt i forhold til de elementer, vi designmæssigt får ud af det, tværtimod. De elementer vi får af dette design er: Det har været utroligt nemt at fjerne og tilføje nye moduler. I de senere tests, hvor vi er interesseret i forskellige aspekter af Enginen, har det været nok at udkommenterer en enkelt linje for helt at Side 28/4

29 fjerne et modul fra systemet. At lave nye moduler og tilføje dem har været stort set lige så nemt, da vi kun behøver at arve fra den abstrakte klasse modul og tilføje en enkelt linje, som registrerer det nye modul i scheduleren. I denne proces er ingen af de andre moduler blevet berørt. På grund af den meget lave, til slet ingen, kobling mellem modulerne har gjort det nemmere at tråde designet, så det går fra at være et enkelt trådet sekventielt design til et multitrådet design. 8.3 Del konklusion Vi kan konkludere, at vores design, baseret på et beskedsystem, ikke nødvendigvis er meget langsommere end et klassisk design og samtidig giver det os en del muligheder i systemet. Med de få afhængigheder modulerne, gennem designet, har til systemet og hinanden, kan vi uproblematisk indsætte, fjerne og modificere moduler uden at de påvirker andre moduler, men blot nedsætter eller tillægger funktionalitet til systemet som en helhed. Side 29/4

30 9 Rendering I dette kapitel vil vi se nærmere på forskellige Scene Management metoder og optimeringer. Spørgsmålet vi gerne vil have besvaret er, om vi med succes kan benytte de ældre teknikker til rendering, dog som er modificeret til en vis grad. Til det har vi brug for at finde ud af, hvordan og i hvilken retning vi skal modificerer teknikkerne, således de kan benyttes. Der vil altid være en øvre grænse for, hvor mange polygoner en given scene kan indeholde, i form af hvor hurtigt grafikkortet er osv. Situationen vil være den, at f.eks. verden-geometrien vil være alt for stor til at den hele kan tegnes med en fornuftig frame-rate. Det er med andre ord en vigtig del af Scene Management at filtrere så meget geometri væk som muligt, der ikke kan ses, inden denne bliver tegnet. Tanken er selvfølgelig, at desto mere effektiv denne proces er, desto mere detaljeret geometri kan vi benytte, uden at vi overskrider grænsen for, hvor mange polygoner, der kan tegnes i en scene. GPU'erne i dag er meget effektive til filtrering og clipping af både polygoner og pixels, som ikke kan ses. Men før GPU'en kan gøre dette, skal al denne data først sendes til GPU'en, herefter skal den så behandles hele vejen op til, hvor polygonerne er blevet transformeret, før en beslutning kan tages, om polygonerne skal tegnes, clippes eller helt filtreres fra. Det samme gælder for pixelene, men her er vi kommet endnu et skridt videre i GPU'en og her derfor også brugt længere tid. Derfor er det vigtigt, at vi har nogle algoritmer og datastrukturer, som er i stand til hurtigt at give en måske grov ide om, hvad der kan ses, og hvad der ikke kan ses, så vi på den måde undgår at bede GPU'en om at tegne noget, som i virkeligheden ikke kan ses. Et biprodukt for disse test er, at vi får lavet datastrukturer, som kan og skal benyttes andre steder i Enginen. Stort set alle dele af en Engine er interesseret i hurtigt at kunne identificerer, hvilket samhørighedsforhold objekter/geometri har mellem hinanden. Disse dele er for at nævne nogle stykker: Collision Control, Physics, AI osv. Collision Control, hvilke objekter støder ind i hinanden, Physics f.eks. skal vide, hvilket underlag bilen kører på, mens AI'en f.eks. skal vide, hvilke spillere, den måske kan se, og derfor skal udføre flere komplekse teste for at finde ud af, om disse virkelig er synlige osv. Det er et delmål at identificere metoder, som er velegnet til disse nævnte opgaver. Fordi vi tager udgangspunkt i Renderingen, vil den kunne give os en direkte idé om, hvor hurtigt vores datastruktur/algoritme er i form af hvor mange, vi laver. Tanken er også, hvis vi kan udnytte noget, som vi alligevel skal lave for at kunne rendere scenen Side 3/4

31 hurtigst muligt, som også kan benyttes i de andre dele i vores Engine, så vi vil få dette ekstra arbejde gratis, om man vil. Fremgangsmåden for de forskellige eksperimenter er, at der vil være et lille eksperiment, som vil sporer os ind på, hvordan vi skal takle det at sende geometridata til grafikkortet og i det hele tages i hvilken retning vi skal bevæge os i. Herefter vil større eksperimenter komme, som vil teste om den retning det lille eksperiment peget også er den rigtige. 9. Lille eksperiment Dette eksperiment skal bruges til at se i hvilken retning vi skal gå med håndteringen af geometridata. Der er to måder at få grafikkortet til at tegne geometri. Den ene er at have det hele pre-genereret og liggende i grafikkortet og så bare bede om at tegne de forskellige meshes. Mens den anden er, at generer geometrien on the fly, som grafikkortet skal tegne. De tests, vi vil lave, er at tegne et mesh med: VertexBuffer med IndexBuffer. VertexBuffer uden IndexBuffer. Sende alle poygonerne til grafikkortet. VertexBuffer og sende Indexes til grafikkortet. Spørgsmålet er så: Giver det grund til at arbejde videre og i hvilken retning? Nedenunder ses objektet vi brugte til at udføre vores lille eksperiment. Det er et objekt med forholdsvis mange vertices 276'24 fordelt på 92'8 faces i et mesh. Det har en texture. Objektet kommer fra DirectX SDK og hedder Scanner.x. Side 3/4

32 Illustration : Object til "Lille eksperiment" i SceneManagement Valget med kun at have et mesh er for at minimerer andre faktorer, der tager tid. Hvis vi havde flere meshes, ville vores test blive påvirket af tiden, det tager at omstille og reinitialisere grafikkortet til at tegne et nyt mesh. Dette er en anden problemstilling, som vi vil kigge nærmere på senere. 9.. Test resultater Nedenunder ses testresultater for, når mesh'et ligger udelukkende på grafikkortet: Med VertexBuffer og IndexBuffer, TriangleList 227,6 227, , , ,62 227,67 227, ,6475 Med VertexBuffer og uden IndexBuffer, TriangleList 227, , , , , , , ,643 AVG AVG Som det kan ses så er hastigheden stort set den samme, om vi bruger IndexBuffer eller ej. Grunden til dette er, at VertexBufferen allerede er genereret således, at den indeholder triangles i den rigtige rækkefølge uden overlap, dvs. VertexBuffer[], VertexBuffer[] og VertexBuffer[2] udgør en triangle og VertexBuffer[3], VertexBuffer[4] og VertexBuffer[5] udgør en triangle osv. IndexBufferen vil så bare tilføje et lille ekstra overhead på, ved først at slå op i IndexBufferen for at se, hvilken Vertex der kommer næste gang osv. Nedenunder ses testresultaterne for at sende geometri data'er direkte til grafikkortet når den skal tegnes: Side 32/4

33 Uden VertexBuffer og uden IndexBuffer, TriangleList 72,97 72,5964 7,854 72,7678 7,752 72,372 72,5278 7,8642 Med VertexBuffer og genereret IndexBuffer, TriangleList 89,476 89,42 89,262 88,972 89,843 89,955 89,388 89,426 AVG AVG ,27 Vi ser en frame rate drop på ca. 58 for når vi sender polygonerne on the fly. Fordi vi kun sender IndexBufferen, som er mange gange mindre end VertexBufferen i antal bytes, ser vi godt nok, som forventet, en forbedring, men det er stadig ikke meget, der er stadigvæk et drop på 38. Det er tydeligt at se, at det ikke er nogen god ide. Frame raten er ganske enkelt alt for lille. Vi vidste godt, at vi ville se en forringelse af frame raten, men vi regnede med, at det ville være et drop, som vi kunne vinde tilbage ved kun at tegne den synlige geometri. Nedenunder ses testresultatet for, hvis vi halverer den genererede IndexBuffer. Med VertexBuffer og genereret IndexBuffer ½, TriangleList 46,2632 4, ,34 46, ,55 44,426 46,269 43,48 AVG Selvom vi har halveret IndexBufferen får, vi mod forventning, ikke en fordobling af frame rate'en. Vi får kun ca. 62% forbedring, og det skal ses i lyset af, at stadigvæk kun er 44 langt fra de 227. Dvs. i dette tilfælde, hvor vi simulerer, at vi kun tegner den synlige geometri (det vil altid være ca. kun halvdelen af det, vi kan se, resten vil være på bagsiden) får vi ikke nogen forbedring, vi kan bruge til noget. Det er med andre ord bedre at tegne hele objektet med Vertex- og IndexBuffer, end det er kun at tegne synlig geometri ved at sende denne direkte til grafikkortet. Nedenunder ses test for hvilken effekt det har at gøre IndexBufferen mindre, når den ligger på grafikkortet. Side 33/4

34 Med VertexBuffer og IndexBuffer ½, TriangleList 327, , , , , ,93 327,64 327,673 Med VertexBuffer og IndexBuffer ¼, TriangleList 383,89 385, , ,92 38, , ,98 383,5993 AVG AVG Her ses en reel forbedring, ved halvdelen får vi 43% og ved en kvart IndexBuffer får vi 7%. I forhold til hvor vi sendte en halv IndexBuffer til grafikkortet, er det en forbedring på 226%. Testene peger på, at vi skal finde ud af, om vi kan benytte algoritmer, som kan håndtere data'erne, som ligger fast på grafikkortet. Nedenunder ses testresultater for frame rate'en, når vi deler IndexBufferen op i mindre og mindre dele. Både Vertex- og IndexBufferen ligger på grafikkortet og bliver ikke ændret, efter de er blevet sendt til grafikkortet. IndexBufferen er hel, dvs. der bliver ikke skåret i antallet af triangles, der skal tegnes. IndexBuffers : : 2 : 3 : 4 : 5 : 6 : 7 : 8 Avg. 227, , , , , , , , , , , , , , , , , , , , ,65 227, ,64 227, , , , , , , , ,65 227, , , , , , , , , , , , , , ,64 227, , , , , ,67 227, ,64 227, , , , , , , , , , , , , , ,63 227, , , , , , , , , , ,44 IndexBuffers : : 2 : 3 : 4 : 5 : 6 : 7 : 8 Avg ,4 225,22 225,57 225, , ,6 225,55 225, , 5 224,78 224, , , , , , , , , , ,66 22,75 27, , ,76 24,54 22, 87 2, ,588 25,2 2, ,858 25, , ,335 2, , ,293 96,646 95,37 93,26 95, ,946 94,754 95, ,222 8,4724 8,573 79,527 8,952 83, , , , ,726 8,25 7,568 7,223 9,2666 9,423 9,992 6,685 8, , , , ,84 86, , ,422 86, , ,427 4,8726 4, ,399 42,37 42,934 42,593 42, , , , , ,2 226, , , , , Vurdering af resultater Det er helt tydeligt, at enhver form for manipulation af bufferne under renderingen vil resultere i et alvorligt performance tab. Det er derfor ikke en mulighed at manipulere disse buffers, som man gjorde i gamle dage hvor det effektivt kunne bruges, som f.eks. i Doom2, hvor man brugte et BSP (Binary Space Partioning) træ til at bestemme, hvilke polygoner der skulle renderes. Side 34/4

35 Derimod ses kun et ringe performance tab, hvis objektet fra starten er delt op i x-antal dele via xantal indexbuffers, selv ved en meget høj opdeling. Selv ved en opdeling på indexbuffers ses et performance tab på kun.48% (se formel nedenunder) =98.52 % dvs. et tab på % % =.48 % De 224 er taget fra opdelingen af indexbufferen i stykker, mens de 227 er taget fra resultatet med en hel indexbuffer. Nedeunder ses kurven for opdelingen af indexbuffer kontra (Frames Per Second). Y-akslen er (Frames Per Second), og X-akslen er antal af indexbuffers. IndexBuffer opdeling 23, 22, 2, 2, 9, 8, 7, 6, 5, 4, 3, 2,,, 9, 8, Illustration : IndexBuffer opdeling Som det kan ses på Illustration, er der kun en lille forringelse af performance, selv ved en meget aggressive opdeling af indexbufferen. Ved at dele indexbufferen op i ' stykker får vi, at der i hver del kun er 276 vertices, hvilket svarer til 92 polygoner. En opdeling, hvor der vil være ca. ' vertices dvs. ca. 33 polygoner, vil kun resultere i et performance tab på.4%, hvilket er så lavt, at det ikke har noget reelt at sige med hensyn til performance tab. Resultaterne for den sidste test er så entydige, at hvis vi på CPU niveau, vil udføre tests på, hvilke dele af et objekt, der kan ses, og hvilke der ikke kan så er den eneste måde, vi kan gøre dette, når det skal tegnes efterfølgende, ved at lave denne indexbuffer opdeling på forhånd. Der er en begrænsning på hvor mange dele, eller rettere sagt, hvor mange indexbuffers, der kan laves, da grafikkortet har et max antal indexbuffers, det kan have. Side 35/4

36 For vores testplatform ligger grænsen for antal af indexbuffers på ca. 9'442. Det er ligegyldigt, om disse indexbuffers indeholder data eller ej. Når Enginen prøver at lave indexbuffer nummer 9'443, kommer der en exception, der fortæller, at vi er løbet tør for ram. Da selve computeren ikke er nær ved at være løbet tør for ram, må det antages, at der bliver refereret til grafikkortet. Da grafikkortet i dette tilfælde har 52MB ram er det yderest usandsynligt at der er reelt tale om en mangel på ram. Det er derfor mere sandsynligt, at der er tale om en form for hard limit på, hvor mange indexbuffers, der kan håndteres. Denne test blev udført, hvor vi enten havde et stort set tomt grafikkort, og et som havde mere eller mindre data liggende. Alle med samme resultat. Dvs. på grund af denne hard limit så kan vi ikke bare hovedløst segmentere objekterne. 9.2 Generelle optimeringer Dette afsnit indeholder optimeringer som er af en generel art, dvs. de kan bruges i alle eller de fleste tilfælde, ligegyldigt hvilke andre optimeringer, der måtte blive benyttet Fjernelse af redundante vertices Vi kan ikke være sikre på, at de meshes, der bliver loadet ind i vores Engine, er optimerede. De kan som f.eks. Occucity og Scanner være lavet således, at de har en vertex for hvert index i IndexListen. For et objekt som er sammenhængende, betyder det, at der vil være mange vertices, som er ens. f.eks. to trekanter vil kunne dele 2 af deres vertices, se illustrationen nedenunder. Vertex 5 Vertex 6 Vertex 3 Vertex 6 Vertex 3 Triangle 2 Triangle 2 Triangle Triangle Vertex 4 Vertex Vertex 2 Vertex Vertex Triangle list Umiddelbart vil vi forvente at vi først og fremmest vil spare ram specielt på grafikkortet. En vertex fylder meget mere end et index i indexbufferen. En vertex har position, normal, texture-koordinat Side 36/4

37 og en farve (de kan sagtens have mange andre attributter), dvs. den fylder ca bytes=32bytes mens et index fylder 4bytes. Vi vil se en performance straf, fordi polygonerne i objekterne, vi bruger, ikke ligger ved siden af hinanden hverken IndexBufferen eller VertexBufferen, hvilket betyder, at GPU'en bliver nødt til at springe rundt i ram'en for at finde de enkelte vertices, i forhold til tidligere hvor den kun skulle læse dem linært. SD-Ram (som bruges overalt i dag) er ikke god til at springe fra en vilkårlig adresse til en anden, derimod er den god til at læse linært dvs. adresse +, adresse +, adresse + 2 osv., hvilket den stort set kan gøre for hvert clock-tick. Så når vi introducerer spring i vertice'ene vil det betyde, at ram'en skal bruge forholdvis lang tid, for hvert spring vi har tilføjet. Husk på, at vi stadigvæk tegner polygonerne ved at læse 3 vertices for hver trekandt/polygon (triangle-list), frem for triangle-fan som læser 3 vertices for første poygon, mens den næste polygon laves ud fra de 2 forrige, dvs. kan lave en polygon for hver efter følgende vertex Test og Resultater Vi har lavet to tests, den første er med et objekt, som er forholdvis stort, så det er nemmere at se resultaterne. Den anden test er med en scene, som indeholder objekter, som er alle forholdsvis store. Første test har 92'8 polygoner, hvilket er et højt polygon objekt i spil verdenen, hvor objekterne typisk har ' 5' polygoner. Anden test har 8'78 polygoner, hvilket igen er mange. f.eks. det nye spil X3 har max ca. 3' polygoner i deres scener. Alle testene er i stand til at ligge i grafikkortets ram, dvs. de bliver ikke påvirket af at det må benytte system ram'en til midlertidigt lager. objekt TriangleList: Vertices 276'24 8'839'68bytes + Indexes 276'24 Vertices 77'896 Indexes 276'24 '4'96bytes 9.48MB 2'492'672bytes + '4'96bytes 3.43MB Vertices reduktion på ca. 7.8% Hastigheds forbedring på ca. 23.5% Ram forbrug forbedring på ca. 63.8% Side 37/4

38 Illustration 2: Objekt for vertex reduktion Screenshot'et viser hvordan scene med det ene objekt ser ud. objekter TriangleList: Vertices 2'435'54 77'924'928bytes Indexes 2'435'54 Vertices 522' '74'66bytes 83.6MB 6'79'232bytes + 46 Indexes 2'435'54 9'74'66bytes 25.23MB 85 Vertices reduktion på ca. 78.5% Hastigheds forbedring på ca. 84.8% Ram forbrug forbedring på ca. 69.8% Illustration 3: Høj polygon scene Screenshot'et viser hvordan scene med de objekter ser ud. Side 38/4

39 9.2.2 Del konklusion Ved fjernelse af redundante vertices er det muligt at spare meget ram og samtidig få en stor performanceforbedring ud af det. Grunden til, at vi får mod forventning får denne performanceforbedring, er sandsynligvis at GPU'en har en eller anden form for cache, hvilket betyder, at den ikke behøver at hente alle vertice'ene fra ram'en, da vi genbruger dem, og af den vej er i stand til at have cache hits for de ens vertices, hvilket den ikke havde mulighed for tidligere, da alle vertice'ene var forskellige set fra IndexBufferens synspunkt. Det er derfor næsten unødvendigt at nævne, at alle objekter skal igennem denne optimering, hvor vi fjerner redundante vertices. Side 39/4

40 Renders Resultatet af eksperimentet i kapitel 9.. fortæller os, at fremgangsmåden for alle optimeringer skal udføres således, at der ikke vil være nogen form for dynamiske ændringer af hverken VertexBufferene eller IndexBufferne, da dette vil medføre en drastisk hastighedsstraf. Det er derimod stort set ligegyldigt, fra et hastigheds synspunkt, at dele bufferne op i mindre dele. Selv ved mange meget små dele ses kun en ringe forringelse af hastigheden. Derfor skal alle Bufferne pregenereres, hvorefter det er op til en underliggende algoritme at bestemme, hvilke buffere der skal bruges hvornår. Ud fra dette kan vi allerede sige, at det ikke vil være muligt at benytte mange af de teknikker, der blev brugt i gamle dage, hvor Engine programmørerne ikke havde den luksus at have dedikeret hardware til 3D grafik (moderne grafikkort). Alle disse teknikker blev brugt til at minimere antallet af polygoner, som skulle tegnes, hvilket stadigvæk er et mål i sig selv, men de blev udført per polygon basis, hvilket ikke er muligt med et moderne grafikkort, uden at der medfølger en hastighedsstraf. I gamle dage var man begrænset til udelukkende at bruge CPU'en til at tegne al grafik, derfor gav det fin mening at benytte denne til at reducere så meget som muligt af geometrien, såldes at der kun blev tegnet de polygoner, som var absolut nødvendige. Det betyder, at hvis vi f.eks. tager en scene, som vil tage 5sek for GPU'en at behandle og sek for CPU'en at sætte op dvs. i alt 6sek, og sammenligner det med en meget smart algoritme til at fjerne alle polygoner, som ikke kan ses, hvor GPU'en bruger sek mens CPU'en bruge sek dvs. i tal sek, vil vi ikke se nogen forbedring. En knap så smart algoritme, som måske kun fjerner objekter, som slet ikke er inde i scenen, og derfor bruger 2 sek på GPU'en mens CPU'en kun bruger 2 sek dvs. i alt 4sek. Pointen er at finde en balance mellem tiden det tager at sætte scene op til GPU'en og den tid GPU'en vil bruge på at renderer den. Spørgsmålet er så, om det er muligt at benytte disse ældre teknikker? Dog ændret så de tager højde for hvordan et moderne grafikkort virker, og den nye sammenhæng mellem at sætte scenen op og rendere den. Teknikkerne vi vil se på er Spatial-partioning i form af: Simple render (vores reference) BSP tree Oct-tree Side 4/4

41 Valget af disse teknikker er, at stort set dem alle har været brugt til at være kernen af forskellige Engines, eller også har de været brugt til anden form for Space-partitioning.. Teori og Analyse Fælles for alle teknikkerne er, at de alle har med Culling at gøre. Culling er, hvor vi tester kameraets Viewfrustum op imod objekternes placering, rotation og størrelse for at bestemme, om objektet kan ses af kameraet eller ej. Hvad der ændrer sig igennem teknikkerne er, hvor aggressive de er, fordi vi helst vil undgå at tegne geometri, som ikke kan ses, dvs. befinder sig uden for Viewfrustum'et Viewfrustum Kamera Illustration 4: Culling.. Simple-Render I vores Simple-Render kigger vi udelukkende overordnet på objekterne. Dvs. hvis et objekt bare delvist er inde i Viewfrustum'et såsom objekt, 2 og 4 på Illustration 4, så vil hele objektet blive renderet, mens objekt 3, som befinder sig udenfor, ikke bliver renderet. Simple-Render er med andre ord vores reference og den simpleste teknik, det er denne teknik vi gerne vil forbedre med de andre teknikker...2 BSP-Tree-Render BSPTree opdeler geometrien i et binært søgetræ. Hvilken geometri, der kommer til at ligge i det ene sub-træ og i det andet, bliver bestemt via et splitting plane, hvor den geometri, som ligger foran, kommer i foran sub-træet, og det, som ligger bagved, kommer i bagved sub-træet. Dvs. en travasering i træet vil foregå ved at tests på hvilken side af den pågældende nodes splitting plan vi Side 4/4

42 befinder os. Data er gemt i bladene da den indledende eksperiment viste, at det ikke var så meget antallet af stykker, der bliver renderet, der bestemmer hastigheden, i forhold til den geometri der kan ses. Screenshot'ene viser hvordan et BSPTree har inddelt et objekt. Begge bruger planer, som er genereret ud fra tilfældige polygoner i objektet. I venstre screenshot indeholder hver node minimum ' polygoner og hver node har sin egen farve. I højre indeholder hver node minimum 2' polygoner. BSPTree har været brugt lige siden starten af 3D Spil. Doom(2), som er en af de første rigtige 3D spil, benyttede sig af en verdens geometri, som ikke måtte overlappe hinanden, dvs. det var ikke muligt at lave f.eks. bro over en vej eller sagt på en anden måde, at have rum oven på andre rum, de skulle være adskilt i XZ-planet (brede og dybe). BSPTree'et blev så brugt til at adskille geometrien ved at lave planer, som lå parallelt med Y-akslen. Quake var også et af de spil, som benyttede sig at BSPTræ'er, men denne gang var der ikke nogen restriktioner med geometrien, som tilfældet var i Doom. Dvs. Splitting planerne vil være orienteret i XYZ-akslerne og ikke kun i XZ. Litteraturen ser BSPTrees som værende hurtige, hvilket ligger i BSPTrees natur, idet det er et binært søgetræ, som er en af de hurtigste datastrukturer at søge i. dvs. når det er oprettet, så kan vi søge efter synligt geometri, og det være en åbenlys mulighed at bruge disse til scenerendering. Det er til gengæld langsomt at opdatere, hvis vi gerne vil bruge det til at sortere al geometri. For vi vil altid have objekter, som kan bevæge sig rundt i verdenen og flytte deres geometri. Når den ligger gemt og sorteret i et BSPTree er der en meget besværlig og dyr operation at ændre. Det kan næsten altid bedre forsvares at generere et nyt BSPTree, hvilket er noget vi ikke vil gøre, når spillet kører, da det er en proces, som tager lang tid. Vi benytter to måder at finde splitting planer for BSP-Tree'et. Den ene kalder vi Geometri-split (Geo-split), den vil splitte geometrien udelukkende via den eksisterende geometri. Denne metode har en tendens til at lave splittingplaner som følger geometrien. I Illustration 5: Geo-Split ses det tydeligt, at splittingplanerne fortrinsvis er blevet fundet langs bygningerne se bilag kapitel 5.2 for en mere uddybende forklaring. Side 42/4

43 Illustration 5: Geo-Split Den anden metode vi bruger, kalder vi Best-split. Denne finder den bedste splittingplan ud fra et vilkårligt plan, som minimerer antallet at splits, mens det maksimerer antallet af vertices på hver side. Dvs. et balanceret træ med så få splits som muligt. I Illustration 6: Best-Split ses best-split på samme objekt, hvor det ses tydeligt, at det er mere tilfældigt opdelt. Illustration 6: Best-Split Se bilag kapitel 5.2 for en mere uddybende forklaring...3 Oct-Tree-Render OctTree opdeler geometrien i et træ indeholdende 8 sub-trees for hver node. Hver node har et /8 rumfang af sin parent node. Dvs. hvert sub-tree er /8 størrelse af noden. Herunder ses screenshots af, hvordan et OctTree opdeler et objekt. Venstre billede stopper opdeling ved minimum ' polygoner, mens højre stopper ved 2' polygoner. Noder, som ikke indeholder geometri, er blevet slettet fra træet. OctTree'et benytter sig af at splitte polygoner, som skærer grænserne mellem noderne (nodernes BoundingBox'e). De grønne kasser repræsenterer Side 43/4

44 noderne, mens geometrien er blevet farvet med forskellige farver, alt efter hvilken node det hører til. Fordelene ved et OctTree er, at det er nemt at forstå. Og da det udelukkende benytter sig at faste relative rumfang og placeringer for alle sub-noder, så er det nemmere at indeksere sig ind i. I polygon splitting OctTree bliver polygonerne splittet, hvis de skærer nodes BoundingBox, således at kun den geometri, som reelt ligger inden i nodes BoundingBox, kommer med. Ved non-splitting OctTree vil den pågældende node have hele polygonen, hvis den ) ligger helt eller delvist inde i nodens BoundingBox 2) var det første sted polygoner blev fundet. Dvs. der vil ikke være redundante polygoner rundt omkring i træet. Hvis en polygon bliver klassificeret til at ligge i en given node, vil den blive fjernet fra listen over ikke klassificeret polygoner. Dog vil den indgå i en ikke klassificeret liste for nodes sub-trees. Splitting vil helt naturligt tilføje X-antal nye polygoner, spørgsmålet er så, hvor stor en betydning har det, hvornår og kan det forsvares at tilføje disse nye polygoner? Non-splitting OctTree vil i en vis udstrækning lave BoundingBox'e som ikke er uafhængige af de andre, dvs. de kan og vil komme til at overlappe hinanden, hvor spørgsmålet så er, hvilken og hvor stor betydning vil det have? Begge metoder har den ekstra overhead, idet vi nu er nødt til at teste på de enkelte dele af objektet, om de skulle ligge inde i kamerates ViewFustrum i stedet for kun at se, om objektet skar ViewFustrumet eller ej. For at forbedre performancen for Oct-Tree'et har vi en metode, hvor vi ikke splitter polygonerne. Dvs. de enkelte polygoner bliver klassificeret til at tilhøre en given node. I Illustration 7: Splitting og Illustration 8: Non-splitting ses forskellen mellem de to teknikker. Side 44/4

45 Illustration 7: Splitting Illustration 8: Non-splitting Det, vi vinder ved ikke at splitte polygonerne er, at vi ikke får tilføjet ekstra polygoner til objektet, som vi ellers er nødt til. Se bilag kapitel 5.3 for en mere uddybende forklaring..2 Test og Resultater Her opsætter vi vores testscenario for at lave de indledende tests for teknikkerne beskrevet ovenover..2. Test scenario Vi har valgt at lave testene på et objekt kaldet Occucity. Objektet kommer fra Microsofts DirectX SDK pakke, ligesom flere af de andre objekter, vi bruger til at teste med. Objektet Occucity består af 8642 vertices trimmet ned til 974 vertices, hvilket er 624 polygoner. Vi har udvalgt forskellige positioner for at gennemføre disse test. Valget ligger på at befinde sig inde i geometrien, være meget tæt på og langt fra, Se halvdelen og se meget lidt af objektet. Start Position (Pos) Bund (buttom) Hele (all) Top (all-top) Side 45/4

46 Halvdelen (all-half) Start, Position og bund er inde i geometrien, dvs. hvor godt håndterer teknikkerne situationer hvor vi befinder os meget tæt på objektet. Hele, Top og Halvdelen tester på, hvordan teknikkerne håndterer situationer, hvor vi befinder os fra en afstand fra objektet. Alle situationerne vil være nogle som vi kommer ud for i et spil. Illustration 9: Start Illustration 2: Position (Pos) Befinde sig inde i geometrien. Illustration 2: Bund (Bottom) Illustration 22: Hele (all) Meget tæt på og langt fra. Side 46/4

47 Illustration 23: Top (all-top) Illustration 24: Halvdelen (all-half) Se halvdelen og se meget lidt af objektet. Hvert sted er blevet testet i lang nok tid til at vi har fået 3 målinger hvert sted. Vi foretager en måling pr. sek i denne test. Dette valg er taget, for at vi ikke skulle få overmåling, dvs. vores målinger påvirker resultatet tilstrækkeligt til, at det har en negativ effekt. Dog skal det nævnes, at vi akkumulerer testdata over dette sekund, således at vi ikke kommer til at udfører stikprøver. Vi laver et testgennemløb for alle teknikkerne. Vi vil teste, hvordan BSP- og Oct-Tree teknikkerne opfører sig, når vi ændre på, hvor meget de skal splitte objektet op..2.2 Resultater og vurdering Resultaterne for testene kan ses nedenunder. # polygons beskriver maximum antallet af polygoner før opdelingen stopper. Start, buttom, pos, all, all-top, all-half er de testpositioner, som er beskrevet ovenover. Reference er vores reference, det er den hastighed vi får, når vi ikke gør noget ved objektet. Side 47/4

48 # polygons Reference Oct-Tree-Render, splitting Oct-Tree-Render, non splitting 25 2 BSP-Tree-Render, Geo-split 25 2 BSP-Tree-Render, Best-split 25 2 start buttom pos all all-top all-half 772,46 93,94 49,4 735, ,54 9,64 76,95 7,9 55,85 65,7 252,98 876,7 7,46 9,83 26,83 675, ,64 958,3 785,8 86,34 68,29 77,83 237,78 6,85 73,9 92,44 39,58 722,6 63,77 2,4 86,3 9,9 62,58 73,4 2377,7 35,22 786,76 95,42 95,83 724, ,83 32,27 84,85 75,6 64,73 7,37 236,46,9 678,68 77,47 75,8 79, ,8 5,56 79,7 85,58 5, 728, ,8,65 68,7 85,6 995,8 669,63 236,73 97,6 697,26 69,26 27,2 693,6 2337,23 992,4 739,65 9,72 22,9 679,82 254,7 964,35 start buttom pos all all-top all-half,%,%,%,%,%,% -7,9%,2%,7% -6,36% -45,5% -3,22% -9,9% -,28% 5,98% -8,% 2,32% -5,%,73% -,7%,83% -2,4%,2% -,28% -5,36% -,4% 8,62% -,75% -28,57%,7% 4,35% -,28% 52,75% -,56% 4,5% 2,53%,85%,3% 4,45% -,43%,8% 2,24% 8,98% -,73%,2% -4,64% 3,32% -,95% -2,4% -,5% 2,% -3,56%,% -,4% -6,9% -,76%,8% -,93% 2,74%,2% -2,27% -,76% -5,4% -8,96% 3,38% -9,2% -9,73% -2,26% 7,43% -5,75% 2,3% -,73% -4,25% -,2% -2,5% -7,57% -5,7% -4,49% Mean Value,% -,76% -,73%,2% -4,36%,48%,5% 2,67% -,93% -,93% -6,98% -,62% -4,2% Illustration 25: Test resultater for Renders Den nederste halvdel af skemaet fortæller i procent hastighedsforskellen mellem referencen og den pågældende test. For at kunne sige noget om, hvor stabil vores tests har været har vi vedlagt et skema, Illustration 26, som fortæller i procent, hvor stor standardafvigelsen har været i forhold til middelværdien meanval /. # polygons Reference Oct-Tree-Render, splitting Oct-Tree-Render, non splitting 25 2 BSP-Tree-Render, Geo-split 25 2 BSP-Tree-Render, Best-split 25 2 start buttom pos all all-top all-half,93%,7%,4%,%,7%,9%,4% 6,28%,6%,%,2%,4%,6%,34%,3%,4%,25%,6%,5%,9%,43%,3%,%,2%,3%,82%,43%,5%,33%,25%,8%,85% 2,47%,3% 2,9%,6%,34%,9%,5%,4%,8%,9% 2,39%,9%,42%,8%,2%,38%,52%,7% 2,56%,4%,%,%,8%,22%,8%,8%,64%,47% 5,47%,% 2,8%,2%,9%,4%,8%,69% 4,58%,63%,4%,5%,7% 8,67%,7%,6%,89%,2% Mean Value,48%,24%,64%,73%,35%,5%,33%,96%,77%,42%,52%,3%,8% Illustration 26: Standard afvigelse i procent Som det kan ses, så ligger afvigelserne meget lavt og har derfor ikke nogen nævnværdig indflydelse på vores testsresultater. Som det kan ses ud af testsresultaterne (som vi har vedlagt nedenunder på Illustration 27), er der ikke meget at hente rent performancemæssigt, når vi skal rendere objekter med OctTrees. Side 48/4

49 # polygons Reference Oct-Tree-Render, splitting Oct-Tree-Render, non splitting 25 2 start buttom pos all all-top all-half 772,46 93,94 49,4 735, ,54 9,64 76,95 7,9 55,85 65,7 252,98 876,7 7,46 9,83 26,83 675, ,64 958,3 785,8 86,34 68,29 77,83 237,78 6,85 73,9 92,44 39,58 722,6 63,77 2,4 86,3 9,9 62,58 73,4 2377,7 35,22 786,76 95,42 95,83 724, ,83 32,27 start buttom pos all all-top all-half,%,%,%,%,%,% -7,9%,2%,7% -6,36% -45,5% -3,22% -9,9% -,28% 5,98% -8,% 2,32% -5,%,73% -,7%,83% -2,4%,2% -,28% -5,36% -,4% 8,62% -,75% -28,57%,7% 4,35% -,28% 52,75% -,56% 4,5% 2,53%,85%,3% 4,45% -,43%,8% 2,24% Mean Value,% -,76% -,73%,2% -4,36%,48%,5% Illustration 27: Oct-Tree-Render test resultater Begge situationer, hvor vi splitter geometrien, resulterer i en overall reduktion i hastigheden. Hvilket i sig selv er logisk nok, da splitting tilføjer en relativ stor mængde nye polygoner til objektet. Disse ekstra polygoner bruger så ekstra tid, når objektet skal renders, som i sidste ende, i bedste fald, bruger den performanceforøgelse, vi forventede at se. Ved at bruge en non-splitting OctTree, begynder vi at se en lille reel hastighedsforøgelse på nogle procent. Dog skal dette resultat ses i lyset af, at der stadigvæk er situationer, hvor det vil være hurtigere at rendere objektet i sin originale form. Der, hvor vi kan hente en hel del performance, er, hvis vi befinder os inde i geometrien, dvs. meget tæt på objektet. Det kunne f.eks. være objekter, som er meget store, og som spilleren ikke kommer til at se det hele af på en gang. Her ser vi en performanceforøgelse på ca. -2% for nonsplitting OctTree. Vi ser et ejendommeligt dyk i Frame Rate'en ved testen all-top og 25 polygoner for begge af OctTree'ene, ved de to andre test-niveauer ser vi en forventet forbedring af Frame Rate'en. Den eneste forklaring er, at den ekstra tid, som CPU'en skal bruge for at bestemme, hvilke noder der kan ses, og hvilke der ikke kan, gør, at hastigheden er blevet halveret i forhold til det, den kunne have været. De efterfølgende tests, hvor vi forøger antallet af polygoner i noderne, viser den mindre overhead, der er, når vi har væsentligt færre noder. Hvis vi ser på resultaterne, opdager vi, at Frame Rate'en hopper lidt frem og tilbage f.eks. ved pos. Vi ville ellers have forventet udelukkende stigning, når vi forøger antallet af polygoner pr. node. F.eks. ved non-splitting, test pos, ser vi ca. for 25 polygoner og 2 polygoner, mens vi ser 6 for polygoner. Fordi hastighedsforskellen er for stor, og eksperimentet er gentageligt, kan vi ikke skyde skylden på Side 49/4

50 støj. Hvis det var støj, så skulle alle de andre tests have været udsat for samme støj, mens polygoner, non-split, ikke var, hvilket er yderest usandsynligt. Tanken er, at det kan være pga. den rækkefølge, de enkelte noder bliver renderet. Dvs. i de forskellige test bliver geometrien renderet i forskellig rækkefølge. Hvis det er tilfældet, så tyder det på, at vi kan vinde megen performance bare ved at sortere geometrien, inden den bliver tegnet. Stort set samme scenario ser vi i testen for BSP-Tree-Render'en. # polygons Reference BSP-Tree-Render, Geo-split BSP-Tree-Render, Best-split 25 2 start buttom pos all all-top all-half 772,46 93,94 49,4 735, ,54 9,64 84,85 75,6 64,73 7,37 236,46,9 678,68 77,47 75,8 79, ,8 5,56 79,7 85,58 5, 728, ,8,65 68,7 85,6 995,8 669,63 236,73 97,6 697,26 69,26 27,2 693,6 2337,23 992,4 739,65 9,72 22,9 679,82 254,7 964,35 start buttom pos all all-top all-half,%,%,%,%,%,% 8,98% -,73%,2% -4,64% 3,32% -,95% -2,4% -,5% 2,% -3,56%,% -,4% -6,9% -,76%,8% -,93% 2,74%,2% -2,27% -,76% -5,4% -8,96% 3,38% -9,2% -9,73% -2,26% 7,43% -5,75% 2,3% -,73% -4,25% -,2% -2,5% -7,57% -5,7% -4,49% Mean Value,% 2,67% -,93% -,93% -6,98% -,62% -4,2% Illustration 28: BSP-Tree-Render test resultater Det BSP-Tree som benytter sig udelukkende af geometrien til at splitte med, klarer sig lidt bedre end det, som finder det optimale splitting plan for den pågældende geometri. Grunden til dette er, at det BSP-Tree, som benytter geometrien til splitting genererer færre polygon splits, hvilket resulterer i, at der skal tegnes færre polygoner, end der skal i Best-split. Det betyder ikke umiddelbart, at Geometri-split er bedre end Best-split. Som vi kan se på bilag kapitel 5.2 (verifikationen af splitting), vil Geometri-split generere splittet geometri, som godt nok følger geometrien, men i dette eksempel (og i andre) på en uhensigtsmæssigt måde. Illustration 29: Geo-split Illustration 3: Best-split Side 5/4

51 Best-split vil generere geometri, som er tættere pakket, mens Geo-split kan og vil generere mere aflang geometri i dette tilfælde. Det betyder i vores tilfælde, at vi får sværere ved at bestemme, hvilke dele af objektet, der skal renderes, i Illustration 3 og Illustration 32 ser vi, hvordan nodens BoundingSpheres vil ligge for de enkelte noder. Overlap Overlap Illustration 3: Fortegnet Geo-split Illustration 32: Fortegnet Best-split Det ses tydeligt at i Illustration 3 er der store mængder af overlap, mens i Illustration 32 er der stadigvæk overlap, men dog væsentligt mindre. Med den overvejelse er Best-Split et bedre valg, når vi skal lave opdelingen. Hvis vi kigger på det lille eksperiment, som ledte op til dette, så viste det, sig at det ikke havde nogen betydning at dele et objekt op i mindre dele, når det skulle renderes. Kun ved en yderst aggressiv opdeling kunne vi se, at Fame Rate'en faldt. Se Illustration 33 nedenunder, som stammer fra det lille eksperiment i kapitel 9.. IndexBuffer opdeling 23, 22, 2, 2, 9, 8, 7, 6, 5, 4, 3, 2,,, 9, 8, Illustration 33: IndexBuffer opdeling Som vi konkluderede, så kunne vi inddele indexbufferen helt op til ca. 5 stykker, inden vi så et drop. Men hvad denne test ikke viste os var, hvorfor denne hurtige drop i Frame Rate for så at flade langsomt ud til sidst. Vi mener, at forklaringen på, hvorfor grafen ser sådan ud, og hvorfor vi ikke får den performanceforøgelse, vi forventede i disse nye test, hænger sammen. Det skarpe drop må skyldes, at vi i CPU'en pludselig ikke kan holde GPU'en beskæftiget. For Side 5/4

52 GPU'en sætter max hastigheden for at rendere dette objekt på ca. 23, hvis GPU'en så skulle til at bruge mere tid, ville vi med det samme se, at Frame Rate'en vil droppe med det samme i takt med det mere arbejde. Men det er ikke det vi ser. CPU'en og GPU'en er i stand til at arbejde parallelt. GPU'en er afhængig af CPU'en for at fortælle den, hvad den skal lave. Når GPU'en er % belastet, hvilket den er når vi kun har det ene objekt at rendere, må det betyde, at CPU'en står noget af tiden og venter på at sende nye kommandoer til GPU'en. For hver kommando CPU'en sender bruger den x-antal tid på. Dvs. hvis CPU'en venter i y tid på at kunne sende renderingskommandoer til den % belastede CPU, vil det betyde, at vi kan bruge CPU tid til noget andet i y tid, uden at det umiddelbart vil have nogen negativ effekt på GPU'en. Det vi ser på grafen er lige netop denne situation, hvor så længe de enkelte renderingskommandoer er under y tid ser vi ingen negativ effekt på renderingen. Men når vi overskrider ca. 5 indexbuffers dvs. 5 renderingskommandoer, så begynder GPU'en at vente på CPU'en. Denne ekstra tid har en forholdsvis meget stor del af den totale tid lige i starten af y + ekstra tid. Mens dette forhold mellem GPU'en og CPU'en hurtigt bliver til at det er udelukkende GPU'en, som venter på data fra CPU'en, da GPU'en ellers kan renderer objektet med 23. Det betyder så i disse tests med Oct- og BSP-Trees, at der har vi allerede får beskæftiget CPU'en med meget andet, da vi allerede på dette tidspunkt er meget tættere på vores endelige 3DGameEngine. CPU'en har derfor meget andet at tage sig til, så derfor er ventetiden på GPU'en der enten ikke eller også er den forholdsvis lille. Derfor er at det ekstra overhead til at bestemme, hvilke noder som skal renderes, og hvilke der ikke skal, hurtigt får en stor betydning på renderingshastigheden. Det er tydeligt af denne test at mindre eksperimenter, som vi udfører for at bekræfte eller afkræfte om en given retning er en god ide, ikke behøver at være korrekte, selvom det ser lovende ud. Det er naturligvis ikke noget, vi helt kan undgå, for hvis det var aktuelt, så ville det ikke være nødvendigt at teste teorien i en større sammenhæng, hvilket det naturligvis er. Spørgsmålet er så, kunne de andre teknikker, som vi kastede væk i starten, være gode nok? For hvis vi kan tage fejl her, kan vi så også have taget fejl før. Til det er der kun at sige, at disse test også viser, at det ikke vil være nogen god ide at sende alt eller noget af data'en til GPU'en, da CPU'en skal bruge mange ressourcer på både at køre Enginen, men også at sende kommandoer til GPU'en og kan stadigvæk ikke bruges til at sende store data mænger over til GPU'en..3 Del konklusion Både Oct- og BSP-Tree testene bærer præg af samme ejendommelige effekt, at Frame Rate'en falder og stiger, men det var ikke forventet, at den stiger i takt med, at vi hæver antallet af Side 52/4

53 polygoner i noderne. Som vi nævnte før,så tyder det på, at det har noget at gøre med rækkefølgen af noderne og derigennem rækkefølgen af geometrien. Vi har derfor i kapitel.4 (Sortering af geometri) valgt at lave et lille eksperiment over, hvilken effekt det har at sortere geometrien. Det er tydeligt, at vi ikke får nogen forbedering af Frame Rate'en ved at bruge hverken Oct- eller BSP-Trees. Der er specielle tilfælde, hvor vi kan med fordel kan bruge disse teknikker. Men til en generel forbedring er både den mulige hastighedsforbedring for lille og den mere typiske hastighedsstraf for stor. Hvis vi ser det fra en anden synsvinkel, var det en succesfuld test af Oct- og BSP-Tree objekt opdeling. Disse Space Partitionering træer (SP-Trees) skal vi bruge mange andre steder, som ikke nødvendigvis har noget med renderingen af objekter at gøre. Dvs. vi har ikke nogen direkte måde at se, om opdelingen foregår korrekt, derfor har store dele af denne test alligevel været en fordel..4 Sortering af geometri Oct- og BSP-Tree testen gav anledning til at se på, hvor meget performance vi kan hente ved at sortere objekterne, inden de bliver tegnet, ved at de bliver tegnet i rækkefølge i forhold til, hvor langt de ligger fra kameraet. Tanken er, at via grafikkortets Z-Buffer, kan vi få højere performance ved at ignorere de prepixels, som har en Z-værdi, der er større end den pixel, som i forvejen ligger der. Dvs. ved at sortere objekterne vil vi kunne minimere antallet at pixels, som bliver overtegnet. Vi kan ikke umiddelbart undgå overtegning, da objekter kan krydse hinanden, og derfor kan vi ikke sige, at det ene er foran det andet..4. Test Vi har opstillet to simple tests. Begge bruger ens objekter og varierer med, hvor mange af disse, der findes i scenen. I den første test ser vi på, når objekterne ligger lige foran hinanden. I den anden dækker de lidt for hinanden. Se Illustration 34 og Illustration 35. Side 53/4

54 Illustration 34: Occluded Illustration 35: Semi occluded.4.2 Resultater Graferne er lavet således, at den blå linje er hastigheden for de sorterede objekter (første tættest på kameraet osv), mens den brune er for de omvendt sorterede objekter. Den venstre graf er testen, hvor objekterne er helt gemt bag hinanden. Mens den til højre er de semi-gemt bag hinanden. Occluded Semi-Occluded # Objects # Objects Illustration 37: Semi occluded Illustration 36: % occluded Occluded Object 2 Objects 3 Objects 4 Objects 5 Objects 6 Objects 7 Objects Sorted Reverse % Improve. % 5% 92% 2% 52% 73% 93% Semi-occluded Sorted Object 2 Objects 3 Objects 4 Objects 5 Objects 6 Objects 7 Objects Reverse % Improve. % 42% 7% % 34% 47% 68% Illustration 38: Test resultater for occluded De to skemaer ovenover viser resultaterne i, og hvor mange procent forbedring vi opnåede. Side 54/4

55 Resultaterne siger meget tydeligt, at det giver meget performance at tegne objekterne sorteret. Testen er en opstillet test, men resultaterne er meget overbevisende. Sagt med andre ord så siger den, at vores endelige render på den ene eller anden måde skal sortere objekterne. Problemet er nu at finde en datastruktur, som i sig selv, gør dette for os, så vi ikke behøver at lave komplicerede tests for at finde en optimal rækkefølge. Som vi allerede har set, skal der ikke meget til, før at en mulig hastighedsforøgelse drukner i kompliceret scene-opsætning, der skal udføres hver gang. Hvis vi kigger på begge tests, hvor vi kun har et objekt, så ser vi en stor forskel mellem de to (occluded og semi-occluded). På trods af, at vi kunne forstille os, at fps burde være nogenlunde den samme, men der er en 43% hastighedsforskel mellem de to tests (272fps mod 389fps). Grunden til denne forskel er antallet af pixels, som skal tegnes, sagt med andre ord, så optager objekter i de to tests forskelligt areal i frame-bufferen. Dvs. forskellen fortæller os, at disse tests, vi laver er pixel-shader tunge, selvom det er en simpel scene. Det gør intet for validiteten af testsne at den er pixel-tung. Det betyder dog, at hastighedsforøgelsen kan risikere at forsvinde, hvis vi laver shader programmer, som er vertex-shader tunge, dvs. pixel-shader(ne) kommer til at vente på data fra vertex-shader(ne), hvilket vil kunne fjerne fordelen ved at sortere objekterne. Kunsten er stadigvæk at sørge for, at arbejdsbyrden mellem vertex- og pixel-shaderne er ens. I fremtiden vil denne bekymring helt forsvinde med grafikkort der har unified shaders..4.3 Del konklusion Som beskrevet er det tydeligt at vi skal have fundet en metode til at sortere objekterne/geometrien, inden den bliver renderet. Vi så i sidste test med Oct- og BSP-Trees, at der ikke skal meget til, før vi mister en mulig forbedring, pga. ekstra overhead til at bestemme, hvilke dele der skal renderes. Det betyder, at vi skal have fundet en metode, som både er hurtig, men også forholdsvis effektiv til at bestemme, hvilke objekter der skal renderes først osv. Som vi tidligere nævnt,e har alle delene i vores Engine brug for i større eller mindre grad, at kunne Space Partitioner objekterne. Det betyder, at vi gerne skal finde en algoritme eller datastruktur, som kan benyttes af andre dele uden større efterbehandling af data'erme. Derfor vil vi kigge på Space Partitionering ved hjælp af Portals (Portal-Graf) i kapitel.5 (PortalRender). Side 55/4

56 .5 Portal render Vi mener, at Portal-Renderen kan løse vores sorteringsproblem, og Portal-Grafen kan desuden benyttes til en effektiv Space Partitionering for andre komponenter. Den er også en af de sidste teknikker, som vi finder i ældre spil (Duke Nuke 'em), hvor den blev brugt til at vælge, hvilke polygoner som skulle tegnes. Portal-Renderen har den fordel, at den i sin natur sorterer geometrien i grove træk efter placering i forhold til kameraet. Denne sortering har vi fundet ud af, tilsyneladende er meget ønskværdigt at gøre med moderne GPU'er, fordi de er i stand til hurtigt selv kunne vurdere, hvad der skal renderes, og hvad der ikke skal renders i forhold til allerede renderet geometri, vel og mærke hvis det bliver gjort i den rigtige rækkefølge..5. Teori og Analyse Partial Visible Sets(PVS) er en teknik til at bedømme, hvornår et område eller lokale skal renderes, eller om det helt skal undlades at blive processeret af grafikkortet[laakso]. Portaler er en afart af PVS, der kun fokuserer på indendørs miljøer[rotenberg], hvor PVS både kan bruges til indendørs og udendørs miljøer. Måden, PVS arbejder på, er ved at beregne lister af områder, der indeholder mulige kamerapositioner, og hvilke dele af verdens geometrien der så er mulig at se fra disse kamerapositioner. Ud fra disse lister genereres nogle zoner, hvor man kan udelukke dele af verdens geometrien fra at blive processeret, når kameraet befinder sig en en given zone[rotenberg]. Portaler derimod arbejder på en mindre beregnings kraftig måde, ved at man opdeler geometrien i segmenter, og indsætter portaler, som binder rummene sammen[rotenberg]. Når en portal er inde i kameraets ViewFrustum, klippes ViewFrustumet til portalen, og med dette nye ViewFrustum renderes geometrien, som portalen fører til. Herefter testes der igen, om der er nogle portaler inde i det nye klippede ViewFrustum. På denne måde renderes der kun rum, som kameraet visuelt har en forbindelse med. Igen, objekter inde i rummene renderes kun hvis deres rum renderes osv. Side 56/4

57 Illustration 39:Portals and camera view frustum På Illustration 39 kan det ses, hvordan kameraets viewfrustum starter i det nederste rum og kigger hen imod rum nummer 2. Dør åbningen mellem lokalerne er portalerne, da portalen mellem rum 2 og 3 ikke er synlig fra kameraets position(det grønne område), bliver lokale 3 ikke renderet (er markeret lysere)..5.2 Analyse af PVS og Portals Fordi vi, som beskrevet i afsnittet omkring kapitel 5 (Krav til 3D Game Engine), har valgt at afgrænse os til kun at arbejde med indendørs miljøer, mener vi, at det er mest relevant at fokusere på Portaler og ikke PVS, da portalerne er beregnet til at arbejde på indendørs miljøer. Samtidig kan portalerne også bruges til Space Partitionering i andre moduler (se kapitel ). Portal algoritmen er en relativ simpel algoritme at implementere. Vi har valgt at lave en fysisk opdeling af de verdens-modeller som GameEnginen skal arbejde med. Under denne opdeling vil det være en fordel at indsætte portaler direkte i modellerne for dermed at sikre, at deres positioner, vinkler o.s.v. matcher modellernes opbygning. En anden mulighed for at arbejde med portaler kunne være at opdele geometrien og indsætte portaler, efter at modellerne er indlæst, så det gøres på kodeniveau. Dvs. vi auto-generer portalerne ud fra en algoritme. Det gør det nemmere at lave modellerne, men kan resultere i enten for mange portaler (portaler som er unødvendige) eller for få. Side 57/4

58 Fordele: Fordelen ved at bruge portaler til rendering, er, at der sendes langt færre objekter til grafikkortet, kun objekter som der er en reel chance for, at der kan ses. Dette vil så frigive en del GPU-tid, som grafikkortet kan bruge på at processere de mere relevante polygoner. Ulemper: CPU'en bliver nødt til at beregne, om en portal er inde i kameraets ViewFrustum, og hvis dette er tilfældet, skal der beregnes et nyt ViewFrustum i forhold til portalen, som derefter bruges til test af næste rum osv. Udbytte: Som beskrevet før er udbyttet afhængig af 2 elementer, ) at kunne sortere objekterne 2) at kunne reducere en mængde af objekter og dermed polygoner fra at blive processeret af grafikkortet. Det betyder, at hvis modellerne er til strækkelig få eller meget simple, vil udbyttet sandsynligvis ikke være mærkbart, da den GPU tid, der spares, bruges på den ekstra tid CPU'en er om at lave sine portalberegninger. Hvis man til gengæld har mange og komplekse modeller, vil fordelen ved portaler hurtig komme til syne. Her vil der nemlig være meget arbejde at spare for GPU'en, med relativ få beregninger på CPU niveau. Det vil vi forvente giver en tydelig forbedring i Frame Rate'en i forhold til, hvis der ikke blev brugt portaler..5.3 Test og evaluering I dette afsnit beskriver vi vores test af portalerne og evaluerer resultaterne. De tests vi har udført bygger på den mere simple implementation, hvor vi har lavet portalerne ved at inkludere dem direkte i modellerne og dermed ikke har en algoritme, der genererer dem Lille test Formålet med denne test er at bevise en hastighedsforøgelse af renderingen, når det ikke er muligt at se alle lokalerne. Til at bevise hastighedsforøgelsen, sammenligner vi frame-raten, når vi renderer med portaler, med frameraten, når vi renderer uden portaler, dvs. samlet i en stor model. Denne test udføres på Test Maskine 2. På Illustration 4 ses de 3 lokaler, og hvordan de er inddelt. Portalerne på dette billede er grønne. Billedet er ikke renderet med vores egen render, men er en direkte rendering af 3 modeller i 3DS Side 58/4

59 Max. Illustration 4:3 lokaler med portaler I denne test placeres kameraet i lokalet til højre, hvorfra det har udsyn til lokale 2 (det i midten) gennem sin portal. Kameraets vinkel gør også, at lokale 2's portal til lokale 3 er synlig gennem kameraet. Illustration 4 viser både kameraets udsyn, når renderingen foregår ved brug af 3 modeller(lokaler), der er forbundet af portaler. Dette bliver brugt i testen, hvor vi kan se 3 rum på en gang. Illustration 4: Test hvor 3 regioner (rum) kan ses Illustration 42: Test hvor kun region (rum) kan ses Illustration 42 viser både renderingen af portaler og uden. Det er visuelt det samme, men ved brug af portaler er der kun et objekt, som skal renderes. Hvorimod uden portaler, skal grafikkortet Side 59/4

60 rendere alle 3 rum Culling af lavpolygons modeller I tabellen Illustration 43 ses frameraten ved renderinger af lokalerne. Rummene har et relativt lavt polygon antal ca. 24 faces pr lokale. Dette er ekstrem simple lokaler, som man nok ikke ser i et spil af en fornuftig kvalitet. Men det kan statigvæk give os en ide om, hvad der bruges af ressourcer til at teste, om portalerne er inde i kameraets ViewFrustum, og hvilken hastighedsforbedring der kan komme. Frame rate Antal lokaler kameraet kan se Portaler Stor model Forbedring i % ved brug af portaler Lav polygons lokaler (~24 faces pr. Lokale) 2 3,3 89,35 74,74,6 89,43 74,88,2 -,9 -,9 Illustration 43: Rendering af -3 rum lav polygon antal Den ovenstående tabel viser Frame Rate'en ved brug af portaler og en stor samlet model, hvor vi varierer antallet af lokaler, der kan ses af kameraet. Som det ses, er der en lille forbedring af Frame Rate'en når der kun er et synligt lokale. Denne forbedring sker i kraft af den færre geometri, som GPU'en skal rendere i forhold til den store model. Hvis vi kigger videre på Frame Rate resultaterne ses det, at når der er 2 eller 3 lokaler synlige, så sker der et lille drop i Frame Rate'en med portalerne i forhold til den store model, dette skyldes sandsynligvis de tests, som portalerne bliver nødt til at udføre for at vurdere, om det næste lokale skal renderes. Side 6/4

61 Lav polygon lokaler 2 Framerate Portaler Stor model Antal lokaler der kan ses Illustration 44:Graf over framerate ved lav polygons lokaler Illustration 44 viser en graf over Frame Rate resultaterne ved brug af lav polygon modeller Vurdering af resultat Resultaterne fra renderingerne af lavpolygon modellerne giver os ikke så konkrete beviser for, om det er en god eller dårlig ide at bruge portaler til at opdele større modeller. Resultatsforskellene er meget små, hvilket ikke beviser håndgribeligt nok, om det ene er definitivt bedre en det andet. Vi kan dog vurdere, at de beregninger, som skal udføres for at teste om en portal er inde i viewfrustumet, er forholdsvis billige ca., % tab i frame-rate. Men det betyder, at en Portal-Render kan være langsommere med at renderer alle objekterne, da vi teoretisk kan komme ud for, at vi kan se alle rummene på en gang. Dog skal det nævnes at PortalRenderen stadigvæk har en fordel af en sorteret liste, mens en rendering af alle objekterne ikke har denne liste, hvilket igen sandsynligvis gør Portal-Renderen hurtigere. Endvidere vil det være usandsynligt, at man vil konstruere en verden, hvor vi kan se den hele på en gang Culling af højpolygons modeller For at få et mere håndgribeligt resultat brugen af portaler er en god ide eller ej, har vi valgt at udføre samme forsøg med modeller med et langt højere polygon antal, som dermed også burde være mere realistisk. Forskellen på lavpolygons modellerne og højpolygons modellerne er, at der er placeret to kasser i hvert lokaler. Disse kasser har et meget højt polygon antal (ca. 95 faces pr kasse) og skal efterligene de evt. rigtige modeller/strukturer, der vil være placeret i lokalerne. Side 6/4

62 For at kunne sammenligne med den forrige test, er placeringen af kameraet det samme som tidligere. Kasserne er placeret i lokalerne på en sådanne måde, at de ikke kan ses af kameraet fra nogle af de testede vinkler. Dette er for at sikre, at selve renderingen af billedet er præcis det samme som tidligere. På denne måde kan vi teste, hvilken indvirkning det har for grafikkortet at skulle afgrænse disse ekstra polygoner i stedet for at teste, hvor hurtigt det er til at tegne dem. Frame rate Antal lokaler kameraet kan se Portaler Stor model Forbedring i % ved brug af portaler Høj polygons lokaler (~9' faces pr. Lokale) ,38 64,3 5,55 68,69 58,7 5,44 23,6 8,3,23 Illustration 45: Rendering af -3 rum høj polygon antal Den ovenstående tabel Illustration 45 viser Frame Rate'en ved brug af en stor model og portaler. Som det kan ses fra tabellen, er der nu en meget stor forbedring, ca. 23%, når der kun kan ses et lokale. Denne forskel kommer af, at grafikkortet kun skal afgrænse sig fra ca. 9' polygoner, når man bruger portaler, hvor det skal Culle ca. 57' polygoner, når den bruger den store model. Vi kan se ved renderingen af 2 lokaler, at der stadig er en pæn forbedring på ca 8%, hvor der ved 3 lokaler ikke er nogen mærkbar forskel. Høj polygon lokaler Framerate Portaler Stor model Antal lokaler der kan ses Illustration 46:Graf over framerate ved brug af høj polygons lokaler På Illustration 46 herover ses en graf over resultaterne ved denne test. Her er det mere synligt Side 62/4

63 hvilken forbedring, der findes ved at bruge portaler, så længe at alle lokalerne ikke er synlige Vurdering af resultat Med brugen af højpolygons modeller er resultaterne langt mere indlysende, at der kan være noget at hente ved at opdele en stor model i mindre dele og forbinde dem via portaler. Med resultater der starter på ca. en 23% forbedring og godt nok daler til ca %, når alt kan ses, er det en klar fordel at bruge portaler. Fordelen ses især i indendørs miljøer, hvor der ofte ikke kan ses mere end et par rum af gangen ud af en hel bane. Ud fra disse resultater kan vi vurdere at det er en forbedring at bruge portaler i miljøer, hvor der ofte kun er dele af en bane synlig som f.eks. indendørsbaner. Hvorimod der ikke er så meget fordel i at bruge portaler, hvis det er et stort rum, hvor alt hele tiden kan ses..5.4 Del konklusion Vi kan i denne test tydeligt se fordelene ved Portaler. De giver en simpel men effektiv grovsortering af, hvilke modeller der muligvis kan ses af kameraet. Med 3 lokaler indeholdene et fornuftigt polygon antal, er det muligt at opnå en forbedring på 23%, og med flere lokaler vil denne forbedring helt klart stige. Det er så op til yderligere mere realistiske tests at bestemme, hvor stor en forbedring vi reelt kan opnå. Se efterfølgende tests. Side 63/4

64 .6 Kombinering af optimeringerne Her vil vi kombinere de forskellige optimeringer, som vi har testet os frem til i de indledende tests. Ud af de tests vi har lavet indtil videre, ser vi nogle mere og mindre lovende teknikker. Det er vores intention at stille et mere realistisk test miljø op, for at vi bedre kan sige, hvilke der er gode, og hvilke der er mindre gode teknikker..6. Tests For at lave et mere realistisk testmiljø, har vi lavet en verden som består af 6 rum, der hver især er mere eller mindre detaljerede, ligesom man ville forvente, andre verdener vil være. På Illustration 47 ses et Wireframe billede af verdenen med de 6 forskellige rum og den rute, som kameraet bruger til at bevæge sig gennem de 6 rum. Vi har lavet en lille AI, som bevæger kameraet via en fast rute igennem alle rummene i nummer rækkefølge ( -> 2 -> 3...), så vi er sikre på, at alle tests bliver udført ens. Illustration 47: Verden oversigt, Wirefame Side 64/4

65 På Illustration 48 til Illustration 52 ses en række wireframe billeder fra den route, som vores AI tager igennem verdenen. Det giver et bedre indtryk af, hvad der sker under testen, som varer i ca. ½ minut. En anden grund til at vise Illustrationerne er for at forsikre både os og jer om, at vores Portal-Render virker. Vi har allerede testet Simple-, OctTree- og BSPTree-Renderne for fejl, se bilag kapitel 5. Her kontrolleres vores Portal-Render for at den, hverken render for meget eller for lidt. Det ses tydeligt, hvis den skulle rendere for lidt, da der så vil opstå tydelige steder med manglende geometri. Mens det ikke ses direkte, om den render for meget, da denne ekstra geometri vil være gemt. Denne gemte geometri kan ses, hvis vi laver en test i Wireframe. Denne test gør det også nemmere at påskønne Portal-renderen, da det ses tydeligt, hvad den vælger ikke at render. Illustration 48: Fra rum Illustration 49: Fra rum 2 Illustration 5: Fra rum 2 Illustration 5: Fra rum 3 Side 65/4

66 Illustration 52: Fra rum 6 Testene er opstillet som beskrevet ovenover. Vores verden med 6 rum, et bord, nogle søjler osv. Under de forskellige tests har vi disable'et alt, hvad der ikke er brug for for at gennemføre den pågældende test. Dvs. Simple-Render vedligeholder f.eks. ikke vores PortalGraph, hvilket vores Portal-Render gør og behøver osv. Vi har for overskuelighedens skyld valgt at slå test resultaterne sammen for de forskellige test. De tests, som er udført, er for: Simple-Render OctTree-Render BSPTree-Render Portal-Render Forbedret Portal-Render ( med Portal ViewFrustum clipping ) For Oct- og BSP-Tree-Render har vi gennemført nogle lav-polygon tests, hvor de deler geometrien, indtil der minimum er henholdsvis (test), 25 (test2) og (test3) polygoner i sub-noderne, mens de i høj-polygon testene inddeler i 25, ' og ' polygoner. Det foregår med samme fremgangsmåde som i vores indledende tests (se kapitel.2.2), for at se, hvordan de vil reagere på forskellige niveauer af inddeling. Grunden til, at disse tests kommer igen, er af den årsag, at vi nu har et større og mere realistisk test miljø, hvor vi faktisk ser en rigtig verden, som vores GameEngine er rettet imod at kunne håndtere (inddørs miljø), plus vores GameEngine er væsentligt mere færdig. Det er derfor muligt at vores Renderere vil håndtere denne opgave med et andet udfald i form af en forhåbentlig bedre Frame Rate. Noget, som vi har taget ved lære fra vores foregående tests, er, at indledende tests kan give et helt Side 66/4

67 andet billede, end det vi forventer, hvilket også har medvirket til at gennemføre nye og mere realistiske test for vores teknikker. Yderligere vil det være interessant, om vi får nogen gavn af at kombinere disse teknikker. Dvs. vi har tests som ser såldes ud: Portal-Render med OctTree-Render Portal-Render med BSPTree-Render Disse tests fungerer ved at benytte vores Portal-Render til at bestemme, hvilken geometri som skal renderes, hertil kommer så enten Oct- eller BSP-Tree-Render som så vil bestemme ud fra den allerede valgte geometri, hvilke underdele af denne skal renderes. Vi benytter med andre ord vores Portal-Render til at gøre den grovkornede bestemmelse af, hvad der kan ses og herefter vores Octeller BSP-Trees til en finere inddeling af, hvad der kan ses, og derfor skal renderes. Det er derfor vores tanke, at vi måske kan se en forbedering, når teknikkerne bliver benyttet på denne måde..6.. Resultater og vurdering Den første af vores tests er vores Simple-Render. Grunden til, at vi fremhæver Frame Rate forløbet over testen for Simple-Render, er, at denne graf viser meget godt, hvordan alle de andre grafer ser ud. SimpleRenderX - Low Polygon Illustration 53: Simple-Render - Low polygon Det er tydeligt at se ud fra grafen hvor henne i test forløbet, vores kamera befinder sig i. Hvis vi husker fra Illustration 47, har vi en fast bane kameraet bevæger sig igennem rummene på. For ikke Side 67/4

68 at terpe igennem hele grafen, har vi valgt at fremhæve de generalle træk. De to større dyk ved tid og 4 er der, hvor kameraet drejer skarpt over til andre rum. Ved er det i rum 2, hvor det starter med stort set at kigge lige ind i en væg uden nogen geometri bagved, herefter skifter kameraet til at kigge ned mod rum 5, dvs. kigger igennem 3, 4 og 5. Ved 4 drejer det rundt i rum 5 og vender sig mod rum 6. Grunden til, at Frame Rate'en stiger stødt fra 4 til slut, er, at efterhånden som kameraet bevæger sig igennem rum 6, vil der hele tiden bliver mindre og mindre geometri foran kameraet. Som et kontrol check har vi udført en tests, hvor vi ikke render noget. Dette er gjort for at sikre os, at der ikke er faktorer som vil væsentligt påvirke vores tests resultater, når testen skrider frem. None and SimpleRenderX - Low Polygon Illustration 54: Simple-Render & No rendering Low polygon Den nederste graf er vores Simple-Render, mens de to øverste er, hvordan Frame Rate'en ser ud, hvis vi henholdsvis lader testen løbe igennem uden rendering. Det ene gennemløb er uden elementer, vi ikke behøver, dvs. lige nok komponenter til Simple-Render'en kan køre, mens den anden er med alle komponenterne kørende. Som det kan ses, så ligger den stabilt på ca. 2, og der er ikke nogen forskel mellem de to. Det fortæller os, at de testresultater, vi får ud i de forskellige tests, er upåvirket af støj. Det skal lige nævnes, at der vil altid være lidt støj tilstede, hvilket kan ses i form af korte Frame Rate drops. Det har ikke noget at sige for vores test, da vi vil sammenligne teknikkerne over hele testforløbet. Et rigtigt problem kunne være, hvis Frame Rate'en var f.eks. kontinuerligt fladende under testen, hvilket ville gøre, at vi ikke kan sammenligne testene. Vi vil ikke vise samtlige tests men udelukkende dem som beskriver en general tendes og hvor det er nemt at vise pointen, eller hvis der er specifikke tests, som opfører sig mærkant anderledes end de Side 68/4

69 andre. For at se alle testene henviser vi til bilag kapitel 6 (Rendering). Graferne Illustration 55 og Illustration 56 viser hastighedsforskellen mellem Simple-Renderen og henholdsvis Oct-Tree-Render og BSP-Tree-Render. OctTreeRenderX Polygon - Low Polygon BSPTreeRenderX Polygon - Low Polygon Illustration 55: OctTree-Render polygon pr. node - Low polygon Illustration 56: BSPTree-Render polygon pr. node - Low polygon Det er tydeligt at se, at vi ikke får nogen form for forbedering ud af disse teknikker. Vi får stort set samme Frame Rate de steder, hvor der er meget lidt geometri at rendere, dvs. steder hvor vi kigger ind i f.eks. en væg. Mens de steder hvor der findes forholdsvis megen geometri, ser vi et relativ stort dyk i Frame Rate'en. Teknikkerne virker korrekte nok, og hvad, der er interessant at se, er, at både Oct-Tree og BSP-Tree bliver hurtigere i takt med at mængden af geometri, der skal tegnes, bliver mindre. F.eks. turen igennem den lange gang (rum 4), hvor kameraet får mindre geometri foran sig i takt med at det bevæger sig igennem rummet. Grunden til, at Oct-Tree er hurtigere end BSP-Tree, er, at vores verden er orienteret så den naturligt passer med det axisis aligned Oct-Tree, det gør at Oct-Tree bedre kan udelukke geometri som ikke kan ses, i forhold til den mere tilfældige BSP-Tree. OctTreeRenderX 25Polygon - Low Polygon BSPTreeRenderX 25Polygon - Low Polygon Illustration 57: OctTree-Render 25 polygon pr. Illustration 58: BSPTree-Render 25 polygon pr. node - Low polygon node - Low polygon Ved at øge antallet af polygoner i hver node i modsætning til den forudgående test, hvor vi havde meget aggressivt inddeling af geometrien, ender vi med to teknikker, som begge er stort set lige så hurtige som Simple-Render, hvilket vi ikke får noget ud af. Side 69/4

70 Det er interessant, at når vi øger den totale mængde af polygoner i vores verden, dvs. vi tilføjer objekter som indeholder mange polygoner (X-antal Column.x fra DirectX SDK), ser vi to teknikker, som stadigvæk ikke er bedre end Simple-Render (se Illustration 59 og Illustration 6), men her er BSP-Tree markant bedre end Oct-Tree. Grunden til dette, findes i at BSP-Tree med Best-Split tilføjer væsentligt færre polygoner til geometrien når den splitter i forhold til Oct-Tree. Da det er meget store objekter, vi har med at gøre, har denne effekt en meget stor indvirkning på forskellen mellem de to. BSPTreeRenderX - Polygoner OctTreeRenderX - Polygoner Illustration 59: OctTree-Render, ' polygoner Illustration 6: BSPTree-Render, ' pr. node High polygon polygoner pr. node Et sted omkring de tid 3, er BSP-Tree-Renderen sågar hurtigere end Simple-Renderen, men det er dog en kort fornøjelse. Helt generelt kan vi konkludere at selv med højpolygon modeller, har disse to teknikker ikke nogen positiv effekt på Frame Rate'en i forhold til at tegne geometrien direkte med vores reference render. Portal-Renderen er implementeret, som beskrevet i teori afsnittet.5.. På Illustration 6 ses forløbet for Portal-Renderen testen. Den brune graf (nederste) er Simple-Renderen, mens den gule er Portal-Render, og den blå er Portal-Renderen hvor vi har forbedret den ved at klippe ViewFrustumet med den pågældende portal, når det går igennem denne. Side 7/4

71 Portal-RenderX - High Polygon Illustration 6: Portal-Render - High polygon Det ses tydeligt, at Portal-Renderen er væsentligt hurtigere end Simple-Renderen. De steder, hvor Portal-Renderen ikke er hurtigere end Simple-renderen, er der, hvor begge metoder fjerner lige meget geometri, dvs. steder hvor kameraet kigger ind i f.eks. en væg uden nogen geometri på den anden side. Mens de steder, hvor Portal-Renderen er i stand til at fjerne geometri, fordi kameraet ikke kan se det pågældende rum, er Portal-Renderen væsentligt hurtigere. Den forbedrede version af Portal-Renderen benytter sig af at klippe ViewFrustumet med den givende portal, således at det klippede Frustum bruges til at teste med i det rum, som portalen fører til osv. Det er tydeligt at se den store effekt på, hvad der bliver renderet, og hvad der ikke bliver renderet. Spørgsmålet er så, vil det have nogen positiv effekt at benytte Oct- eller BSP-Tree-Renderene på denne Portal-Render. I Illustration 62 og Illustration 63 ses testresultaterne for en kombination af Oct- og BSP-Tree med vores Portal-Render. Som sagt, så bestemmer Portal-Renderen overordnet hvilke objekter, som skal renderes mens Oct- og BSP-Tree bestemmer hvilke dele af objektet, der skal renderes. Den brune graf er Portal-Renderen, mens den blå er henholdsvis Oct- og BSP-Tree-Renderene kombineret med Portal-Renderen. Side 7/4

72 PortalOctRenderX Polygon - Low Polygon PortalBSPRenderX Polygon - Low Polygon Illustration 62: Portal- & OctTree-Render, polygoner pr. node - Low polygon Illustration 63: Portal- & BSPTree-Render, polygoner pr. node - Low polygon Igen må vi desværre erkende, at disse to teknikker ikke er i stand til at give nogen forbedring. Vi ser de samme karakteristika, som da Oct- og BSP-Tree-Renderne kørte for sig selv. Vi har også testet for, når vi har en højpolygon verden, ligesom den vi testede med sidst. Dette ses på Illustration 64 og Illustration 65, hvor den blå graf er Portal-Render og den brune er henholdsvis Oct- og BSP-Tree. PortalRenderX and OctTreeRenderX Polygon - High Polygon PortalRenderX and BSPTreeRenderX Polygon - High Polygon Illustration 64: Portal- & OctTree-Render ' Illustration 65: Portal- & BSPTree-Render ' polygoner pr node - High polygon polygoner pr node - High polygon Oct- og BSP-Tree kombineret med Portal-Renderen er hurtigere end Simple-Renderen alene, men de er langt fra hurtigere end Portal-Render alene. Igen ser vi samme tendens, at BSP-Tree er en smugle hurtigere end Oct-Tree ved de store modeller. Hvilket igen skyldes, at BSP-Tree genererer færre polygon splits og derved færre ekstra polygoner. Alle vores tests har været succesfulde, idet de har produceret konsistente resultater, da alle har været gentagelige, dvs. alle tests, når gentaget, viste præcis samme resultater, hvilket taler godt for vores testmiljø i den hensende. Yderligere er det positivt med henblik på vore genererering af Trees, at de bliver genereret forholdsvis konsistent, dvs. vi ser ikke nogen nævnværdige udsving i forhold til, hvordan vores algoritmer vælger at splitte geometrien, som ellers kunne have givet udsving, når testene blev gentaget. Dette kunne nemt have været tilfældet i f.eks. BSP-Tree, hvor vi benytter Best-split, som er en relativ tilfældig algoritme til at bestemme det sandsynlige bedste splitting-plan. Side 72/4

73 Det er nu tydeligt at Oct- og BSP-Trees ikke kan give os nogen hastighedsmæssige forbederinger, men de er stadigvæk interessante, bare ikke til dette renderings formål. Selv ved kombineringen, hvor vi drastisk reducerer mængden af geometri, som Oct- og BSP-Trees skal tage stilling til (Portal-Render kombineret med enten Oct- eller BSP-Tree), ses ingen fordel ved at bruge disse trees til culling. Det ses tydeligt, at BSP-Tree'et med sin Best-split, er i stand til at vælge opdelinger, som giver mindst ekstra geometri, noget som Oct-Tree'et ikke er i stand til. Dette er en værdifuld viden at tage videre, fordi vi i andre sammenhæng er nødt til at dele geometri ind i søgetræer, hvor det ikke er fordelagtigt at tilføje for meget ekstra data på denne bekostning. Det ses tydeligt at BSP-Tree's vil være det bedste at benytte i forhold til Oct-Tree's. Ved at benytte Best-split på BSP-Tree'et har vi været i stand til, i gennemsnittet, at reducere antallet af noder i træet med op til en /3, dvs. fra hvor vi før havde 3 noder med maximalt polygoner, har vi nu noder med maximalt polygoner, hvilket er en forbedering der er vigtigt. Spørgsmålet, som nu er interessant at besvare, er, om disse test og resultater kan føres over i den virkelige verden eller rettere sagt i andre 3DGameEngines. Dette er stadigvæk et testmiljø dvs. fokus for vores 3DGameEngine er ikke, at vi skal kunne spille et spil på den på nuværende tidspunkt, men det skal være muligt for os at gennemføre fornuftige tests. Enginen mangler komplette moduler, som vi ellers forbinder med en 3DGameEngine, såsom Fysik-, Collision Detection-, AI-modul osv. Den har et render system, som er understøttet af forskellige datastrukturer og opdateringsfunktioner. Det eneste, der stort set mangler, er de moduler, som lige er nævnt. Dvs. vi har på nuværende tidspunkt hele infrastrukturen til at kunne bygge resten af Enginen på. Det betyder for det første, at CPU'en på nuværende tidspunkt ikke har nær så mange arbejdsopgaver, som den ellers vil få, når de sidste moduler kommer på. Vi har allerede set, at CPU kraft er en mangelvare, som bevirker, at vi ikke kan benytte vores Oct-, BSP-Trees, da de bruger for megen CPU tid. Dette er et faktum, som kun vil blive forværret, når der kommer flere moduler, hvilket yderligere beviser, at vi ikke kan benytte disse Trees i en 3DGameEngine til Culling, fordi CPU kraft er typisk en mangelvare i de fleste 3DGameEngines. Så ad den vej rundt kan vores testresultater sagtens overføres til andre 3DGameEngines, da det er sandsynligt, at disse også har for lidt CPU kraft til tilrådighed til at gennemføre disse Tree tests. Nøjagtig hvor stor en hastighedsstraf, de vil have på andre 3DGameEngines, kan vi ikke sige noget direkte om. Side 73/4

74 .6.2 Yderligere evaluering Noget, som ville være interessant at teste videre med vores Trees, er, om der findes elementer som evt. bruger meget CPU kraft, og som kan forbedres, udover det som bruges på at sende kommandoer til GPU'en. Størstedelen af det, som vores Trees gør i forhold til Simple-Renderen, er at teste, om en given node befinder sig helt eller delvis inde i ViewFrustum'et. Måske kan det være muligt at forbedre dette for at få noget ekstra performance. For at lave denne intersection test benytter vi XNA's ViewFrustum og BoundingSphere. Måske er denne test blevet lavet ineffektiv? Hvilket den med stor sandsynlighed ikke er, da vi må mene, at Microsoft ved hvad de laver, og derfor har sikret sig at deres funktioner er forholdsvis optimale. Men var der måske en anden måde, hvor vi kunne bestemme, om en given node befinder sig inde i ViewFrustum'et, som kunne være en væsentlig forbedering af ViewFrustum og BoundingSphere intersection testen? For at besvare dette kan vi kigge på den fra den modstatte side: Hvor hurtig er denne intersection test, vi skal forbedre? En BoundingSphere er et punkt og en radius, mens et ViewFrustum er 6 planer (near-, far-plane og de 4 sider). Hvad ville være den værst tænkelige kompleksitet for en intersection test her? Det ville være, at vi var nødt til at teste alle 6 planer op imod BoundingSphere'en for at bestemme en mulig intersection. En bestemmelse af relationen mellem en sphere og et plan er udelukkende en bestemme af, hvor ligge centrum i forhold til planet (foran, bagved eller på), herefter kan vi bestemme, om sphere'en intersecter med planet ved at se, om afstanden fra centrum og planet er mindre end eller lig med radius. Plane BoundingSphere Planenormal Radius Centrum Illustration 66: Plane & BoudingSphere intersection Illustration 66 viser denne test. Som det kan ses, er det en meget nem test, og implementeret i kode indeholder den kun 2 liner. Vi kan derfor formode, at det vil være yderst vanskeligt at finde en metode, der er endnu mere effektiv til at bestemme, om en node er inde i ViewFrustumet. Det ville kræve en datastruktur, som i sig selv bare skulle læses for at give resultatet af denne intersection test, og hvor opdateringen af datastrukturen var yderst hurtig. Dvs. hvis vi kigger på, hvor hurtig denne intersection test mellem ViewFrustum og BoundingSphere er i forhold til, hvad det kræver at sende en kommando til GPU'en, som nemt kan løbe op i '5 operationer for at gennemfører [TOMSD], kan vi med ro i sindet sige, at det ikke er her vi kan hente noget performance. Side 74/4

75 Nu hvor vi er sikre på at den største flaskehals er at sende data og kommandoer til GPU'en, ville det være interessant at se på teknikker for at minimere dette. Det ville være interessant, hvis vi kunne finde metoder til at lave denne reduktion af kommandoer større. En hurtig metode kan være at tage to ens stationære objekter i rummet og slå dem samme til et objekt og derved spare en Draw-kommando. Umiddelbart er der 2 problemer med denne metode: Vi vil bruge mere plads på grafikkortet, idet at lægge objekter sammen, som måske bliver brugt andre steder, gør, at vi ikke kan genbruge dette. I bedste fald vil det kun være indexbufferen, som bliver gjort større. Nedenunder ses eksempler på forskellige scenarier på objekt sammensætning. VertexBuffer VertexBuffer IndexBuffer VertexBuffer IndexBuffer IndexBuffer Obj Obj Obj VertexBuffer IndexBuffer Obj Obj Illustration 67: Individuelle obj Obj Illustration 68: Ens obj Illustration 69: Forskellige sammensætning obj sammensætning I Illustration 67 har vi individuelle objekter (nuværende opsætning) med hver deres egne VertexBuffers og IndexBuffers. Det er nemt at genbruge objekterne rundt omkring, men det kræver en Draw-kommando pr. objekt. I Illustration 68 har vi to objekter f.eks. to stole ved et bord, som kan være en fordel at sætte sammen til et objekt, fordi vi kun behøver en Draw-kommando for effektivt at tegne to stole, men de er meget svære at genbruge, fordi det kræver, at der bruges dette sammensatte objekt andre steder, hvor deres indbyrdes placering i forhold til hinanden også er korrekt, da vi ikke umiddelbart har mulighed for at ændre transformation-matrix'et, mens vi render objektet. Illustration 69 viser en løsning, som har samme problemer som tidligere, men her er vi nødt til at bruge endnu mere plads, da de to objekter ikke deler VertexBuffers. En mulig løsning på dette overforbrug af ram kunne være at tilføje ekstra IndexBuffers, således at vi kun behøver en repræsentationer af objekterne i rammen. Side 75/4

76 VertexBuffer IndexBuffers Obj Obj Illustration 7: Individuelle og sammensatte IndexBuffers I Illustration 7 har vi en indexbuffer for hver af de individuelle objekter plus en samlet indexbuffer, hvis vi skal tegne dem begge. Denne optimering kunne også lade sig gøre, hvis vi tegnede det ene objekt ud fra den samlede indexbuffer med et offset, så vi kom udover det første osv. Kan vi så ikke bare kombinere alle objekterne? Det kan vi godt, men problemet er, at mulige kombinationer mellem objekterne stiger med n 2 for hvert tilføjet objekt, hvilket meget hurtigt vil betyde, at vi løber tør for ram, se Illustration 7. VertexBuffer IndexBuffers Obj Obj Obj Illustration 7: Flere kombinerede objekter Det andet problem er, at vi stadigvæk ikke kan ændre placeringen mellem objekterne, da vi ikke umiddelbart kan ændre på transformations-matrix'et, mens vi render objekteret. Vi skal også huske på at ændre en parameter til GPU'en betyder, at vi bliver nødt til at sende en kommando til den, hvilket er det, vi forsøger at minimere. En mulig løsning kunne være at vi havde et shader program, som kunne modtage x-antal transformations-matrix'er, som så selv kunne bruge det rigtige matrix til de forskellige sammensatte objekter. Lad os sige på baggrund af dette, at vi er i stand til med meget få kommandoer til GPU'en at rendere vores Scene, om det så måtte være Simple-Renderen, Portal-Renderen eller Oct/BSP-Renderen, vi benyttede os af. Oct- og BSP-Trees må antages at være hurtigere i dette tilfælde, da de er i stand til at reducerer antallet af polygoner, som skal behandles af GPU'en, og antallet af kommandoer er konstant. CPU'en skal stadigvæk analysere mere data for at bestemme hvilke dele af geometrien der kan ses, men som vi er kommet frem til, så er det ikke så stor en byrde. Side 76/4

77 Portaler vil være endnu hurtigere i de fleste tilfælde med denne metode, da de er i stand til at fjerne geometri, som ikke kan ses pga. at de er skjulte bag foranliggende geometri. Yderligere kan vi forstille os, at en kombination mellem Portaler og Oct/BSP-Trees vil være endnu bedre, da de kan reducerer geometrien endnu mere. Problemet, med det test vi har lavet, hvis vi ser lidt pessimistisk på det, er, at hvis de viser sig at være rigtigt, de teorier vi har opstillet. Det betyder at de tests vi har lavet omhandler primært om hvor mange kommandoer vi sender til GPU'en. Hvilket ad den vej gør, at vi ikke kan sige noget om, hvilke teknikker er hurtigere udelukkende for GPU'en at rendere en scene med. Dvs. GPU'en stadigvæk kan nyde godt af Oct- og BSP-Trees, men samlet set for hele systemet, CPU og GPU, tager teknikkerne for lang tid. Et eksempel kan være: Meget forsimplet er hastigheden for at rendere en scene bestemt af, hvilken del der tager længest tid, CPU tiden eller GPU tiden. Et eksempel kunne være for Simple-Render: 5 sek for CPU'en og 8 sek for GPU'en = 8 sek pr. scene. Mens i vores forudgående test for BSP kunne det se sådan ud: sek for CPU'en og sek for GPU'en = sek pr. scene. Ved at reducere antallet af kommandoer ses måske denne situation for BSP: 6 sek for CPU'en og sek for GPU'en = 6 sek pr. scene. Derfor kunne det være yderst interessant at finde en teknik til at reducere antallet af kommandoer til GPU'en, da det ad den vej vil være sandsynligt, at de teknikker, vi har testet, vil være brugbare..6.3 Del konklusion Portal-Grafen gør, at vi meget nemt kan lave en grovkornet sortering og bestemmelse af, hvilke objekter der sandsynligvis kan ses, hvorefter en rendering kan finde sted. Dette har vist sig fra et renderingssynspunkt, at være en meget effektiv metode. Når denne Portal-Grafen er så effektiv, er det så muligt at bruge den i andre komponenter, som kunne gøre gavn af en hurtig måde at bestemme, hvilke objekter er i nærheden af hinanden. Vi vil derfor benytte den forbedrede Portal-Render til renderingen samt BSP-Trees med Best-split til geometri inddeling og/eller søgning i forbindelse med kollisions detektering. Side 77/4

78 Collision Detection / Control I dette afsnit kommer der nogle overvejelser omkring det at vi bruger Collision Detection modulet til at simulere, arbejdsbyrde både fra Collision Detection, men også til at simulerer arbejds belastningen fra andre komponenter, som vi har valgt ikke at lave. Det er ikke meningen, at der vil komme en udførlig gennemgang af, hvordan vi har konstrueret vores Collision Detection, da dette ikke umiddelbart er væsentligt for testene. Denne gennemgang findes i bilag kapitel 4 (Collision Detection). Vi ser nærmere på, om vi kan benytte vores Portal-Graf til effektivt at forbedre performancen af vores Collision Detection, hvilket var et mål vi stillede os selv tidligere.. Kompleksitet Hvad der er væsentligt for at vi kan bruge vores Collision Detection modul til at lave realistiske tests med set som værende en ekstra arbejdsbyrde, er, at den nødt til at leve op til den hastighedskompleksitet, vi ser i andre kommercielle Collision Detection komponenter, da vi ellers i realiteten kun ville kunne teste, hvordan vores teknikker og Engine håndterer en tilfældig ekstra arbejdsbyrde og ikke en realistisk arbejdsbyrde. Litteraturen siger, at den hurtigste måde, vi kan udføre en sammenlignings-søgning på, er O log n [CORMEN] se bilag kapitel 4. (Konstruktion). Da Collision Detection bund og grund er en søgning i den mulige geometri for evt. Collisions, skal den maksimalt tage O log n [ERICSON], hvilket vores kollisiontests gør, se bilag kapitel 4. (Konstruktion). Det samme er gældende for objekter, som bevæger sig, hvor vi skal finde et evt. kontakt punkt. Dette kan igen gøres i O log n [CORMEN] [ERICSON] tid, da det er en sammenlignings test. Der vil være nogle løsninger, som, når der er målt pr. tid, er hurtigere end vores, men kompleksitetmæssigt vil de være ens. Sagt med andre ord så har vi en Collision Detection modul, som kan finde en evt. Collision mellem to objekter, der bevæger sig i O log t O log n =O log t n tid, hvor t er tidspunktet mens n er kontakt polygon(erne). Hvilket ifølge [CORMEN] [ERICSON] er det hurtigste..2 Simulering Det er så vores tanke, at dette Collision Detection modul skal kunne gøre det ud for at vi ikke har Side 78/4

79 implementeret de andre beregningstunge komponenter i vores Engine endnu, så som Phyics, AI osv. Problemet med denne løsning er, at vi måske ender op med vi ikke får en faktisk simulering disse komponenter, eller sagt med andre ord, fordi vi bruger en komponent (Collision Detection) til at simulere de andre komponenter, kan vi så virkelig sige noget om performancen, hvis vi havde disse andre manglene komponenter. Ved at tilføje flere kugler i testen får vi gjort, at Collision Detection modulet bliver mere belastet, hvor vi så ser den direkte effekt på, at et Collision Detection modul bruger mere beregningskraft. Tanken er, at disse testresultater kan overføres til en Engine, hvis vi havde alle de andre komponenter. Men som sagt der er en risiko for at vi faktisk ikke rigtigt kan sige noget om performancen, da vi ikke har de andre komponenter. Det betyder ikke, at vi ikke kan bruge denne metode at teste på, men det betyder, at vi kun kan give et forsigtigt bud på, hvordan den færdige Engine vil opføre sig. Testene, som bygger på belastningen fra Collision Detection, er valide idet de vil fortælle os, om de forskellige teknikker vil være i stand til at forbedre performancen på Enginen med Collision Detection. Det betyder så også, at vi skal være opmærksomme på, at de andre moduler måske har mere gavn af andre teknikker. Så hvorfor har vi så valgt at bruge Collision Detection? For det første, at vi har en meningsfyldt verden at teste i. Det nytter ikke noget, at en realistisk verden tillader, at objekter og spilleren kan bevæge sig igennem væggene osv. For det andet, at Collision Detection indeholder elementer, som er mere eller mindre typiske for de andre komponenter. Pointen er, at de andre komponenter vil indeholde beregninger, som i kompleksitet minder om med det, vi finder i Collision Detection. Et Physics komponent har f.eks. tilfælles med en Collision Detection.. X-antal objekter som skal opdateres, med evt. forholdsvis komplekse algoritmer. 2. Gentagende opdateringer i samme update, f.eks. rammer flere vægge i samme update. 3. Skal tage stilling til, hvad og hvordan interaktionen mellem to eller flere objekter er, f.eks. glider henover en overflade. Disse elementer kan betragtes som primære linære operationer n. Men hvad der er værd at bemærke, så vil 2 og 3 benytte sig af informationer fra Collision Detection for at kunne udføre beregningerne. En AI komponent.. Kunne følge banen, f.eks via waypoints. 2. Kunne bestemme, om den kan se andre spillere/ai'er. 3. Træffe beslutninger ud fra nogle kriterier, som enten er fastsatte eller opstået, f.eks. den Side 79/4

80 bliver ramt (opstået) og har for lidt armor og derfor skal flygte (fastsatte). og 3 er igen primære linærer operationer. Mens 2 gøres via f.eks. at kaste en CollisionRay fra AI'en til spilleren, hvis denne ikke rammer noget på vejen dvs. den udelukkende rammer spilleren, så kan AI'en se spilleren, hvilket igen kræver en Collision Detection. Collision Detection er et vigtigt og gentagende element i dette tilfælde både Physics- og AIkomponenten, hvilket gør, at vi ad den vej faktisk kan sige noget fornuftigt omkring hastighedsforøgelsen, vi kan forvente i den endelige Engine. Men igen skal vi holde os for øje, at dette billede vil ændre sig, når f.eks. Netværk-, Lyd-modul osv. kommer ind i Enginen..3 Portal-Graf Vi ville gerne have, at vi kunne benytte vores Portal-Graf til mere end kun rendering, af den simple årsag, hvis vi med succes kunne bruge den andre steder, vil det betyde, at den tid, vi bruger på at opdatere den, effektivt bliver mindre, i den forstand at vi sparer tid andre steder, som har gavn af en godt nok lidt grovkornet, men hurtigt Space Partitioning datastruktur. Vi vil derfor gerne se, hvilken effekt det har, hvis vi benytter denne Portal-Graf til at bestemme, hvilken geometri er i nærheden af hinanden, dvs. hvilken geometri befinder sig i samme region, og derfor skal testes på, om der foregår en Collision mellem dem..4 Test og evaluering Vi laver to tests, den første tester vi udelukkende på, om noget bevægeligt geometri kolliderer med den stationære geometri. Vi har disablet renderne, så vi ikke får støj fra disse, idet vi udelukkende er interesseret i forskellen mellem, med og uden Protal-Graf. Se bilag kapitel 4.. for en mere uddybende forklaring af testen. En kort forklaring er, at vi har de 6 rum, hvori vi placerer x-antal kugler (,, 2, 4, 8, 6). Disse kugler bevæger sig med samme hastighed og kan i den ene test kun kollidere med verdengeometrien, men i den anden kan de også kollidere med hinanden. Side 8/4

81 Regions (rum) Objects Portals Illustration 72: Test scenearie overblik Vi starter med at teste, hvor objekterne udelukkende kan kollidere med den stationære geometri. I Illustration 73 benytter vi ikke nogen form for Space Partitionering. Mens vi i Illustration 74 benytter portal-grafen til at bestemme, hvilke objekter som sandsynligvis vil kollidere med den statiske geometrien. Normal - Statisk Portal - Statisk Illustration 73: Statisk Collision - Normal Illustration 74: Statisk Collision - Portal Den første blå søjle er reference, dvs. Frame Raten vi har ved kugler. I de efterfølgende stiger antallet af kugler,, 2, 4, 8 og 6 kugler. Som det kan ses, så er vores portal graf næsten % hurtigere, end den test, hvor vi ikke benytter nogen from for Space Partitionering. Det skal også nævnes, at i den normale test har vi fjernet portal grafen helt, således at den ikke bliver opdateret, og således vi får et mere realistisk resultat. Side 8/4

82 I denne test kan kuglerne både kollidere med hinanden og den statiske geometri. Normal - Dynamisk 3 2 Portal - Dynamisk Illustration 75: Dynamisk Collision - Normal 4 Illustration 76: 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,, 2, 4 og 8 kugler. Pga. at testen for om kuglerne støder ind i den dynamiske geometri dvs. andre kugler stiger i kompleksitet med n2 (n er antal kugler), ser vi en endnu større hastighedsforøgelse, når vi benytter os af Portal-Grafen til Space Partitionering. Her er hastighedsforøgelse over 2% nogen steder. Det er meget tydeligt, at selv med denne grovkornede Space Partitionering, vinder vi meget ved at lave denne, inden vi begynder at se, om nogen af dem kolliderer med hinanden. Grunden til, at den er så effektiv, er, at når først Portal-Grafen er opdateret, er det eneste, der skal til, for at bestemme, hvilke objekter der er inden i en given region, er at læse dette direkte. Der forkommer derfor ikke nogen beregninger, når denne information skal hentes. Hovedparten af alle testene i Collision Detection komponenten vil være en simple BoundingSphere og BoundingSphere intersection test, da de ikke er tæt nok på hinanden til en yderligere test se bilag kapitel 4.. Denne BoundingSpere intersection test er tilsyneladende langsom nok til, at vi ser en forholdsvis stor forbedring af hastigheden, når Portal-Grafen benyttes. Dette resultat lægger op til at se, om en yderligere Space Partitionering af regionerne inde i PortalGrafen kan retfærdiggøres ved en besparelse af intersection tests. En evt. metode, vi kunne bruge, var et axices alligned Oct-Tree, som inddeler en region i et passende detaljeringsgrad, dvs. nodernes Side 82/4

83 størrelse skal være store nok til minimum effektivt at kunne indeholde det mindste objekt i verdenen, ellers vil det kunne tænkes, at vi hurtigt ville forbruge den performanceforøgelse som f.eks. et Oct-Tree vil kunne give os i form af vedligeholdelse af Oct-Tree datastrukturen, når objekterne bevæger sig igennem det. Hvis vi kigger på, hvad der kræves for at opdatere Portal-Grafen, så vil de objekter, som bevæger sig (kuglerne) lave hver især en CollisionRay, som har startpunkt i den gamle position fra sidste update og slutpunkt i den nye position. Hvis denne CollisionRay intersecter med en portal, vil objektet blive flyttet over i det rum (region), som portalen peger på. Typisk vil der ikke være nogen intersection mellem portalen, og CollisionRay'en derfor vil det være en BoundingSphere og Plane intersection test. Lad os se på, hvad der sker i den første test, hvor vi har 6 rum, som bliver testet op imod kuglerne. Denne test kunne gøres noget hurtigere ved at sørge for, at vi kun testede op imod det rum, som den pågældende kugle befinder sig i. Dvs. vi sparer 5 BoundingSphere og BoundingSphere intersection tests, da kuglen ikke kan kollidere med andre rum, end det, som den befinder sig i. Vi har lige set, for at opdaterer Portal-Grafen for et objekt laves en intersection test, hvilket betyder, at vi total sparer 4 intersection test i denne udgave. Det betyder ikke, at den bliver 4 gange hurtigere, hvilket testen også viser, da tiden, det tager at finde ud af, om der sker en kollision mellem det rum som kuglen befinder sig i vil tage længere tid end en intersection test. Regions (rum) Objects Portals Illustration 77: Test scenearie overblik Med denne anskuelse vil det ikke give mening at benytte yderligere datastrukturer, som skal vedligeholdes til at generere en finere Space Partitionering. Et objekt, som bevæger sig igennem f.eks. et Oct-Tree, skal klassificeres ind i Oct-Tree'et. Objektet kan meget let befinde sig i grænsen mellem to eller flere noder som yderligere vil komplicere klassifikationen. En direkte kollisionstest vil tage O log t n, hvor resultatet tidsmæssigt typisk er i størrelsesorden 4 til evalueringer se bilag kapitel 4.. Vedligeholdelsen af et Oct-Tree kan hurtigt blive enten lige så dyrt eller dyrere, hvilket betyder, at vi sandsynligvis ikke får noget ud af at partitionere yderligere i den første test. I den anden test har vi derimod x-antal kugler, som kan kollidere med hinanden. Det gør, at vi får Side 83/4

84 2 X 2 kollisionstests. Ved at bruge Portal-Grafen får vi reduceret dette tal til X /6 pr. rum og totalt for alle rum til 6 X /6 2, hvilket er væsentligt lavere end X 2. Hvilket afspejler sig i vores test. Spørgsmålet er, om vi evt. kan vinde noget her, hvis vi lavede en yderligere Space Partitionering? Hvis vi går ud fra, at Oct-Tree'et bruger tid enheder pr. objekt på at opdatere sig, og vi bruger enhed for hver kollisionstest, hvor de ikke er i nærheden af hinanden. Har vi så kugler betyder det, at med Portal-Grafen bruger vi 6 /6 2 =666 tid totalt. Antager vi nu, at vi i gennemsnit kan reducere antallet af kollisions test til par af 2 og 2 med vores Oct-Tree får vi O X C = 5=5 tid totalt, (hvor O er opdaterings tiden pr. objekt i Oct-Tree'et, X er antallet af objekter og C er tiden brugt på kollisions tests). Umiddelbart kan det tyde på, at vi kunne spare tid ved at lave en ekstra Space Partitionering, når vi har et større antal af bevægelige objekter, som kan interagere med hinanden. Hvad de nøjagtige tider på de enkelte datastrukturer er, er svært med nogen nøjagtighed at sige noget om. Hvad vi kan sige er at den tidsmæssige kompleksitet ikke stiger ved at indføre et Oct-Tree, men at den faktisk falder. Vi har en tidsmæssige kompleksitet på O n2 både med og uden Portal-Grafen, med OctTree'et vil tid kompleksiteten være i væreste fald O n2 da alle objekter kan være i samme node, men meget mere typisk vil den være tæt på den nedregrænse på n, som er en lineær funktion, da de enkelte objekter typisk vil være i hver sin node. Regions (rum) Objects Oct-Tree Regions (rum) Objects Portals Illustration 78: Portal region uden Oct-Tree Portals Illustration 79: Oct-Tree partitionering af Region (rum) Illustration 78 viser, at for et rum med 3 objekter skal der laves 3 kollisionstests, mens der på Illustration 79, hvor vi benytter et Oct-Tree til Partitionering, i dette tilfælde ikke behøver at udføres nogen kollisionstests mellem objekterne..5 Del konklusion Fra det synspunkt, at vores Collision Detection komponent lever op til en tidsmæssig kompleksitet, hvad vi kan forvente at finde i andre Collision Detection moduler i andre Engines, betyder det, at vi Side 84/4

85 umiddelbart kan overføre resultaterne til andre 3DGameEngines med Collision Detection. På trods af, at vi mangler forskellige komponenter, mener vi stadigvæk på bagrund af, hvordan vores Collision Detections module opfører sig, at det kan bruges til at give en god ide omkring, hvordan Enginen ville performe, hvis den havde de andre moduler. Hvad, der kunne være interessant at arbejde videre på er, hvad en yderligere Space Partitionering kunne give af performance. Vi forventer, at vi sandsynligvis vil kunne hente noget her, men det kræver som sagt yderligere tests og implementation(er). Vi vil derfor fremover prøve at benytte Portal-Grafen til Space Partitionering for vores Collision Detection og evt. andre kommende komponenter, såfremt at det er en succes.. Side 85/4

86 2 Multi threading Moderne processorer i dag er multi cores/threaded, og selv spillekonsoller benytter sig af komplekse multi-core'ed CPU'er. Denne trend er udsprunget af, at processorindustrien har nået et maksimum for, hvor højt de skal skrue clock-frekvensen op på komplekse kredsløb som CPU'er. Dette maksimum er opstået af mange faktorer, de primære er strømforbug og varme. Ved at fordoble clock-frekvensen firedobler man strømforbruget og dermed varmen. Løsningen for at tilfredsstille forbrugeren med hurtigere processorer er at sætte flere CPU'er eller cores i samme indpakning. Logikken er, at to 2GHz CPU'er i samme indpakning betyder en fordobling af processorkraften, i forhold til en 2GHz CPU, mens varme udviklingen pr. core er uændret. Denne løsning fra hardware producenterne betyder, at programmørerne, hvis de vil udnytte den ekstra processorkraft der er til tilrådighed, bliver nødt til at lave et flertrådet design, da en enkelt tråd ikke kan eksekveres på flere Cores/CPU'er samtidigt. Det præsenterer GameEngine udviklerne med det problem, at 3DGameEngines altid har været et meget serielt stykke software og har typisk kun været tiltænkt at skulle køre på en enkelt CPU. Derfor står udviklerne overfor at skulle omskrive helt eller delvis deres 3DGameEngines for at kunne udnytte de nye processorer. Det interessante er, som sagt, at der faktisk ikke rigtigt er lavet trådet 3DGameEngines endnu. Der findes spiltitler, som har fået en patch, der gør dem i stand til at udnytte flere Cores, lidt i stil med det vi så, da de første 3D hardware blev alment tilgængeligt. De spil, som der findes patch'es til er forholdsvis få. Spil som Quake 4 og Call Of Duty 2 er implementeret til at bruge to tråde og dermed mulighed for at udnytte to Cores[WALTON], men hvad nu, hvis det er en Quad-Core som Enginen kører på? Problemet med de to nævnte spil er helt generalt, i hvor stor grad trådene kan køre parallelt. Som med Quake 4 og Call of Duty 2 vil en tråd pocessere AI fysik o.s.v mens en anden tager sig af grafik, lyd bruger indput osv. Dette giver en udmærket arbejdsdeling så længe, at det tager lige så lang tid at håndtere grafik og lyd, som det tager at processere AI og fysik. Ofte ser vi, at det er grafik-delen som begynder at blive flaskehalsen, specielt når opløsningen (skærm størrelsen) sættes op, og vi ad den vej skubber balancen mellem de to tråde over imod tråden med grafik-delen. Dette bevirker, at den anden tråd skal vente på, at tråden med grafik-delen bliver færdig[walton]. De spørgsmål vi gerne vil have belyst i dette afsnit er: Hvordan kan vi tråde vores 3DGameEngine? Og hvilken metode er bedst i hvilke Side 86/4

87 situationer. Hvilke performance forøgelse kan vi forvente at få? 2. Teori og Analyse De spil, der findes, som kan udnytte to Cores i dag er blevet designet ved at splitte 3DGameEnginen over i to dele, hvor så hver del bliver tildelt en Core. Som vi senere skal se, scaler dette ikke så godt. Disse to tråde er som sagt direkte afhængig af hastigheden af den anden, og er ikke i stand til at yde noget bidrag til processeringen, hvis en af dem kommer til at stå idle. Problemet, eller rettere sagt målet, er at udnytte processoren, vi har til rådighed, %, uanset om den er en dual core eller multi-core. Vi vil se på forskellige niveauer for trådning i vores Engine. Dele Enginen over i to dele. (2 tråde) - Grov opdeling Dele komponenter op i x-antal dele (2+ tråde) - Fin opdeling Indføre et overordnet styrende modul til tråde - Finere til meget fin opdeling Disse forskellige niveauer har både positive og negative sider. 2.. Grov opdeling teori Det positive ved at dele vores Engine i to dele, er, at det er en forholdvis nem løsning, og som vi skal se, en udmærket løsning. Problemet er, at vi ikke kan sikre os, at vi altid udnytter processoren %. Et eksempel kan være, at processoren har 3 cores, og derfor vil en to trådet løsning ikke udnytte den sidste core, og derved miste 33% af den processor kraft, der er til rådighed. Et andet eksempel er, at de to tråde ikke kan forventes at løbe i samme hastighed, fordi arbejdsbyrden ikke nødvendigvis er lige stor. Hvis den ene er længere tid om at levere data, end den anden er til at behandle det, vil det resultere i, at en af trådene må vente på data, eller vente på at kunne sende data videre. Side 87/4

88 Tråd, Seriel processering ) Tråd Tråde, Seriel processering Tråd 2 2) Tråd Tråde, Paralel processering 3) Tråd Tråd Tråde, Paralel processering Tråd 2 4) Tråd 2 2 Illustration 8: Opdeling af Engine i to dele På Illustration 8 ses problemstillingen ved en direkte opdeling af en 3DGameEngine. Fordi denne metode deler en seriel-orienteret Engine op i to dele, betyder det, at de to tråde er direkte forbundet til hinandens arbejde. Ved punkt ses hvordan arbejdsgangen ser ud i en seriel trådet Engine, dvs. det klassiske design. Arbejdsopgaverne er opdelt i to, orange og grønne kasser. De påførte tal refererer til, hvilken update arbejdsopgaverne hører til, dvs. orange skal udføres inden grøn kan udføres osv. Hvis vi kigger på punkt, kan vi se, at vi har en tråd og ikke noget spild. Ved punkt 2 har vi trådet Enginen således, at Enginen og Renderen har fået sin egen tråd, men vi har ikke indført nogen form for buffering mellem trådene, hvilket resulterer i, at de er nødt til at vente på hinanden. Som det kan ses, giver det ikke nogen forbedering, kun ekstra programmeringsarbejde. Ved punkt 3 har vi indført buffering mellem trådene således, at de ikke er direkte afhængig af det arbejde, som kommer. Dette resulterer i, hvis arbejdsbyrderne er lige store, at der effektivt fordobles den mængde arbejde, vi får udført. Ved punkt 4 ses et mere realistisk billede af, hvordan situationen typisk vil se ud. Her vil en af arbejdsopgaverne tage længere tid end den anden, hvilket resulterer i, at den korte opgave kommer til at vente på den anden. Vi får stadigvæk en hastighedsforøgelse, i forhold til den enkelt trådede Engine (punkt ), men vi får også en del spildtid, som ellers kunne have været brugt Fin opdeling teori Side 88/4

89 Ideen med vores design er, at tråde de enkelte komponenter hver for sig. Alle komponenterne er, gennem vores design, ikke direkte afhængig af hinanden, men bliver kørt sekventielt. Ideen er at generere X-antal tråde pr. komponent, alt efter hvad der er muligt. Tråd, Seriel processering ) Core X Tråde, Paralle processering Core 2) Core 2 X Tråde, Paralle processering Core 3) Core 2 Core 3 X Tråde, Paralle processering Core 4) Core 2 Core 3 Core 4 Illustration 8: Opdeling af komponenter i dele På Illustration 8 eksempel, ses Engine forløbet med update, 2 osv. Dette design kører på Core. Hver af disse updates er inddelt i nogle komponenter, som bliver kørt sekventielt. Ideen er at opdele komponenterne i X-antal tråde, som kan splittes op mellem de forskellige Cores. De grå kasser er spildtid, hvor en given Core ikke har noget at lave. Eksempel 2 viser at den første komponent ikke kan deles op i mindre opgaver, og derved ikke kan trådes, hvilket efterlader Core 2 uden arbejde. Men de andre komponenter kan godt deles op, og derved levere arbejde til begge Cores. Designet er stadigvæk fundamentalt sekventielt, hvilket resulterer i, at processeringen af næste komponent først kan begyndes, når den foregående komponent er færdig. Dette resulterer i spildtid, enten fordi en komponent ikke kan opdeles, eller fordi opgaverne i komponenten ikke kan deles over i lige store dele til hver Core. Eksempel 3 og 4 illustrerer, hvordan det kan se ud, hvis vi tilføjer flere processerings Cores til systemet. Der vil være en hastighedsforøgelse, men den vil ikke være linær med den potentielle processorkraft, som er til rådighed Meget fin opdeling teori En tredie løsning er at se hele Engine som en samling arbejdsopgaver ( jobs ), der har nogle Side 89/4

90 afhængigheder i forhold til hinanden. Formålet er, at alle disse jobs kan udføres individuelt, så længe de overholder hinandens indbyrdes rækkefølge. X Tråde, Parallel processering Core ) Core 2 Core 3 Core 4 X Tråde, Parallel processering Core Core 2 Core 3 Core 4 2) Illustration 82: Schedulering På Illustration 82 er tanken, at en reschedulering af arbejdsopgaverne, se eksempel 2, ville kunne udfylde de huller, som vil opstå i det mindre aggressive trådet design, se eksempel. Der vil stadigvæk være spildtid i dette design, men det burde være minimalt. 2.2 Test og evaluering Alle tests vil bruge Portal-Renderen, samt Collision detection med Portal-Grafen til space partitioneringen. Vi tester med henholdsvis,, 2, 4, 8, 6 og 32 kugler for at se, hvordan testmiljøet opfører sig under større belastninger. Alle kuglerne har samme hastighed, men deres retning og positioner er forskellige. Miljøet er det samme, som er blevet brugt i afsnittet om Rendering se kapitel.6.. Side 9/4

91 Regions (rum) Objects (kugler) Portals Illustration 83: Test scenarie På Illustration 83 ses et overblik over test scenariet. Vi ser de forskellige rum (regions), med deres tilhørende portals. Kuglerne har alle en retning, og hastigheden er den samme. Nogle af dem reflekterer på verden-geometrien. Nedenunder ses et billede af nogle kugler i testmiljøet set i rum 6 med ryggen til rum. Illustration 84: Kugler i rum 6 Fordi vi er kommet frem til, at vi sandsynligvis kan gøre vores Collision Detection lineær med hensyn til antallet af bevægelige objekter, må vi antage, at hvis det er muligt, så vil andre Collision Detections modeller også kunne gøre dette, se kapitel.4. Derfor har vi valgt at teste vores Collision Detection komponent, hvor den opfører sig lineært. Dvs. i disse tests har vi fjernet muligheden for, at de enkelte kugler kan kollidere med hinanden, hvor vi så får den ønskede linearitet med hensyn til antallet af kugler i testen. Dette har vi valgt at gøre for at nærme os et så realistisk testmiljø som muligt Grov inddeling Side 9/4