Gruppen har lärt sig hur det är att jobba i en grupp som får en beställning i form av en programvara, för att sedan utveckla den. Det var första gången gruppmedlemmarna jobbade fram en plan och specificerade krav med en verklig kund. Gruppen fick också testa på en agil arbetsmetodik och trots att det var en egen variant av en etablerad metodik har gruppen förstått vikten av en väldefinierad metod för utveckling. Rent utvecklingsmässigt fick alla i gruppen goda kunskaper i Unity, och några lärde sig även Blender. Med Unity-utvecklingen lärde sig gruppen programspråket C#, och fick förståelse för hur en spelmotor kan användas för programvaruutveckling.
7
Slutsatser
I detta kapitel dras slutsatser genom att besvaras frågeställningarna i avsnitt 1.3 utifrån re- sultatet och diskussionen.
Hur kan ett program för visualisering av personskador implementeras så
att man skapar värde för kunden?
Gruppen anser att projektet kan stå som ett gott exempel för hur det kan göras. Man kan se till hur kommunikationen har strukturerats; man kan se till hur programkod har distribuerats mellan medlemmarna; man kan också se till hur vi gått från att spåna designidéer till att få fram en färdig produkt, samt hur den faktiska implementationen ser ut.
Vilka erfarenheter kan dokumenteras från projektarbetet som kan vara
intressanta för framtida projekt?
Samtliga gruppmedlemmar känner att de har fått många bra erfarenheter som kan vara nytti- ga i framtida projekt. Framförallt fick medlemmarna testa att jobba i en grupp på sju personer under en lång period. Gruppen fick också använda en agil arbetsmetodik och utveckla pro- gramvara i en spelmotor.
Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?
Istället för att följa upp systemanatomin som togs fram för kursen strukturerades program- varan enligt Unitys praxis. Denna frågeställning skulle besvaras genom att testa att följa upp systemanatomierna i projektet; eftersom gruppen inte gjorde det kan inte denna fråga besva- ras.
Hur kan ett program tas fram med stora krav på användarvänlighet?
Gruppen anser att projektet har visat på hur man kan utveckla en användarvänlig produkt. Genom att alltid ha användarupplevelsen som diskussionsunderlag för designen och att ha återkoppling med referensgrupper, anser gruppen att ett användarvänligt resultat kan nås.
A
En spelmotors påverkan på ett
projekt som vårt av Martin
Jirenius
A.1
Inledning
Ett av de första besluten som vi i gruppen behövde ta var om vi skulle göra en egen 3D-motor eller använda en redan befintlig. Vi undersökte frågan kort och märkte att spelmotorer verka- de smidigt och att en egen motor krävde mycket arbete. Vi valde som rapporten avslöjar att använda oss av spelmotorn Unity [75]. Jag kommer i det här individuella bidraget att studera hur en 3D-motor generellt sett är uppbyggd. Jag kommer vidare att jämföra hur en 3D-motor skiljer sig i olika abstraktionsnivåer. Detta kommer att vara nödvändigt då en undersökning kommer att göras där denna teori är nödvändig för att förstå och kunna resonera kring frå- gorna som tas upp. Denna undersökning kommer att ha som mål att se vad personer föredrar för funktioner och arbetssätt när de ska arbeta i ett projekt som detta. Jag kommer som re- sultat att redovisa vad som togs fram i undersökningen och diskutera utifrån detta om hur man kan resonera kring vad som har fungerat och vad som hade kanske fungerat bättre. För vidare läsning om spelmotorer hänvisas läsaren till appendix B där en jämförelse mellan två populära spelmotorer har gjorts.
A.1.1
Syfte
Syftet med det här individuella bidraget är att ge läsaren insikt i hur man kan resonera och jämföra alternativen när det kommer till 3D-utveckling. Gruppen ansåg att det inte skulle vara lönt att göra en egen 3D-motor och valde att använda en spelmotor. Detta var baserat på att gruppen inte visste vad en egen 3D-motor innebar, varken i tid eller komplexitet. Ett av målen med det här bidraget är därför att ge läsare en bättre förståelse inom 3D-motorer för att man ska kunna förstå de olika fördelar och nackdelar som alla alternativ för med sig.
A.1.2
Frågeställningar
1. Vad är och hur fungerar en 3D-motor?
2. Hade det varit bättre om gruppen hade gjort en egen 3D-motor till projektet istället för att använda Unity?
A.2
Teori
A.2.1
3D-grafik
3D-grafik kan delas upp i tre delar: modellering, placering och animering samt rendering.
A.2.1.1 Modellering
En viktig egenskap hos ett godtyckligt, datorgenererat 3D-objekt är att den är uppbyggd av trianglar, mer exakt av tre noder som representerar en triangel. Detta kan enkelt illu- streras med en kub som figur A.1 visar. Trianglar har viktiga matematiska egenskaper som gör att flera algoritmer i senare skede blir effektiva. Däremot är det framför allt den enda 2-dimensionella geometriska formen som, approximativt, kan bygga upp alla andra geomet- riska former i både 2D och 3D [70].
Figur A.1:En kub uppbyggd av trianglar
Figur A.2:Sfärer uppbyggda av olika antal trianglar
Figur A.2 illustrerar den approximation som kan behöva göras om man man har ett begränsat system. Vissa modelleringsprogram kan bygga upp objekt med hjälp av godtyckliga mång- hörningar, ty detta kan ses som enklare för nybörjare. Det är däremot sett som en dålig metod att bli van vid då det finns stora nackdelar med att använda godtyckliga månghörningar i en 3D-modell. Många matematiska formler och algoritmer stödjer bara trianglar och kommer resultera i oönskade beteenden med polygoner utöver trianglar. En annan stor nackdel är att alla 3D-motorer inte är byggda för att kunna hantera dessa. Se A.2.2 för mer information. Den grupp av polygoner som bygger upp en kropp kallas för mesh, ”polygonnät”. När man arbetar med 3D-modeller är det ofta modellens polygonnät man är intresserad av istället för att arbeta med individuella polygoner. Det finns många sätt att representera po- lygonnät på i form av en fil vilket är anledningen till den stora mängd filtyper som finns för 3D-objekt. Dessa sätter upp förutsättningar för vad en 3D-motor kan avläsa från modellen och olika metoder kan medföra både för- och nackdelar för motorn. Till exempel har filtypen OBJ [52] betydligt mindre information om ett objekt än vad filtypen FBX [30] har.
A.2. Teori
A.2.1.2 Placering och animering
Att placera en 3D-modell i ett rum handlar i grund och botten om att definiera vad alla noder har för koordinater. Att manuellt definiera var de olika delarna av polygonnätet är utsatta är inte konstigare än att skriva över deras koordinater. Däremot är detta sällan vad man önskar när man vill animera en modell från ett läge till ett annat. Därför animerar man gärna 3D- modeller med hjälp av en rig, ”struktur”. “Rigging is a process of taking any character or object and attaching various controllers and manipulators to its structure so that the animator can easily grab them to perform transformations and set key-frames for animation” [12]. Detta kan tolkas och översättas som: ”Att koppla ett godtyckligt objekt till en struktur innebär att man tilldelar den ett antal olika styrmetoder för att det ska bli enkelt för en animatör att animera med hjälp av transformationer och nyckelrutor”. Däremot är det nödvändigt att introducera kon- ceptet om ”stela kroppar” (eng. rigid bodies) innan man kan börja diskutera animering med strukturer. Man definierar en stel kropp som ett system bestående av partiklar med fixerad position gentemot varandra [46]. För att sätta detta i sammanhanget för modeller kan vi byta ut partiklar mot noder så det går att använda sig av de matematiska formler som tillämpas på stela kroppar. Det finns flera matematiska metoder för att räkna ut hur en stel kropp rör sig, och med hjälp av dessa metoder kan man definiera ett system för hur en struktur beter sig. Det finns flera metoder på hur en struktur kan kopplas till ett polygonnät och därför finns det likaså flera filtyper som tar hand om detta på olika sätt.
A.2.1.3 Rendering
De två huvudkoncepten som kommer tas upp under det här kapitlet är nodtransformation samt rastrering och fragment. Nodtransformation är den teknik man använder sig av för att kunna översätta en 3D-kropp till en 2D-skärm. Detta inkluderar dessutom hur man går från kroppens koordinater till rumskoordinater relativt kameran osv. Eric Lengyel har i sin bok ”Mathematics for 3D Game Programming and Computer Graphics, Third Edition” illustrerat detta flöde på ett tilltalande sätt [46].
Figur A.3:Nodtransformationer under rendering
Figur A.3 illustrerar väl hur man just tar sig från objektets eget 3-dimensionella koordinat- system till skärmens 2-dimensionella koordinatsystem. För det här bidraget är det irrelevant hur dessa transformer ser ut utan för vidare läsningen hänvisas läsaren till Eric Lengyels bok.
Den andra viktiga delen inom rendering är rastrering och fragment. Rastrering är den pro- cess som utförs när man fyller de horisontala spann av pixlar som tillhör polygonen. För en triangel kan det fungera så som figur A.4 nedan visar, (tagen ur “A Superscalar 3D Graphics Engine” av Andrew Wolfe och Derek B. Noonburg) [3].
Figur A.4:Illustration av en rastrering.
Däremot så kan det vara flera saker som spelar in för vad som bestämmer pixelns slutgiltiga färg. Till detta räknar man ofta djupet, en modifierad nodfärg och texturen vilket tillsam- mans med pixelns koordinat utgör ett fragment. Innan en pixel ritas ut på skärmen måste man kontrollera om den logiskt sett behöver ritas ut. Denna kontroll gör man genom fem tester illustrerade i figur A.5 nedan.
A.2. Teori
Det första testet, ”pixelägande” (eng. pixel ownership), är det test som kollar om fragmen- tet ligger i ett synligt fönster. Detta skulle t.ex. kunna misslyckas om fragmentet ligger i ett fönster men som täcks av ett annat fönster. Detta är dessutom det enda test som måste im- plementeras. Det andra testet, ”urklippstest” (eng. scissor test), är om ett program har begärt att ett område har begränsad rendering. Ett exempel på detta kan vara att skuggor inte all- tid ska synas. ”Transparenstest” (eng. Alpha test) är det tredje testet och det undersöker, efter att den slutgiltiga färgen har beräknats, om fragmentet ska uppföra sig som genomskinligt. Nästa test är ”stenciltestet” (eng. stencil test) vilket kollar om vissa kriterier är uppfyllda. Ett program kan välja vad som ska hända beroende på om testet lyckas eller misslyckas vilket t.ex. är en viktig egenskap i vissa renderingstekniker för skuggor. Det sista testet är ett ”djup- test” (eng. depth test). Det här testet ser om fragmentet har för stort djupvärde och inte borde renderas. Om alla dessa tester lyckas kommer bildbufferten att skriva in detta kombinerade värde till bufferten, vilket kallas blending eller blandning. Detta kommer i sin tur resultera i att bildskärmen ändrar sig.
A.2.2
3D-motor
Att prata om 3D-motorer är väldigt brett men man kan åtminstone konstatera att alla 3D- motorer har en sak gemensamt och det är tillhandahålla logik för att visa 3D-grafik. Det innebär att man måste skapa stöd för olika typer av 3D-objekt så att man vet vad det är för modell man läser in. Sen måste man dessutom skapa stöd för att kunna rendera grafiken på skärmen. Detta är ett minimikrav för en 3D-motor men ett nästan lika självklart krav är att kunna hantera hur man förflyttar och animerar kropparna som visas på bildskärmen. Har man skapat allt detta har man skapat ett lågnivå-API. API står för Application Programming Interface som betyder ’applikationsprogrammeringsgränssnitt’ och är det gränssnitt man i det här fallet skulle kommunicera med för att rita ut 3D-objekt på skärmen. Idag finns det många redan färdiga gränssnitt på låg nivå så som OpenGL [55], Direct3D [27] och Vulkan [87]. Dessa är utrustade med mer än bara det ovannämnda, och är man intresserad av vad de erbjuder hänvisas läsaren till respektive API. För det här arbetet räcker det med att veta att gränssnitten existerar och tillhandahåller all logik när det kommer till att kunna hantera 3D-grafik.
Eftersom det finns lågnivåsgränssnitt finns det även högnivåsgränssnitt. Dessa gränssnitt till- handahåller ofta mer logik för en applikation så som scener, event, m.m. Dessa är dessutom ofta byggda på ett lägre nivås gränssnitt. Exempel på dessa är Java 3D [43], OpenSceneGraph [56] och OGRE [54].
A.2.3
Spelmotor
En spelmotor, i synnerhet en som behandlar 3D, är egentligen bara ett högnivåsgränssnitt för 3D-grafik som har ännu fler funktioner. Vad som kännetecknar spelmotorer är att de nästan uteslutande tillhandahåller ett grafisk program för att man enklare ska kunna bygga upp sitt spel. Dessutom innehåller deras API många funktioner som är relevanta för spel. Vägsök- ningsverktyg, verktyg att bygga användargränssnitt med, fysikmotor och utökningsbarhet är några av de funktioner som Unity går ut med på sin hemsida [75].
A.3
Metod
A.3.1
Informationssökande
Till den här studien införskaffades teori och information via böcker, vetenskapsartiklar, ide- ella hemsidor och upphovsmakarnas hemsidor. Utifrån den teori som införskaffades kunde en undersökning annordnas vilket var det underlag som främst användes för att besvara de frågeställningar som definierades.
Den bok som främst användes var “Mathematics for 3D Game Programming and Computer Graphics, Third Edition” av Eric Lengyel [46]. Det är en kursbok som beskriver matematisk teori bakom 3D-grafik. Det hjälpte att läsa hans definitioner av begrepp men också formlerna som han härleder för att få en ökad förståelse inom ämnet.
Vetenskapsartiklar hittades främst via databasen ACM [6]. De sökfraser som användes var följande:
• 3D graphics engine • Game engine performance • Mathematics 3D graphics • Unity best practices
Artiklar valdes utifrån relevans, hur aktuella de var och antal citat.
För att hitta övergripande information om antingen ett program eller en produkt använ- des antingen programmets/produktens egna hemsida eller uppslagsverket Wikipedia.
A.3.2
Undersökning
Frågorna i undersökningen var ställda på ett sätt som gör att det går att kolla vad grupp- medlemmarna har tyckt varit fördelaktigt med utvecklingen i Unity. Det går även att urskilja om gruppmedlemmarna upplevs vilja arbeta med en låg- eller högnivå-API för 3D-grafik. Gruppmedlemmarna fick läsa ett påstående där de skulle svara:
• Instämmer inte alls • Instämmer delvis • Instämmer helt • Övrigt svar
Om övrigt svar valdes var medlemmen tvungen att skriva en egen kommentar. Om med- lemmen valde instämmer delvis uppmanades hen att kommentera för att det skulle bli tydligt vad hen tyckte stämde. Frågorna som ställdes var följande:
• 1. Jag känner att det hade varit bättre om alla i gruppen kunde köra Unity på sin laptop. • 2. Jag känner att versionshantera Unity har bromsat utvecklingen av programmet. • 3. Jag tror att det hade varit fördelaktigt om Unity var under Open-source licens. • 4. Jag tycker att scenerna laddar långsamt eller att de inte fungerar som jag önskar. • 5. Jag önskar att jag hade mer kontroll över hur man hanterar materials, shaders och
A.4. Resultat
• 6. Jag känner att Unitys GUI-system är begränsande.
• 7. Jag känner att Unity är krångligt p.g.a. alla funktioner som Unity har men som vi inte behöver.
• 8. Jag tycker att det hade varit bättre om vi hade hållit oss minimalistiska när det kom- mer till 3D-rendering.
• 9. Jag tycker att en grafisk utvecklingsmiljö har varit nödvändig för vårt utvecklande med 3D.
• 10. Jag känner att jag hade kunnat utvecklat vissa funktioner bättre för det här projektet än vad Unity tillhandahåller.
• 11. Jag känner att jag har blivit bromsad av att behöva leta efter hur Unity vill ha saker istället för att göra funktionerna själva.
A.4
Resultat
Resultatet från undersökningen kommer att presenteras i en tabell och kommentarerna kom- mer att skrivas därefter.
Tabell A.1: Tabell över resultat på undersökning
Fråga Jag instämmer helt Jag instämmer inte Jag instämmer delvis Övrigt svar
1 4 2 0 0 2 2 2 2 0 3 2 3 1 0 4 0 5 1 0 5 3 3 0 0 6 1 2 2 1 7 2 3 1 0 8 2 2 0 1 9 6 0 0 0 10 1 4 0 1 11 1 4 1 0
Nedan följer de kommentarer som införskaffades på vardera fråga. 1. -
2. Mergea scener är problem
Det har tagit tid från faktiska programmeringen men risken är att ännu mer tid hade lagts på annat om vi inte gjort så, det är svårt att veta!
3. I alla fall ingen nackdel
4. Ibland laddar det långsamt. Men sen beror det ju också på vilken dator man använder 5. Tror inte det behövs i vårt fall.
6. Har lite mindre koll på Unity så svårtatt säga vad som är begränsande. Fungerar rätt bra ändå
Det är en svår uppgift att packa så mycket funktionalitet i ett GUI så att det känns lättförståeligt. Minns bara att initialintrycket var rörigt.
7. Stort program, man vet inte riktigt vad som är rätt väg att gå för just vårt problem 8. Vet ej, har dålig koll
9. Att kunna se och ändra direkt i en scen har hjälpt.
10. Svårt att säga då jag har lite mindrekoll på vad Unity begränsar oss med. Vissa funktioner hade nog gått att optimera till just det vi vill använda det till
11. Man blir ju begränsad till unitys sätt att göra saker på, men det är ju inte bara negativt, deras sätt är ju rätt bra så bra att lära sig det ju.
Det är lätt att hitta information om Unity.
A.5
Diskussion
A.5.1
Metod
Vad man kan utvinna ur den här studien är subjektivt och frågorna kan ses som vinklade. Därför kommer jag nedan att diskutera hur jag ser på frågorna för att sedan ha mer substans till diskussion för resultatet.
1. Jag känner att det hade varit bättre om alla i gruppen kunde köra Unity på sin laptop. Att ha möjligheten att jobba mobilt är sällan en nackdel. Generellt sett har fullstora ut- vecklingsmiljöer, i synnerhet spelmotorer, höga systemkrav vilket ibland gör det svårt att köra på bärbara datorer med låga systemkrav. Därför hade en lösning på detta pro- blem kunnat vara att endast använda sig av en API utan en grafisk utvecklingsmiljö eller som tvingar utvecklaren att använda tunga algoritmer.
2. Jag känner att versionshantera Unity med git har bromsat utvecklingen av program-
met.
Unity har ingen inbyggd versionshantering med Git och har visat sig ha problem att få det att fungera smidigt baserat på det arbete som gjorts under projektets gång. Det finns andra spelmotorer som har integrerad versionshantering som tyvärr inte hunnits utforskats. Däremot är risken att man får den här typen av problem mindre ju mer kod man skrivit själv då förståelsen ökar.
3. Jag tror att det hade varit fördelaktigt om Unity var under open-source eller MIT-
licens.
Programmet som utvecklas måste gå under en MIT-licens [49]. Unity är inte under den licensen och det skulle kunna bli ett potentiellt problem för kunden i framtiden om de vill vidareutveckla. De två lösningarna till det här problemet är att antingen välja en spelmotor under en öppen källkodslicens eller bygga en egen motor.
4. Jag tycker att scenerna laddar långsamt eller att de inte fungerar som jag önskar. Många högnivås-API:er har en strikt scenhanterare som kan vara svår att manipulera. Spelmotorer optimerar oftast dessa för att kunna stödja stora spel med mycket i scenen. Även vanliga grafikmotorer kan ha försökt optimerat dessa till att lösa ett generellt problem. Detta är inte alltid nödvändigt, framför allt inte om man skriver ett vanligt program. En lösning är att gå ifrån högnivåsgränssnitt till lägre nivåer.
5. Jag önskar att jag hade mer kontroll över hur man hanterar materials, shaders och
lighting.
De flesta spelmotorer, Unity inkluderat, har ett automatiskt sätt hur man hanterar dessa egenskaper hos 3D-objekt. I vissa fall kan detta ta onödig datorkraft om programmet
A.5. Diskussion
man utvecklar inte kräver de avancerade inställningarna. Därför kan det ibland vara fördelaktigt att ha ett eget system för detta där man endast hanterar det som är nöd- vändigt. Detta alternativ kommer man lättast åt på lågnivåsgränssnitt.
6. Jag känner att Unitys GUI-system är begränsande.
Unity har tillsammans med många andra spelmotorer ett inbyggt sätt att hantera det tvådimensionella användargränsnittet. Detta är mycket p.g.a. att spel oftast kräver and- ra funktioner hos sitt användargränssnitt än vad vanliga program gör. Det kan däremot