FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK HOVEDOPPGAVE

NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK HOVEDOPPGAVE Kandidatens navn: Joakim Tysseng Fag: Datateknikk Oppgavens tittel (norsk): Observasjonspunkttilpasset projeksjon i et distribuert system for bildeveiledet kirurgi Oppgavens tittel (engelsk): Viewpoint adapted projection in a distributed system for image guided surgery Oppgavens tekst: Innen minimalt invasiv terapi benyttes i stadig økende grad 3D-datagrafikk for å veilede kirurgi og visualisere objekter som befinner seg utenfor brukerens synsfelt. Kombinert med stereografiske bildemetoder, er slik grafikk med på å øke nøyaktigheten av, og senke tiden brukt ved, kirurgiske inngrep. I dag benyttes hovedsaklig hodemonterte display (HMD) for å fremstille stereografiske bilder. Dette utstyret har enkelte ulemper som gjør det upraktisk i bruk. Som et alternativ til HMD, kan man benytte lerretsprojeksjon. Ved hjelp av spesialmaskinvare oppnår man stereosyn, samtidig som fysiologiske problemer knyttet til bruk av HMD elimineres. Visning av stereografiske bilder på lerret introduserer imidlertid nye problemer. Dersom observatøren ikke befinner seg sentrert foran lerretet, vil bildene oppfattes som forvrengte. Dette medfører at objektenes romlige plassering endres dersom observatøren forflytter seg. Objektenes bevegelser er kontraintuitive, de reduserer maksimal oppnåelig presisjon og kan resultere i ubehag for brukeren av systemet. Det er derfor ønskelig å utvikle et system som tar hensyn til observatørens posisjon. Ved å tilby relasjoner mellom den virtuelle og reelle verden som resulterer i objektbevegelser som kjennes naturlige for observatøren, kan bruken av et slikt system forenkles og ubehagsfølelsen motvirkes. For å redusere maskinvarekostnadene bør systemet distribueres over en klynge av standard-pc-er. Utred eksisterende systemer for distribuert rendrering og foreslå løsninger for et fremtidig system. Foreslå videre mulige relasjoner mellom den virtuelle og den reelle verden, og etabler et prototypesystem som gjør det mulig å teste og evaluere relasjonene. Oppgaven gitt: 07.10.02 Besvarelsen leveres innen: 03.03.03 Besvarelsen levert: 03.03.03 Utført ved: Institutt for datateknikk og informasjonsvitenskap Veileder: Eigil Samset Oslo, 3. mars 2003 Lars Aurdal Faglærer

Forord Dette er en hovedoppgave i datateknikk ved Institutt for datateknikk og informasjonsvitenskap, Norges teknisk-naturvitenskapelige universitet. Oppgaven er skrevet ved Intervensjonssenteret, Rikshospitalet universitetsklinikk, vinteren 2002-2003. Jeg vil gjerne takke veilederene mine, Eigil Samset og Lars Aurdal, for all oppfølging og støtte underveis i arbeidet med oppgaven. Videre vil jeg takke Arne Enger Hansen for hjelp med oppsett og testing av prototypesystemet, samt alle som deltok i testingen, kom med innspill eller hjalp til med korrekturlesing. En spesiell takk rettes til Mette Lafton for innsatsen under sluttføringen av rapporten. Oslo 3. mars 2003 Joakim Tysseng

Sammendrag I denne rapporten beskrives et system for observasjonspunkttilpasset 3D-grafikk til bruk i bildeveiledet kirurgi. En viktig trend i moderne medisin er minimal invasiv behandling, muliggjort ved bildeveiledet kirurgi. I det siste er også 3D-datagrafikk kombinert med medisinske bilder tatt i bruk. Dette krever intuitive og nøyaktige visualiseringsmetoder. Systemet som foreslåes i denne rapporten er et verktøy for 3D-grafikk der brukerens bevegelser påvirker posisjon og orientering av systemets virtuelle kameraer, og dermed vedkommendes oppfatning av virtuelle objekters romlige posisjon. Ved hjelp av observasjonspunktkorrigert perspektivprojeksjon kompenserer systemet for forvrengninger som oppstår dersom observatøren ikke befinner seg direkte foran visningsenheten. Tre forhold mellom brukerens bevegelser, den reelle og den virtuelle verden diskuteres. 1. Den virtuelle og reelle verden er sammenkoblet slik at virtuelle objekter har en fast posisjon i den reelle verden. Observatørens bevegelser i den reelle verden reflekteres direkte i kamerabevegelser i den virtuelle verden. 2. Den virtuelle verden låses i en fast posisjon i brukerens synsfelt. De virtuelle objektene følger observatørens bevegelser og forholdet fungerer dermed som et virtuelt hodemontert display. 3. Den virtuelle og reelle verden er sammenkoblet i et referansepunkt, men den virtuelle verden roterer slik at brukeren til enhver tid ser den virtuelle scenen fra samme vinkel. Observatørens bevegelser i den reelle verden resulterer i en bevegelse for det virtuelle kameraet langs aksen fra observatør til referansepunktet. Dette tillater studier av modellens detaljer uten at observatøren mister ønskede synsvinkel, samt muliggjør korreksjon av forvrengninger også for todimensjonale bilder. En prototype av systemet implementeres ved hjelp av et API for interaktiv 3D-grafikk. For automatisk plassering av observasjonspunkt brukes et videobasert sporingssystem. Tester gjennomført viser at sporingssystemets kalibrering og nøyaktighet ikke er tilstrekkelig i sitt nåværende oppsett. Prototypen har markante problemer med oscillopsia, tilsynelatende bevegelser av den virtuelle verden i forhold til en stabil referanse [4], selv når brukeren står stille. De tekniske aspektene for de foreslåtte forholdene mellom den reelle og virtuelle verden fungerer som planlagt, det samme gjelder for observasjonspunktkorrigert projeksjon.

iv Resultatene av arbeidet rapportert her er akseptert for publikasjon på konferansen Computer Assisted Radiology and Surgery (CARS) 2003 [43].

Innhold 1 Introduksjon 1 1.1 Motivasjon og bakgrunn........................ 1 1.2 Problemstilling............................. 2 1.3 Organisering av oppgaven....................... 2 2 Bakgrunn 5 2.1 Intervensjonssenteret.......................... 5 2.2 IGVaC.................................. 5 2.3 Virtuell og utvidet virkelighet...................... 6 2.3.1 Virtuell og utvidet virkelighet i medisin............ 6 2.4 Problemer i eksisterende systemer................... 6 2.5 Stereosyn................................ 7 2.6 Bildegenerering og -visning i 3D-grafikk............... 8 3 Forarbeid 9 3.1 Om distribuert rendrering........................ 9 3.1.1 Tre tjenertyper......................... 9 3.1.2 Oppgavedeling......................... 10 3.1.3 Rendreringsmetoder...................... 10 3.2 Eksisterende systemer for distribuert rendrering............ 11 3.2.1 WireGL............................. 11 3.2.2 Chromium........................... 12 3.2.3 Distributed 3D RealTime Rendering at Washington...... 14 3.2.4 OpenRT............................. 14 3.2.5 Distributed Open Inventor................... 16 3.3 Sammenlikning............................. 17 3.3.1 Krav til vårt system....................... 17

vi Innhold 3.3.2 WireGL og Chromium..................... 19 3.3.3 Distributed 3D RealTime Rendering at Washington...... 20 3.3.4 OpenRT............................. 21 3.3.5 Distributed Open Inventor................... 22 3.3.6 Konklusjon........................... 22 4 Metoder 25 4.1 Forhold mellom den reelle verden, den virtuelle verden og observatør 25 4.1.1 Tre ulike forhold........................ 25 4.1.2 Sporet posisjon......................... 26 4.1.3 Låst posisjon og synsvinkel.................. 26 4.1.4 Låst synsvinkel......................... 27 4.1.5 Posisjonering av den virtuelle verden............. 27 4.2 Realisering - relasjonsmatrise...................... 29 4.2.1 Relasjonsmatrise, sporet posisjon............... 30 4.2.2 Relasjonsmatrise, låst posisjon og synsvinkel......... 34 4.2.3 Relasjonsmatrise, låst synsvinkel................ 35 4.3 Observasjonspunktkorrigert perspektivprojeksjon........... 40 4.3.1 Projeksjonskorreksjon..................... 41 4.3.2 Konseptuelt........................... 42 4.3.3 Teori og matematikk...................... 44 4.4 Sporing av observatør.......................... 45 4.5 Kamerakorreksjon ved stereosyn.................... 46 4.5.1 Konseptuelt........................... 46 4.5.2 Teori og matematikk...................... 47 5 Verktøy og maskinvare 49 5.1 Biblioteker og operativsystem..................... 49 5.1.1 OpenGL............................. 49 5.1.2 Open Inventor.......................... 49 5.1.3 Coin............................... 50 5.1.4 Distributed Open Inventor................... 50 5.1.5 ARToolKit........................... 50 5.1.6 OpenTracker.......................... 50 5.1.7 Operativsystem og kompilator................. 51 5.2 Maskinvare............................... 51

Innhold vii 5.2.1 Datamaskiner.......................... 51 5.2.2 Projeksjonssystem....................... 51 5.2.3 Sporingssystem......................... 52 6 Realisering 55 6.1 Kravspesifikasjon............................ 55 6.2 Analyse av Coins rendreringssystem og kameraklasser........ 56 6.3 Implementasjonsdetaljer........................ 57 6.3.1 Observasjonspunktkorrigert projeksjon og relasjonsmatrise.. 57 6.3.2 Stereosyn............................ 59 6.3.3 Sporing............................. 60 6.3.4 Hjelpefunksjoner........................ 60 6.4 Diskusjon av implementasjon...................... 62 6.4.1 Frakobling av kamera- og sporingssystem........... 62 6.4.2 Sporet posisjonering av reelle objekter............. 62 6.4.3 Utskilling av matriseberegninger................ 63 6.4.4 Representasjon av lerret.................... 63 6.4.5 Automatisk lerretsoppsett................... 63 6.4.6 Korrekt beregning av clipping planes............. 63 6.4.7 Forenklet oppsett av initiell relasjonsmatrise.......... 64 6.4.8 Dynamisk bytte av forholdstype................ 64 6.4.9 Utvidet synsfelt......................... 64 7 Resultater og diskusjon 65 7.1 Brukertest................................ 65 7.2 Testoppsett............................... 66 7.2.1 Sporet posisjon......................... 67 7.2.2 Låst synsvinkel......................... 67 7.2.3 Låst posisjon og synsvinkel.................. 68 7.3 Testresultater.............................. 68 7.3.1 Sporet posisjon......................... 68 7.3.2 Låst synsvinkel......................... 70 7.3.3 Låst posisjon og synsvinkel.................. 70 7.4 Diskusjon av testresultater....................... 70 7.4.1 Sporingssystem......................... 71 7.4.2 Kritiske bemerkninger til testresultatene............ 71

viii Innhold 7.5 Oppsummering............................. 72 7.5.1 Brukertest............................ 74 7.5.2 Prototype............................ 74 8 Konklusjon 77 8.1 Oppsummering av resultater...................... 77 8.2 Fremtidig arbeid............................. 78 A Relasjonsmatriser 81 B Brukertest av SoSCPerspectiveCamera 85 B.1 Sporet posisjon............................. 85 B.2 Låst synsvinkel............................. 86 B.3 Låst posisjon og synsvinkel....................... 87 C Testfiler 89 D Ordliste 91 E Kildekode 97 E.1 SoSCPerspectiveCamera.h....................... 97 E.2 SoSCPerspectiveCamera.cpp...................... 100 Bibliografi 119

Figurer 2.1 Symmetrisk og asymmetrisk viewing volume............. 8 3.1 To bilder generert side ved side..................... 19 4.1 Sporet posisjon............................. 26 4.2 Translasjon, låst posisjon og synsvinkel................ 27 4.3 Rotasjon, låst posisjon og synsvinkel.................. 28 4.4 Låst synsvinkel............................. 28 4.5 Låst synsvinkel - 2D-bilder på plan................... 29 4.6 Initiell relasjon mellom og............. 31 4.7 Plassering og orientering av i og............. 31 4.8 Plassering av "!........................... 32 4.9 # med origo i $ $!......................... 32 4.10 &% med origo i (') "!......................... 33 4.11 +*, % kompensert for orientering................... 33 4.12 Endelig plassering av i, låst synsvinkel............. 33 4.13 Rotasjon av for å kompensere for hoderotasjon........... 34 4.14 Endelig plassering av i, låst synsvinkel og posisjon...... 34 4.15 Referansebase i, og...................... 36 4.16 Punkt relativt til referansebase..................... 37 4.17 Endelig plassering for punkt...................... 37 4.18 Bevegelser i, for låst synsvinkel.................. 38 4.19 Referansebase med kamerapunkt i origo................ 39 4.20 Rotasjon av referansebase........................ 39 4.21 Ny referansebase i den virtuelle verden................. 39 4.22 Før bevegelser i for låst synsvinkel................ 40 4.23 Etter bevegelser i for låst synsvinkel................ 41 4.24 Forvrengning av skjermbilde...................... 42

x Figurer 4.25 Korrigering av skjermbilde....................... 43 4.26 Skråstilt projeksjonsplan........................ 44 4.27 Objekters projeksjon på lerret...................... 47 4.28 Stereoprojeksjon med symmetriske viewing volume-er........ 48 4.29 Stereoprojeksjon med asymmetriske viewing volume-er........ 48 5.1 Sporingsmarkør brukt i ARToolKit................... 51 5.2 Maskinvareoppsett, testsystem..................... 52 5.3 Prosjektøroppsett............................ 52 5.4 Sporingskamera............................. 52 6.1 Kalltre for getviewvolume....................... 56 7.1 Testperson foran lerret......................... 66 7.2 Modeller for sporet posisjon, plassering................ 67 7.3 Modeller for sporet posisjon...................... 67 7.4 Modell for låst synsvinkel....................... 68 7.5 Modell for låst posisjon og synsvinkel................. 68 7.6 Visualisering og objekt i den reelle verden............... 69 7.7 Forskjellig virtuell og reell stereoseparasjon.............. 73 7.8 Bevegelser ved varierende stereoseparasjon.............. 73

Tabeller 3.1 Sammenlikning av systemer for distribuert rendrering......... 18 5.1 Maskinspesifikasjon, rendreringsklynge................ 51 6.1 Funksjon asymperspective....................... 57 6.2 Nye felter i SoSCPerspectiveCamera.................. 58 6.3 Funksjon setscreen........................... 58 6.4 Funksjon calccp............................ 58 6.5 Funksjon calcmapping......................... 59 6.6 Funksjon stereocorrect......................... 59 6.7 Funksjon callbackf........................... 60 6.8 Funksjon settrackingsource...................... 60 6.9 Funksjon settrackingmode....................... 61 6.10 Funksjon gettrackingmode....................... 61 6.11 Funksjon forcecamposition....................... 61 6.12 Funksjon forcecamorient....................... 61 6.13 Funksjon setlockedcamorient..................... 61 6.14 Funksjon iscamorientlocked..................... 62

Kapittel 1 Introduksjon 1.1 Motivasjon og bakgrunn Minimal invasiv terapi (MIT) er en av de viktigste trendene i moderne medisin i dag. Gjennom bruk av minimalt invasive metoder, forkortes pasientens sykehusopphold og rehabiliteringstid, noe som også gir samfunnsøkonomiske besparelser. Avansert medisinsk bildefremstilling er hovedkraften bak minimal invasiv terapi. Kikkhullskirurgi assistert av videoskopiske teknikker, er en bredt akseptert teknologi. I den senere tid er også bildeutstyr som tidligere er benyttet til diagnostikk, tatt i bruk for veiledning av minimalt invasive intervensjoner. CT, MR, røntgen og ultralyd er eksempler på slikt utstyr. Med nye metoder kommer også nye problemer. For MIT er ikke lenger øye-håndkoordinasjon via direkte syn mulig, men isteden erstattet av visualisering via skop eller radiologiske billedverktøy. Synsfeltet for videoskop er begrenset til det som ligger rett foran skopet og instrumenters plassering utenfor dette området, er derfor usynlig for brukeren. For å kompensere for ulempene ved MIT, er nye navigeringsverktøy under utvikling. Verktøyene baserer seg på visuell sammenkobling av bildeinformasjon fra ulike kilder. Gjennom bruk av nye verktøy håper man å oppnå en gevinst i form av økt produktivitet og kortere prosedyrer. Det ultimate målet er å gi medisinsk personell en form for supersyn med muligheter for ikke bare å se inn i pasienten, men også gjennom organoverflater til organenes indre strukturer. Verktøy for slik visualisering må være brukervennlige både i form av enkle, intuitive bruksmetoder og ergonomisk utforming. Utstyret må kunne benyttes av personell uten spesialkompetanse innen IKT, og det må kunne tilpasses ulike prosedyrer, samtidig som høy presisjon er svært viktig. Prisen på eksisterende spesialsystemer for visualisering er ofte svært høy. Samtidig er systemenes levetid ikke vesentlig høyere enn det som er normalt for andre datamaskiner. Det er derfor ønskelig å utvikle systemer som benytter standard masseproduserte PC-komponenter. Ved å kombinerer flere maskiner i en klynge, antas det at man kan oppnå tilfredsstillene ytelse til en lavere pris.

2 Introduksjon 1.2 Problemstilling For økt presisjon ved for eksempel bildeveiledet plassering av prober i organer, benyttes i dag 3D-datagrafikk kombinert med stereografiske metoder. Studier som er rapportert i [33] viser at presisjonen øker og tiden som brukes på korrekt probeplassering minskes dersom brukeren gis stereosyn fremfor monosyn. I eksisterende systemer for medisinsk visualisering benyttes i hovedsak hodemonterte displayer (HMD) for stereografisk fremstilling av bilder. Dagens HMD-utstyr er tildels tungt og upraktisk i bruk. Brukeren må ta av og på eller endre konfigurasjonen av utstyret for å flytte blikket fra visualisering til pasient. I tillegg kan lang tids bruk av utstyret være ubehagelig. Som et alternativ til HMD kan man benytte lerretsprojeksjon og briller som er spesialberegnet for stereosyn. Brukeren kan i denne situasjonen flytte blikket fritt mellom virtuelle og reelle objekter, og fysiologiske problemer knyttet til vekt og utforming av HMD-utstyr elimineres. Ved bruk av lerretsprojeksjon vil bildet kun oppfattes korrekt dersom observatøren befinner seg rett foran lerretet. For projeksjon av stereografiske bilder vil et annet observasjonspunkt gi feilaktig oppfatning av virtuelle objekters utseende og romlige posisjon. Objektene vil tilsynelatende bevege seg dersom observasjonspunktet flyttes. Denne bevegelsen er kontraintuitiv, reduserer observatørens presisjon, og antas å være en viktig årsak til svimmelhet og kvalme ved lengre tids bruk av slikt utstyr. For å beholde presisjon ved bruk av lerretsprojeksjon og samtidig motvirke årsakene til ubehag, er det ønskelig å utvikle et system som tar hensyn til observatørens posisjon og bevegelser relativt til visningsenheten. Ettersom systemet skal benytte et lerret, må projeksjonen korrigeres for å gi observatøren korrekt perpektivfølelse. I systemer for virtuell eller utvidet virkelighet eksisterer det til enhver tid et forhold mellom den reelle og virtuelle verden. Forholdet definerer virtuelle objekters plassering, orientering og størrelse i den reelle verden. Ved å la observatørens posisjon og bevegelser påvirke dette forholdet kan man oppnå økt forståelse av de virtuelle objektenes oppførsel. Konkrete forholdstyper som dekker behovene MIT stiller til et visualiseringssystem må defineres. Forholdene kan testes gjennom realisering av en prototype. 1.3 Organisering av oppgaven Kapittel 2 gir en kort introduksjon til eksisterende programvare for visualisering utviklet ved Rikshospitalet universitetsklinikk. Virtuell og utvidet virkelighet omtales. Ulike metoder for stereosyn beskrives. Problemer innen dagens systemer for medisinsk visualisering presenteres. Kapittel 3 er en studie av eksisterende systemer for distribuert rendrering. Fem ulike systemer presenteres og vurderes opp mot hverandre og opp mot krav til et fremtidig system for medisinsk visualisering. Kapittel 4 beskriver et system for observasjonspunktstilpasset projeksjon. Kapittelet består av fire deler. Første del inneholder metoder for beregning av forholdet mellom den reelle verden brukeren befinner seg i og den virtuelle verden man ønsker å

1.3 Organisering av oppgaven 3 studere, samt definerer hvordan brukerens bevegelser i den virkelige verden påvirker forholdet. Tre mulige forhold foreslås. Del to beskriver observasjonspunktkorrigert perspektivprojeksjon. Tredje del beskriver kort muligheter for sporing av bruker og visningsenhetens posisjon. I siste del redegjøres det for hvordan man kan benytte to virtuelle kameraer for å gi brukeren forbedret dybdesyn. Kapittel 5 er en gjennomgang av programvare og maskinvare som benyttes ved utviklingen av en systemprototype. I kapittel 6 stilles kravene til et prototypesystem, eksisterende kildekode analyseres og en overordnet implementasjonsbeskrivelse gis. Implementasjonen av prototypen diskuteres i siste del av kapittelet. Kapittel 7 er i sin helhet viet resultater og diskusjon. Faglige betraktninger av prototypens ytelse trekkes frem. Oppsett, gjennomføring og diskusjon av en brukertest står sentralt i kapittelet. I kapittel 8 oppsummeres oppgaven og konklusjoner trekkes. Til slutt foreslås fremtidig arbeid. Teksten benytter i hovedsak norske oversettelser på engelske faguttrykk, disse finnes i ordlisten i appendiks D. I enkelte tilfeller finnes ingen gode norske oversettelser. I disse tilfellene, og i tilfeller der engelske uttrykk er innarbeidet i det norske språket, benyttes de engelske ordene. Eksisterende kildekode for programvare og bibliotek som benyttes, er skrevet på engelsk. Dette konvensjonen videreføres i prototypen. Av denne grunn benyttes også engelske forkortelser for noen ord i teksten. Forkortelser som er benyttet i oppgaven, finnes i ordlisten i appendiks D. I tilfeller der funksjoner og andre programmeringselementer beskrives i teksten er disse uthevet med skrivemaskinskrift.

Kapittel 2 Bakgrunn 2.1 Intervensjonssenteret Intervensjonssenteret (IVS) ved Rikshospitalet Universitetsklinikk, er et forskningssenter for medisinsk teknologi. Senteret fungerer som en utviklingsavdeling for alle kliniske enheter ved sykehuset og har omkring 50 ansatte fra ulike disipliner. 70% av de ansatte tilhører kliniske disipliner kirurgi og radiografi, mens 30% tilhører tekniske disipliner som ingeniører, fysikere og matematikere. Hovedfokus i forskningen ligger på minimalt invasiv terapi. Forskningsområdene inkluderer robotkirurgi og bildeveiledet kirurgi. IVS samarbeider tett med industrien og har avtaler med blant annet Silicon Graphics [35] for sanntids bildebehandling, GE/Vingmed [19] for ultralyd og ComputerMotion [14] innen robotkirurgi. 2.2 IGVaC IGVaC (Image Guidance, Visualization and Control) er et programvaresystem for bildeveiledet kirurgi, utviklet ved Intervensjonssenteret. Systemet er fortsatt under utvikling, men kan i sin nåværende implementasjon visualisere MR-bilder romlig, som en del av et 3D-miljø. Med IGVaC gis medisinsk personell en tredimensjonal fremstilling av pasientens anatomi. Videre kan klinisk utstyr som prober og skop vises i kombinasjon med bildene. Ved å spore en probes posisjon og fremstille denne sammen med MRbilder eller 3D-modellen vil pasienten i praksis bli transparent og kirurgen vet nøyaktig hvor proben befinner seg i forhold til pasientens organer. Fysiske fenomener som ikke kommer frem på MR-bildene kan også visualiseres. Eksempelvis benyttes det i dag en probe for å fryse og ødelegge levertumorer. Fordi MR ikke kan fange opp bilder fra områder der temperaturen er lavere enn o grader celsius, kan man ikke se tilstanden til områder som fryses ned. Levertumoren må fryses til under o for å sikre at alle cellene er døde. Ut ifra eksperimenter og beregninger vet man hvordan temperaturen rundt fryseproben sprer seg over tid. Ved å vise temperaturen som en isoterm kan man se når hele tumoren er nedkjølt til ønsket temperatur og man unngår å ødelegge større deler av leveren enn nødvendig. Kirurgen gis på denne måten en form for utvidet virkelighet. IGVaC vil over tid utvikles til å utføre andre oppgaver.

6 Bakgrunn 2.3 Virtuell og utvidet virkelighet Med virtuell virkelighet (virtual reality, VR) menes syntetiske, datagenererte immersive 3D-miljøer [41]. Brukeren plasseres i et virtuelt miljø og kan samhandle med systemet gjennom eksplisitte kommandoer til datamaskinen eller ved at systemet sporer brukerens bevegelser. Treningssimulatorer for piloter og spill der brukeren benytter HMD, er kjente bruksområder for VR. Mens VR tilbyr brukeren et altomfattende kunstig miljø, kombinerer utvidet virkelighet (augmented reality, AR) kunstige og reelle objekter. AR gir mulighet for å visualisere ikke-eksisterende objekter i et reelt miljø eller forsterke og tydeliggjøre eksisterende objekter og fenomener. AR utvider den reelle scenen med mer informasjon [40]. 2.3.1 Virtuell og utvidet virkelighet i medisin Innen medisin ble VR initielt tatt i bruk for å visualisere komplekse medisinske data, spesielt for diagnostikk og planlegging av kirurgiske inngrep [45]. Medisinsk undervisning og telemedisin er også områder som drar nytte av VR. Med AR gis medisinsk personell muligheten til å kombinere visualiseringer av data med den virkelige verden. Virtuelle objekter gis en romlig posisjon og kan sees samtidig med reelle objekter, eksempelvis i en operasjonssituasjon. Videre kan man med bruk av AR-metoder tilsynelatende se gjennom organers overflate til indre strukturer. Bilder kan projiseres på pasienten, vises på HMD med mulighet for gjennomsyn, eller vises på gjennomsiktige skjermer, og på denne måten gi kirurger mulighet til å se organmodeller relativt til pasienten. 2.4 Problemer i eksisterende systemer Eksisterende HMD-utstyr er tungt og brukerens bevegelighet begrenses av at utstyret er koblet til rendreringsmaskinene med en kabel. En operasjon kan pågå i mange timer og HMD har ofte en vekt og utforming som gjør lang tids bruk slitsomt. Det er også et ønske å kunne flytte blikket fra pasienten til visualiseringen av organet uten store bevegelser, noe som for eksempel kreves når en skal ta på seg HMD. Som et alternativ til HMD, kan man benytte bilder vist på skjerm eller lerret. Ved å projisere visualiseringen på et lerret vil kirurgen kun behøve å bevege hodet for å se ønskede bilder. Tilsvarende løsning vil være mulig ved bruk av en normal PC-skjerm, men dersom denne plasseres et stykke unna kirurgen vil ikke en enkelt skjerm kunne vise et stort nok bilde til å gi kirurgen de nødvendige detaljer. Det vil også være umulig å koble sammen flere skjermer sømløst. Bruker man derimot prosjektører og lerret vil man relativt enkelt kunne utvide synsfeltet ved å benytte flere prosjektører og/eller øke projeksjonsstørrelsen. Ved bruk av lerretsprojeksjon for stereobilder, må brukeren være posisjonert rett foran lerretet. Hvis dette ikke er tilfelle vil brukeren få feilaktig inntrykk av objekters romlige posisjon. Objektene vil også oppfattes som forvrengte. Ved bevegelser rundt i rommet

2.5 Stereosyn 7 beveger objektene seg, de innehar ingen fast posisjon. Dette er i beste fall forvirrende, i mange tilfeller kan det oppfattes som ubehagelig og resultere i svimmelhet og kvalme hos brukeren [44, 16]. Systemets ytelse avhenger av tilgjengelig maskinvare. Spesialmaskinvare for visualisering er svært dyrt og priser i hundretusenkronersklassen er ikke uvanlig. Slikt utstyr utdateres like fort som tilfellet er for annet datautstyr, og kan resultere i en uforholdsmessig stor kostnad for visualiseringssystemet. 2.5 Stereosyn Ved å rendrere to ulike bilder, ett for hvert øye, kan man gi virtuelle objekter en tilsynelatende plass i rommet. De to bildene genereres ved hjelp av to kameraer som plasseres tilsvarende langt fra hverandre som avstanden mellom brukerens øyne. Stereosyn kan oppnås på mange ulike måter. Av enklere metoder kan nevnes: Lokasjonsseparerte displayer, eksempelvis bruk av to skjermer i et HMD. Tidsseparerte displayer, for eksempel briller der glassene kan lukke for utsyn i gitte tidsrom (shutter glasses) og gjennom synkronisering av lukking og bildevisning på skjermen som gir brukeren forskjellige bilder for hvert øye. Stereoseparering ved hjelp av fargefiltre (rød-grønne briller) med polariserte brilleglass der polariseringen filtrerer ut riktig bilde for hvert øye. Dette er også de vanligste teknikkene for å gi stereosyn. Flere metoder beskrives i [1]. Som nevnt er ikke alltid HMD-ene spesielt egnet for lengre tids arbeid. Shutter glasses har den ulempen at de må synkroniseres med visningen og derfor trenger innebygget elektronikk samt kommunikasjon med utstyret som genererer bildene. Ved fargefiltrering kreves kun et sett med lette briller for å separere bildene. Denne teknikken har likevel den ulempen at nettopp farger ikke kan brukes eller ikke trer spesielt godt frem. Bruk av polariserte glass tillater derimot full bruk av farger mens man bevarer fordelen med lette briller. Polarisering krever spesielt utstyr for visning. En vanlig PC skjerm vil ikke kunne generere det polariserte lyset som er nødvendig for å separere bildene. Ved bruk av lerretsprojeksjon trengs to prosjektører med ulike polariseringsfiltre, en for hvert øye. I tillegg kreves et spesielt lerret som reflekterer lyset uten å endre polariseringen. Slikt utstyr er i dag relativt dyrt, men løsningen er også den mest fleksible og anvendelige sett fra et brukerperspektiv. For å gi brukeren rett oppfatning av objekters plassering i rommet, må kameraseparasjonen være tilpasset brukerens øyne. Dersom nøyaktig posisjonering ikke er nødvendig, kan avstanden mellom de virtuelle øyepunktene justeres for å forandre dybdevirkningen. Studier som beskrives i [50], viser at øyeseparasjonen kan justeres dynamisk uten at brukeren merker dette dersom endringen skjer over tid.

8 Bakgrunn I denne oppgaven benyttes stereoseparasjon på en måte som gjør nøyaktig stereoseparasjon viktig. Overdreven separasjon vil gi en større dybdevirkning enn ønsket. Videre studier av stereojustering er utelatt fordi hovedfokus i oppgaven ligger på metoder for observasjonspunkttilpasset projeksjon. 2.6 Bildegenerering og -visning i 3D-grafikk I de fleste systemer for 3D-grafikk genereres bilder som om brukeren står i kamerapunktet og ser langs kameraets synsretning. For å gi et korrekt bilde benyttes et såkalt symmetrisk viewing frustum der vinkelen mellom synsretning og ytterkantene på viewing volume-et er like på begge sider av synsretningsaksen (figur 2.1). For at slike bilder skal se riktig ut må brukerens synsretning være normalt på visningsenheten. Dersom brukeren sitter rett foran en skjerm eller har på seg HMD, er dette kravet oppfylt. Har man derimot tilfeller der brukeren av ulike årsaker ikke befinner seg rett foran skjermen, vil vedkommende se et forvrengt bilde. Et objekt som sett rett forfra ser 10 cm ut vil synes smalere dersom observatøren beveger seg mot høyre eller venstre. I tillegg vil linjer som synes parallelle sett rett forfra, oppfattes som om de skrår mot hverandre når de sees fra siden. For å gi brukeren et bilde som svarer til hva brukeren forventer å se, kreves derfor en korrigering av bildet på skjermen. Denne korrigeringen er avhengig av brukerens posisjon i forhold til skjerm/lerret og av lerretets posisjon i forhold til den virtuelle modellen. Synsretning Synsretning a b a b Figur 2.1: Symmetrisk og asymmetrisk viewing volume. Viewing volume-er definerer hvilke objekter i den virtuelle scenen som er synlige og hvordan disse rendreres. For symmetriske viewing volume-er (venstre) er vinkel a og b like store. For asymmetriske viewing volume-er er vinkel a og b ulike.

Kapittel 3 Forarbeid Dette kapittelet er en studie av eksisterende systemer for distribuert rendrering. Først defineres begreper brukt i studiet, deretter presenteres fem utvalgte systemer. Til slutt kommer en sammenlikning og kritikk av systemene sett i lys av krav til et fremtidig system for medisinsk visualisering. 3.1 Om distribuert rendrering Det finnes flere ulike måter å distribuere rendreringsprosessen på. Systemer for distribuert rendrering kan bestå av en eller flere maskiner som tar seg av beregningen av bildedata, en eller flere maskiner for visning av bildedata og en eller flere maskiner for applikasjonskjøring. Videre kan systemene benytte seg av ulike språk for beskrivelse av 3D-miljøene og de kan benytte ulike metoder for produksjon av bildedata. Deling av rendreringsoppgaver kan skje enten i objektrommet (object space) eller i bilderommet (image space). Oppgavedelingen kan enten være statisk eller kan endres dynamisk underveis. De to neste seksjonene forklarer de viktigste begrepene brukt i gjennomgangen av eksisterende systemer for distribuert rendrering. 3.1.1 Tre tjenertyper Rendreringssystemene kan grovt sett deles inn i tre ulike deler ut ifra hvilke oppgaver de utfører: Rendreringstjener: Maskin/programvare som konverterer objektdata til pikseldata. Applikasjonstjener: Maskin/programvare som mottar inndata fra bruker og/eller foretar nødvendige beregninger på objektdata før disse behandles av rendreringstjeneren(e). Displaytjener: Maskin/programvare som mottar og viser pikseldata. Det er ingen absolutte grenser mellom disse typer tjenere. En maskin kan opptre som rendrerings-, applikasjons- eller displaytjener, eller en vilkårlig kombinasjon av disse,

10 Forarbeid samtidig. I sammenlikningen i dette kapittelet kreves det imidlertid at minst to maskiner samarbeider om produksjonen av resulterende bildedata. 3.1.2 Oppgavedeling I systemer for sanntidsrendrering vil hastigheten til maskinen som utfører rendreringen være en flaskehals for systemets ytelse. Ved å dele jobben mellom flere maskiner kan man øke systemets totale ytelse. Tre ulike metoder for deling av rendreringen forekommer i systemene som er studert: Bilderom: Oppgavedelingen baseres på lokasjon i den resulterende todimensjonale bildematrisen. En maskin blir tildelt et sett med bildepunkter og er alene ansvarlig for rendreringen av disse. Objektrom: Oppgavedelingen gjøres på objekt/triangelnivå, hver maskin får ansvaret for et sett objekter. Dette kan resultere i flere sett med pikseldata for hver piksel i den endelige bildematrisen hvor den korrekte pikselverdien bestemmes på bakgrunn av de individuelle pikselverdienes dybdebuffer og transparens. Image Layer Decomposition: Image Layer Decomposition (ILD) er en metode for lastdeling som i hovedtrekk baserer seg på å sortere objekter på bakgrunn av avstanden fra det virtuelle kamera. Ved å dele rendreringen slik at ingen to maskiner rendrerer grupper av objekter som gjensidig overlapper hverandre, unngår ILD behovet for filtrering av resulterende bilder på bakgrunn av dybdebuffer [27]. Fordelingen av oppgavene kan gjøres statisk eller dynamisk. Ved statisk deling vil den enkelte maskin få tildelt en del av bildet eller et sett med objekter ved oppstart. Maskinene vil alltid rendrere de tildelte delene uavhengig av tiden rendreringen tar. Dette kan resultere i at enkelte maskiner står ubrukte store deler av tiden mens andre maskiner alltid er opptatt. Ytelsen til maskinene som alltid er opptatt vil dermed være den begrensende faktoren i systemet. Ved dynamisk lastdeling forsøker man å fordele rendreringsoppgavene underveis slik at ingen maskiner blir stående uten oppgaver. På denne måten utnyttes systemressursene bedre. 3.1.3 Rendreringsmetoder Med rendreringsmetoder menes metoder for å konvertere tredimensjonale scenebeskrivelser til todimensjonale bilder. To ulike varianter benyttes av systemene som er studert: Ray tracing: Ray tracing er fellesbetegnelsen på algoritmer som beregner bilder ut ifra å sende en stråle ut i det virtuelle rommet for hver piksel i det ønskede bildet. Avhengig av objekters form, farge, tekstur, lyssetting og andre parametre fanger strålen opp en fargeverdi som lagres i det gitte bildepunktet. Ray tracing kan gi svært realistiske bilder men, er også meget prosessorintensivt.

3.2 Eksisterende systemer for distribuert rendrering 11 Scan-conversion-metoder: OpenGL-baserte systemer benytter i hovedsak såkalte scan-conversion-metoder for å rendrere bilder. Ulike algoritmer eksisterer for rendrering av ulike objekttyper. Noen slike algoritmer beskrives i [5]. Scan-conversion er generelt raskere enn ray tracing og benyttes ofte i systemer for sanntidsrendrering. 3.2 Eksisterende systemer for distribuert rendrering I denne delen beskrives fem ulike systemer som utfører distribuert rendrering. Først kommer en kort gjennomgang av de individuelle systemene med kommentarer til fordeler og ulemper. Deretter vises en tabell som sammenlikner systemene. Til slutt gis en vurdering av systemene sett opp mot krav som stilles til et fremtidig system for medisinsk visualisering. Som hovedbetingelser kreves det at systemene kjøres på en klynge (cluster) av standard PC-er (commodity machines), at rendreringsprosessen deles på flere maskiner og at rendreringen skjer i sanntid. Sammenlikningene og beskrivelsene baserer seg på publiserte tekster fra produsentene av systemene, i hovedsak [22] (WireGL), [23] (Chromium), [26] (DDDDRaW), [49] (OpenRT) og [20] (DIV). 3.2.1 WireGL Faktaopplysningene i denne seksjonen er, hvis ikke annet spesifiseres, hentet fra artikkelen Distributed Rendering for Scalable Displays [22]. Fordeler og ulemper kommenteres på grunnlag av teksten og er en generell vurdering av systemet. WireGL er utviklet ved Computer Science Department, Stanford University. WireGL er et system for 3D-grafikk på store videovegger (tiled displays) og tilbyr deling av bilde over flere skjermer/prosjektører. Hver skjerm er koblet til en dedikert rendreringstjener/videoutgang. Det kreves derfor like mange rendreringstjenere 1 som det er skjermer i videoveggen samt en applikasjonstjener som koordinerer alle maskinene. Systemet baserer seg på OpenGL 2 og støtter eksisterende OpenGL-baserte applikasjoner direkte uten at endringer av disse er nødvendig. Ved å maskere seg som opengl.dll i MS Windows og libgl.so i Linux kan systemet utføre distribusjonen uten at applikasjonen har kjennskap til dette. Rendreringstjenerene gjør bruk av underliggende maskinvare med OpenGL-støtte og oppnår således høy ytelse sammenliknet med rene programvarebaserte alternativer. I WireGL er det OpenGL-kall som distribueres. Distribusjon av data skjer kontinuerlig. Systemet trenger ingen forhåndsinformasjon om scenen som skal rendreres men såkalte GLhints kan benyttes for å bedre ytelsen. Bildene på en skjerm kan kun genereres av en enkelt maskin og visning av bildene skjer derfor bare på utenheter tilkoblet den aktuelle rendreringstjeneren. Det foretas dermed heller ingen form for dynamisk lastdeling, hver rendrerer tar seg av sin tildelte bit av det totale bildet. 1 Programvare, flere rendreringstjenere kan kjøre på samme maskin og utnytte flere grafikkadaptere. 2 Se seksjon 5.1.1 for mer om OpenGL.

12 Forarbeid Systemet skalerer tilsynelatende bra, det hevdes at videoveggens ytelse er tilnærmet uavhengig av den totale oppløsningen. Nettverkstrafikken minimeres ved å kode Open- GL-kallene effektivt og kun distribuere data til de som trenger disse, når de trenger det. Fordeler Applikasjonen trenger ingen kjennskap til WireGL. Eksisterende applikasjoner kan derfor vises/distribueres uten endring i applikasjonens kildekode. WireGL bygger på og støtter OpenGL API versjon 1. En rekke eksisterende og fremtidige applikasjoner støttes derfore direkte samtidig som programmerere tilbys et kjent API. Systemet er bygget for videovegger og det er derfor rimelig å anta at rammesynkronisering mellom rendreringstjenerene støttes. Dette er ikke verifisert. Støtte for nettverkstypen Myrinet [9] gir muligheter for høye datarater. Ulemper WireGL tilbyr ingen tilbakelesning (readback) av bildedata, det er derfor ikke mulig å vise resultatet av rendreringen på en enkelt skjerm. Det er heller ikke mulig å dele renderingen av en celle i videoveggen mellom flere maskiner. Fordi rendrering av en celle kun gjøres av maskinen koblet til cellens skjerm tilbys ingen dynamisk lastdeling. Store maskinressurser kan stå ubenyttet og den faktiske ytelsen til systemet ligge under hva som er teoretisk mulig. WireGL distribuerer bare OpenGL-delen av applikasjoner. Dette er et problem for applikasjoner der pekermarkøren ikke er kodet i OpenGL, men isteden vises av vindussystemet, da markøren ikke vil vises på videoveggen. Problemet er delvis løst i videreutviklingen av WireGL, Chromium, som beskrives i neste seksjon. 3.2.2 Chromium Faktaopplysningene i denne seksjonen er, hvis ikke annet er spesifisert, hentet fra Chromium: A Stream-processing Framework for Interactive Rendering on Clusters [23]. Chromium er en videreutvikling av WireGL og drives som et prosjekt via Source- Forge [12]. Både WireGL og Chromium er tatt med i dette studiet av eksisterende systemer for distribuert rendrering fordi funksjonaliteten varierer mellom systemene. Ved å beskrive systemene i separate seksjoner kommer forskjellen klarere frem. Utover funksjonaliteten som finnes i WireGL, tilbyr Chromium parallelle applikasjoner muligheten til å rendrere til det samme konseptuelle displayet. Dette tillater i bedre skalering på applikasjonssiden enn tilfellet er for WireGL.

3.2 Eksisterende systemer for distribuert rendrering 13 Chromium er bygget opp av Stream Processing Units (SPU) som behandler strømmen av OpenGL-kall. Hver SPU utfører en bestemt tjeneste som rendrering, tilbakelesning av pikseldata og visning av bilder. Ved å koble sammen flere SPU-er kan man bygge opp nøyaktig den tjenesten man ønsker. Sammenkoblingen skjer dynamisk gjennom et oppstartsskript. Alle SPU-er må implementere, men er ikke begrenset til, OpenGL API-et. Dette gjør det enkelt å implementere nye SPU-er ved behov. Gjennom bruken av såkalte readback SPU-er kan et bilde som vises på en enkelt skjerm genereres av flere maskiner. Distribusjonen kan skje på to måter: Bilderomsbasert distribusjon, der hver enkelt skjerms bildeflate deles i flere deler og tilsvarende mange maskiner rendrerer hver sin del. Objektromsbasert distribusjon, der selve applikasjonen distribueres og man lar enkeltmaskiner rendrere et fast sett med polygoner. I begge tilfeller kreves et raskt nettverk fordi store mengder bildedata skal overføres. Datamengden er likevel desidert størst for objektromsbasert distribusjon. For det første må dybdeinformasjon for hver enkelt piksel i bildet sendes med for å bestemme hvilke piksler som representerer objekter nærmest skjermen, for det andre må hver rendrerer sende hele bildeflaten for hvert bilde ettersom distribusjonen av rendreringsoppgaver er uavhengig av objektenes plassering i bilderommet. Ved objektromsbasert distribusjon kreves i tillegg behandling av bildedata på visningsmaskinen fordi flere enkeltbilder må filtreres og settes sammen til et bilde. Fordeler Parallell OpenGL- API, muliggjør distribusjon av polygongenerering og dermed mulighet for distribusjon av applikasjonsdelen av systemet. Chromium kan, via tilbakelesning, fordele rendreringen av en enkelt skjerms bilde mellom flere maskiner. Ny funksjonalitet kan legges til med egenproduserte SPU-er. Dette gjøres uten å endre Chromiums eksisterende kildekode. Som en løsning på problemet som oppstår når markøren ikke er kodet i OpenGL kan Chromium utføre rendrering av bilde lokalt på applikasjonsmaskinen i tillegg til å vise bildet på en videoveggen. Dette krever likevel større ressursbruk da applikasjonstjeneren også må fungere som rendreringstjener. Ulemper Scenebeskrivelser i Chromium gjøres i OpenGL, noe som krever at overliggende applikasjoner selv genererer all nødvendig geometri. Dette er ingen stor mangel da OpenGL støtter mange eksisterende og fremtidige applikasjoner direkte.

14 Forarbeid 3.2.3 Distributed 3D RealTime Rendering at Washington Faktaopplysningene i denne seksjonen er, hvis ikke annet opplyses, hentet fra DDDD- RRaW: A Prototype Toolkit for Distributed Real-Time Rendering on Commodity Clusters [26]. Distributed 3D RealTime Rendering at Washington (DDDDRRaW) er en prototype for distribuert sanntidsrendrering utviklet ved University of Washington, Seattle. Systemet er implementert som et bibliotek for VRML-rendrering. Systemet er beregnet å kjøre på en kombinert applikasjons-/displaytjener og bruker distribusjon for å øke rammeraten. En klynge av maskiner rendrerer deler av bildet og sender resultatet til applikasjonstjeneren, der bildet settes sammen. Applikasjonen som ligger på toppen av DDDDRRaW har ingen kjennskap til distribusjonen av rendreringsoppgavene. Lastdelingen i DDDDRRaW bestemmes ved en egen algoritme, Image Layer Decomposition (ILD) beskrevet i [27]. Denne algoritmen forsøker å gjennomføre dynamisk lastdeling slik at tilgjengelige ressurser blir best mulig utnyttet. I den nåværende implementasjonen krever ILD forhåndsprosessering av scenedata. Av den grunn støtter ikke DDDDRRaW objektbevegelser, kun kamerabevegelse. Heller ikke dynamiske endringer av scenen støttes. All scenedata distribueres til alle rendreringstjenere før rendreringen starter første gang. Fordeler DDDDRRaW utfører dynamisk lastdeling og utnytter således de tilgjengelige ressursene godt. Ulemper DDDDRRaW mangler støtte for dynamiske scener og objektbevegelse. DDDDRRaW tilbyr muligheter for overlappende kommunikasjon og rendrering i et forsøk på å øke rammeraten. Dette øker samtidig forsinkelsen ved bevegelse og dermed også den oppfattede responstiden fra programmet. Dersom applikasjonen tilbyr interaktiv kontroll av bevegelse, kan for høy responstid gjøre det vanskeligere for brukeren å navigere i den virtuelle verden. 3.2.4 OpenRT Faktaopplysningene om OpenRT i denne seksjonen er, hvis ikke annet spesifiseres, hentet fra A Flexible and Scalable Rendering Engine for Interactive 3D Graphics [49]. OpenRT er et system for interaktiv ray tracing utviklet av Computer Graphics Group ved Saarland University, Tyskland. OpenRT er et API som ligner på OpenGL, men API-ene er ikke identiske.

3.2 Eksisterende systemer for distribuert rendrering 15 Ray tracing-prosessen er i utgangspunktet svært lett å distribuere. Alle bildepunkter beregnes uavhengig av hverandre og kan derfor distribueres over et stort antall maskiner for å oppnå høy ytelse. Ray tracing er samtidig en svært prosessorintensiv oppgave. For OpenGL-baserte løsninger er det vanlig med maskinvareakselerasjon av rendreringsprosessen. Da denne rapporten ble påbegynt eksisterte ikke slikt utstyr for interaktiv raytracing. Senere har utviklerene av OpenRT lansert en egen arkitektur for maskinvareakselerert sanntids ray tracing, SaarCOR [32]. Realismen som tilbys gjennom ray tracing overgår det som kan oppnås med OpenGLbaserte rendrerere. Ray tracing skalerer også angivelig svært godt. Wald et al. [49] rapporterer logaritmisk kompleksitet med hensyn til antall triangler i scenen. For standard rasteriseringsalgoritmer hevdes det at kompleksiteten er lineær. Det påstås videre at hastigheten for ray tracing vil overgå hastigheten for triangelrasterisering i komplekse scener. Distribusjonen i OpenRT er transparent for overliggende applikasjoner, disse kommuniserer med systemet omtrent som de ville gjort med et underliggende system basert på OpenGL. Lastdeling i OpenRT skjer dynamisk, hver rendreringstjener forespør en sentral koordineringstjeneste om oppgaver og får disse basert på tidligere rendrerte stråler. På denne måten oppnås både utnyttelse av cache og god bruk av tilgjengelige ressurser. Rendrerte piksler sendes tilbake til applikasjons-/displaytjeneren og settes sammen til ett bilde. Som for alle systemer der tilbakelesning av pikseldata er mulig krever dette stor båndbredde og nettverket er derfor en av de begrensende faktorene. OpenRT støtter både dynamiske scener og objektbevegelse, men får angivelig problemer med ytelsen dersom endringene er store og/eller antall rendreringstjenere er stort. Dette begrunnes med bruken av en sentral scenedatabase og broadcast for å oppdatere scenedata hos rendreringstjenerene. Fordeler Akselerasjonsstrukturene og algoritmene som brukes for å finne skjæringspunkter mellom objekter og stråler gjør at ray tracing skalerer svært godt med hensyn til scenekompleksitet. Bildene som produseres ved ray tracing er av overlegen kvalitet i forhold til OpenGL-baserte rendrerere dersom fotorealisme ønskes. Skygger, refleksjon, diffraksjon og andre optiske fenomener kan fremstilles korrekt og uten bruk av for eksempel refleksjonskart (reflection maps). OpenRT tilbyr metoder for å kombinere ulike rendreringstyper. Eksempelvis kan volumdata rendreres uten endringer i systemet. Dette implementeres som en surface shader. Lastdeling benyttes, systemressursene utnyttes derfor bra. Ulemper Preprosessering kreves for å oppnå interaktive hastigheter. Statiske strukturer bygges opp før start. Programmet er derfor ikke uavhengig av scenen som skal

16 Forarbeid vises. Foreløpig eksisterer maskinvare for akselerasjon av rendreringsprosessen kun i et svært lite omfang. Mye objektbevegelse skaper skaleringsproblemer da alle endringer må broadcastes. Dette er likevel ikke unikt for OpenRT, men forekommer også for de andre systemene. Hvorvidt problemet er større for OpenRT er ukjent. OpenRT er et nytt og ukjent API. Selv om det er tett knyttet opp mot OpenGL må eksisterende applikasjoner skrives om. 3.2.5 Distributed Open Inventor Faktaopplysningene om DIV er hentet fra A Practical Approach to Distributed 3D graphics [20] dersom ikke annet er spesifisert. Distributed Open Inventor (DIV) er en utvidelse av Open Inventor (OI) og er utviklet ved Institute of Computer Graphics and Algorithms, Vienna University of Technology (Technische Universität Wien)[42]. DIV tilbyr konseptuell deling av scenegraf, flere brukere på flere maskiner får tilgang til samme scene. Scenegrafen kan oppdateres mens programmet kjører, nye subtrær kan legges til eller fjernes og transformasjoner endres. I tillegg kan hver enkelt brukers applikasjon være individuelt tilpasset slik at den kan inneholde individuelle variasjoner i scenegrafen. Bruken av DIV er nær transparent. Kun få linjer med kode må legges til for å dele ut/hente inn en scenegraf. Scenegrafen distribueres initielt til alle maskiner, senere sendes kun informasjon om endringer i grafen. I tillegg tilbyr DIV et eget system med dedikerte sporingstjenere (tracking servers) som tar imot og behandler sporingsdata. For minimal responstid kan sporingstjenerene kommunisere direkte med de enkelte klienter, posisjoneringsdata trenger ikke gå veien om en sentral applikasjonstjener. Distribusjonen i DIV skjer på objektnivå, scenegraf og tilhørende grafikkommandoer distribueres. Systemet støtter ikke deling av rendreringsjobber mellom flere maskiner. Isteden regnes hver enkelt maskin som en uavhengig rendreringstjener. Dette fører til at hver rendrerer jobber i sitt eget tempo uten synkronisering mellom rendreringstjenerene. DIV er likevel tatt med i dette studiet fordi DIV kan benyttes for deling av stereorendrering mellom to maskiner, samt fordi dagens system, IGVaC, benytter DIV. Fordeler OI er et avansert rammeverk for objektorientert 3D-grafikkprogrammering. Ved å utvide OI nyttiggjør DIV seg den teknologien som ligger i OI. Samtidig tilbys programmerere et velkjent API for utvikling av applikasjoner, terskelen for å lage distribuerte programmer blir dermed lav. Det er mulig å endre scenegrafen under kjøring (runtime).