Implementering av interaktionsmetoder i 3D med haptik för undervisning i mekanisk konstruktion NIKLAS SCHERP

Implementering av interaktionsmetoder i 3D med haptik för undervisning i mekanisk konstruktion NIKLAS SCHERP Examensarbete Stockholm, Sverige 2010

Implementering av interaktionsmetoder i 3D med haptik för undervisning i mekanisk konstruktion NIKLAS SCHERP Examensarbete i datalogi om 30 högskolepoäng vid Magisterprogrammet, datalogi Kungliga Tekniska Högskolan år 2010 Handledare på CSC var Lars Kjelldahl Examinator var Yngve Sundblad TRITA-CSC-E 2010:023 ISRN-KTH/CSC/E--10/023--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.kth.se/csc

Sammanfattning I detta examensarbete, som är den del av EU Tempus-projektet, har undersökts och implementerats olika metoder för interaktion i en 3D VR-miljö med målet att de ska användas för undervisning i mekanisk konstruktion på ett universitet i Kairo. Prototypen har designats och implementerats för att användas till att montera en pump med maskindelar (som är 3DS-modeller från Kairo) och samtidigt mäta tiden som en del av en arbetsstudie. Tidtagningen var ett önskemål från universitetet i Kairo. Utrustningen för interaktionen är den vanliga datormusen och ett haptiskt pekdon. Olika metoder för att flytta objekt har implementerats och jämförts. Med den första metoden kan användaren markera ett objekt och sen placera det genom att klicka på dess korrekta destination. Med den andra metoden kan användaren dra ett objekt till dess destination. Förflyttningarna kan göras i alla riktningar (x, y, och z). Vi tror att interaktion med haptik är mer naturlig än att använda musen. Tidtagning har inkluderats i prototypen och fungerar med alla interaktionsmetoder. Det är möjligt att ändra inställningar genom att ändra i en fil med en texteditor. Dessa inställningar gör det möjligt att montera en annan maskin än den som har använts vid testerna av prototypen i detta examensarbete. Instruktioner för hur den filen ska ändras finns i ett appendix i slutet av denna rapport. Prototypen innehåller inget riktigt GUIgränssnitt eftersom detta arbete endast fokuserar på 3D-interaktionsmetoder ur en programmerares och användares synvinkel. En utvärdering av prototypen har inte kunnat göras inom tidsgränsen för detta arbete. Ett frågeformulär har skrivits och inkluderats i appendix för att underlätta en sådan undersökning i framtiden. För implementationen har programspråket Python använts. Under arbetet med att implementera funktionerna upptäcktes att CAD-figurerna har för hög upplösning och antalet polygoner i dem måste minskas för att de ska kunna användas i undervisningen. Haptiken var svår att få att fungera bra i prototypen på grund av begränsningar i utvecklingsmiljön. En begränsning är att området för avkänning är begränsat och alla objekt som ligger utanför detta ignoreras. Dessa begränsningar beskrivs mer utförligt i denna rapport. Python har också en del begränsningar som programmeringsspråk till att utveckla 3D-applikationer, men för en prototyp som denna var det tillräckligt. Trots allt tror vi att en fungerande prototyp hade krävt mer tid att utveckla så att det haft tillräcklig kvalitet för att användas i undervisningen. Även en separat version för haptiken vid sidan av de övriga interaktionsmetoderna hade varit nödvändig.

Abstract Implementation of methods for interaction and use of haptic for education in mechanical construction In this master s project being part of a EU Tempus project we investigate and implement different methods for interaction in 3D VR environment with the goal that it will be used for teaching in mechanic construction at a university in Cairo. The prototype that has been designed and implemented aims at assembling machine elements to a pump (delivered as 3DS models from Cairo) and also for measuring time as part of a work study environment according to wishes from the Cairo university. Interaction devices used are an ordinary 2D mouse and a haptic device. Different methods of moving objects have been implemented and compared. With the first method the user can mark an object and then place it by clicking on its destiny position. With the second method the user can drag the object to its destiny position. Movements can be done in all directions (x, y,and z). We feel that interaction with the haptic device is more natural than with the mouse. Time measurement has been included in the prototype and is working in all interaction modes. The different settings are possible to change in a file using a text editor. These settings makes it possible to for instance assembly other machine components than has been used during testing in this prototype. Details on the setting file is included in appendix of this report. The prototype does not include a real GUI interface but has only been focused on 3D interaction from a user's and implementer s point of view. An evaluation of the prototype could not be done within the time limits of this work. A questionnaire has been set up to make it easier to do such an evaluation in the future. The implementation used the Python programming language. During implementation it was found that resolution of the CAD-models is too high and that the number of polygons need to be cut down before use in education. The haptic was hard to get working in the prototype because of limitations in the development environment. One limitation is that the space for registration use a limited region and all objects are ignored outside of this region. These limitations are described in more detail in this master s thesis. Python also has some limitation as a programming language for developing 3D-applications, but for a prototype like this it was acceptable. Although we think that a working prototype has been developed more time would be needed to make a system of enough quality to be used in education and also that a separate version of the program for the haptic is needed.

Innehållsförteckning 1 Introduktion om Virtual Reality...1 1.1 Vad Virtual Reality är för något?...1 1.2 Blandformer av Virtual Reality...2 1.3 Hårdvaran för Virtual Reality...2 1.3.1 Haptik...2 1.3.2 Skärmar...3 1.4 Vad det brukar användas till?...4 1.5 Problem med Virtual Reality...5 1.6 Virtual Reality som utbildningsverktyg i mekanisk konstruktion...5 2 Tempus-projektet...6 2.1 Om projektet...6 2.2 Projektets mål...6 2.3 Projektets begränsningar...7 2.4 Användningen på ASU...7 3 Programmet Vizard...7 3.1 Översikt...7 3.2 Specifikationerna...7 3.3 Bra egenskaper...8 3.4 Svagheter...9 3.5 Körmiljön...10 4 Planeringen av prototypen...10 4.1 Examensarbetets mål...10 4.2 Avgränsningar...11 4.3 Relaterat arbete...11 4.4 Hur prototypen bör se ut...12 5 Genomförande...12 5.1 De olika metoderna som övervägdes...12 5.2 Rotation och skalning av vyn...13 5.2.1 Funktion...13 5.2.2 Matrishanteringen...14 5.3 Markering av objekt...15 5.3.1 Problemställning...15 5.3.2 Shader för omarkerat objekt...16 5.3.3 Shader för markerat objekt...17 5.4 Peka och placera...18 5.4.1 Problemställning...18 5.4.2 Implementation...19 5.5 Markera och dra...19 5.5.1 Problemställning...19 5.5.2 Implementation...20 5.6 Peka och dra med haptik...20 5.6.1 Förutsättningar...20 5.6.2 Implementation...21 5.6.3 Kollisionsdetektion vid haptisk förflyttning...22 5.7 Detektion av haptik...23 5.8 Tidtagningen...23 5.9 Utseendet...24 5.10 Utplacering av objekt vid start...24

6 Diskussion...25 6.1 Gränssnittet...25 6.2 Interaktion med musen...26 6.3 Haptiken...26 6.4 Prestandan...27 6.5 Buggar i Vizard...27 7 Resultat och slutsatser...28 7.1 Resultatet...28 7.2 Kodkvaliteten...28 7.3 Testning av prototypen...28 7.4 Haptiken...28 7.5 Testresultatet...29 8 Framtida arbete...29 8.1 Förslag på förbättringar...29 8.2 Förslag på användartest...30 8.3 Versioner...30 8.4 Haptik...30 9 Litteratur...31 10 Bilaga A: Ordlista...33 11 Bilaga B: Mini-manual...34 12 Bilaga C: File format...36 13 Bilaga D: Questions about the program...37 14 Bilaga E: How to set up haptic and Vizard...38

1 Introduktion om Virtual Reality I detta kapitel beskrivs Virtual Reality, dess historia och ett antal grundläggande begrepp inom detta område. De som är bekanta med vad Virtual Reality är kan hoppa över det här kapitlet. I detta examensarbete har Virtual Reality inte använts under utvecklingen av prototypen, men resultatet ska vara möjligt att köra i de VR-system som ASU ska använda. En speciell programvara har använts för att utveckla prototypen. Programmet gör det enkelt att anpassa prototypen till en VR-miljö. Mer om detta program i nästa kapitel. 1.1 Vad Virtual Reality är för något? Virtual Reality brukar förkortas VR och är en teknik för att interagera med en datorgenererad värld. Det finns många olika definitioner och typer (Pantelidis, 1996), men det gemensamma för alla är alltså interaktionen. Interaktion kan ske på olika sätt och ofta är det haptiska verktyg som används. Det är dock inte nödvändigt att använda haptik eller någon annan typ av force feedback 1 för att det ska kallas "Virtual Reality". Det är inte heller nödvändigt att använda så kallade VR-hjälmar (HMD, Head Mounted Display). Kraven för att det ska kallas Virtual Reality är följande (Psotka, 1995): Det ska gå att interagera med objekten, dvs plocka, flytta, osv. Interaktionen bör vara naturlig. Användaren ska kunna titta åt olika håll i den virtuella världen och kunna förflytta sig i denna. Det finns olika typer av Virtual Reality. Artikeln (Pantelidis, 1996) listar några olika typer: Genom skärm: Det absolut vanligaste sättet att presentera 3D-informationen på. Det är också det billigaste eftersom det räcker med att använda standardhårdvara, som kan köpas överallt där datorer säljs. Immersiv: vilket innebär att användaren är helt omsluten av den virtuella miljön. För att uppnå detta används vanligen en HMD (Head Mounted Display) för att titta sig omkring i miljön. Simulator för bil, flyg och andra fordon. Används för att träna körning med det fordon som avses. Simulatorn är då inredd som en riktig bil eller som en cockpit med bildskärmar istället för vanliga fönster. Ratten samt övriga reglage är kopplad sensoriskt till en dator. Force feedback kan förekomma. I en flygsimulator är det vanligt att det finns en rörlig hytt som reflekterar hur mycket planet lutar. Spegelvärld där användaren ser en avatar av sig själv, där denne kan interagera i miljön. CAVE är ett rum med upp till sex väggar som får bilden projicerad utifrån på väggarna. Denna typ har idag oftast ersatts av HMD eftersom det är billigare och 1 Force feedback är när en händelse i 3D-miljön ger en respons i form av en kraft eller motstånd i den utrustning som användaren håller i. Exempel är vibrationer i rattar för spel eller det motstånd som kan kännas när en penna på ett haptiskt pekdon stöter emot ett objekt. 1

är då inte knutet till någon lokal med fast installerad utrustning. Tidigare fanns en CAVE som kallades VR-kuben på KTH. Den användes för forskning och demonstrationer. En enklare indelning existerar också (Mujber, 2004): Icke-immersiv: Med vanlig standardutrustning för dator som mus, tangentbord och skärm. Semi-immersiv: Joystick, haptik och större skärm, eventuellt projektor. Full immersiv: HMD, CAVE. Den icke-immersiva typen kostar minst att ordna och full immersiv är betydligt dyrare. 1.2 Blandformer av Virtual Reality Utöver Virtual Reality finns också blandformer: Augmented Reality: Här placeras virtuella objekt in i en bild av vår verkliga värld. Augmented Virtuality: Här är det tvärtom, verkliga objekt i en virtuell värld. Den som är intresserad av mer läsning rekommenderas lästipsen som finns i litteraturlistan. 1.3 Hårdvaran för Virtual Reality 1.3.1 Haptik Ett viktigt och vanligt redskap inom Virtual Reality är haptik. Ett haptiskt pekdon brukar se ut som i figur 1 på nästa sida. Det består av en penna på en arm, som kan röras i olika riktningar. På pennan finns knappar som på en mus för att greppa med. Med haptik kan användaren ta på objekt på ett annat sätt än med musen. Musen ger en något onaturlig interaktion med virtuella objekt eftersom den rör sig i bordsplanet och enbart har två frihetsgrader 2. En kropp i 3D-rummet har sex frihetsgrader, tre för rotation och tre för translation [1]. Frihetsgrader brukar ha det kortare namnet DOF, efter engelskans Degrees Of Freedom. För haptik används frihetsgrader för att ange vad de klarar att göra. Den utrustning som används i detta projekt (Phantom Omni) har sex frihetsgrader för geometrin och tre för haptiken. Det finns även sådana som är billigare (Falcon) och den har bara tre för geometrin. När det gäller haptiken är det ofta endast tre frihetsgrader, alltså ingen vridkraft i pennan. Haptik brukar användas till en hel del, än så länge mest inom forskning. Exempel på 2 Frihetsgrader är ett begrepp inom fysik och mekanik. Det anger hur partiklar (objekt) kan röra sig i en 3D-värld. Frihetsgraderna kan delas upp i translationsfrihetsgrader och rotationsfrihetsgrader. 2

användningsområden är utbildning av sjuksköterskor där de får träna på att sätta in sprutor. Ett annat användningsområde är visualisering av seismiska data där det är svårt att förstå den volymetriska datamängden. Då är haptik bra för att känna sig fram. Det ska även gå att göra modellering av föremål med haptik (Salisbury, 1999). Det finns ett program som stöder användning av haptik och det är ClayTools från Sensable, som också är tillverkaren av Phantom Omni. [9]. Figur 1: Ett haptiskt pekdon, här Phantom Omni. Bild från vrealities.com. 1.3.2 Skärmar För Virtual Reality är det vanligt att kunna se bilden i 3D. Det finns olika sätt att göra det på. Varje metod har sina fördelar och nackdelar. Den enklaste och billigaste metoden är den anaglyfiska. Det innebär att bilden delas upp i två olika färger, vanligen röd och cyan. Även kombinationen röd och grön förekommer. Kostnaden för ett par sådana glasögon är mycket låg. Det fungerar med en vanlig datorskärm utan några speciella krav. Att dela upp bilden är enkelt med OpenGL och programmet Vizard, som beskrivs i kapitel 3.3, har detta stöd inbyggt. I båda ramverken kan detta konfigureras med ett enda kommando. Med anaglyfisk 3D är det vanligt att ghosteffekter uppstår på grund av att färgerna på bilden inte exakt överensstämmer med glasögonens filter. Det problemet undviks med metoder baserade på polarisation. Med denna metod används en särskild skärm där det finns två olika polarisationsriktningar inbyggda. Det går att göra samma sak med projektor och då används två stycken projektorer med varsitt polarisationsfilter på. Det skulle i princip kunna gå att sätta polarisationsfilter på vanliga projektorer om de som används är av DLP-typ 3. Till detta krävs förstås särskilda glasögon med polarisationsfilter. Filtren ska stämma med riktningarna på glasögonens respektive öga. Fördelen med denna metod är att bilden blir bättre än vad den anaglyfiska kan erbjuda. 3 Det går inte att sätta polarisationsfilter på LCD-projektorer eftersom de redan har ett sådant inbyggt. Två filter med olika riktning ger inte ändrad polarisation, utan bilden blir istället blockerad. 3

Det finns ett sätt till att få 3D och det är att använda skärm som klarar en uppdateringsfrekvens på minst 120 Hertz. Till det används glasögon som växlar mellan ögonen (shutter glasses). Växlingen går till på det sättet att glasögonen har flytande kristaller och ett polarisationsfilter i glaset. Bilden blockeras genom att det sätts en spänning på de flytande kristallerna så att inget ljus släpps igenom. Varje öga får därför varannan bild, 60 gånger per sekund. Det behövs också oftast en infraröd ljusgivare som synkroniserar glasögonen så att bilderna ges till rätt öga. Varannan bildruta visas på höger och varannan på vänster. För att kunna visa i 3D utan att flimmer uppstår bör uppdateringsfrekvensen alltså vara minst 120 Hertz på skärmen. Därför har det varit vanligt att CRT-skärmar användes eftersom LCD-skärmarna inte klarat detta krav på prestanda. Det finns numera LCDskärmar som kan användas till detta, men det fanns inte många att välja på under hösten 2009. Det finns ytterligare en typ av skärmar, som dock inte skall förväxlas med vanlig LCD. De ger en 3D-bild och metoden kallas autostereoskopisk. Det innebär att särskilda glasögon eller något annat hjälpmedel inte används för att se bilden i 3D. En sådan skärm är WOWvx från Philips. Om fler tillverkare börjar göra autostereoskopiska skärmar eller om de överhuvudtaget når konsumentmarknaden återstår att se. 1.4 Vad det brukar användas till? Virtual Reality kan användas till en rad olika ändamål. Utbildning som i detta fall är ett av dem och den vanligaste. Exempel på områden där Virtual Reality är lämpligt att använda är: Konstruktion (mekanisk, arkitektur, osv...) Medicin (kirurgi och tandläkare) Träning i simulator (bil, flyg, osv...) Molekyler, kemi. (T.ex ett annat examensarbete inom Tempus, Wikell 2009). Datorspel (Dock brukar interaktionen inte vara naturlig ). I övrigt, som inte är utbildning, kan det användas för till exempel arktitektur och design. Däremot finns tillämpningar där Virtual Reality är olämpligt. Sådana är till exempel där användaren interagerar med sig själv på något sätt, som att sätta in kontaktlinser (Pantelidis, 1996). Eftersom utrustning för Virtual Reality brukar vara dyrbar, åtminstone om full immersion önskas, brukar de som använder tekniken vara begränsat till institutioner och större företag. Sådana skulle kunna vara till exempel biltillverkare, flygindustrin och universitet där det finns ett behov av detta. Det är ju till exempel inte så lämpligt att träna nya tandläkare på riktiga patienter utan att först testa på virtuella objekt. Innan Virtual Reality fanns utfördes träningen på dockor, men de kan endast användas ett begränsat antal gånger och kostar pengar att ersätta. För användning i datorspel finns glasögon och tillhörande givare att köpa, men haptik (bortsett från forcefeedback) och immersiv 3D-upplevelse lär dröja ett tag till. 4

1.5 Problem med Virtual Reality Virtual Reality är inte helt problemfri. Ett vanligt problem med Virtual Reality är illamående. En orsak av flera till problemet är att det användaren ser inte stämmer med vad balanssinnet rapporterar. Användaren sitter stilla medan denne förflyttar sig i den virtuella världen [2]. Normalt brukar avvikelser i balanssinnet, av hjärnan, tolkas som att något olämpligt har ätits och därför uppstår illamåendet. För att det ska uppstå krävs att det ska vara immersivt (hela synfältet) och att användaren rör sig i 3D-miljön. Det räcker inte med endast en bild på en skärm (Johnsson, 2003). Problemet ökar med antalet detaljer i den virtuella världen. Symptomen brukar vara av arten sjösjuka dvs yrsel, illamående, koncentrations-svårigheter och trötthet. Upp till 80-90% av användarna får symptom. I Tempus-projektet kommer 3D-glasögon att användas och de ger inte dessa problem eftersom de inte täcker hela synfältet. Däremot kan glasögonen ge ont i ögonmusklerna vid längre tids användning och det är på grund av att ögonen intar en onaturlig position i förhållande till fokuspunkten (skelning). Några faktorer som påverkar graden av illamåendet (förutom verklighetsgraden): Täckningsgraden av synfältet (inneslutning). Fördröjning mellan manöver och respons. Hur snabbt användaren rör sig i den virtuella världen. Mängden 3D-information. 1.6 Virtual Reality som utbildningsverktyg i mekanisk konstruktion För varje tillämpningsområde ställs specifika krav på utrustningen. I fallet med att lära ut mekanisk konstruktion behöver den virtuella miljön efterlikna den verkliga situationen, även om det inte är helt nödvändigt. Det beror naturligtvis på hur mycket kostnader som ska läggas ut på utrustningen. Tillverkningsprocessen omfattar följande steg: (1) tillverkning, (2) montering, (3) kontroll och verifiering. Steg 1 innebär att maskindelarna tillverkas, steg 2 innebär att delarna sätts ihop till en färdig produkt, och i steg 3 testas att produkten fungerar. Det program som har utvecklats i detta examensarbete omfattar steg 2, nämligen monteringssteget. I programmet ska därför finnas färdiga delar som har gjorts i ett CAD-program. Målet med Virtual Reality i monteringssteget brukar vara följande (Mujber, 2004): Att minska antalet steg och tiden som behövs för att göra delarna till en produkt. Delarna måste nämligen designas för att kunna sättas ihop utan svårigheter. Att utvärdera hur bra monteringen blir. Hur svårt det är att montera och vad det kostar i form av arbetstid. Även risken för att fel görs vid monteringen utvärderas. Att verifiera montering, men också demontering. Det får naturligtvis inte vara för svårt att ta isär apparaten om det blir aktuellt med reparation. Montering sker inte bara vid tillverkningen utan även vid reparation och underhåll. 5

Inget av dessa mål handlar primärt om utbildning av montörer, men det hindrar inte att Virtual Reality används till det ändå. Tidtagningen, som ska finnas i programmet, är tänkt att hjälpa studenterna att optimera sin strategi vid monteringsarbetet. Det är närmast relaterat till punkt två ovan. 2 Tempus-projektet 2.1 Om projektet Tempus-projektet startades under år 2007. Det är ett samarbete mellan Ain Shams University (ASU) i Egypten, Helwan University i Egypten, KTH i Stockholm och Nottinghams universitet i Storbritannien. Projektet är finansierat av EU. Bland annat ska exempelvis speciella 3D-skärmar köpas in till studenternas laborationssal. Arbetet utförs av examensarbetare och anställda på de respektive universitet som deltar i projektet. Projektet fortsätter även efter att detta examensarbete blivit färdigt. 2.2 Projektets mål Tempus-projektet är ett projekt vars syfte är att bygga upp ett VR-labb på Ain Shams University (ASU) i Egypten. Laborationssalen ska användas för undervisning i mekanisk konstruktion. KTH och Nottingham bidrar med kunskaper som ASU inte har. KTH bidrar med 3D-grafiken och detta examensarbete är en del av det. Den planerade laborationssalen ska bestå av en föreläsningssal med möjlighet att visa 3D-bilder med hjälp av stereoprojektion. Salen ska rymma cirka 25 personer. De ska använda två projektorer som är modifierade med INFITEC-teknik 4 och studenterna (åskådarna) har speciella glasögon för att kunna se bilden. Utöver föreläsningssalen ska också finnas ett antal datorer i laborationssal för studenterna att träna på. De är utrustade med speciella LCD-skärmar som kan visa bilden i 3D och enligt planer ska det också finnas någon form av haptik. Övriga mål inom Tempus-projektet är följande: Förbättra och förnya kurserna för teknologstudenterna på Ain Shams University. Utvidga kunskaperna och använda ny teknik för ingenjörers arbete. Introducera nya sätt att lära ut metoder, med inriktning mot samarbete och interaktion mellan studenter. Göra virtuella experiment inom olika kunskapsområden. Träning för de lärare och övrig personal på att använda den nya tekniken. Erbjuda träning för ingenjörer som arbetar i industrin. 4 Projektorerna är typ F30 och normalt polariserade, men i detta fall är det INFITEC som används, vilket innebär att varje öga får varsitt våglängdsintervall inom rött, grönt och blått. 6

2.3 Projektets begränsningar Det är tänkt att det ska finnas minst åtta datorer i laborationssalen för studenterna. Det faktum att datorerna ska användas av studenter måste beaktas eftersom hårdvaran, till exempel haptiska pekdon är små, dyrbara och lätta att ta med sig. Det har förekommit diskussioner om de ska ha två haptiska pekdon per dator, men de är osäkra på om varje dator ska ha två stycken, endast en, eller ingen alls. De är dyra och det är också enligt uppgift onödigt att ha två stycken. 2.4 Användningen på ASU I Tempus-projektet ska det tas fram program som är tänkta att användas på universitetet i Egypten. De som ska använda dem är lärare och studenter på mekanisk konstruktion och maskin. Studenterna ska genomföra experiment och övningar inom utbildningen. De program som tas fram genom examensarbetena inom projektet kommer förmodligen att användas som prototyper och behöver därför utvecklas på något sätt innan de kan användas i undervisningen. Varje program som utvecklas är tänkt att vara fristående och kommer inte att sättas ihop till en applikation. 3 Programmet Vizard 3.1 Översikt Det program som har valts för arbetet inom Tempus-projektet är Vizard från Worldviz. På nästa sida finns en bild på hur programmeringsmiljön ser ut. Det är ett program som gör det möjligt att på relativt kort tid göra en prototyp med hjälp av Python-script. Python är centralt i Vizard på så sätt att all kod som skrivs är i Python. Programmet kostar pengar, men bygger på öppna projekt som OpenSceneGraph och fysikmotorn ODE. 3.2 Specifikationerna I Vizard ingår ett stort antal olika moduler för visualisering i 3D och Virtual Reality. Långt ifrån alla används i Tempus, men för att ge en helhetsbild av vad det är för program ges här en lista på en del av de egenskaper och specifikationer som Vizard har i kortform: Python 2.4 OpenSceneGraph 1.2 Stöd för många olika modellformat, inklusive 3DS (3D-studio) som används i Tempus Stöd för udda hårdvara som används för Virtual Reality. 7

Haptikstöd (endast Senasble-hårdvara än så länge) och tracking. Fysik via ODE (Open Dynamics Engine). En bekväm IDE (Integrated Development Environment) där koden kan skrivas och provköras. Den använder Scintilla för kodeditorn. Möjlighet att göra HUD (Heads Up Display), som är en slags meny i 3Dfönstret. Dock endast text i dem. Stöd för cluster och CAVE. Det finns fler funktioner och om dem går det att läsa på Vizards hemsida där det också finns en mer detaljerad lista på vilka format som stöds. En länk dit finns i länksamlingen. En fullt fungerande demoversion som fungerar i 90 dagar finns att hämta där om epostadress uppges. Kod som skrivs i demoversionen fungerar fullt ut i den riktiga. Figur 2: Vizard IDE. Det är här Pythonkoden skrivs. 3.3 Bra egenskaper För priset fås en miljö där utvecklaren kan skriva kod i Python. Dessutom är programvaran färdiganpassad för Virtual Reality-tillämpningar. Med programmet följer ett antal moduler för hårdvara för exempelvis haptik, HMD och tracking. Alternativet, om koden ska skrivas med C++, är att utvecklaren måste leta reda på dem själv och få dem att fungera med grafikens kärna (OpenSceneGraph). Det är inte bara att sätta ihop modulerna. Det krävs kod som sköter kommunikationen mellan modulerna. Att sätta upp en fungerande kompileringsmiljö med separata moduler som laddas ner från respektive projekts hemsida tar också en del tid. Med miljön följer även ett antal exempel, även om de är ganska få till antalet. Trots det är det enkelt att komma igång med programmet och dess API är på så pass hög nivå att behövs så mycket kod. 8

Programmet har stöd för en mängd olika format för 3D-modeller som exempelvis 3DS och obj för att nämna de vanligaste formaten. Stödet för alla formaten är inbyggt i OpenSceneGraph och är inte något som är unikt för Vizard. Även animationsformat finns med. Mer om vad som ingår går att läsa på OpenSceneGraphs och Vizards hemsidor, se i länklistan. Fysikmotorn ODE är visserligen av det lite enklare slaget. Det finns en mer avancerad som heter Bullet och som också är öppen kod, ZLib, men den här duger till det allra mesta av det som Vizard är tänkt att användas till. Den version av OpenSceneGraph som används i Vizard är gammal, version 1.2, medan den version som finns att hämta från OSGs hemsida är version 2.8.2 nu i oktober 2009. Troliga orsaken till att de har blivit kvar med den gamla versionen är att det krävs stora förändringar i Vizards kod för att den nya ska fungera där. Version 2.x är nämligen inte bakåtkompatibel med 1.x. Dock planerar Worldviz en version där de gått över till OSG 2.x, men det dröjer innan de är färdiga med den, förmodligen tidigast under år 2010. Det kommer troligen inte att bli några skillnader i Python-API på grund av migreringen. Jag tror inte att versionen i detta sammanhang har så stor betydelse, men i C++ är OSG version 2.x mycket enklare att hantera än 1.x. Mycket av den funktionalitet som i version 1.x krävde externa bibliotek finns nu integrerad i de senaste versionerna. Exempelvis behövs inte längre Cal3D för att göra animationer. API-dokumentationen är något ordfattig. Däremot finns ett antal exempel som kan användas som en utgångspunkt och de är enkla att förstå. Annars är det enkelt att testa för att avgöra vilket beteende funktionerna har. Den stora fördelen med Vizard kan sammanfattas med ett enda ord: Enkelhet. 3.4 Svagheter Det allra tydligaste är att Vizard inte gör all den funktionalitet som finns i OpenSceneGraph tillgänglig från Python-miljön 5. Det är bara en mycket liten del av funktionaliteten som är tillgänglig och under projektets gång visade det sig vara en liten nackdel. Fast denna nackdel kan också vara en fördel. Det är nämligen så att om det hade varit många fler funktioner kanske det hade varit svårt att hitta den funktion som ska användas. En annan begränsning är prestandan. Normalt används C++ för att göra 3Dapplikationer, men här är det som sagt Python. Prestandaskillnaden mellan C++ och Python är stor [5]. Tillräckligt stor för att den ska vara tydligt märkbar. Python har bra prestanda jämfört med många andra scriptspråk och många känner till det språket. Ett annat språk som heter Lua kan ha ännu lite bättre prestanda, men det är inte lika många utvecklare som kan det språket, särskilt inte hos målgruppen för Vizard. Lua är annars ett vanligt scriptspråk inom spelutveckling. Ett tredje problem är att programmet kostar pengar och i och med att den kostar är koden till utvecklingsmiljön och bindningarna till modulerna inte tillgängliga, även om 5 Jag har jämfört Vizard-help med OpenSceneGraph API-dokumentation. Se referens [3] och [4]. 9

delarna som har använts är från öppna projekt. Det är tillåtet enligt LGPL och BSD 6. Med källkoden tillgänglig hade det varit möjligt att lägga till den funktionalitet som krävts för att kunna göra prototypen på smidigast möjliga sätt. Nu fick det bli lite fulkod här och där, vilket förmodligen drar ner prestandan något. Det har inte gjorts några tester som verifierar prestandaskillnaden, men jag utgår från det som normalt gäller om script jämfört med kompilerad kod. Det skall sägas att dessa nackdelar är ur en programmerares synvinkel. Målgruppen för programmet Vizard är inte de som är erfarna programmerare utan är tänkt att användas inom många olika områden där programmering inte hör till den normala verksamheten, framför allt akademiska kretsar exempelvis inom kemi, naturvetenskap, arkeologi, mekanik med flera. I sådana sammanhang är det inte alltid det finns tillgång till en programutvecklare. 3.5 Körmiljön Vizard är konstruerad för att köras i Windows XP. Utvecklarna på WorldViz skriver i sitt eget forum att Windows Vista fungerar oftast men det är några funktioner som inte är helt kompatibelt med det operativsystemet. Möjligen har det rättats vid tidpunkten då när detta examensarbete avslutats. Programmet fungerar även i Wine (Linux) som jag kör hemma, dock utan haptik. Hur det ska installeras beskrivs i bilaga 5. 4 Planeringen av prototypen Detta kapitel handlar om planeringsfasen där en prototyp skulle tas fram. Hela genomförandet kan här delas upp i planering (detta kapitel), implementation (kapitel 5) och diskussion (kapitel 6). 4.1 Examensarbetets mål Huvuduppgiften var att undersöka olika metoder för interaktion. En prototyp skulle tas fram som demonstrerar de olika metoderna för interaktion med maskindelar. Det är meningen att användaren ska plocka ihop en maskin, i detta fall en pump. För att kunna göra det finns olika metoder för att markera och flytta de olika delarna. Under monteringen av delarna ska även tid mätas från det användaren startar tills alla delarna är på plats. Den hårdvara som skulle användas var musen och ett haptiskt pekdon (Phantom Omni). I första hand var det musen som skulle används och i andra hand haptik. Till utvecklingen av prototypen lades tio veckor. 6 LGPL och BSD är licenser för mjukvara. Gemensamt för dessa är att det ges möjlighet att ta del av källkod, modifiera den och distribuera den vidare till tredje part. Villkoren är olika. BSD tillåter att inte lämna ut källkod för de ändringar som har gjorts medan LGPL inte gör det. 10

4.2 Avgränsningar Det som skulle göras var att undersöka vilka metoder som finns, implementera dem och utvärdera hur implementationen blev. Avgränsningarna kan därför summeras som nedan: Undersökning av vilka vanliga förflyttningsmetoder som finns och eventuellt hitta egna. Skriva kod för olika interaktionsmetoder i språket Python med Vizard IDE. Skriva Python-kod för användning av haptik. I första hand en enhet. Skriva kod för tidtagning så att tidsstudier kan göras. Utvärdera erfarenheter och kvalitet av den kod som skrivits och testats. Eventuellt testa två haptiska enheter (vänster och höger) om det kunde lånas in en extra Phantom Omni en kort tid för ändamålet. 4.3 Relaterat arbete Nedan finns kortfattade beskrivningar på några arbeten som är relaterade till de frågeställningar som har undersökts i denna rapport: Design of interactive transformation tools in a medical application (Wrange, 2007) är ett examensarbete som utförts på KTH och KI. Rapporten handlar om transformationsverktyg för att flytta objekt i en 3D-miljö. Där är användningen till för visualisering av molekylstrukturer inom medicin. De operationer som är möjliga att göra där är translation, skalning och rotation. Jämförelser med 3Dmodelleringsverktyg görs i rapporten. Virtual Reality and Engineering Education (Pantelidis, 1996) är en undersökning om hur Virtual Reality fungerar för användning för utbildning i mekanisk konstruktion. Det beskriver hur ett labb kan byggas för detta ändamål med låg kostnad. Den tar också upp fördelarna och nackdelarna i sammanhanget. Artikeln är dock ganska ålderstigen. Det som står där är inte nödvändigtvis tillämpbart idag i alla delarna. Virtual Reality: A design tool for enhanced consideration of usability validation elements (Marsot, 2007). Här går det att läsa om användning av haptik vid simulering av tillverkning, i detta fall vikning av plåt. Immersive training systems: Virtual reality and education and training (Psotka, 1995). Detta handlar om Virtual Reality inom utbildning i allmänhet, inte bara mekanisk konstruktion. Arbetet kan betraktas som föråldrat. Virtual reality applications in manufacturing process simulation (Mujber et al. 2004). Här görs jämförelser mellan olika VR-system för mekanisk konstruktion. A virtual reality-based experimentation environment for the verifcation of humanrelated factors in assembly processes (Chryssolouris et al. 2000). Denna artikel undersöker olika metoder att utföra montering av föremål i en Virtual Realitymiljö. Det som används är handtracking. 11

4.4 Hur prototypen bör se ut Det är tänkt att studenterna på ASU ska kunna använda programmet på både vanliga skärmar och speciella 3D-skärmar. Det kan inte förutsättas att en 3D-skärm alltid används. Det kan nämligen tänkas att studenterna skulle vilja köra det på sina egna datorer och då inte har möjlighet till stereoskopisk 3D. Det är samma sak med haptiken, saknas det måste det vara möjligt att flytta objekten med musen. I prototypen bör också finnas ett läge för att göra placeringen av maskindelarna på den position där de ska vara då monteringen startas. Det bör finnas eftersom det är svårt att mata in siffror utan att se var delarna hamnar. Ett avancerat GUI med menyer och dylikt har låg prioritet eftersom detta arbete ska fokusera på interaktionsmetoder. 5 Genomförande I detta kapitel beskrivs hur de olika interaktionsmetoderna med musen och haptik har implementerats. Varje delkapitel utom de tre sista består av en problemställningsdel och en implemenationsdel. 5.1 De olika metoderna som övervägdes I detta examensarbete övervägdes några olika metoder för förflyttning av objekt exklusive de som redan gjorts i ett annat examensarbete. Här listas metoderna och en diskussion om huruvida de var svåra eller enkla att implementera i Vizard. Metod 1: Direkt förflyttning med musen. Objektet flyttas genom att klicka med musen och dra denna till den nya positionen. Det fanns här olika alternativ. Musen har tre knappar och den i mitten brukar vara ett rullhjul. I ett tidigt skede bestämdes att mittenhjulet skulle reserveras till för att rotera och skala vyn. Då var det naturligt att låta den vänstra knappen flytta objektet i ett 2D-plan och den högra i den tredje dimensionen. Alternativen att välja mellan är om planet ska vara parallellt med skärmens (vyn) eller om den ska ligga med XZ-axlarna. Eftersom programmet är gjort så att vyn roteras runt Y-axeln ungefär som i 3D-programmet Maya, faller det naturligt att detta plan läggs ihop med XZ-axlarna och att den tredje dimensionen är längs med Y. Denna metod var enkel att implementera i programmet. Mer om hur det har gjorts finns i kapitel 5. Metod 2: Placering med musklick. Med denna metod klickar användaren först på det objekt som ska placeras och sen på den plats där den ska placeras. Denna metod var den enklaste av alla att implementera. Det finns kod i projektet som gör beräkningar på grund av att de funktionerna helt enkelt saknas i Vizard, men det är inte omfattande och här påverkas inte prestandan märkbart. Dessa beräkningar avgör om användaren har klickat på rätt plats för att placera objektet. Metod 3: Förflyttning med hjälp av en manipulator. I 3D-program, som Blender och Maya, finns en så kallad manipulator som ser ut som tre pilar i olika riktningar. Det 12

vanliga är att RGB överensstämmer med ordningen XYZ, det vill säga att exempelvis rött är längs X-axeln. Denna metod hade förmodligen varit den absolut bästa vid sidan av haptiken då den är lätt att förstå. Det finns ett problem: för att få den att fungera måste Z-bufferten manipuleras. Om ett objekt skulle vara större än manipulatorn skulle den befinna sig inuti objektet och därför inte synas, se figur 3 på hur det är tänkt att se ut. Därför behöver Z-bufferten nollställas innan manipulatorn ritas. I programmet Vizard finns ingen möjlighet att göra de nödvändiga operationerna på Z-bufferten under pågående ritning. Den här metoden kan därför inte implementeras med Vizard. Figur 3: Manipulator för (1) translation, (2) skalning och (3) rotation Metod 4: Flyttning med hjälp av ett haptiskt pekdon. Denna metod måste anses vara det absolut bästa av alla då den ger den mest naturliga flyttningsrörelsen, men på grund av att utrustningen är så dyr finns även de andra metoderna baserat på att använda musen med i prototypen. Till skillnad från musen, där olika skiftlägen är nödvändiga för att flytta i respektive axel, kan användaren med en Phantom Omni flytta objekten direkt i alla riktningar och dessutom rotera objekten. Det tar lite tid att vänja sig vid att hålla i pennan, men det går fort. Denna metod finns med i prototypen, även om vissa begränsningar finns. Mer om begränsningarna senare under beskrivningen av implementationen. 5.2 Rotation och skalning av vyn 5.2.1 Funktion Den interaktionsrutin som finns inbyggd i Vizard och används som standard är inte tillräckligt bra för det ändamål som prototypen ska användas för. Standardfunktionen i Vizard är sådan att vyn roteras och flyttas beroende på den riktning musen dras från den punkt på skärmen där förflyttningen startas. Till exempel om användaren klickar på en punkt någonstans i vyn och drar musen uppåt flyttas kameran 7 framåt i en konstant hastighet. Förflyttningen är av den typ som förekommer i 3D-spel, användaren går framåt, bakåt och åt sidorna i ett rum. I denna prototyp ska användaren inte gå runt i rum. Här är det istället en maskin som visas och musen ska användas för att rotera den runt dess centrum. Därför har det gjorts så att rotationen kan styras exakt genom att muspositionen avgör vilken vinkel figuren visas från. Jag har valt att göra rotationerna så att figuren roteras på samma sätt som i Maya. Här är det mittenhjulet på musen som används för både rotation och skalning. Med denna metod roteras kameran runt Y-axeln om musen flyttas horisontellt och runt X-axeln om musen flyttas vertikalt. Det är också 7 Kamera är ett begrepp inom 3D och är den punkt som 3D-miljön visas från. Ett annat ord som kan förekomma är ögonpunkt (eng: eye point). 13

samma rotation som används i 3D-spel för att titta åt olika håll, men skillnaden från standardläget i Vizard är att det görs en rotation och inte en förflyttning. Dessutom befinner användaren sig här utanför origo. Det enklaste var att göra modifikationerna i modelview-matrisen. Först hämtas matrisen ut från Vizard genom att anropa viz.mainview.getmatrix(). Sen roteras matrisen på samma sätt som att operationen glrotate() anropas i OpenGL, fast här är det min egen kod i Python som gör det. Därefter läggs den ändrade matrisen tillbaka in i Vizards vy. Resultatet av operationen är att vyn har roterats. 5.2.2 Matrishanteringen Det är vanliga 4x4-matriser som används och de fungerar på exakt samma sätt som i OpenGL, som är ett högerhandssystem. För att kunna göra rotationerna smidigt med en X- och Y-position från musen behövs därför två olika matriser, en för rotation runt X och en för Y. Dessutom behövs en matris för skalningen, egentligen en translationsmatris. Alla vinklar är i grader eftersom rotationerna i OpenGL är i grader. Matriserna är egentligen enligt vänsterhandssystemet eftersom musen har origo i övre vänstra hörnet medan OpenGL har den i nedre vänstra hörnet. Det är ju som bekant så att -sin(y) = sin(-y). Rotation runt X och Y samt skala ger följande matriser: 0 0 0 rx=[1 1] 0 cos x sin x 0 0 sin x cos x 0 ry=[ 0 0 0 cos y 0 sin y 0 1] 0 1 0 0 scale=[1 sin y 0 cos y 0 0 0 0 För skalningen är värdena sx och sy alltid 0 eftersom ingen förflyttning i sidled eller uppåt/neråt görs. Alla förflyttningar görs i Z-led. Eftersom figuren är stor är skalfaktorn satt till 5.0. Matriserna multipliceras därefter ihop på följande sätt: mtx= ry rx scale Mtx är den matris som skickas tillbaka till modelview. Det är också viktigt att tänka på att matrisen följer layouten i OpenGL. Där ligger siffrorna i denna ordning: [0 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15] Och i Python skall siffrorna därför stå i denna ordning: mtx = [0, 4, 8, 12, 1, 5, 9, 13, 2, 6, 10, 14, 3, 7, 11, 15] 0 0 sx 0 1 0 sy 0 0 1 sz 0 0 0 1 ] Skalningen är egentligen inte en riktig skalning. Skulle det göras en äkta skalning uppstår det en del problem, främst med haptiken. Istället är den funktionen gjord så att 14

kameran flyttar sig närmare objektet om det ska bli större och bort från den om det ska bli mindre. Denna metod fungerar bäst ihop med de positioner som objekten har och med den haptiska avkänningen. Haptiken har en begränsning för avkännings-området och den är +/-50.0 i alla riktningar från origo. Är objektet utanför det området går det inte att ta på det. Därför bör äkta skalning undvikas. Det hade varit bäst om det inte hade funnits någon begränsning på avkänningsområdet. Undersökningar har gjorts för att avgöra om det finns något annat sätt att komma runt problemet, men det fanns ingen sådan lösning. Det mest troliga är att begränsningen finns i Vizard, men den kan också finnas i en drivrutin. Lösningen är acceptabel och eftersom objekten inte befinner sig i ett rum märks det inte att skalningen egentligen är en translation. 5.3 Markering av objekt 5.3.1 Problemställning För att kunna markera ett objekt måste användaren få en feedback så att han vet att det valda objektet är markerat. Annars är det lätt att tro något är fel. För att visa att ett objekt är markerat finns olika sätt att göra det på. Ett sätt som en annan exjobbare i Tempus-projektet har gjort är att ha två olika versioner av varje objekt. En med ordinarie färg och en annan i avvikande färg, som är den markerade versionen. För att visa att det är markerat läggs det färgade objektet, som är något större, utanpå det ordinarie. I hans fall är objekten enkla sfärer som ska föreställa molekyler och då går det att göra på det sättet. I det här examensarbetet består objekten av maskindelar som inte nödvändigtvis är konvexa och då kan problem uppstå om något objekt läggs utanpå. Problemen visar sig genom att konkava delar inte hamnar på rätt position när föremålet är större. Om till exempel bokstaven E läggs ovanpå en mindre version av samma bokstav är det lätt att se att den översta vågräta linjen hamnar lite för högt och den nedre lite för lågt. Se figuren nedan. Figur 4: En större bokstav täcker inte den mindre eftersom den inte är konvex. Ett annat sätt, som är bättre, är att använda en shader som färglägger figurerna. Fördelen 15

med en shader är att det är lätt att påverka färgen och att endast en upplaga av figurer behövs. En shader är också enkel att byta ut eller underhålla utan att ändringar i pythonkoden behöver göras. Då uppstår frågan om vilken färg som det markerade objektet ska ritas med för att det ska synas så bra som möjligt. Det måste fungera oavsett vilken färg som objekten har. Samtidigt får det inte uppstå en situation där ett markerat objekt råkar få samma färg som ett annat. 5.3.2 Shader för omarkerat objekt Egentligen skulle det kunna räcka med att endast ha shader för markerat objekt, men det är inte snyggt med matta ytor på de omarkerade. Eftersom de är maskindelar bör de vara blanka. En shader behövs därför även för omarkerade objekt. Jag har övervägt mellan olika algoritmer, till exempel Phong och Cook-Torrance, som är avsedda för metalliska ytor. Med båda algoritmerna kan konstanter sättas och som påverkar blänkeffekten på objekten. Algoritmerna fungerar dock på helt olika sätt. Jag valde Phong som är enkel att implementera. Egentligen spelar det ingen roll vilken som används. Enkelheten kan dock ha en viss fördel om någon på ASU skulle vilja ändra på dess kod. Så här ser koden för Phong ut: Vertex-shader: varying vec3 normal; varying vec3 vertex; void main() { normal = gl_normalmatrix * gl_normal; vertex = (gl_modelviewmatrix * gl_vertex).xyz; } gl_texcoord[0] = gl_multitexcoord0; gl_frontcolor = gl_frontmaterial.diffuse; gl_position = ftransform(); Fragment-shader: varying vec3 normal; varying vec3 vertex; // gl_vertex kan ej läsas i fragment-shader! // Lånad från GLSL-laboration 8. vec3 phong(vec3 Normal, vec3 Ambient, vec3 Diffuse, vec3 Specular, float Shininess) { vec3 L = normalize(gl_lightsource[0].position.xyz - vertex); vec3 H = vec3(gl_lightsource[0].halfvector); vec3 LAmbient = vec3(gl_lightsource[0].ambient); vec3 LDiffuse = vec3(gl_lightsource[0].diffuse); vec3 LSpecular = vec3(gl_lightsource[0].specular); } return vec3(diffuse * LDiffuse * max(dot(normal, L), 0.0) + LAmbient * Ambient + Specular * LSpecular * pow(max(dot(normal, H), 0.0), Shininess)); 8 Den GLSL-labb som nämns här är den som ges i AGI-kursen på KTH CSC och bygger på Martin Fitgers examensarbete (Fitger, 2008). När koden skrevs som en labbuppgift utgick jag från information på Wikipedia, se länk [7]. Wikipedia brukar, men inte alltid, vara korrekt. 16

void main() { float pot = 34.0, ks = 0.7; vec3 N = normalize(normal); vec3 Specular = vec3(ks, ks, ks); } // Eventuell textur skickas till diffuse, dvs tex.xyz * // gl_frontmaterial.diffuse.xyz. gl_fragcolor = vec4(phong(n, gl_frontmaterial.ambient.xyz, gl_frontmaterial.diffuse.xyz, Specular, pot), 1.0); Som synes är det GLSL som koden är skriven i. Stöd för det språket finns inbyggt i OpenSceneGraph och kan därför användas direkt utan inläsning av extra moduler i Vizard. GLSL är också det enda shaderspråk som stöds. Shaderkoden placeras i egna filer utanför Python-källkoden och läses in med hjälp av en inbyggd funktion i Vizard. Det finns en avhandling som beskriver Phong-shading, se denna för detaljer bakom algoritmen (Phong, 1975). Jag har för enkelhetens skull valt att låta konstanterna pot och ks ha sina värden direkt i koden. Annars kan det vara lämpligt att göra en uniformvariabel, som sätter konstanten, från programmet som använder shadern. Det är lika enkelt att ändra i shaderns kod som att ändra i huvudprogrammet och programmet har ingen nytta av att kunna ändra på dessa konstanter eftersom de angivna värdena är de som bäst liknar metall. När användaren startar programmet är det förstås endast Phongshadingen som syns eftersom alla objekt är omarkerade. Figuren nedan visar skillnaden. Figur 5: Den vänstra är utan shader och den högra är med shader. 5.3.3 Shader för markerat objekt Som jag skrev tidigare måste ett markerat objekt vara tydligt avvikande från de övriga. Ett bra sätt att göra det på är att använda normalkodning. Det blir både snyggt och tydligt. Shaderkoden är mycket enkel och kort: Vertex-shader: varying vec3 normal; void main(void) { vec4 v = vec4(gl_vertex); gl_frontcolor = gl_color; 17

} normal = gl_normalmatrix * gl_normal; gl_position = gl_modelviewprojectionmatrix * v; Fragment-shader: varying vec3 normal; void main(void) { gl_fragcolor = gl_color * vec4(normalize(normal), 1.0); } Normalens värde i varje punkt på objektet används här för att sätta en färg. Denna shader används normalt till att hämta värden från en normal-map, men passar även till detta ändamål eftersom den ger ett tillräckligt avvikande utseende på det valda objektet att det syns tydligt. En beskrivning av algoritmen så som den brukar användas finns i boken Real-Time Rendering (Möller, 2002) på sid 299-301. Ovanstående shaderkod kan inte användas för normal-mapping eftersom den här är ändrad för att vara anpassad just till denna prototyp och en del funktioner är därför utelämnade. När ett objekt har markerats så att shadern aktiveras, då ser det ut som i figur 6 på nästa sida. Figur 6: Ett objekt som är markerat. 5.4 Peka och placera 5.4.1 Problemställning I denna interaktionsmetod, att peka och placera, är det tänkt att användaren ska klicka på ett objekt så att den markeras. Det går att klicka var som helst på objektet. Därefter ska användaren peka och klicka på den plats där objektet ska vara. Även här kan musklicket hamna var som helst inom ett område där objektet ska placeras. En metod är att beräkna avståndet mellan musklick på två olika punkter. Det är svårt att göra på det sättet eftersom användaren klickar på två ställen, det första klicket är på objektet och det andra på ett område vid destinationen. Därför kan avståndet mellan de två muspositionerna variera och kan inte användas för att avgöra om det är rätt plats att placera objektet på. Jag har i implementationen därför valt en annan lösning än ovanstående. 18