Automatisk generering av navigationsdata i en 3D-rymd.

C-uppsats i Datavetenskap

Automatisk generering av

navigationsdata i en 3D-rymd.

Författare: Martin Svensson Davoust Handledare: Martin Blomberg Termin: VT11

Abstrakt

Datorspel genomgår en konstant utveckling mot mer komplexitet och i takt med att de virtuella spelvärldarna växer behövs mer och mer effektiva metoder att navigera genom dessa. I denna rapport undersöks möjligheten att

automatiskt generera navigationsinformation och ett förslag presenteras på hur en algoritm för detta skulle kunna se ut.

Abstract

Innehållsförteckning

4 Resultat och analys ________________________________________ 12 4.1 Applikationens komponenter ____________________________ 12

5 (25)

1

Introduktion

Datorspelen genomgår en ständig utveckling mot skarpare grafik, djupare handling och större och mer komplexa spelvärldar. Detta är till stor del tack vare hårdvarans accelererande utveckling.

I takt med att de virtuella spelvärldarna växer behövs mer och mer effektiva metoder att navigera genom dessa. En lösning på detta är att bygga upp en navigationsgraf, ofta kallad navigationsmesh, parallellt med att spelvärlden skapas. Detta är förstås tidskrävande och möjligtvis helt onödig då detta sannolikt kan automatiseras.

I denna rapport kartläggs möjligheten att automatiskt generera en navigationsmesh.

1.1

Bakgrund

Nackdelarna med att använda rutnätet har fått mig att leta efter andra lösningar och det har fått mig att börja fundera på hur man ska kunna navigera genom spelvärlden. Detta är den huvudsakliga orsaken till projekts utformning.

1.2

Syfte

Projektets syfte är att undersöka möjligheten att automatiskt generera en navigationsmesh.

En applikation som klarar av detta kommer utvecklas för att få tydligare förståelse för problematiken med genereringen. Målet med applikationen är att den ska kunna ta emot en polygonbaserad 3D-modell, analysera denna och tillslut skapa en navigationsgraf. I och med att applikationen inte ska köras realtid i ett spel kommer fokus läggas på att ha en tydlig objektorienterad struktur och logisk inkapsling framför prestanda.

Förhoppningsvis kan arbetet bidra med en tydlig beskrivning och exempel på metoder för att lösa problemet.

1.3

Problemformulering

För att kunna generera en navigationsmesh krävs sannolikt en komplex analys av 3D-modellens geometri och flera lager av bearbetning av denna. Det huvudsakliga problemet är att det inte finns relevanta artiklar om detta som ger konkreta förslag på hur man kan lösa problemet. På grund av bristen på artiklar blev frågan:

7 (25)

1.4

Avgränsningar

2

Teori

I detta kapitel förklarar jag vissa centrala begrepp som används flitigt i rapporten.

2.1

Definitioner och begrepp

2.1.1 Polygon

En polygon är en månghörning som beskriver ett geometriskt objekt som oftast inom datorgrafik beskrivs med hörn, ofta kallade vertexar, och indexeringar av hörnen. Till exempel är en triangel en polygon med tre hörn och en rektangel en polygon med fyra hörn.

2.1.2 Voxel

En voxel är en enhet för ett volymetriskt element och kan även beskrivas som en tredimensionell motsvarighet till pixeln. Gemensamt med pixeln så äger voxeln ofta inte dess egna koordinater.

2.1.3 AABB

9 (25)

2.1.4 Mesh

En mesh är en geometrisk representation av en tredimensionell modell inom datorgrafik och brukar även kallas 3D-modell. Meshen består av konvexa polygoner, oftast trianglar eller rektanglar.

3

Metod

3.1

Utvecklingsverktyg

I projektet valdes C++ som implementationsspråk och Microsoft Visual Studio 2010 som utvecklings miljö. I detta kapitel beskrivs dessa.

3.1.1 C++

Applikationen skrevs i C++. C++ är ett av de mest populära programmeringsspråken och är baserat på C. C++ är ett mångsidigt språk med stöd för objektorienterad programmering och har dessutom C fördelar med bland annat lågnivåtillgång till minnen. Språket valdes tack vare dess mångsidighet men även till stor del på grund av tidigare erfarenhet med språket.

3.1.2 Microsoft Visual Studio 2010

11 (25)

3.2

Genomförande

3.2.1 Utveckling och implementation

På grund av avsaknaden av relevanta vetenskapliga artiklar var jag till stor del tvungen att testa mig fram under utvecklingsfasen. När ett steg i processen för att skapa navigationemeshen var klart gjordes observationer och slutsatser drogs om det var en bra lösning eller ej.

3.2.2 Datainsamling

När applikationen var klar påbörjades datainsamling. Datainsamlingen bestod av att spara renderade stillbilder av de olika momenten i applikationen. För att förtydliga och förenkla förklaringen av de olika momenten som bearbetade geometrin ersattes terrängen med en enkel triangel.

4

Resultat och analys

4.1

Applikationens komponenter

I denna del presenteras förslaget på utformning av applikationen som genererar navigationemeshen. Jag analyserar och förklarar de olika metoder jag använde för att skapa varje steg i processen och motiverar valet av dessa.

4.1.1 Skapandet av volymetrisk information

Det första momentet i applikationen är att omvandla den ursprungliga terrängens, i form av polygoner, till en navigerbar volym. För att representera denna volym används enhetskuber, valet gjordes på grund av kubens relativt exakta beskrivning av volymen.

För att spara minnesutrymme implementeras enhetskuberna som ett höjdfält med listor av voxlar. Detta görs på grund av den enorma mängd voxlar som annars skulle krävas och deras minnesbredd. Redan vid en upplösning av 5123

voxlar med endast en 8bit flagga tillhörande varje voxel, för att beskriva om den var navigerbar eller ej, resulterar i 134Mb minnesbredd. Därför används en dynamisk lista som endast tilldelas voxlar som var navigerbara.

13 (25)

Bild 4.1.1.1: Ursprunglig triangel inuti voxelvolym

4.1.2 Skapandet av spann

När samtliga trianglar i terrängen hade testats mot voxelvolymen kunde själva analysen av denna börja.

Det första som görs i detta steg är att iterera igenom varje voxel i listan för att analysera den associerade triangelns lutning. Lutningen testas mot ett gränsvärde och om testet klaras skapas ett nytt objekt för att hålla ytterligare information som behövs för att avgöra dess tillgänglighet.

För att skapa information om maximalt tillåten höjd på föremål som ska kunna navigera över terrängen, analyseras varje objekts spann i höjdled. I samband med detta skapads även en hierarkisk struktur på dessa spann för att enkelt kunna avgöra om de ligger intill varandra.

15 (25)

Bild 4.1.2.1: Navigerbar volym ovanför polygon.

4.1.3 Skapandet av områden

För att trianglarna i navigationsmeshen ska fördelas väl över terrängen och för att få en lämplig storlek på dessa så valde jag att använda en slags watershed-algoritm för att skapa olika logiska områden.

Algoritmen som implementerades skapar även, i vissa omständigheter, små oönskade områden, dessa måste antingen läggas till ett närliggande område, om det finns ett, eller filtreras bort i ett extra steg.

I områdena som nu var skapade bestämds hörnelement och kantelement. Kantelementen behövs för att snabbt avgöra var områdets kanter befinner sig och för att bestämma vilka dess gränsande områden är.

17 (25)

4.1.4 Skapandet navigationsgrafen

När områdena är klara är det dags att skapa de slutgiltiga trianglarna. Områdenas hörnelement blev utgångspunkt för att skapa den polygon som skulle ersätta informationen i området innan trianguleringen av polygonen kan påbörjas. Till att börja med skapas en vertex för varje hörn i området och läggs till polygonen. Därefter dras en linje mellan varje vertex. Sedan jämförs det närmaste avståndet från linjen till områdets kantelement med ett gränsvärde för max tillåtet avstånd, om kantelement ligger utanför detta värde skapas en ny vertex till polygonen och processen upprepas tills samtliga kantelement ligger innanför det tillåtna värdet.

4.2

Navigationsmeshens storlek

Navigationsmeshen slutgiltiga antal trianglar varierar mycket beroende på terrängens utformning.

Vid en mer varierad och bergig terräng skapas fler trianglar till navigationsmeshen än vid en platt. Antalet slutgiltiga trianglar påverkas även sannolikt av lutningens gränsvärde, vid större acceptans skapas fler trianglar. Applikationen skulle därmed vara mer motiverad att använda för en platt terräng.

Tabell 4.2.1: Antalet trianglar vid olika terränger med olika tillåtna lutningar. Samtliga terrängmodeller som användes vid testet bestod av 45000 trianglar.

Terräng Lutning Navmesh Trianglar Procent av ursprung

19 (25)

Bild 4.2.1: Bild på den platta terrängen.

Bild 4.2.1: Bild på den blandade terrängen.

4.3

Applikationens Precision

På grund av att voxelvolymens upplösning bestäms i heltal och även snabbt begränsas utav minnesutrymme och så kommer navigationsmeshen få en viss förskjutning i jämförelse med den ursprungliga 3D-modellen

21 (25)

5

Diskussion

En stor del av projektets tid las på att leta information om hur navigationsmeshen skulle kunna genereras. Jag hittade inga artiklar, men däremot ett par webbsidor som gav förslag på hur man skulle kunna gå till väga för att lösa problemet.

Under slutskedet av utvecklingen av applikationen blev jag även tvungen att optimera vissa algoritmer eftersom den totala exekveringstiden hade blivit över en minut för den enklaste terrängen jag använde. Detta hade jag inte räknat med att behöva göra och kunde säkert ha undvikits med bättre förkunskap.

6

Avslutning

Syftet med projektet var att undersöka och skapa en applikation som kunde generera navigationsdata automatiskt.

I projektet har problematiken bakom skapandet av navigationsmeshen kartlagts och en applikation som genererar meshen har tagits fram.

Den slutliga applikationen är inte perfekt även om målen som sattes upp är uppfyllda. För att applikationen ska skapa en tillräckligt exakt navigationsmesh för att användas till ett spel behövs mer optimering, bättre hantering av vissa brister i precisionen och mer testning. Men applikationen är en bra utgångspunkt för fortsatt arbete.

23 (25)

7

Referenser

7.1

Vetenskapliga artiklar

C. Andújar, P. Vázquez, and M. Fairén (2004). Way-Finder: guided tours through

complex walkthrough models.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.7364&rep=rep1&type=pdf

D. Haumont, O. Debeir and F. Sillion (2003). Volumetric cell-and-portal generation.

http://artis.imag.fr/Publications/2003/HDS03/mcp.pdf

Elmar Eisemann, Xavier D´ecoret (2008). Single-Pass GPU Solid Voxelization for

Real-Time Applications.

http://artis.imag.fr/Publications/2008/ED08a/solidvoxelizationAuthorVersion.pdf

Julien Pettré, Jean-Paul Laumond and Daniel Thalmann. A navigation graph for

real-time crowd animation on multilayered and uneven terrain.

http://vrlab.epfl.ch/~jpettre/publis/05vcrowdpettre.pdf

Long Zhang, Wei Chen, David S. Ebert, Qunsheng Peng (2007). Conservative voxelization.

http://www.purdue.edu/discoverypark/vaccine/publications/pdf/Conservative%20Voxelizatio n.pdf

L.M. van Driel (2008). Semantic navigation in video games.

Michael Schwarz, Hans-Peter Seidel (2010). Fast Parallel Surface and Solid

Voxelization on GPUs.

https://mpi-inf.mpg.de/~mschwarz/papers/vox-siga10.pdf

Tomas Akenine-Möller (2001). Fast 3D Triangle-Box Overlap Testing.

http://www.cs.lth.se/home/Tomas_Akenine_Moller/pub

Zhao Dong Wei Chen Hujun Bao Hongxin Zhang Qunsheng Peng (2004).

Real-time Voxelization for Complex Polygonal Models.

351 95 Växjö / 391 82 Kalmar Tel 0772-28 80 00

dfm@lnu.se Lnu.se

7.2

Övriga referenser

David Eberly (2002). Triangulation by Ear Clipping.

http://www.geometrictools.com/Documentation/TriangulationByEarClipping.pdf

David Miles. Crowds in a Polygon Soup: Next-Gen Path Planning.

http://www.navpower.com/gdc2006_miles_david_pathplanning.ppt

Mikko Mononens. Navigation-mesh Construction Toolset for Games.

http://code.google.com/p/recastnavigation/

Subhash Suri. Polygon Triangulation.