Virtueller Operationssaal

Eine Virtual-Reality-Umgebung zur Planung und Visualisierung von r umlichen Kongurationen, zeitlichen Abl ufen, sowie a a Daten ssen im Operationssaal u

Studienarbeit
vorgelegt von

Daniel Selbach

Institut f r Computervisualistik u Arbeitsgruppe Computergrak

Forschungsbereich Life Science Informatik

Betreuer: Dipl. Math. Ron Schwarz, Fraunhofer-Institut FIT.LIFE Pr fer: Prof. Dr. Stefan M ller, Universit t Koblenz-Landau u u a

September 2003

Inhaltsverzeichnis
1 2 Einleitung und Motivation Anwendungen von Virtual Reality 2.1 VR-Anwendungen in der Medizin . . . . . . . . . . . . . . . . . 2.2 Virtuelle Geb udeplanung . . . . . . . . . . . . . . . . . . . . . a Anforderungen an den Virtuellen Operationssaal 3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6 6 8 9 9 12

Erstellung von Virtual Reality 13 4.1 3D-CAD-Software . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Java3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Entscheidung f r eine Entwicklungsumgebung . . . . . . . . . . 17 u Virtual Reality Benutzerschnittstellen 5.1 Visualisierung . . . . . . . . . . . 5.2 Interaktion . . . . . . . . . . . . . 5.2.1 Navigation . . . . . . . . 5.2.2 Manipulation . . . . . . . 20 20 21 22 22 25 27 29 30 34 35 38 40 44

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Der virtuelle Operationssaal 6.1 Visualisierung . . . . . . . . . . . . . . . . . . . . . . 6.2 Interaktion . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Aufbau von Raumkongurationen . . . . . . . 6.2.2 Navigation im Raum . . . . . . . . . . . . . . 6.2.3 Manipulation von Objekten . . . . . . . . . . 6.2.4 Speichern und Laden von Raumkongurationen 6.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . Fazit

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Einleitung und Motivation

Virtual Reality (VR) ist eine Visualisierungs- und Simulationstechnologie, die es Benutzern erm glicht im dreidimensionalen Raum einer virtuellen Welt mit Obo jekten zu interagieren und zu arbeiten. Ein solcher 3D-Interaktionsraum erlaubt die Konstruktion von umfangreichen Anwendungen, die mit herk mmlichen o Computersystemen bisher nicht umsetzbar waren. Die bislang verf gbaren, auf u 2D-Techniken beruhenden Visualisierungsmethoden reichen nicht mehr f r die u zunehmenden Anspr che der heute durchgef hrten Simulationen aus. Mit der u u Komplexit t steigen auch die Anforderungen an die Methoden, mit denen die a Ergebnisse solcher Simulationen dargestellt werden. VR bietet wesentliche Erleichterungen, vor allem f r die Planung kompliu zierter dynamischer Vorg nge, deren wissenschaftlich-technische Analyse die a mehrdimensionale Darstellung der Prozesse in Raum und Zeit erfordert. In der Automobilindustrie werden beispielsweise VR-Techniken zur Optimierung der vielschichtigen Produkt-Entstehungsprozesse eingesetzt. Ein weiteres Beispiel f r solch anspruchsvolle Vorg nge stellen chirurgische Operationen am Menu a schen dar, die mit Fortschritt der Forschung auch die Notwendigkeit von immer komplexeren Arbeitsr umen mit sich bringen. a Speziell minimalinvasive Operationstechniken und die intraoperative Nutzung neuer bildgebender Verfahren wie Computertomographie (CT) und Kernspinresonanztomographie (MRT), die mehr und mehr Einzug in die Kliniken nden, erh hen die Komplexit t des gesamten Ablaufs einer Operation. Zur Nutzung o a solcher Techniken w hrend einer Operation sind z.B. spezielle, den Chirurg a unterst tzende Ger te notwendig, dir vor allem auf Grund ihres Platzbedarfs u a in die Planung vieler verschiedener Prozesse einbezogen werden m ssen. Von u der Vorbereitung eines speziellen Operationsablaufes bis hin zur Planung neuer Operationss le sind alle Ebenen betroffen. Schlielich benden sich in einem a Operationssaal (OP) viele weitere Ger te und Instrumente, die dynamisch zu a verschiedenen Zeitpunkten an anderen Positionen ben tigt werden. Eine Vielzahl o von unterschiedlichen Kongurationen der Objekte im Raum kann f r einen einu zigen Eingriff n tig sein, um optimale Arbeitsbedingungen f r die Operateure und o u das OP-Personal zu schaffen. Um etwaigen Platzproblemen im oft engen Operationssaal vorzubeugen, ist daher eine sorgf ltige Planung notwendig. Abbildung a 1 zeigt, wie eng es in einem OP w hrend eines neurochirurgischen Eingriffs bei a gemeinsamer Verwendung von computergest tzer Navigation, Ultraschallger t u a und Mikroskop ist. Die Tatsache, dass einige Ger te untereinander uber Leitungen Daten (z.B. media zinische Bilddaten) austauschen m ssen oder sie sich durch andere Abh ngigkeiu a ten (z.B. Magnetfelder) beeinussen, erweitert die Grundproblematik. 3

Abbildung 1: OP w hrend eines neurochirurgischen Eingriffs unter Einsatz von a computergest tzter Navigation, Ultraschallger t und Mikroskop u a

Diese komplexen und dynamischen Aspekte einer Konguration des Raumes sollten daher bereits bei der Planung von Operationss len und von neuen a Operationsverfahren Ber cksichtigung nden. Dazu kann eine Virtual-Realityu Umgebung dienen, mit der r umliche Kongurationen, zeitliche Abl ufe sowie a a Daten sse im Operationssaal geplant und visualisiert werden k nnen. Solch ein u o virtueller OP gestattet es, die R umlichkeit einer geplanten Operation vor der a Durchf hrung zu testen und verschiedene Varianten von r umlichen Anordnungen u a und Operationsszenarien gefahrlos und mit geringem Aufwand auszuprobieren.

Motiviert durch die oben genannte Problematik geht diese Studienarbeit anfangs auf spezielle Anwendungen von VR sowie die Anforderungen an einen virtuellen Operationssaal ein. Anschlieend wird die Eignung von verschiedenen Entwick lungsm glichkeiten eines solchen Projektes diskutiert. Grundlagen uber die Vio sualisierung von und Interaktion mit virtuellen Welten folgen, um im darauf folgenden Kapitel auf die Dokumentation der Implementation einzugehen, die auf den vorher eingef hrten Grundlagen basiert. Eine ausf hrliche Beschreibung der u u im Rahmen dieser Arbeit erstellten VR-Software iet in diesen Abschnitt mit ein. Ein Fazit mit Ausblick schliet die Studienarbeit ab, die am Fraunhofer-Institut f r u Angewandte Informationstechnik (FIT) im Forschungsbereich Life Science Informatik in Sankt Augustin durchgef hrt wurde. Die vorliegende Arbeit und die entu wickelte Virtual-Reality-Umgebung dienen als Grundlage f r die Weiterentwicku lung eines umfassenden Systems, das vorerst institutsintern bei unterschiedlichen Projekten Anwendung nden soll.

Anwendungen von Virtual Reality

Noch vor einigen Jahren setzten komplizierte und kostspielige Flug- oder Fahrsimulatoren die Allgemeinheit auf Grund ihrer realistischen Darstellung in Erstaunen. Heute jedoch ist nicht nur die Jugend an den Anblick aufw ndigster dreidia mensionaler Computerspiele gew hnt, die die Leistung der damaligen Systeme o ubertreffen. Mittlerweile hat sich VR weit verbreitet und ndet in verschiedensten Gebieten von Milit r- und Raumfahrttechnik bis hin zur Unterhaltungstecha nologie Anwendung. Auch in Bereichen der Medizin und Architektur haben sich VR-Anwendungen verbreitet.

2.1

VR-Anwendungen in der Medizin

Kaum einem Einsatzbereich von Virtual Reality wird soviel Aufmerksamkeit geschenkt wie dem der Medizin. In den neunziger Jahren wurden die bildgebenden Verfahren Computer- und Kernspintomographie in der Medizin eingef hrt. u Heutzutage kann die computermedizinische Technik patientenspezische Bilder von so hoher Qualit t erzeugen, dass diese in drei Dimensionen rekonstruiert a werden k nnen. Die erfassten 3D-Daten k nnen beispielsweise zur Erzeugung o o von Volumenbildern genutzt werden, mit Bildverarbeitungsmethoden wie z.B. Segmentierung weiterverarbeitet werden, um gewisse Organe oder Gewebearten lokalisieren zu k nnen, oder in 3D-Simulationen umgesetzt werden. Resultiereno de Darstellungen k nnen sowohl pr - und intraoperativ Anwendung nden, als o a auch in der Aus- und Weiterbildung von Medizinern verwendet werden. Unter Verwendung der Bilddaten ist es m glich, Operationen patientenspezio sch zu planen oder im Voraus in VR-Simulationen virtuell durchzuf hren. u Dadurch k nnen eventuell bestehende Risiken fr h erkannt und minimiert wero u den. Mit der intraoperativen Nutzung von Systemen, die auf den Patienten-Daten aufsetzen, kann der Chirurg w hrend der Operation Unterst tzung bekommen. a u Der Operateur wird dazu mit Informationen versorgt, die in der realen Welt teilweise nicht direkt zu erschlieen sind. Zum Beispiel kann eine Visualisierung von MRT-Daten zur Aufndung von Tumorgewebe genutzt werden, das f r das u menschliche Auge nicht sichtbar ist, weil es durch anderes Gewebe oder Blut verdeckt ist. W hrend einer Operation sind solche Zusatzinformationen sehr hilfa reich und insbesondere minimal-invasive Operationstechniken protieren davon, da bei solchen Eingriffen kein direkter Sichtkontakt zum Operationsfeld besteht.

Bislang dienen bei der Ausbildung von Medizinern in Formalin konservierte Leichen dazu, erste F higkeiten in der Lokalisierung von Organen, Sehnen, a Nerven und Knochen zu entwickeln. Problematisch ist jedoch, dass Leichen nur in begrenztem Mae zur Verf gung stehen und eine Operation am lebenden u Menschen nicht vollst ndig simulieren k nnen, da viele Begebenheiten wie z.B. a o Stoffwechsel, Blutdruck und die Funktion von Organen nicht mehr vorhanden sind. Daher m ssen Mediziner ihre Erfahrungen bisher w hrend des Studiums u a durch Beobachtung von Operationen am realen Patienten sammeln. Solche Operationen sind auf eine kleine Teilnehmerzahl begrenzt, um den Eingriff nicht zu st ren. Als Abhilfe dienen noch Video bertragungen in einen H rsaal. Virtual o u o Reality wird eingesetzt, um erweiterte und individuellere M glichkeiten bieten o zu k nnen, Fachkenntnisse zu erlangen. Die Forschung befasst sich mit solchen o Systemen. Ferner sind bereits Trainingsumgebungen entwickelt worden, die f r u Patienten kein Risiko bergen: Das Fachk nnen wird am virtuellen Patienten o erlernt. Medizinstudenten k nnen ein VR-Training auch zur Ausbildung von o Grundlagenwissen wie der Anatomie nutzen. Beispielhaft sind Applikationen aus The Visible Human Project der amerikanischen National Library of Medicine. In den letzten Jahren ist die Forschung in der Humanmedizin so weit fortgeschritten, dass selbst erfahrene Chirurgen mit v llig neuen Anforderungen und o Techniken konfrontiert werden, etwa in der minimalinvasiven Chirurgie und der robotergest tzten Neurochirurgie. Selbst ge bte Spezialisten k nnen nicht das u u o Risiko auf sich nehmen, diese neuen Methoden ohne ausreichendes Training zur Anwendung zu bringen. Die Schulung durch VR-Systeme, z.B. eine virtuelle Endoskopie, ist daher auch bei der Weiterbildung von Medizinern hilfreich. Eine Vision der VR-Medizin ist es virtuell eine realit tsgetreue Operation a am Patienten durchf hren zu k nnen. Um dem Benutzer dabei eine Reaktion u o zu vermitteln, muss man die Stimulationen der verschiedenen Sinne k nstlich u erzeugen. Dies geschieht unter Zuhilfenahme von spezieller Hard- und Software. Dazu z hlt man nicht nur die dreidimensionale Visualisierung, sondern auch a haptische Systeme, die Ber hrungen simulieren k nnen. Solche komplexen und u o immersiven Realisierungen benden sich noch im Prototypenstatus bzw. sind Forschungsthemen. Ein Beispiel ist das im Rahmen des Projektes HapticIO am Forschungszentrum Karlsruhe in Kooperation mit der Kopfchirurgie des Universit tsklinikums Leipzig entstandene haptische Bedienger tesystem f r a a u Virtual-Reality-Trainingssysteme in der minimal-invasiven Chirurgie.

2.2

Virtuelle Geb udeplanung a

Software f r Computer Aided Design (CAD) ist heute in der Welt der Architeku tur sowie Innenarchitektur und Raumgestaltung weit verbreitet und nicht mehr wegzudenken. Das wohl bekannteste Beispiel ist das Programm AutoCAD des Herstellers Autodesk. Grunds tzlich wird bei CAD zwischen 2D- und 3D-Zeichnungen unterschiea den, wobei ein Hauptunterschied in der Verwendung des Endergebnisses besteht. W hrend 2D-Zeichnungen haupts chlich als Ersatz f r das mastabsgetreue und a a u genaue Handzeichnen dienen, k nnen 3D-Zeichnungen f r eine Vielzahl von o u Anwendungen eingesetzt werden. Zu diesen z hlen Visualisierung, Animation, a Prototyping und direkte Verwendung von Zeichnungsdaten zur Berechnung und Auswertung. Von einer Animation ist es wiederum nur ein kleiner Schritt zur Virtuellen Realit t. Im wesentlichen unterscheiden sie sich durch die zus tzlia a che Interaktivit t. Diese erm glicht es, lange vor dem tats chlichen Baubeginn a o a virtuelle Geb ude zu erstellen, durch die sich der Betrachter wie durch einen a realen Raum bewegen kann. So kann ein Architekt seinem Auftraggeber das zu bauenden Haus zeigen, indem er ihm einen virtuellen Rundgang durch das Geb ude erm glicht. Dabei kann jeder beliebige Raum virtuell betrachtet werden. a o Programme zur Erstellung interaktiver VR-Anwendungen sind jedoch deutlich weniger verbreitet als die Standard CAD-Software, die lediglich 2D-Zeichnungen oder Animationen und grasche Simulationen zulassen. Vor allem bei der Gestaltung von Innenr umen spielt es eine groe Rolle, a wie Erscheinungsbild und Ambiente auf den Betrachter wirken. Daher ist es kein Zukunftstraum mehr, dass man z.B. beim Kauf einer Einbauk che diese u vorher auf Bildern des individuell zugeschnitten 3D-Modells aus verschiedenen Blickrichtungen betrachten kann. Ahnliche Visualisierungen gibt es in Bereichen der M blierung und Beleuchtung von Innenr umen. So kann beispielsweise ein o a Wohnzimmer virtuell eingerichtet oder umgestaltet werden, ohne dabei die M bel o bewegen oder neu kaufen zu m ssen. Neue Raumeindr cke sind ganz exibel u u auf Tastendruck oder Mausklick abrufbar. Auch hier sind virtuelle Welten mit der M glichkeit zur Interaktion in einer dreidimensionalen Szene eine Seltenheit, o denn noch sind zweidimensionale foto hnliche Visualisierungen viel st rker a a vertreten.

Anforderungen an den Virtuellen Operationssaal

Die Nutzung von VR zu Trainings- und Simulationszwecken in der Medizin sowie virtuelle Geb udeplanung sind eher traditionelle Anwendungsgebiete. a Diese Studienarbeit besch ftigt sich mit der kaum beachteten Problematik a der Konguration von Arbeitsr umen in einem Operationssaal. Analysen am a Fraunhofer-Institut haben ergeben, dass die Einf hrung neuer Technologien wie u Robotik, Systeme zur computergest tzen Navigation, intraoperative bildgebende u Verfahren oder minimalinvasive Therapiesysteme h ug an der r umlichen Sia a tutation im OP scheitert. Neue Systeme stehen im Verdr ngungswettbewerb mit a etablierten Ger ten wie Ultraschall, Mikroskopen oder An sthesie-Ger ten, auf a a a die nicht verzichtet werden kann. VR-Szenarien k nnen die r umlichen Probleme o a aufzeigen und l sen helfen, wodurch die Akzeptanz f r die Einf hrung moderner o u u Verfahren erh ht wird. o

3.1

Anforderungen

Im Allgemeinen w nscht man sich von einem virtuellen Operationssaal (VRu OP) m glichst alle Eigenschaften, die ein realer OP aufweist. Manche Aspekte o k nnen jedoch vernachl ssigt werden, denn bei der Erstellung des VR-OP liegt o a der Schwerpunkt auf Ergonomie und Funktionalit t, nicht auf dem Erscheinungsa bild oder dem Ambiente der Software. Der entwickelte virtuelle Operationssaal dient prim r der unterst tzenden Anwendung bei verschiedenen Projekten des a u Fraunhofer-Instituts. Diese haben alle gemeinsam, dass zus tzliche Roboter- oder a Computersysteme mit spezieller Hardware zur Verf gung gestellt werden, die u den Operateur unterst tzen. Um das bereits vorhandene Platzproblem dadurch u nicht noch weiter zu versch rfen, soll der VR-OP zur Konzeption von effektiven a Arbeitsabl ufen und Prozessen dienen, wobei besonders den Kongurationen der a Ger te im Raum zu unterschiedlichen Zeitpunkten Beachtung geschenkt wird. a Hauptaugenmerk gilt daher der dreidimensionalen Darstellung sowie der funktionalen Variabilit t des Raumes mit seinem Inhalt. Dies betrifft Ausmae und a Ausstattung des OP genauso wie die freie Anordnung der Objekte im Raum, um m glichst alle realen Raumkongurationen simulieren zu k nnen. Sekund r kann o o a die Anwendung zudem als optisch attraktive Visualisierung der institutseigenen Konzepte eines Operationszenarios dienen. Die sp teren Nutzer des Systems werden von Anfang an in die Entwicklung a mit einbezogen bzw. werden nach der Fertigstellung ausf hrlich in die Benutzung u eingewiesen. Daher steht die Gestaltung einer intuitiven Schnittstelle eher im 9

Hintergrund und der m glichst effektiven sowie exiblen Nutzung kann mehr o Aufmerksamkeit gewidmet werden. Dennoch sollte der Benutzer des VR-OP in die virtuelle Realit t durch eine geeignete Mensch-Computer-Schnittstelle a (siehe Abschnitt 5) eintauchen k nnen. Jede Art dieser Mensch-Maschineo Kommunikation hat ihre besonderen St rken und Schw chen. In diesem Fall ist a a eine zweidimensionale Anzeige auf einem herk mmlichen Computerbildschirm o und die Interaktion durch Standard-Eingabeger te (Maus und Tastatur) ausreia chend. Ein immersives System mit dreidimensonaler Ein- und Ausgabetechnik ist nicht sinnvoll, da das System haupts chlich als Planungswerkzeug gedacht a ist und dabei andere Aspekte im Vordergrund stehen: Die Operationsszenarios sollen nicht als m glichst real erlebt werden, sondern so effektiv wie m glich o o geplant werden k nnen. Durch diese Anforderungen kann der VR-OP an einem o gebr uchlichen PC genutzt werden und ben tigt keine spezielle Hardware, auer a o einer 3D-Grakkarte, die mittlerweile Standard in jedem PC ist. Die folgende Aufz hlung von Anforderungen fasst die einzelnen Funktionalit ten a a des virtuellen Operationssaales zusammen, die im Rahmen dieser Studienarbeit implementiert wurden. Anzeige und Interaktion uber eine grasche Benutzerschnittstelle (Graphical User Interface, GUI). Abbildung 2 zeigt eine GUI-Aufteilung, nach der sich die Gestaltung der endg ltigen Schnittstelle richten soll. u Mehrere Sichten mit unterschiedlichen Blickrichtungen in die virtuelle Welt Interaktionsm glichkeiten w hrend der Anzeige uber die GUI zug nglich o a a Objektmodelle: Operationstisch, OP-Personal, Patient, MRT-Scanner, Narkoseger t, Operationsbestecktische, Infusionsst nder, Trackingkamera, a a Monitor-Rollwagen Kontextsensitives Hinzuf gen aller Objekte mit Auswahlliste u Kontextsensitives Entfernen aller Objekte Objekte interaktiv per Maus selektierbar und im Raum frei beweglich Kameraposition interaktiv ver nderbar a Raumgr e stufenlos verstellbar o Kollisionserkennung beim Bewegen von Objekten, inklusive Visualisierung von Kollisionen M glichkeit zum Speichern und Laden von erstellten Raumkongurationen o 10

 Visuelle Unterst tzung zur Absch tzung von Abst nden u a a Erweiter- bzw. Modizierbarkeit f r weitere Funktionalit ten gew hrleisten u a a

Abbildung 2: Die w hrend der Anforderungsanalyse festgelegte Aufteilung der a GUI Als erstes in die Tat umzusetzendes Anwendungsszenario dient ein Projekt des Fraunhofer Instituts-FIT in Zusammenarbeit mit der Localite GmbH und der Klinik f r Neurochirurgie des Universit tsklinikums Kiel. Die Localite GmbH u a ist ein SpinOff-Unternehmen des Fraunhofer-Instituts f r Angewandte Inforu mationstechnik, die sich zur Aufgabe gemacht hat Forschungsprototypen von Navigationssystemen f r die Chirurgie in marktreife Medizinprodukte weiter u zu entwickeln. Gemeinsam mit dem Team der Klinik f r Neurochirurgie unter u Leitung von Direktor Prof. Dr. med. H.M. Mehdorn wird die intraoperative Verwendung eines neurochirurgischen Navigationssystems angestrebt, das den Chirurgen durch Anzeige von MRT-Daten in Echtzeit unterst tzt. Da auch die u MRT-Aufnahmen intraoperativ erfasst werden, und deshalb ein MRT-Scanner im OP vorhanden ist, sind in diesem Fall noch intensivere Planungen von Ger tea kongurationen und Arbeitsabl ufen n tig. Schlielich erzeugen MRT-Ger te ein a o a extrem starkes Magnetfeld und nehmen sehr viel Platz ein.

11

3.2

Beispiel

An der University of Michigan wurde vor einigen Jahren bereits ein ahnliches Projekt realisiert. Im Rahmen des interdisziplin ren Projektes The Medical Reaa diness Trainer wurde in Kooperation mit mehreren Institutionen der Virtual OR (Operating Room) erstellt. Informationen dazu sind auf den Projektwebseiten (http://www-vrl.umich.edu/mrt/index.html) zu nden. Dort steht die von Andre Zoldan erstellte VRML-Version (n heres zu VRML wird in Kapitel 4.3 a besprochen) eines virtuellen Operationssaals zur Ansicht bereit, die M glichkeio ten zur Interaktion bietet. Der Benutzer kann neben der VRML-typischen frei ver nderbaren Kameraposition einige vordenierte Standpunkte zur Ansicht im a Raum w hlen. Einige der vorhandenen Objekte k nnen beliebig im Raum bea o wegt werden. Von anderen Objekten, wie z.B. dem Operationstisch und der Deckenbeleuchtung, sind jedoch ausschlielich bestimmte Teile beweglich. Durch ansprechende Ger temodellierung, Texturierung mancher Gegenst nde und Bea a leuchtung der Szene wirkt der virtuelle Operationssaal realistisch. Dieser Eindruck wird jedoch durch das Nichtvorhandensein von Kollisionerkennung oder -vermeidung zwischen den einzelnen virtuellen Objekten im Raum getr bt. Auf u der Internetseite ist zudem ein Screenshot (siehe Abbildung 3) einer mit OpenInventor erstellten Version des Virtual OR zu nden, die von JoAnn Render f r u die Betrachtung in der CAVE (Computer Animated Virtual Environment), einer speziellen immersiven Anzeigetechnologie, angepasst wurde.

Abbildung 3: Bild aus der Inventor Version des Virtual ORder University of Michigan erstellt, Quelle: http://www-vrl.umich.edu/mrt/andre iv full.jpg

12

Erstellung von Virtual Reality

Nicht jedes Programm, das Bilder von 3D-Objekten liefert, ist zur Erstellung einer Virtual-Reality-Umgebung geeignet. Jedoch werden Applikationen aus dem Bereich der 3D-Animation und Simulation (wie z.B. 3D Studio Max von Autodesk, Cinema 4D von Maxon oder Softimage von Avid Technology Inc.) vermehrt auch zur Erstellung von Systemen genutzt, die virtuellen Welten ahnlich sind. Dabei ist die schon angesprochene Interaktionsm glichkeit der Ergebnisse stets eingeo schr nkt oder vorherbestimmt. Die erw hnte 3D-Grak-Software ist zudem oft a a sehr teuer, viel zu komplex und nicht benutzerfreundlich, da an sie andere Anforderungen gestellt werden, die eher f r fotorealistisches Rendering oder realit tsu a getreue Animation relevant sind. Zwei Entwicklungssysteme, die den Anspr chen u dieser Studienarbeit ann hernd entsprechen, werden im folgenden Abschnitt disa kutiert. Im darauf folgenden Unterkapitel wird die Java3D API (Application Programming Interface) vorgestellt. Diese Programmierschnittstelle stellt genau wie andere 3D-Grak-Programmiersprachen z.B. OpenGL und VRML die m chtigste a M glichkeit zum Kreieren einer virtuellen Welt dar. Die speziellen Eigenschaften o sowie Vor- und Nachteile von Java3D werden erl utert, woraus sich die Gr nde a u f r die Entscheidung zu Gunsten einer Entwicklungsumgebung ergeben. u

4.1

3D-CAD-Software

Aus einer Reihe von 3D-Software-Paketen stellten sich Mantra4D von Criterion Software Ltd. [mantra] und die tucan series 2003 von Awaron [awaron] als potentiell geeignete Entwicklungswerkzeuge heraus. Allerdings weisen beide Programme eine so hohe Komplexit t auf, dass im Rahmen des hier zu realisiea renden Projektes lediglich ein Teil der Funktionen getestet und bewertet wird. Dabei wird in erster Linie auf die Herstellerinformationen zur ckgegriffen. Einige u Test zur Einsch tzung der Handhabung und zur Uberpr fung der Funktionalit t a u a wurden jedoch durchgef hrt. u Mantra4D wird in Deutschland von der Firma ComLogic Systeme GmbH vertrieben und vom Hersteller als eine 3D Softwaresuite f r Simulation, Visualisierung, u Datenoptimierung, Management und Analyse beworben. Zur Erstellung oder Modikation einer VR-Umgebung mit dem Funktionsumfang von Mantra4D ist das enterprise SDK, ein Software-Entwicklungs-Kit mit eigenem Interface und einer kompletten API, n tig. Mit diesem sollen einfache und schnelle Layo outs dank Scripting, vorhandenen C++ Bibliotheken und Application Wizards m glich sein. Zudem werden Multirenderer, Echtzeit-Verkn pfung zu CAD sowie o u mathematische und physikalische Module f r effektive Echtzeit 3D-L sungen u o geboten. Sogar interaktive immersive VR-Planung mit optischem Tracking und 13

stereoskopischer Darstellung, die rationelles Arbeiten in realit tsnahen Szenarien a garantieren sollen, wird unterst tzt. In Anwendungstests der zeitlich limitierten u Demoversion mit voller Funktion stellte sich heraus, dass eine l ngere Einarbeia tungszeit n tig ist, um diese umfangreiche Applikation effektiv und umfassend o nutzen zu k nnen. Eine komplette Realisierung des virtuellen Operationssaals o mit allen gew nschten M glichkeiten scheint durchf hrbar zu sein. Preisinformau o u tionen sind auf den Hersteller- und Vertriebswebseiten nicht zu nden. Es kann keine Forschungslizenz o. ., sondern ausschlielich eine Vollversion erworben a werden. Die tucan series 2003 der Awaron AG ist sowohl unter MS Windows als auch unter Linux lauff hig und wird vom Hersteller als professionelle Echta zeit-Visualisierungs-Software beschrieben, mit der als echte VR-L sung die o polygon-basierenden Modelle ohne Zwischen- oder Vorberechnung permanent in gerendertem Zustand interaktiv bearbeitet und pr sentiert werden k nnen. Die a o Funktionalit ten zum Aufbau von Echtzeit-Modellen, u.a. mit denierten Blicka punkten und Durch gen, stellt dabei tucan design bereit. Um in einer Szene u Bewegungen von Modellbestandteilen denieren zu k nnen, wird tucan animate o ben tigt und zur Betrachtung aller Modelle steht der kostenfreie tucan view zur o Verf gung. Die jeweilige Szene wird schon w hrend des Erzeugungsprozesses u a in tucan design in ihrem vollst ndigen und realistischen Aussehen pr sentiert, a a wodurch dieser Teil der Software sowohl zur Erstellung als auch zur Betrachtung bzw. Anwendung des VR-Operationssaals genutzt werden k nnte. Mit dieser o Entwicklungsumgebung k nnen jedoch nicht alle in Kapitel 3 beschriebenen o Anforderungen realisiert werden, da z.B. keine M glichkeit besteht, Kollisioo nen zwischen beweglichen Objekten zu erkennen. Laut Hersteller werden VRund Programmier-Expertise beim Aufbau von virtuellen Szenen wie z.B. Animationen, Beleuchtungen, Spiegel chen, AVI-auf-Polygon nicht ben tigt. Die a o Bedienung hat sich bei der Anwendung der kostenlosen Studentenversion, die im Funktionsumfang dem eingeschr nkten tucan design entspricht, als angemessen a und nicht zu komplex herausgestellt. F r den Rahmen dieser Studienarbeit w rde u u die angesprochene Studentenversion ausreichen, f r die sp tere Nutzung w re u a a eine Lizenz zum Preis von ca. 5.000,- EUR n tig, die tucan design, tucan animate o und tucan movie umfasst.

14

4.2

Java3D

Die Java3D API ist eine Erweiterung der objektorientierten Programmiersprache Java 2 von Sun Microsystems, wobei alle Eigenschaften von Java auf diese Erwei terung ubertragbar sind. Sie entstand in Zusammenarbeit von Intel, SGI, Apple und Sun und vereinigt Ideen aus existierenden APIs wie Direct3D, OpenGL, QuickDraw3D, OpenInventor und XGL. Die grundlegende Funktion ist das Erzeugen und Darstellen von dreidimensionalen Szenen, wobei die API auf dem Szenengraphenprinzip basiert. Das bedeutet, dass die gesamte zu zeichnende Szene in einem Graphen gespeichert wird, der alle r umlichen sowie funktionalen a Beziehungen der graschen Objekte untereinander repr sentiert. Abbildung 4 a zeigt einen allgemeinen Java3D Szenengraphen. Die objektorientierte Sicht der 3D-Darstellung erm glicht abstraktes Arbeiten und das schnelle Erstellen von o anspruchsvollen Anwendungen. Momentan sind Implementationen f r Microsoft u Windows Betriebssysteme sowie f r Sun Solaris, HP-UX, SGI-IRIX und Linux u erh ltlich. Die Java3D API ist inzwischen in der dritten uberarbeiteten und erweia terten Version verf gbar. u

Abbildung 4: Beispiel eines Java3D-Szenengraphen, Quelle: [j3dtut]

15

Folgende im Rahmen dieser Arbeit wichtigen Eigenschaften sind vom JavaKonzept vererbt und werden daher nicht n her beschrieben: a einfach objektorientiert interpretativ architekturunabh ngig a portabel multithreading sicher robust dynamisch Ein groer Vorteil von Java3D ist die Zugriffsm glichkeit auf vorgefertigte dynao mische Funktionalit ten. Diese sind in Java3D durch so genannte Behaviors a implementiert. Sie sind Bl tter des Java3D Szenengraphen und werden unter a bestimmten Kriterien (Wakeup Criteria) von Ereignissen aktiviert, um dann Teile des Graphen in der angegebenen Weise zu ver ndern. Solche Aka tivierungssignale k nnen zum Beispiel Mausklicks oder -bewegungen sowie o Tastatureingaben sein. Ein typisches Beispiel f r ein Behavior ist die Selektion u eines graschen Objektes in einer Java3D-Szene durch Mausklick auf das entsprechende Objekt. Das Behavior erwacht aufgrund des Mausklicks und ermittelt anschlieend das ausgew hlte Objekt. Um die Auswahl (auch Picking genannt) a deutlich zu machen, werden daraufhin z.B. Farbe oder Materialeigenschaften dieses Objekts ver ndert. Behaviors machen die Programmierung mit dieser API a komfortabel, da sowohl f r viele Interaktionsm glichkeiten mit dem Benutzer, alu o so auch f r automatisches Verhalten von 3D-Objekten solche Klassen existieren, u die zudem erweiterbar sind bzw. ver ndert werden k nnen. Die teilweise nicht a o ausreichende Dokumentation und manchmal undurchsichtige Funktionsweise der Behaviors setzt jedoch eine gewisse Einarbeitung voraus. Trotz der sehr umfangreichen Funktionalit t ist diese API einfach zu benuta zen, denn beispielsweise werden die Details des Rendering, die Ermittlung von Farbwerten, das Ausblenden nicht sichtbarer Fl chen, die Berechnung von Transa formationen usw. automatisch gehandhabt. Im Gegensatz zu den im vorherigen Abschnitt erw hnten 3D-Entwicklungsprogrammen ist die Nutzung von Java a 16

und Java3D komplett kostenfrei, die Applikation muss daf r aber selbst erzeugt u werden. Die jeweiligen Entwicklungs- und Laufzeitumgebungen k nnen von o Suns Java Homepage [java] inklusive Dokumentationen, Tutorials und teilweise mit Quellcode heruntergeladen werden. Java3D ist jedoch eine recht junge Pro grammiersprache f r 3D-Computergrak, die von ihrer ubergeordneten Sprache u den geringen Nachteil geerbt hat, keine Spitzenwerte bei der Performanz zu leisten. Dies ist einer von mehreren Gr nden, warum sie in der VR-Entwicklung u nicht so viel Anwendung ndet wie OpenGL. Viele Designentscheidungen beim Entstehen von Java3D wurden jedoch zugunsten der Geschwindigkeit getroffen. Die Funktionen werden auf bestehende APIs abgebildet, die auch 3D-Hardwarebeschleunigungen u. . unterst tzen. Durch das SceneGraph-Model sind a u Optimierungen m glich, die es bei direkter Darstellung wie bei OpenGL nicht o gibt. Ein groer Vorteil, den der direkte Zusammenhang mit Java hervorbringt, sind die umfangreichen M glichkeiten zur Einbindung graphischer Ober chen, o a z.B. mittels der Swing-Klassen. Java3D ist mittlerweile so weit verbreitet, dass es kein Problem ist, ausreichend Literatur, Tutorials, Webseiten und Diskussionsforen zu nden, die sich mit der Programmierung von Spielen bis hin zu wissenschaftlichen Anwendungen besch ftigen. a

4.3

Entscheidung fur eine Entwicklungsumgebung

Im vorangegangenen Abschnitt wurde bereits dargestellt, dass Java3D eine komfortable Entwicklungsumgebung darstellt. Die in Kapitel 4.1 diskutierten 3D-Applikationen haben den groen Nachteil, dass ihr Funktionsumfang feststeht und der Quellcode weder einzusehen noch ver nderbar ist. Es ist also nicht a bzw. nur uber Plug-Ins oder Umwege m glich, eine Funktionalit t der virtuellen o a Welt zu implementieren, die die Grundm glichkeiten der Software uberschreitet. o 3D-Grak-APIs hingegen sind in dieser Hinsicht viel exibler, da offen, erweiterbar und ver nderbar. Viele erdenkliche Eigenschaften sind programmierbar und a auch nach Abschluss der Studienarbeit problemlos hinzuzuf gen. Diese Funku tionen m ssen zwar selbst gefertigt werden, jedoch ist dies mit Java3D nicht u zeitaufw ndiger als die Einarbeitung, die zur effektiven Nutzung von komplea xen 3D-CAD-Programmen n tig ist. Programmiersprachen m ssen zwar auch o u erlernt werden, sind dann jedoch umfassender einsetzbar. Zudem kann in diesem Fall auf den Quelltext und die Erfahrung von anderen Java3D-Projekten des Fraunhofer-Instituts zur ckgegriffen werden. Ohnehin ist Java3D mit Computeru grakgrundwissen und Programmiererfahrung in Java mit Hilfe von Tutorials und Literatur in kurzer Zeit erlernbar. Vor allem bei der Umsetzung von anspruchsvolleren Funktionen kommen CADAnwendungen an ihre Grenzen. Zum Beispiel f r die Visualisierung von abu strakten Gegenst nden, etwa einem Magnetfeld oder dem Sichtbereich einer a 17

Kamera, stellt Java viel mehr M glichkeiten zur Verf gung. Dies gilt ebenso f r o u u die Darstellung von Zust nden (z.B. Sterilit t) wie f r die technische Umseta a u zung von Objektabh ngigkeiten (z.B. Abstandsbeschr nkungen auf Grund von a a Kabell ngen). Besonders die visuelle Umsetzung von Daten ssen zwischen a u Objekten ist vielschichtig und ben tigt die ausgedehnten F higkeiten einer Proo a grammiersprache. Eine mit Java gefertigte Anwendung ist mit wenig Aufwand in der Lage, Daten in Dateien zu speichern oder aus ihnen zu lesen. Die Datenstruktur kann dabei selbst gew hlt werden und es muss nicht, wie bei den CAD-Anwendungen, auf meist a mit anderen Programmen inkompatible Datentypen zur ckgegriffen werden. u Flexibilit t und unkomplizierte Nutzbarkeit sind Voraussetzungen f r die zuk nfa u u tige externe Nutzung der Anwendung, die langfristig angestrebt wird. Die Plattformunabh ngigkeit von Java unterst tzt dies, im Gegensatz zu den Betriebsa u system abh ngigen CAD-Systemen. Die Benutzerober chen dieser sind zudem a a mit vielen Funktionen uberladen, die f r die geplante VR-Software nicht von u Interesse sind. Dadurch wird die Bedienbarkeit f r unge bte Nutzer wie z.B. u u Arzte unn tig erschwert, was mit einer speziell f r die Aufgaben ausgelegten o u Ober che nicht der Fall ist. Ferner ist der zuk nftige Vertrieb einer Java3D Apa u plikation einfacher, da kein Dritthersteller beteiligt ist oder Lizenzrechte beachtet werden m ssen. u 3D-Grak-Anwendungen eignen sich jedoch hervorragend zur Modellierung von Objekten, denn wenn man umfangreiche Objekte erschaffen will, wird sehr viel Code ben tigt, allein um die Punktkoordinaten der Objektober chen zu o a bestimmen. Deshalb stellt Java3D Methoden bereit, mit denen man Objekte mit geringerem Aufwand erzeugen kann. Mit verschiedenen vorgegebenen Primitiven k nnen eigene Objekte aus Dreiecks chen erstellt werden. Zudem gibt es so o a genannte Loader-Klassen, die Objekte aus Dateien in Java3D importieren, die z.B. mit einer 3D-Modelling-Software erstellt wurden. Solche Loader existieren f r viele standardisierte Dateitypen. u Neben Java3D sind auch andere Programmierschnittstellen wie OpenGL und VRML (Virtual Reality Modeling Language) zur Realisierung des Projektes geeignet. OpenGL ist eine unter F hrung von SGI entwickelte Grak API, u die auf der SGI IRIX eigenen Grakbibliothek (GL) basiert. Sie ist sowohl vom Betriebssystem als auch vom Windowmanager unabh ngig, da es keine APIa Funktionen innerhalb von OpenGL gibt, die die Anbindung an das Betriebssystem durchf hren. Sie zeichnet sich vor allem dadurch aus, dass sie die F higkeiten u a vorhandener Grakhardware sehr gut ausnutzt. OpenGL ist eine sogenannte 18

low-level API. Das bedeutet, dass sie lediglich Funktionen auf sehr einfachem Niveau enth lt. Dies macht die Arbeit aufw ndiger und unkomfortabler als mit a a Java3D. Es ist z.B. mit OpenGL weder m glich Szenengraphen zu verwalten, o noch sonstige Kontextinformationen zu speichern. Dennoch ist sie im Moment wahrscheinlich die am meisten genutzte Grak-API im professionellen Bereich. Viele high-level APIs, wie z.B. Java3D, benutzen OpenGL als Basis, um ihre Ausgabe darzustellen. Da mit Java3D also alle wichtigen OpenGL Eigenschaften einfacher und schneller genutzt werden k nnen, wird diese API zur Realisierung o des VR-OP genutzt. Ferner sind die Objektorientierung und das Konzept der Vererbung von Java f rderlich. Die von Silicon Graphics initiierte Beschreibungso sprache VRML bietet zwar nur geringf gig weniger M glichkeiten im Bereich u o der 3D-Darstellung als Java3D, und hat sogar an einigen Stellen Vorteile, ist jedoch ein mittlerweile veralteter und nicht mehr weiterentwickelter Standard. Wie die CAD-Software hat auch VRML keine m chtige Programmiersprache im a Hintergrund, sie ist urspr nglich zur reinen Webanwendung f r Internetbrowseru u PlugIns gedacht. VRML erfreute sich bis vor ein paar Jahren groer Beliebheit und wurde auch oft zu anderen Zwecken genutzt. Daher sind sehr viele Modellierungsprogramme mit VRML-Import und -Export M glichkeiten ausgestattet. o Dies macht die Verwendung von VRML als Datenstruktur zur Speicherung von modellierten Gegenst nden interessant. F r Java3D existieren verschiedene a u der angesprochenen Loader-Klassen zum Import von VRML-Modellen. Diese k nnen dadurch einfach an beliebiger Stelle in den Szenengraphen eingeh ngt o a werden. Auf Grund dieser Argumente wurde Java3D zur Erzeugung des virtuellen Operationssaals ausgew hlt und Java f r die GUI-Erstellung und spezielle Funktionen a u im Hintergrund genutzt. Die 3D-Objekte, die der Raum beinhaltet, wurden mit CAD-Software modelliert und via VRML-Dateien in die Welt des VR-OP importiert.

19

Virtual Reality Benutzerschnittstellen

Wenn ein Mensch mit einem technischen System interagiert, hat er es immer mit einer Schnittstelle (engl. interface) zu tun, die Informationen zwischen dem Menschen und den technischen Vorg ngen innerhalb der Maschine austauscht. Schon a seit langem stellt die Entwicklung solcher Schnittstellen f r die Kommunikation u zwischen Mensch und Maschine ein eigenes Forschungsgebiet dar. Mit wachsender Funktionalit t von Computer-Systemen nimmt deren Komplexit t zu. In den a a Anfangszeiten der Computerinterfaces musste der Anwender sich oft an die Systeme anpassen und m hevoll den Umgang mit ihnen erlernen. Heute wird viel u Aufwand betrieben, um diese H rde m glichst zu minimieren, indem die Schnittu o stellen immer intuitiver gestaltet werden. So soll auch Laien die Benutzung dieser Systeme erm glicht werden. Die Interaktion mit virtuellen Welten und Ino terfaces die diesen ahnlich sind, wird im Gegensatz zur allgemeinen MenschMaschine-Kommunikation weniger intensiv untersucht. Jedoch wird immer mehr Forschung in diese Richtung betrieben, schlielich ist der Entwurf von intuitiver 3D-Interaktion wichtig um komplexe VR-Anwendungen, die sich immer mehr etablieren, f r jeden bedienbar zu machen. Im Folgenden werden die Grundu lagen der Visualisierung von und die Interaktion mit 3D-Benutzerschnittstellen erl utert. a

5.1

Visualisierung

Eine ansprechende, ubersichtliche und einfach verst ndliche visuelle Gestaltung a der graphischen Benutzerschnittstelle ist daher besonders bei VR die Voraussetzung f r den schnellen und intuitiven Zugriff eines unerfahrenen Nutzers auf u die angebotene Menge der meist komplexen und vielschichtigen Informationen. Durch die Nutzung von VR-Technologien besteht die M glichkeit, Informationen o bzw. Gegebenheiten so darzustellen, dass der Anwender sie auch unterbewusst wahrnimmt. Auf diese Weise lassen sich beispielsweise Farben und Formen dazu verwenden, bestimmte Assoziationen hervorzurufen. Daher ist allgemein der Einsatz von Metaphern anzustreben, die dem Benutzer aus dem t glichen Leben a in der realen Welt bekannt sind. Hauptbestandteil jeder VR-Desktop Anwendung, also einer Realisierung mit herk mmlichen Ein- und Ausgabeger ten, ist ein Darstellungsbereich zur Sicht o a in die virtuelle Welt. In diesem Bereich der GUI werden zur Visualisierung der einzelnen virtuellen Objekte einfache geometrische Formen sowie Polygonz ge u verwendet. Aus diesen Geometriedaten wird dann in mehreren Schritten eine virtuelle Umgebung aufgebaut.

20

Ein Beispiel f r die angesprochenen Metaphern ist Tiefenwirkung durch peru spektivische Projektion, die durch bestimmte Aspekte Dreidimensionalit t, auch a bei der Anzeige auf 2D-Ger ten wie Monitoren, erzeugen kann. Dabei wird a z.B. die Position von Bestandteilen der 3D-Welt, die sich r umlich vor bzw. a hinter anderen benden, genauso wie in der Realit t wahrgenommen, wenn der a Gegenstand im Vordergrund den im Hintergrund bendlichen verdeckt. Auerdem werden zwei Objekte mit dem selben Ausma bei unterschiedlicher Lage im Raum wie gewohnt verschieden gro angezeigt. Dies sind nur einige der Eigenschaften von perspektivischer Raumwirkung, die alle gleichermaen erf llt u werden m ssen, damit der Anwender einen konstanten 3D-Eindruck bekommt. u Da mit einem PC-Monitor meist nur ein 2D-Anzeigeger t zur Verf gung steht, a u kann es auch leicht zu Darstellungssituationen der Lage oder Bewegung von Objekten im dreidimensionalen Raum kommen, die durch den Betrachter auf mehrere verschiedene Weisen interpretiert werden k nnen. Es werden z.B. Obo jekte bei Betrachtung von einer leicht erh hten seitlichen Position als uber o dem Boden schwebend erkannt, obwohl sie direkt auf einer Boden che stea hen. Eine zweite zus tzliche Seitenansicht dieses Szenarios kann die eindeutige a Position verdeutlichen. Dies ist u.a. der Grund daf r, dass in CAD- und 3Du Modellierungsprogrammen neben einer Sicht, in der interaktive Ver nderung a der Blickrichtung m glich ist, drei weitere je zueinander orthogonale Sichten o angezeigt werden. Diese repr sentieren die Standardblickrichtungen von vorne, a oben und der Seite auf die Szene. Vor allem bei der Manipulation von komplexen 3D-Szenarien sind mehrere Sichten manchmal der einzige Weg, um den Benutzer den ben tigten Grad an Kontrolle und Orientierung zur interaktiven Ver nderung o a der virtuellen Welt zu geben.

5.2

Interaktion

Im Allgemeinen versteht man unter Interaktivit t, dass ein System w hrend des a a Betriebs Eingriffe des Benutzers erlaubt, auf die es in angemessener Zeit und auf geeignete Weise reagiert. Die spezielle Interaktion mit virtuellen Welten kann in drei Interaktionsparadigmen eingeteilt werden: Navigation, Manipulation und Kommunikation. Der Aspekt der Kommunikation wird hier nicht behandelt, da er im Rahmen dieser Studienarbeit nicht von Interesse ist. Dieser Teilabschnitt befasst sich also mit der freien Beweglichkeit des Benutzers in der virtuellen Welt und der Manipulation virtueller Gegenst nde. a Da die weit verbreiteten Standard-GUIs meist mit einer Tastatur und einem Zeigeger t ( blicherweise einer Maus) bedient werden und Realit tsn he bzw. Immera u a a sion nicht zu den Anforderungen dieses Projektes geh ren, werden nur Aspekte o der Interaktion mit herk mmlichen Ein- und Ausgabeger ten angesprochen. o a 21

5.2.1

Navigation

Die dreidimensionale Sicht in virtuelle Welten ist vor allem von der jeweiligen Position, an der sich der Betrachter virtuell bendet, und von dessen Blickrichtung abh ngig. In diesem Zusammenhang spricht man auch von einer virtuellen a Kamera (bzw. Viewpoint), die in einen bestimmten r umlichen Ausschnitt der gea samten simulierten Welt hineinsieht. Die Kamera kann in der Regel innerhalb der Modellwelt frei bewegt werden oder bestimmte vordenierte Kamerapositionen einnehmen. Diese Ver nderung der Lage und Orientierung der Kamera durch den a Benutzer wird Navigation genannt. Wenn mehrere Sichten in die virtuelle Welt existieren - z.B. aus oben genannten Gr nden, oder bei der Benutzung durch mehrere Benutzer zur gleichen u Zeit - ist es f r die freie Blickpunktwahl meist erforderlich, eine Darstellung des u jeweiligen Anwenders in die virtuelle Welt zu integrieren. Solch eine Avatar genannte Repr sentation eines Benutzers in der VR ist technisch gesehen ein a geometrisches Objekt wie alle anderen, das stets an der Position des Benutzers dargestellt wird, also allen Bewegungen der Kamera folgt. Wenn f r den Anu wender dieses virtuelle Ich selbst zu sehen ist, spricht man von einem Third Person Anzeigemodus. Bei der First Person Darstellung ist der Avatar aus der eigenen Sicht nicht vorhanden. Bei Multibenutzeranwendungen k nnen sich die o einzelnen Nutzer durch die Existenz der Avatare gegenseitig wahrnehmen und miteinander in Interaktion treten. Die Art und Weise wie ein Avatar und damit die Kamera durch die virtuelle Realit t bewegt wird, ist von einem System zum a anderen unterschiedlich. Von direkter Eingabe via Maus und/oder Tastatur bis hin zur Steuerung uber Kn pfe, Scrollbalken und andere GUI-Elemente sind alle o erdenklichen Mischformen zu nden. Welche Form der Navigation am besten f r u eine individuelle VR-Anwendung geeignet ist, variiert auf Grund der jeweiligen Anforderungen.

5.2.2

Manipulation

Zur manipulativen Handhabung von 3D-Objekten ist zun chst die Selektion a dieser notwendig. In ubersichtlichen virtuellen Umgebungen ist die direkte Selektion durch Zeigen auf das gew nschte Element die einfachste Variante. Bei u dieser als Picking bezeichneten Methode wird an der durch ein Eingabeger t a (meist Maus) gezeigten Stelle das jeweils vorderste Objekt ermittelt und ausgew hlt. Dabei wird beim Bet tigen einer Maustaste vom Betrachter durch den a a Cursor, der die Position der Maus auf dem Bildschirm repr sentiert, ein Projeka tionsstrahl in den 3D Raum projiziert. Der Lagepunkt des Cursors beschreibt 22

die 3D-Punkte des Strahls, die auf seine Position in der 2D-Anzeige che aba gebildet werden. Der erste Schnittpunkt des Strahls mit einem Objekt deniert eindeutig einen virtuellen Gegenstand, der zur Interaktion herangezogen wird. Wenn ein virtueller Gegenstand selektiert werden soll, der durch andere teilweise oder ganz verdeckt wird. sind mehrere Sichten in ein und dieselbe Szene hilfreich.

Abbildung 5: Projektion des Picking-Strahls

Durch die Selektion stehen dann die dreidimensionalen K rper zur direkten o Manipulation bereit und sie sind ab diesem Zietpunkt sensitiv gegen ber Beu nutzereingaben. Dies ist eine Interaktionsweise, bei der durch direkte Handlung (Zeige- sowie Bewegungsgeste) bestimmte Ver nderungskonzepte realisiert und a sofort sichtbar gemacht werden, ohne dass dazu uber bestimmte GUI-Elemente oder andere Eingaben ein Befehl umgesetzt werden muss. Nach [preim] ist die direkte Manipulation durch folgende Eigenschaften gepr gt: a Es existiert eine grasche Repr sentation der Applikation, also der Aufgaa ben und Objekte, die mit der Ober che bearbeitet werden sollen. a Die Bearbeitungsschritte werden durch Manipulation dieser Repr sentatioa nen mittels geeigneter Eingabeger te durchgef hrt. Von dort werden sie oha u ne weitere Benutzeraktionen an die Applikationen weitergegeben. Das Ergebnis dieser Bearbeitung ist sofort am Bildschirm sichtbar An einmal erlernte Aktionen, die direkt-manipulativ durchgef hrt werden, u kann man sich leicht erinnern. Die Ober che ist relativ sprachunabh ngig, bedingt durch die Verwendung a a eines graphischen Modells. 23

In dieser Arbeit sind besonders die Translation und Rotation von Objekten von Bedeutung. Eine weitere wichtige, aber nicht betrachtete manipulative Aktion, neben vielen weiteren Formen, ist die Skalierung. Die drei Raumtransformationen sind der Interaktion mit Gegenst nden in der realen Welt nachempfunden, indem a die bekannten r umlichen Metaphern Verwendung nden. Die Translation ist die a einfachste dieser Interaktionen, solange sie sich, wie hier von Interesse, auf zwei Dimensionen beschr nkt. Die virtuellen Gegenst nde werden dann proportional a a zur Bewegung der Maus in den bestimmten Dimensionen in der VR verschoben. Zur leichteren Handhabung wird dabei meist die Bewegung um einen gewissen individuellen Faktor skaliert, dadurch muss der Benutzer mit der Maus keine langen Wege zur cklegen. Rotation von Objekten in je einer Dimensionen setzt die Exiu stenz sowie die Kenntnis uber die Lage der entsprechenden Rotationsachse voraus. Im Dreidimensionalen ist dementsprechend ein Punkt als Rotationszentrum n tig. Ob diese Achsen bzw. der Punkt selbst auch manipuliert werden k nnen, ist o o vom jeweiligen System abh ngig. Analog zur Rotation im Realen wird der Grad a der Rotation durch den Faktor der Bewegung der Maus ausgedr ckt, wobei dieser u zur Umsetzung spezieller Aufgaben auch wieder unterschiedlichen Skalierungen unterzogen werden kann. Die St rke der Bewegung wird dadurch reguliert. F r a u eine exakte Platzierung und Ausrichtung von Gegenst nden in der VR ist die Ana zeige von Hilfslinien, z.B. in der Form eines Rasters, sehr hilfreich. Diese Elemente k nnen nicht nur zur Orientierung beim Bewegen dienen, sondern auch o der Verdeutlichung von Abst nden bzw. Proportionen in der meist perspektivisch a verzerrten virtuellen Welt.

24

Der virtuelle Operationssaal

In diesem Kapitel werden Funktionsumfang und -weise der mit Java3D implementierten Virtual-Reality-Umgebung zur Planung und Visualisierung von r uma lichen Kongurationen, zeitlichen Abl ufen sowie Daten ssen im Operationsa u saal erl utert. Es verbindet den Charakter einer Dokumentation der technischen a Hintergr nde und eines Tutorials f r die Nutzung des Systems miteinander. Die u u Funktionalit ten der Anwendung richten sich dabei nach den in Kapitel 3 gea stellten Anforderungen und greifen auf die Grundlagen zur ck, die in Abschnitt 5 u eingef hrt wurden. Bei der Entwicklung wurde in erster Linie auf das sp tere Nutu a zungsumfeld und speziell auf den ersten Anwendungsfall im Gemeinschaftsprojekt mit der Localite GmbH und der Kieler Klinik f r Neurochirurgie hingearbeiu tet. Da die Anwender Fachleute im Umgang mit dem Computer sind, wird wie bereits in Kapitel 3 angesprochen, in diesem Fall beim Design des Benutzerinterfaces eine m glichst hohe Effektivit t der Intuitivit t beim Umgang mit der o a a Software vorgezogen. Das Projekt dient als Grundlage f r eine Weiterentwicklung u nach Abschluss dieser Studienarbeit. Aus diesem Grund wird an einigen Stellen auf angestrebte Funktionalit ten hingewiesen, f r deren Realisierung der zeitliche a u Rahmen der vorliegenden Arbeit zu gering war. Zum Kompilieren und Ausf hren u des Projektes werden die Installationen folgender Teile der Java API (zzgl. Erweiterungen) vorausgesetzt, die auf den Webseiten von Sun (siehe [java]) zum kostenlosen Download bereit stehen. Java 2 Platform Standard Edition (genutzte Version: Java 2 SDK, Standard Edition 1.4.2 01) Java 3D 1.3.1 API (genutzte Version: Java 3D SDK f r Windows inkl. Runu time, OpenGL Version) VRML-Loader Klassen: vrml97.jar (von ehemals http://www.vrml.org) in das Verzeichnis ../lib/ext des Java Installationsverzeichnisses kopieren Das UML-KLassendiagramm in Abbildung 6 zeigt die Struktur des gesamten Projektes und die Zusammenh nge der implementierten Klassen untereinander. Bei a einigen detaillierten Erl uterungen einzelner Funktionen werden Klassen bzw. a Methoden genannt, die diese in der Implementation umsetzen. Damit wird die zu Grunde liegende Technik mitbeschrieben.

25

Abbildung 6: UML-Klassendiagramm des VR-OP

26

6.1

Visualisierung

Zur Darstellung und Interaktion mit dem virtuellen Operationssaal ndet eine nicht immersive Visualisierung Verwendung, die in eine eigens daf r erstellte grau sche Ober che eingebettet ist. Das GUI-Fenster, das sich nach dem Starten der a Anwendung offnet, ist in Abbildung 7 zu sehen. Die Platzierung und Aufteilung der einzelnen Elemente ubernimmt die Klasse PanelManager. Das Fenster enth lt zwei unterschiedliche Sichten in die virtuelle Welt. Die Gr nde, die f r a u u die Verwendung von multiplen Sichten sprechen, sind Kapitel 5 zu entnehmen. Es reichen hier zwei statt der dort angesprochenen drei Blickrichtungen aus, da der Inhalt des Raumes nur in zwei Dimensionen transformiert werden kann. Der Kern, und somit das gr te Element der Benutzerschnittstelle, ist die Fl che o a zur Anzeige der Hauptsicht in das dreidimensionale virtuelle Szenario. Dieser Bereich bietet dem Anwender alle zur Verf gung stehenden M glichkeiten zur u o Erstellung, Betrachtung und Modikation von Raumkongurationen des VR-OP, die im folgenden Unterkapitel angesprochen werden. Wie in Abbildung 7 zu sehen, ist der initiale Zustand der virtuellen Welt ein First-Person-Blick in einen leeren Raum. Die betrachtende Kamera bendet sich dabei an einer Position, die der Augenh he eines realen Menschen nachempfunden ist und sich an der o Stirnseite des Raumes bendet. Aus welchen Teilen dieser Operationssaal besteht und wie umfassende Kongurationen von Objekten im Raum erzeugt werden k nnen, wird im Teil 6.2.1 beschrieben. o Auch im kleineren Nebenfenster in der rechten oberen Ecke des Interfaces ist der leere Raum zu sehen. In dieser Sicht ist die Position der Kamera einige Meter uber der Mitte des Raumes und der Blickwinkel ist so gew hlt, dass von oben a senkrecht durch die Decke in den Raum gesehen wird. Durch die Sicht aus der Vogelperspektive und auf Grund der Tatsache, dass sich alle Objekte immer auf dem Boden benden, sind auf dieser zweiten Fl che stets alle Objekte sichtbar. a Es wird von oben in den Saal hinein gesehen, obwohl die Sicht durch eine Fl che, a die die Decke des Raumes bildet, verdeckt sein sollte. Dasselbe gilt f r die Sicht u im Hauptfensterteil. Dort wird durch die Wand der Raumstirnseite hindurch geschaut. Realisiert wird dies durch Polygone mit durchsichtiger R ckansicht, u einer von OpenGL bekannten Eigenschaft. Die Fl chen bestehen aus einseitigen a Polygonen, die ausschlielich bei frontaler Ansicht dargestellt werden. Wo Vorne und wo Hinten bei diesen Polygonen ist, wird in Java3D durch die Richtung, in der die Eckpunkte der Fl che angegeben werden, festgelegt. Alle vier W nde, a a sowie Decke und Boden weisen diese Eigenschaft auf, um einen st ndigen Blick a ins Innere des Raums zu gew hrleisten, auch wenn die Kamera sich auerhalb des a Raums bendet. Schlielich ist nur der Inhalt des Raumes und nicht der auere 27

Abbildung 7: Das grasche Benutzerinterface nach dem Start der Anwendung

Anblick f r die vorliegende Anwendung von Interesse. u Bei den gew hlten Startpositionen der beiden Kameras ist nur in der Vogela perspektive zu erkennen, dass der Hintergrund der virtuellen Welt schwarz ist und der OP in der Luft zu schweben scheint. Die Farbe wurde so gew hlt, um die a Aufmerksamkeit des Benutzer nicht vom Wesentlichen, n mlich dem Rauminhalt, a abzulenken. Dies ist unter anderem auch ein Grund f r die Nichtmodellierung u der Welt um den Raum herum. Diese Umwelt m sste sich bei Ver nderungen u a des Raumes anpassen. Aber genau dies ist einer der gr ten Vorteile des in VR o simulierten OP. Es sind vielseitige Manipulationen bzw. Umgestaltungen des Raums m glich, ohne dass dabei Auswirkungen auf die umliegenden R ume o a bzw. das gesamte Geb ude bedacht werden m ssen. Bei Ver nderung der Ausa u a richtung oder Position von Gegenst nden im Innenraum sind jedoch jegliche a Wechselwirkungen mit anderen Objekten von groer Bedeutung.

28

Ebenfalls nur in der kleineren Sicht von oben ist ein kleiner, auf der Seite liegender, gelber Kegel als Avatar der Hauptkamera zu sehen. Zur Orientierung sind an diesem sowohl die Position, als auch die Ausrichtung, die der Blickrichtung der Kamera entspricht, leicht zu erkennen, ohne dass der Avatar stark auff llt a oder st rt. Das spitze Ende des Kegels zeigt in die Richtung, in die die Kamera o momentan sieht. Technisch wird die Darstellung mit den zwei Sichten durch die Verwendung von zwei Objekten der Klasse ViewPlatform mit je einem View umgesetzt. Diese lassen mehrere Blickpunkte mit unterschiedlichen Transformationen der Kamera in ein und derselben Szene zu. Die beiden verschiedenen Ansichtsrichtungen sind durch die Verkn pfung mit einzelnen Canvas3D-Objekten in die grasche u Ober che eingebunden. a Der restliche Teil im unteren rechten Bereich der Benutzerober che ist f r Funka u tionen gedacht, die im sp teren Verlauf des Projektes zug nglich sein werden. a a Wie von Standardanwendungen bekannt, enth lt die GUI zum Aufruf vieler a Funktionen eine mit der Klasse MyMenuBar realisierte Men leiste. Dort kann u die Anwendung wie gewohnt uber das Feld Exit im Men eintrag File beendet u werden. Neben diesem Befehl stehen dort die M glichkeiten zum Laden und o Speichern von Raumkongurationen zur Verf gung, deren Funktion in Abu schnitt 6.2.4 genauer beschrieben werden. Der Men eintrag Edit stellt weitere u Editierm glichkeiten bereit, deren einzelne Funktionsweisen in den folgenden o Unterkapiteln erl utert werden. a

6.2

Interaktion

In der virtuellen Umgebung stehen einige Mittel zur Interaktion mit dem VR-OP zur Verf gung. Der folgende verallgemeinerte Anwendungsfall zeigt den beispielu haften Ablauf der Bedienung nach dem Start der Applikation. Alle darin existierenden Funktionen sind in der aktuellen Version verf gbar und werden in den u weiteren Abschnitten n her beschrieben. a 1. Anpassen des Raums in L nge, H he und Breite an die gew nschte Gr e a o u o 2. Einblenden des Hilfsliniennetzes mit angemessenem Rasterma 3. Position zum Einf gen eines Objektes ausw hlen, durch Picken der Bodenu a che an der entsprechenden Stelle a 4. Objekt des gew nschten Typs aus der Liste ausw hlen und Eingabe best tiu a a gen

29

5. Position und Ausrichtung des Objekts bis zur gew nschten Konguration u modizieren 6. Wenn n tig, Kamera navigieren, um Fehlkongurationen zu vermeiden o oder verdeckte Bereiche sichtbar zu machen 7. Punkt 3 bis 6 wiederholen, bis alle gew nschten Objekte vorhanden sind u bzw. die gew nschte Raumkonguration erstellt ist u 8. Bestehende Raumkonguration speichern 9. Weitere Raumkongurationen durch Hinzuf gen/Entfernen bzw. Bewegen u von bestimmten Objekten erstellen und speichern Wie im Anwendungsfall zu sehen ist, stehen mit Navigation und Manipulation verschiedene Arten der Interaktion bereit. Nach dem Prinzip der Trennung technischer bzw. funktionaler Belange ist die Eingabe der unterschiedlichen Interaktionsweisen auf die beiden Standardeingabeger te verteilt. Die Navigation wird nur a durch Tastatureingabe geregelt (siehe 6.2.2) und unabh ngig davon die Manipulaa tion von Objekten durch Eingaben mit der Maus (siehe 6.2.3). Alle selektiven und manipulativen Interaktionsm glichkeiten sind sowohl im Haupt- also auch im Neo benfenster zug nglich, werden aber nur am Beispiel der Nutzung im Hauptfenster a vorgestellt. 6.2.1 Aufbau von Raumkongurationen

Wie bereits angesprochen existiert nach dem Start der Anwendung schon ein leerer Raum in der VR. Dieser Zustand ist nur vor bergehend, bis die zeitintensiven u Modellierungen aller angestrebten Gegenst nde des Operationssaals abgeschlosa sen sind. Dann wird initial eine minimale Raumkonguration vorhanden sein. Die Ausmae des sichtbaren OPs entsprechen denen des Saals in Kiel aus dem ersten Anwendungsszenario. Generell besteht die R umlichkeit des virtuellen Operationssaals immer aus vier a zueinander senkrecht stehenden W nden und einer Boden- sowie Decken che, a a die diese von unten bzw. oben zu einer quaderf rmigen Geometrie abschlieen. o Diese sechs Grenz chen des Raumes werden durch jeweils einen, in der Klasa se Room erzeugten QuadArray-Polygonzug dargestellt. Um den r umlichen a Eindruck zu verst rken und dem Nutzer eine gute Differenzierbarkeit zwischen a diesen Fl chen zu geben, wurden die Uberg nge zwischen diesen durch untera a schiedliche Farben der einzelnen Polygonz ge hervorgehoben. Die W nde stellen u a jedoch nur eine visuelle Abgrenzung dar, denn sie k nnen von Kamera und o Gegenst nden durchschritten werden. N heres dazu kann dem Abschnitt 6.2.3 a a entnommen werden, der das Thema Kollisionsbehandlung vertieft. 30

Die Gr e des VR-OP kann durch Eingabe stufenlos in beliebigem Mae in o allen drei Dimensionen ver ndert werden. Uber den Eintrag Edit in der Men leisa u te kann durch Auswahl von Resize Room... die Methode resizeRoom der Klasse Room aufgerufen werden, die die Ausmae auf die ubergebenen Werte setzt. Diese Werte f r L nge, Breite und H he werden daf r in Metern ins Textfeld u a o u des Dialogfensters eingegeben, das sich automatisch offnet. Alle drei Angaben sind in der genannten Reihenfolge als Dezimalwerte (Nachkommastellen durch einen Punkt getrennt) einzugeben und durch Leerstellen zu trennen (z.B. 9.5 6.8 2.5). Nach Best tigung der Eingabe wird die Gr e des angezeigten Saals dann a o automatisch angepasst. Die maximale im Nebenfenster anzeigbare Gr e eines o Raums betr gt 15m x 12m in der Grund che, da ein OP nur selten gr er ist. a a o Der wichtigste Aspekt der gesamten Anwendung ist die Erstellung von Raumkongurationen durch das Hinzuf gen von Rauminhalt. Dies kann auf zwei u unterschiedliche Arten geschehen. Durch kontextsensitives Einf gen eines Obu jektes an eine durch Picking bestimmte Stelle in der 3D-Szene oder durch Anwahl des Punktes Add Object... im Edit-Men . Die erste Variante selektiert u durch Bet tigung der rechten Maustaste einen Punkt auf der Boden che, an a a dem der gew nschte Gegenstand dann eingef gt wird. Diese Selektion durch u u Picking regelt die Klasse PickManager die einen MouseListener implementiert und dadurch auf MouseEvents wartet. Sie legt je ein Java3D eigenes PickCanvas uber die beiden Canvas3D des Haupt- und Nebenfensters. Die jeweiligen Schnittpunkte des Picking-Strahls mit Objekten werden uber die Methode pickAllSorted von PickCanvas ermittelt, die ein Array an PickResults zur ckliefert. Das erste Element im Array entspricht dem u vordersten Schnittpunkt. Dem PickResult kann durch Aufruf der Methode getIntersection ein Objekt der Klasse PickIntersection entnommen werden, dessen Methode getPointCoordinatesVW den genauen Schnittpunkt mit der Boden che liefert. Besonders zu beachten bei der Implea mentierung war die Tatsache, dass bei Lage der Kamera auerhalb des Raumes der vorderste Schnittpunkt stets mit einer Wand oder der Decken che vorliegt. a In diesen F llen ist der Schnittpunkt, der von Interesse ist, nicht der vorderste im a Array. F r die angewandte Selektierungsart m ssen bestimmte Capabilities u u (F higkeiten) f r das Picking bei den entsprechenden Geometrien und Knoten des a u Szenengraphs gesetzt sein. Diese werden ausschlielich f r das QuadArray, das u den Boden repr sentiert, beim Erzeugen des Raumes in der Klasse Room gesetzt. a Schnittpunktberechnungen mit den anderen Fl chen sind schlielich nicht n tig. a o Wenn eine Position auf dem Boden durch die beschriebene Weise ausgew hlt a wurde, offnet sich ein kleines Kontextfenster mit der Auswahlm glichkeit Add o Object...(siehe Abbildung 8). Nach dem Klick auf diese offnet sich ein Dia31

Abbildung 8: Screenshots: links nach Picking der Boden che, rechts nach Sea lektion eines Objekts

logfenster mit einer Liste zur Auswahl aller zum Einf gen bereit stehenden u Raumobjekte. Nach Wahl eines Gegenstandes und Best tigung der Eingabe, wird a das Objekt an der selektierten Position auf der Boden che dem Raum hinzua gef gt. u Die Informationen uber Geometrie und Aussehen der einzelnen Objekte benden sich nicht direkt im Java3D-Quellcode des Projektes, sondern werden aus VRMLDateien importiert. Diese wurden mit einer Modellierungssoftware erstellt und als VRML-Dateien gespeichert bzw. exportiert. Den Import in Java3D ubernimmt ein VRML-Loader aus dem Package com.sun.j3d.loaders.vrml97. Das Klassenpaket vrml97.jar stammt von der nicht mehr existenten Webseite http://www.vrml.org. Die Nachfolgeorganisation X3D Task Group des Web3D Consortium (http://www.web3d.org/x3d.html) bietet im Rahmen des Xj3D Projekts (http://www.xj3d.org) einen neuen VRML-Loader an. Da die Anbindung dessen mit Schwierigkeiten verbunden ist, wird auf den alteren und einfach nutzbaren Loader zur ckgegriffen, der alle Anforderungen erf llt und bereits u u in anderen Projekten des Instituts verwendet wird. Den Aufruf des Loaders und damit das Importieren der jeweiligen Modellszene ubernimmt die Klasse VRMLFileLoader. In der Methode importVRML der Klasse RoomObject wird das Einh ngen der vom Loader gelieferten BranchGroup, welche die a geladenene Geometrieinformation enth lt, in den Szenengraph durchgef hrt. Die a u abstrakte Klasse RoomObject, von der alle Objektklassen (z.B. Cart) erben, enth lt zudem alle weiteren Informationen und Eigenschaften des jeweiligen a Objekts.

32

Damit die farbigen Ober chen der VRML-Modelle auch in der Java3D-Umgea bung als solche dargestellt werden, muss eine virtuelle Beleuchtung vorhanden sein. Die Klasse SceneGraphManager kreiert in der Methode lightScene zwei Lichtquellen verschiedener Beleuchtungsarten und h ngt sie in den Szea negraphen ein. Eine vom Typ AmbientLight simuliert in alle Richtungen gestreutes Umgebungslicht und die andere vom Typ DirectionalLight entspricht in etwa einer weit entfernten Lichtquelle wie z.B. der Sonne. Falls ein Gegenstand f lschlicherweise eingef gt wurde oder in der aktuellen a u Konguration nicht mehr ben tigt wird, kann er wieder aus dem Raum ento fernt werden. Die n tige Selektion funktioniert wieder, analog zum Einf gen, o u uber Picking. Jedoch werden hier nicht Schnittpunkte mit der Boden che, a sondern mit den Objekten im Operationssaal erfasst. Dazu m ssen bestimmte u Picking-Capabilities gesetzt werden, was die Methode setPickingCapabilities in der Klasse RoomObjekt beim Importieren des Modells der jeweiligen Objekte ubernimmt. Da auch das Picking zum Entfernen mit der rechten Maustaste ausgef hrt wird, sind beide Picking-Varianten gleichzeitig u aktiv. Ob ein Objekt eingef gt oder weggenommen werden soll, ist nur davon u abh ngig, was selektiert wird. Bendet sich an der selektierten Stelle als vordersa tes Element der Boden, dann wird die Position des Bodens ausgew hlt. Ist das a vorderste Element der Teil eines Objektes, dann wird dieses ausgew hlt und kann a entfernt werden. Je nach Fall ist der entsprechende Eintrag im Kontextmen , das u sich in beiden F llen offnet, aktiv (schwarze Schrift) und der andere inaktiv (graue a Schrift). Der Punkt im Kontextmen zur Entfernung eines Gegenstandes tr gt die u a Bezeichnung Remove Object. Wird dieser nach dem Picking eines gew nschten u Raumobjektes ausgew hlt, so wird dem entsprechenden PickResult durch die a Methode getNode der dar berliegende Knoten des Szenengraphen entnommen. u Von diesem Knoten aus wird im Baum des Szenengraphen bis zur n chsten a BranchGroup aufgestiegen. Zum tats chlichen L schen des Teilbaums wird a o diese dann mit dem Aufruf detach aus dem Szenengraphen entnommen. Dazu sind die entsprechenden Capabilities beim Erzeugen der einzelnen Knoten gesetzt worden. Auerdem stehen zum Herausnehmen von Kongurationsgegenst nden auch zwei Eintr ge im Edit Men bereit. Die Auswahl des Eintrags a a u Remove All Objects hat das L schen aller Objekte aus dem Szenengraph und o somit aus dem virtuellen OP zur Folge, woraufhin der Raum wieder leer ist. In zuk nftigen Versionen ist geplant, dass der Saal nicht komplett geleert wird, u sondern nur alle selbst eingef gten Objekte entfernt werden. Somit kann der u initiale Zustand mit der minimalen Raumkonguration wieder hergestellt werden. Ein weiter Eintrag Remove All Objects Of Type... offnet ein Dialogfenster zur Wahl einer Objektklasse, dessen s mtliche Instanzen bei Best tigung der Eingaa a be aus dem VR-OP entfernt werden. Diese Funktionalit t hat im Szenengraph a 33

dieselben Auswirkungen wie die bisherige. Alle gemeinsam sind in der Klasse RoomManager implementiert. Durch mehrfaches Hinzuf gen bzw. Entfernen von Gegest nden kann so jeu a de beliebige Kombination erstellt werden. Ein gef llter Raum bringt oft den u Wunsch nach Navigation der virtuellen Kamera mit sich, um hinter Dinge sehen zu k nnen bzw. zum Einsch tzen von Abst nden n her an ein Objekt herantreten o a a a zu k nnen. o

6.2.2

Navigation im Raum

Aus Kapitel 5.2.1 ist die freie Kamerabewegung in virtuellen Welten bekannt. Im VR-OP setzt diese die Behavior erweiternde Klasse KeyBehavior um, die die M glichkeit bietet, eine TransformGroup auf Grund von Tastatureingabe o durch die Java3D-Szene zu bewegen. Grundlage des Quellcodes dieser Klasse ist die von [j3d.org] bezogene Implementation von Andrew AJ Cain (Swinburne University, Australia), die wiederum auf dem Code von Gary S. Moss (U. S. Army Research Laboratory) aufbaut. Der Quelltext wurde zur Anpassung leicht modiziert. Die folgende Tabelle f hrt alle m glichen Kamerabewegungsarten u o und die zum Ausf hren dieser Aktion entsprechenden Tastenkombinationen auf. u Tastenkombination hoch runter links rechts Alt + links Alt + rechts Strg + hoch Strg + runter Shift + hoch Shift + runter Shift + links Shift + rechts Shift + Alt + links Shift + Alt + rechts Shift + Strg + hoch Shift + Strg + runter ausgefuhrte Aktion vorw rts bewegen a r ckw rts bewegen u a nach links drehen nach rechts drehen nach links bewegen nach rechts bewegen nach oben bewegen nach unten bewegen schnell vorw rts bewegen a schnell r ckw rts bewegen u a weit nach links drehen weit nach rechts drehen schnell nach links bewegen schnell nach rechts bewegen schnell nach oben bewegen schnell nach unten bewegen 34

Die jeweilige Navigation wird schrittweise ausgef hrt. Die Stecke der einzelnen u Bewegungsschritte im virtuellen Raum betr gt je 0,3 Meter bzw. 0,6 Meter bei a schneller Bewegung. Das Drehen nach links und rechts entspricht der Rotation der Kamera um eine senkrecht auf der Boden che stehende Achse. Die Schritte a betragen hier /16 bzw. /8. Die Kameranavigation kann wie erw hnt an der a Bewegung des repr sentatierenden Avatars nachvollzogen werden. a 6.2.3 Manipulation von Objekten

Kern der VR-OP-Anwendung ist die Nachbildung von r umlichen Konguraa tionen der Ger te und Personen in einem realen Operationssaal. Dazu ist neben a dem Hinzuf gen und Entfernen von Raumbestandteilen auch deren Platzierung u und Orientierung im Saal die Hauptaufgabe. Dieser Aufgabe widmet sich die freie Beweglichkeit aller manipulierbarer Objekte. Die Raumobjekte mit dieser Eigenschaft k nnen selektiert und dann direkt manipuliert werden. Alle Objekte, o die diese in der Klasse RoomObjekt durch die boolean Variable movable gesetzte Eigenschaft nicht besitzen, werden ohne Manipulationsm glichkeit eino gef gt. Die Auswahl, ob ein bestimmtes Objekt beweglich sein soll oder nicht, u wird in der Liste des Add Object...-Dialogfensters beim Einf gen getroffen. u Als Interaktionsstil wurde die direkte Manipulation gew hlt, da sie in diesem a Fall das einfachste, effektivste und intuitivste Mittel zur Bedienung darstellt. Ihr muss, wie schon beschrieben, eine Selektion vorausgehen. Diese wird ebenfalls durch Picking des gew nschten Raumobjektes ausgef hrt. Hierf r wird, im Geu u u gensatz zum Einf gen/Entfernen-Picking, mit der linken oder mittleren Maustaste u die Auswahl bestimmt und diese Taste f r den Zeitraum der Bewegung gedr ckt u u gehalten. Es werden hier zwei Tasten ben tigt, da es zwei Manipulationsm glicho o keiten gibt: Die Translation zur Positionierung mit der linken Maustaste und Rotation zur Ausrichtung des Elementes mit der mittleren. Die Klassen MyPickTranslateBehavior und MyPickRotateBehavior, welche die Java3D-Klassen PickMouseBehavior bzw. PickTranslateBehavior erweitern und je ein MouseBehaviorCallback implementieren, erm glio chen dies. Nach Selektion eines Gegenstandes und Tastendruck zur Translation kann dieser im gesamten virtuellen Operationssaal durch Bewegen der Maus mit gedr ckter u linker Maustaste frei verschoben werden. Er wird dabei nur in zwei Dimensionen verschoben, so dass er stets auf der Boden che stehen bleibt. Es ist auch a m glich, Objekte durch andere Objekte oder die W nde durch zu schieben. o a Diese in der Realit t unm glichen und daher im VR-OP ungewollten Aktionen a o werden durch eine Kollisionserkennung, die im Folgenden n her erl utert wird, a a 35

Abbildung 9: Screenshots: links w hrend, rechts nach einer Kollision a

bemerkbar gemacht. Um die Bewegung der Raumbestandteile beim Verschieben der jeweils korrespondierenden Bewegung der Maus anzugleichen, d.h. damit der Gegenstand stets in die Richtung transformiert wird, die analog zur Bewegung der Maus in der Hand des Anwenders ist, wurde die Manipulation in Abh ngigkeit a mit der Kameraposition gesetzt. Auf diese Weise bewegt sich ein Objekt im Raum nach hinten, wenn die Maus vom Betrachter weg geschoben wird. Dies wird Reiz-Reaktions-Korrespondenz genannt und auch bei den anderen Translationsrichtungen eingehalten. Der Faktor, der dabei die St rke der Transformation a proportional zur Mausbewegung bestimmt, ist auf einen passenden Wert gesetzt. Dasselbe gilt f r den Faktor der Rotation, die die zweite Manipulationsart daru stellt. Sie wird durch Picking des gew nschten Objektes und Gedr ckthalten der u u mittleren Maustaste aktiviert. Viele dieser Eingabeger te, die zwei Tasten und ein a Scrollrad statt drei Tasten besitzen, bieten die Funktion der mittleren Maustaste durch Dr cken des Scrollrades oder Dr cken der Alt-Taste und linken Maustaste u u gleichzeitig an. Bei aktiver Rotationsm glichkeit wird das ausgew hlte Objekto a modell durch Schieben der Maus nach links oder rechts entsprechend um eine Achse rotiert, die senkrecht auf der Boden che steht und durch das Zentrum des a jeweiligen Objektes geht. Auch durch diese Interaktion kann es zu Kollisionen zwischen Geometrien des Rauminhalts untereinander oder mit dem Raum kommen. Solche unerw nschten u Uberschneidungen der Modelle werden von der Anwendung durch Einf rben der a kollidierenden Objekte mit roter Farbe deutlich gemacht. Abbildung 9 zeigt zwei solcher Situationen: Eine mit bestehender Kollision zwischen den beiden Tischen, die andere nach Behebung der Kollision. Es wird dabei stets die Farbe aller in eine Kollision verwickelten Raumobjekte ge ndert. Kollidiert ein Gegenstand a

36

jedoch mit einer Wand, wird die Farbe der Wand nicht gewechselt, sondern nur die des Gegenstandes. Dieser farblich auff llig gekennzeichnete Zustand der a Raumkonguration soll den Benutzer so uber die Kollision in Kenntnis setzten und auffordern, die Fehlkonguration durch entsprechende Translationen oder Rotationen zu beseitigen. Wird dies getan, wechselt die Farbe der Objekte wieder zur ck in die urspr ngliche Farbe. Der technische Hintergrund der rechenaufwenu u digen Kollisionserkennung ist in der Java3D API bereits enthalten. Die Klasse CollisionDetector macht davon Gebrauch, indem sie ein Behavior erweitert, das zum Aufwachen auf ein WakeupCriterion (bzw. Instanz der Subklassen WakeupOnCollisionEntry oder WakeupOnCollisionExit) wartet. Das System achtet dadurch f r alle Geometrieteile des Objektes auf Kolliu sionsbeginn oder -ende mit anderen Geometrien und ubergibt im gegebenen Fall das entsprechende WakeupCriterion. Dieses wird von Java3D automatisch beim jeweiligen Kollisionsereignis erzeugt. Geometrien eines Objekts k nnen o jedoch nur gepr ft werden, wenn ihre Capabilities zur Erkennung von u Kollision gesetzt sind. Dies geschieht gemeinsam mit dem Setzen der PickingCapabilities beim Import der Modelle. F r die vier Wand-Geometrien u werden diese einmalig bei ihrem Erzeugen gesetzt. Durch diese Implementation werden alle Kollisionen von im Raum bendlichen Objekten erkannt und dargestellt. So kann der Nutzer des VR-OP diese beheben und sicherstellen, dass nur solche Raumkongurationen erstellt werden, die auch in einem realen Operationssaal m glich sind. Dies ist von groer Bedeutung, da sonst der Bezug zur o Realit t verloren gehen w rde, welcher die Grundlage jeder effektiven Planung a u sein muss. Vermeidung von Kollisionen, so dass es nicht zu Uberschneidungen von Objekten kommen kann, ist kein Bestandteil von Java3D und aufw ndig zu a programmieren. Deshalb kann sie nicht im Umfang der Studienarbeit erarbeitet werden. Unterst tzung f r den Vergleich einer virtuell erstellten Raumkonguration mit u u einer realen bietet die Einblendung eines Gitternetzes oberhalb der Boden che a durch den Aufruf von Show Mesh... im Edit-Men der Men leiste. Dieses Netz u u dient durch die Gr enskala, die es darstellt, vor allem dem besseren Absch tzen o a von Abst nden, solange die geplante Funktion der Abstandsmessung zwischen a beliebigen Punkten im Raum noch nicht programmiert ist. In das Textfeld des sich beim Aufruf von Show Mesh... offnenden Dialogfensters muss ein Dezimalwert als Abstandseinheit zwischen den Linien des Gitternetzes eingegeben werden. Bei Eingabe des Werts 1.5wird z.B. ein Netz mit Linien im Abstand von eineinhalb Meter angezeigt, wie es in beiden Teilen der Abbildung 9 zu sehen ist. Es sind Werte zwischen 0.1 und 5.0 zugelassen. Wenn das Netz nicht mehr ben tigt wird, o kann es durch Wahl des Edit-Men Eintrages Hide Mesh wieder entfernt werden. u

37

Zusammengefasst bieten diese Interaktionswege umfassende Mittel, um unterschiedliche Raumkongurationen eines realen operativen Eingriffs nachzustellen. Durch Variation von Positionen des Saalinhaltes sind so eventuell neue, den Platz besser ausnutzende Szenarien zu nden. Planungen von zeitlichen Abl ufen a und damit der Wege bzw. Kongurationen, die Objekte im realen OP durchlaufen, k nnen ebenfalls durch schrittweise Erstellung r umlicher Anordnungen o a vollzogen werden. 6.2.4 Speichern und Laden von Raumkongurationen

Die Zusammenstellung eines der Realit t nachempfundenen virtuellen Operaa tionssaales mit seinem Inhalt ist auf Grund der Komplexit t dieses Vorganges a teilweise sehr zeitaufw ndig. Die investierte Arbeit w rde beim Beenden des VRa u OP verloren gehen, wenn die erstellte Raumkonguration nicht in irgendeiner Weise gespeichert wird, um zu einem sp teren Zeitpunkt wieder geladen werden a zu k nnen. Diese Funktionen sind uber Save Cong... bzw. Load Cong... im o File-Men zug nglich. In einem Standard-Dialogfenster wird dabei die Bestimu a mung der Datei angeboten, in die die Raumdaten geschrieben bzw. aus der die Raumdaten gelesen werden sollen. Als Datenformat wurde aus mehreren Gr nden XML gew hlt. Diese Metau a sprache ist ein universeller und weitverbreiteter Standard, der eine einfache und einheitliche Syntax aufweist, aber trotzdem die Darstellung von komplexen Datenstrukturen erm glicht. XML ist exibel erweiterbar und es wird eine Trennung o von Stuktur und Formatierung vorgenommen, die f r die vorliegende Anwendung u sinnvoll ist. Zudem existieren f r Java so genannte Parser zum komfortablen u Auslesen der Informationen aus XML-Dateien. Die VR-OP-Anwendung nutzt einen in der Java 2 Plattform integrierten SAXParser, der in der f r das Laden zust ndigen Methode loadConfig der u a Klasse RoomManager unter Verwendung von SAXParserFactory erzeugt wird. Der Vorteil dieses Parsers gegen ber anderen ist die schnelle und speicheru schonende serielle Verarbeitung. Der SAX-Parser ben tigt einen Handler, der o angibt, was beim Lesen der jeweiligen Elemente des Inhaltes ausgef hrt werden u soll. Diesen Handler implementiert die DefaultHandler erweiternde Klasse XmlParserHandler. Sie ruft die entsprechenden Methoden auf, die den Inhalt der eingelesenen Datei visualisieren. Die Strukturregeln der XML-Dateien stecken in einer so genannten DokumenttypDenitions-Datei, der cong.dtd. Diese gibt die in den XML-Dateien erlaubten Elemente, Attribute und Verschachtelungsm glichkeiten an. Abbildung 10 zeigt o eine Visualisierung des aktuellen Inhaltes der Datei cong.dtd. 38

Nach dieser richtet sich auch die Methode saveConfig von RoomManager beim Speichern einer Raumkonguration. Die gesamten Informationen des virtuellen Operationssaals werden dabei in eine Datei geschrieben. Von Raumgr e o und Kameraposition uber eine Liste aller Raumobjekte mit Eigenschaften und Transformation bis hin zu Sichtbarkeit und Faktor des Hilfsliniennetzes werden alle Aspekte aufgezeichnet. Den Speicherungsprozess ubernimmt der Java-eigene FileWriter, wobei der Quelltext so gestaltet wurde, dass die g ltige XML-Syntax u eingehalten wird. Die Verwendung von XML als Datenschnittstelle erm glicht o die einfache Umsetzung sp terer Modikationen der Datenstruktur in beliebigem a Mae. Ver nderungen und Erweiterungen der Dokumenttyp-Denition-Datei f r a u zuk nftig zu speichernde Aspekte sind problemlos durchzuf hren. u u

Abbildung 10: Visualisierung der XML-Struktur in der Dokumenttyp-DenitionsDatei cong.dtd

39

6.3

Ausblick

Den gesamten gew nschten Leistungsumfang umzusetzen, den man sich von u einem virtuellen Operatiossaal w nscht, ubersteigt den Umfang dieser Studienu arbeit. Die f r die Zukunft geplanten Leistungen stellt die folgende Aufz hlung u a zusammen. Im Anschluss daran werden Varianten zur Realisierung einiger Funktionen vorgestellt. Bereitstellung einer Funktion zur R ckg ngigmachung von durchgef hrten u a u Aktionen Visualisierung von abstrakten Objekten (z.B. Magnetfeld, R ntgenstraho lung) Einschr nkung der Objektebeweglichkeit auf Grund von Abh ngigkeiten a a (z.B. Kabel zwischen Objekten) Visualisierung bzw. Beachtung von Objektzusammenh ngen (z.B. funktioa nale Voraussetzungen) Animationen in der 3D-Szene zur Darstellung von Abl ufen bzw. r umlicha a zeitlichen Abh ngigkeiten zwischen Objekten a Abstandsmessung zwischen Objekten bzw. Raumbestandteilen im Dreidimensionalen Visualisierung von Objektzust nden (z.B. Sterilit t, Aktivit t) a a a Beweglichkeit spezieller Objektteile (z.B. OP-Tisch heben, senken und schwenken) Auswahlm glichkeit von unterschiedlichen Kamerapositionen o Objekte, die nicht auf dem Boden stehen, sondern an der Decke des Raums befestigt sind Realistischer wirkende Visualisierung durch Texturierung, aufw ndiger a modellierte Objekte, bessere Beleuchtung, Schattenwurf u. . a Kollisionsvermeidung beim Bewegen der Objekte Visualisierung von Daten ssen u

40

 Im VR-OP durchgef hrte Anderungen k nnen nur r ckg ngig gemacht werden, u o u a wenn intern alle Aktionen unter Verwendung eines Listen- oder Stapel-Datentyps mitprotokolliert werden. Bei Aufruf des Widerrufs wird die letzte Anderung aus diesem Zwischenspeicher gelesen und r ckg ngig gemacht. u a Es existieren im realen Operationssaal unsichtbare bzw. nicht dingliche Objekte, wie z.B. Magnetfelder und der Sichtbereich der Kamera eines Navigationssystems, die als abstrakte Objekte bezeichnet werden k nnen. Diese d rfen bei o u der Planung einer Raumkonguration keinesfalls auer Acht gelassen werden. Gerade bei der intraoperativen Nutzung eines MRT existiert im Raum ein sehr starkes Magnetfeld. Daher m ssen alle auf Magnetismus sensitiven Ger te in u a einem gewissen Abstand entfernt stehen. Dies ist ein Aspekt, der die Platzierung der Objekte grundlegend beeinusst. Die Darstellung von abstrakten Objekten mit semitransparenten Ober chen erm glicht die Sichtbarkeit dieser und damit a o die Einbeziehung in die Planung. Andere Elemente des Raumes w rden dennoch u nicht verdeckt. Ferner kann mit entsprechend kongurierter Kollisionserkennung die Einhaltung der Abst nde vom MRT-Ger t uberpr ft werden. a a u Abh ngigkeiten und andere Zusammenh nge zwischen Objekten sind weitea a re wichtige Gesichtspunkte, die beachtet werden m ssen. Beim Einf gen von u u Objekten, deren Anwendung die Existenz anderer Objekte voraussetzt, sollte das Vorhandensein der entsprechenden Objekte uberpr ft werden und diese u gegebenenfalls mit hinzugef gt werden, oder das Hinzuf gen zumindest vorgeu u schlagen werden. Es gibt neben diesen Nutzungsabh ngigkeiten auch r umlia a che Abh ngigkeiten zwischen Gegenst nden, z.B. auf Grund von Kabeln oder a a Schl uchen. Durch diese Verbindungen miteinander d rfen die Objekte nur eine a u maximale Entfernung voneinander haben. Die Beachtung dieser Tatsache und Implementation entsprechender Einschr nkungen bei der Objektmanipulation a ist nicht trivial. Eine m gliche L sung w re die Denition von Schnittstellen, o o a die jedes Objekt besitzt. Mit diesen Schnittstellen k nnten dann Objekte einer o Klasse Kabel verkn pft werden, die intern die Einschr nkungen (z.B. L nge u a a des Kabels) umsetzen. So w ren dann zwei oder mehr Raumelemente virtuell a durch ein Kabel verbunden. Eine Methode der Klasse Kabel w rde bei allen u Manipulationen abfragen, ob die Einschr nkungen weiterhin eingehalten werden. a Bei Nichteinhaltung kann dies uber die Schnittstellen an die verbundenen Gegenst nde berichtet werden. Eine Visualisierung eines solchen Ereignisses k nnte a o das Einf rben in einer bisher nicht verwendeten Farbe sein. a Bisher k nnen die Abst nde zwischen Gegenst nden nur mit Hilfe des Gitterneto a a zes von Hilfslinien gesch tzt bzw. angen hert werden. Eine konkrete Messung a a der Entfernungen ist aber w nschenswert. Dieser Aspekt kann auch mit in die u 41

Abh ngigkeiten zwischen Objekten einieen, die zuvor angesprochen wurden. a Zur Berechnung von Distanzen ist die eindeutige Bestimmung von mindestens zwei Punkten im dreidimensionalen Raum n tig. Die Selektion durch Picking o kann hierf r genutzt werden, um Objekte auszuw hlen, deren Abst nde gemessen u a a werden sollen. Eine m gliche Umsetzung von objektunabh ngiger Messung w re o a a das Einf gen kleiner Hilfsk rper wie z.B. von Kugeln, die wie andere Objekte u o frei bewegt werden k nnen, und deren Positionen zur Abstandsberechnung hero angezogen werden. Eine rein objektbezogene Distanzmessung w rde sich auch u im Zusammenhang mit der Klasse Kabel realisieren lassen. Schlielich muss dort sowieso f r die Einhaltung der Kabell nge der Abstand berechnet werden. u a Java3D bietet mit einem speziellen Behavior, der Interpolator-Klasse, die M glichkeit zur automatischen Animation von Szenengraphelementen. Von o PositionInterpolator uber RotationInterpolator bis hin zu Kombinationen mit Vorgabe eines Bewegungspfades stehen verschiedenste Klassen bereit. Die Eignung dieser zur Animation von Objektbewegungen ist zu pr fen. u In sp teren Versionen, mit Objekten, die an der Decke befestigt sind, muss a die Position der Kamera in der Sicht der Vogelperspektive an eine Stelle verlegt werden, die sich unterhalb der deckenbefestigten Ger te bendet und die a Projektion auf orthographisch gestellt werden. Damit wird der grundriss hnliche a Charakter dieser Ansicht erhalten. Weitere M glichkeiten sind das generelle o Unsichtbarmachen der entsprechenden Objekte in der zweiten Sicht, sowie das Ausblenden durch Clipping an der Near-Clipplane. Der Groteil aller Ger te in einem Operationssaal ist direkt oder indirekt in a die Prozesse der Erfassung, Verarbeitung und Anzeige von Patientendaten (Vitalfunktionen, Bilddaten etc.) involviert. Da diese Prozesse meist auf mehrere Ger te verteilt sind, m ssen die Daten zwischen diesen transportiert werden. a u Dadurch entstehen weitere Abh ngigkeiten zwischen Ger ten und somit Bestima a mungen f r Raumkongurationen. Um diese Gegebenheiten in die Planung eines u Operationsablaufen einbinden zu k nnen, ist die Visualisierung dieser n tig. o o Daten sse, die Aussagen dr ber machen, welche Informationen zwischen Beu u standteilen eines Systems ieen, werden im Allgemeinen mit gro chigen a zweidimensionalen Diagrammen visualisiert. Die direkte Ubertragung dieser in eine virtuelle 3D-Welt ist nicht sinnvoll. Im VR-OP k nnten Daten sse mit in o u die oben genannte Klasse Kabel eingebunden werden. Beispielsweise in einem gesondert aktivierbaren Anzeigemodus w re es m glich, die Verbindungen, uber a o die Daten ausgetauscht werden, durch 3D-Geraden von Objekt zu Objekt darzustellen. Diese entsprechen zwar auf Grund ihrer schwebenden Lage im Raum 42

nicht realen Kabeln, w rden aber den Zweck der Visualisierung der Konnektivit t u a erf llen. Verschiedene Linienarten oder Farben w rden dabei die Art der Daten, u u die ieen, ausdr cken. Die Richtung des Datenusses k nnte eine Pfeilspitze an u o einem Ende der Geraden aufzeigen. Es gilt dabei zu uberlegen, welche Punkte von Objekten sich gut als Ansatzpunkt f r diese Geraden eignen. u

43

Fazit

Mit dem virtuellen Operationssaal liegt dem Nutzer eine interaktive DesktopVR-Anwendung zur Planung von ger teabh nigen Prozessen im OP w hrend a a a chirurgischer Eingriffe vor. Die umfassende Recherche zu Beginn dieser Arbeit f hrte zu einer Anforu derungsanalyse, welche die Basis f r eine z gige Implementationsphase war. u u Die Realisierung von Picking und Kollisionserkennung stellten zeitaufw ndige a H rden dar. W hrend des gesamten Erstellungsprozesses wurde regelm iger u a a Kontakt zu den Anwendern aufrechterhalten, um m glichst nutzerorientiert zu o arbeiten. Die Entscheidung zur Nutzung von Java3D als Entwicklungsplattform kann nahezu ausnahmslos als positiv bewertet werden. Bis auf sehr seltene und scheinbar hardwareabh ngige Anzeigefehler, wie z.B. fehlende Wand chen nach Ver ndea a a rung der Raumgr e, sind keine Makel aufgetreten. Selbst die Java3D eigene o Kollisionserkennung ist bis auf das vereinzelte Nichterkennen oder das f lscha liche Bestehenbleiben von Kollisionen tauglich. Diese Einzelf lle beeinussen a die Zweckm igkeit der Software jedoch nicht. Die Programmierung mit Java3D a ist im Allgemeinen komfortabel, jedoch l sst die Dokumentation und Durcha schaubarkeit der API an manchen Stellen zu w nschen ubrig. In Hinsicht auf u zuk nftige Erweiterungen sind besonders mit Java als Basis bisher keine Grenzen u durch die Programmierschnittstelle in Sicht. Bei Nutzung des VR-OP auf Rechnern mit unterschiedlicher Hardware hat es sich als exible Applikation mit geringen Anforderungen gezeigt. Auch auf Computern, die nicht die neueste Grakhardware und st rkste Rechenleistung a besitzen, kann mit der Anwendung angemessen gearbeitet werden. Die aktuelle Version stellt die Grundlage der Visualisierung und des Funktionsumfangs dar. Der institutsinternen Nutzung im Rahmen von verschiedenen Projekten steht bis auf eventuelle Anpassung oder zus tzliche Objektmodellierungen nichts im a Wege. Bei einem Projekttreffen im Rahmen des Gemeinschaftsprojektes mit der Localite GmbH und der Neurochirurgie des Universit tsklinikums Kiel zeigten a die Projektpartner groes Interesse am VR-OP. Operationsszenarien, die keine F lle an modellierten Ger ten voraussetzen, u a sind bereits simulier- und planbar. F r die Ber cksichtigung komplexerer Zusamu u menh nge zwischen Objekten und um detailierte Planungen aufstellen zu k nnen, a o sind jedoch Erweiterungen n tig. Der Ausbau des VR-OP in diese Richtungen o ist in Aussicht, da die Arbeit an der Software nicht mit der vorliegenden Studienarbeit beendet wird. Visualisierung von abstrakten Objekten und Daten ssen, u 44

Abstandsmessung und die Konstruktion weiterer Objektemodelle werden dabei die Hauptaufgaben sein. Die Zusammenarbeit mit dem Forschungsbereich Life Science Informatik des Fraunhofer-Instituts f r Angewandte Informationstechnik verlief sehr erfreulich. u Regelm iger Kontakt, gekoppelt mit Unterst tzung und konstruktiver Kritik trug a u dazu bei, dass der VR-OP die analysierten Anforderungen erf llt. u

45

Literatur
[preim] [raskin] [barril] [brown] [selman] [rowe] [awaron] [mantra] [cvrml] [java] Preim, Bernhard: Entwicklung interaktiver Systeme. Berlin, Heidelberg: Springer Verlag, 1999 Raskin, Jef: Das intelligente Interface. M nchen: Addison-Wesley, 2001 u Barrilleaux, Jon: 3D User Interfaces with Java 3D. Greenwich: Manning Publications Co., 2000 Brown, Kirk; Petersen, Daniel: Ready-to-Run Java 3D. New York: Wiley, 1999 Selman, Daniel: Java 3D Programming. Greenwich: Manning Publications Co., 2002 Rowe, Glenn W.: Computer Graphics with Java. Basingstoke: Palgrave, 2001 Homepage der Firma Awaron AG http://www.awaron.com/de/index.htm Mantra4D Produkt-Homepage der Firma Criterion Software Ltd. http://www.mantra4d.com Konno, Satoshi: CyberVRML97 for Java. http://www.cybergarage.org/vrml/cv97/cv97java/index.html The Source for Java Technology. http://java.sun.com, Sun Microsystems Inc., 2002

[j3dspec] Sowizral, Henry; Rushforth, Kevin; Deering, Michael: The Java3D API Specication, Version1.3. http://java.sun.com/products/java-media/3D/forDevelopers/J3D 1 3 API/ j3dguide/index.html, Sun Microsystems Inc., 2002 [j3dtut] Bouvier, Dennis J.: Getting Started with the Java3D API, A Tutorial for Beginners. http://developer.java.sun.com/developer/onlineTraining/java3d/index.html, Sun Microsystems Inc., 1999 The Java 3D Community Site. Hosted by Yumetech Inc. http://www.j3d.org

[j3d.org]

46