Interaktive, dynamische 3D-Karten zur Kommunikation ... · Interaktive, dynamische 3D-Karten zur...

Interaktive, dynamische 3D-Karten zur Kommunikation

raumbezogener Information

Dissertation

zur Erlangung des akademischen Grades Doktor der Naturwissenschaften

(Dr. rer. nat.) in der Wissenschaftsdisziplin Informatik

eingereicht an der Mathematisch-Naturwissenschaftlichen Fakultät

der Universität Potsdam

von Oliver Patrick Kersting

geboren am 11.12.1972 in Münster

Potsdam, 9. Dezember 2002

i

VORWORT

Raumbezogene Informationen stehen im Mittelpunkt vieler kommerzieller und wissenschaftlicher Anwendungsfelder, wie zum Beispiel dem Bereich der mobilen Kommunikation, des Transports und Verkehrs, der Energieversorgung, der Geographie oder der Kartographie. Die technischen Fortschritte in der Datenerfassung, wie zum Beispiel durch Satellitenbeobachtung oder Laser-Scanning, erlauben die Sammlung immer größerer Mengen an raumbezogenen Daten in zuneh-mend hoher Qualität und Geschwindigkeit. Um diese Flut an raumbezogenen Daten zu bewältigen und aus ihnen Informationen zu gewinnen bedarf es besonderer Verfahren und Strategien zur ihrer Verarbeitung und Visualisierung. Mit Visualisierung wird versucht, Einsicht in Daten, in ihre Struktur und in ihre Zusammenhänge zu erhalten. Hierbei dient Visualisierung als Instrument zur Präsentation, Exploration und Analyse von meist hochdimensionalen Datenräumen. Die computergestützte Visualisierung zieht in besonderem Maße von dem rapiden technischen Fortschritt der Computergraphik-Hardware Nutzen. Jedoch müssen für einzelne Anwendungsfel-der, wie z. B. der Geovisualisierung, Verfahren, Werkzeuge und Systeme entwickelt werden, die den spezifischen Merkmalen des jeweiligen Gebiets Rechnung tragen, um dieses Potential voll auszuschöpfen. Als adäquate Medien zur Kommunikation räumlicher Informationen dienen seit Jahrhunderten kartographische Darstellungen, allen voran die Karte. Sie hat sich in den vergangenen Jahren vom statischen Medium hin zum interaktiven, dynamischen Medium entwickelt, ebenfalls durch den rasanten technischen Fortschritt, wie z. B. im Bereich der Geoinformationssysteme. Durch die Möglichkeit Informationsdichten und Darstellungsformen dynamisch an die jeweiligen Nutzergruppen und Aufgabenanforderungen anzupassen, ergeben sich neue Formen der Kommunikation raumbezogener Information. Häufig werden dabei virtuelle, dreidimensionale Umgebungen zur Darstellung räumlicher Information genutzt, die in vielen Anwendungsfällen dem Menschen vertrauter sind als orthographisch zweidimensionale Darstellungen, weil sie der natürlichen Sehgewohnheit des Menschen näher kommen und bezüglich Raum und Zeit größere Freiheitsgrade aufweisen. In dieser Arbeit werden Konzepte für 3D-Karten sowie Entwurf und Implementierung eines 3D-Kartensystems vorgestellt. 3D-Karten repräsentieren ein interaktives, dynamisches Medium zur Kommunikation raumbezogener Information, das auf interaktive dreidimensionaler Visualisierung beruht. Konkret beschreibt diese Arbeit das zugrundeliegende Softwaresystem, ausgewählte Vi-sualisierungsstrategien und -verfahren sowie ausgewählte Anwendungsbeispiele für 3D-Karten. Zur Implementierung des 3D-Kartensystems wurde die Systemprogrammiersprache C++ und die Skriptsprache Tcl verwendet. Zur Beschreibung der statischen, dynamischen und physischen As-pekte des entwickelten Softwaresystems wird die Unified Modeling Language eingesetzt. Als Schnittstelle zur Graphikhardware diente das Renderingsystem OpenGL. Die zum Verständnis dieser Arbeit notwendigen Grundkenntnisse der 3D-Computergraphik wurden kurz gefasst in die-se Arbeit aufgenommen. Für eine ausführliche Einführung in Konzepte der 3D-Computergraphik

ii

sei auf Foley et al. [29] verwiesen. Englische Fachbegriffe wurden - soweit sinnvoll möglich – in die deutsche Sprache übersetzt. Wenn keine adäquate Übersetzung möglich erschien, wurden sie beschrieben und im Original verwendet.

An dieser Stelle möchte ich mich bei Prof. Dr. Jürgen Döllner bedanken, der durch seine stetige Förderung und Kritik zum Gelingen dieser Arbeit wesentlich beigetragen hat. Danken möchte ich auch Prof. Dr. Hartmut Asche und Prof. Dr. Guido Wirtz dafür, dass sie mir als Ratgeber zur Seite standen und sich als Gutachter zur Verfügung gestellt haben. In besonderem Maße möchte ich mich bei Dr. Konstantin Baumann für die fruchtbare Zusam-menarbeit bei der Entwicklung des LandExplorer-Systems bedanken. Außerdem möchte ich mei-nen Kollegen Henrik Buchholz, Florian Kirsch und Marc Nienhaus für die unzähligen Diskussio-nen und motivierenden Gespräche danken. Darüber hinaus möchte ich mich bei Herrn Axel Woldenga von der Wasser- und Schifffahrtsdi-rektion Nordwest und bei Herrn Dr. Wolf Mende, Herrn Stefan Hoffrichter und Herrn Eckhard Oppermann von der T-Mobile für die Kooperation im Rahmen der Anwendungen des 3D-Kartensystems bedanken. Abschließend aber nicht zuletzt danke ich meinen Eltern und meiner Freundin Jana Blits, die durch ihre permanente Förderung und den mir gebotenen Rückhalt diese Arbeit mit ermöglicht haben.

iii

INHALTSVERZEICHNIS

1. KARTENBASIERTE VISUALISIERUNG................................................................. 1 1.1 Grundlagen der Computergraphik.................................................................................2 1.2 Grundlagen der Kartographie .......................................................................................7 1.3 Aufbau der Arbeit ......................................................................................................11

2. MODELLIERUNG INTERAKTIVER, DYNAMISCHER 3D-KARTEN ..................13 2.1 Anforderungen an 3D-Karten .....................................................................................14 2.2 Aufbau des 3D-Kartensystems ...................................................................................15 2.3 Visuelle 3D-Kartenbauelemente..................................................................................16 2.4 Strukturelle 3D-Kartenbauelemente ............................................................................24 2.5 Verhaltengebende 3D-Kartenbauelemente ...................................................................25 2.6 Zusammenfassung......................................................................................................28

3. VISUALISIERUNG VON DIGITALEN GELÄNDEMODELLEN............................31 3.1 Rendering von TIN- und Gitterdaten...........................................................................32 3.2 Level-of-Detail-Modellierung .....................................................................................33 3.3 Anforderungen im Kontext von 3D-Karten..................................................................33 3.4 Verwandte Arbeiten zur Geländemodellierung.............................................................34 3.5 3D-Karten Geländemodell-Geometrie .........................................................................37 3.6 Zusammenfassung......................................................................................................40

4. VISUALISIERUNG VON RASTERDATEN.............................................................41 4.1 Texturierungstechnik..................................................................................................42 4.2 Anforderungen im Kontext von 3D-Karten..................................................................44 4.3 Verwandte Arbeiten zur Geländemodell-Texturierung .................................................44 4.4 3D-Karten Geländemodell-Texturierung .....................................................................46 4.5 Darstellung dynamischer Rasterdaten .........................................................................51 4.6 Zusammenfassung......................................................................................................52

iv

5. VISUALISIERUNG VON VEKTORDATEN............................................................55 5.1 Darstellung von Vektordaten in 3D.............................................................................56 5.2 Anforderungen im Kontext von 3D-Karten..................................................................57 5.3 Verwandte Arbeiten zur Darstellung von Vektordaten .................................................58 5.4 Hardwareunterstützte Rasterisierung von Vektordaten ................................................59 5.5 Interaktion mit Vektordaten ........................................................................................65 5.6 Erweiterte Gestaltungsmöglichkeiten...........................................................................66 5.7 Zusammenfassung......................................................................................................67

6. ORIENTIERUNG UND NAVIGATION ...................................................................69 6.1 Anforderungen im Kontext von 3D-Karten..................................................................70 6.2 Verwandte Arbeiten zur Orientierung und Navigation .................................................70 6.3 Virtuelle Kamera........................................................................................................71 6.4 Orientierungswerkzeuge .............................................................................................72 6.5 Navigationswerkzeuge................................................................................................74 6.6 Dynamischer Entwurf des Karteninhalts .....................................................................77 6.7 Zusammenfassung......................................................................................................79

7. KONFIGURATION VON 3D-KARTEN...................................................................81 7.1 Anforderungen im Kontext von 3D-Karten..................................................................81 7.2 Verwandte Arbeiten zur C++-Interpreteranbindung.....................................................83 7.3 Technik der verwendeten Interpreteranbindung............................................................84 7.4 Skriptbeispiele ...........................................................................................................94 7.5 Zusammenfassung......................................................................................................96

8. ANWENDUNGSBEISPIELE ....................................................................................97 8.1 Visualisierung hydrographischer Daten.......................................................................97 8.2 Interaktive Visualisierung von Funknetzen..................................................................99

9. ZUSAMMENFASSUNG UND AUSBLICK............................................................103

LITERATUR ......................................................................................................................105

1

Kapitel 1 KARTENBASIERTE VISUALISIERUNG

Karten dienen zur Kommunikation räumlicher Information. Die der Karte zugrundeliegenden Konzepte stammen aus unterschiedlichen Disziplinen, insbesondere aus der Kartographie im Sin-ne einer kartographischen Ausdrucksform, der Mathematik in Form der Abbildung und der Psy-chologie in Form der kognitiven Karten. Im Kontext der Geoinformatik wird der Begriff Karte von Hake [37] beschrieben als „maßgebundenes und strukturiertes Modell räumlicher Bezüge“. Über Jahrhunderte hinweg diente die Karte als Datenspeicher mit sichtbarer Topologie, das heißt sie war Anzeigemedium und Datenhaltung zugleich. Diese Eigenschaft ist in den vergangenen Jahrzehnten zunehmend durch den Einzug von Geoinformationssystemen (GIS) in den Hinter-grund geraten. Zur Darstellung von räumlichen Informationen werden heute deshalb immer häu-figer digitale Ausgabegeräte genutzt (z. B. Monitor, Drucker, Plotter). Die Erzeugung einer konkreten Karte benötigt heute nicht mehr Wochen oder Monate, sondern dank digitaler Technik nur noch Bruchteile von Sekunden. Karten verwandeln sich dadurch von einem statischen Medium in ein dynamisches Medium. Als Folge muss eine einzelne Karte nicht mehr ein Höchstmaß an räumlicher Information für eine große Nutzergruppe optimal vermitteln (single optimal map), sondern kann nutzer- und aufgabenspezifisch aufgebaut werden. In der Kartographie wurden Strategien und Verfahren entwickelt, die die Vermittlung des Karten-inhalts optimieren: Regeln zur Farbgebung, für Zeichenstile, zur Symbolwahl oder zur Ausrich-tung von Textmarkierungen wurden perfektioniert und fixiert. In den vergangenen Jahren trat die Computergraphik durch die rapide Entwicklung der Graphikhardware in den Bereich der Karto-graphie vor und führte dank der Echtzeitfähigkeit der Graphik zu neuen Betrachtungsweisen. Die Karte dient dabei als Metapher für die interaktive, dynamische Visualisierung von räumlicher Information. Die Regeln der klassischen Kartographie bilden einen profunden Ausgangspunkt für die Handhabung und Gestaltung dieses dynamischen Mediums, wenngleich auch neue Regeln erforderlich sind, um die neuen Möglichkeiten zu erschließen. In dem Spannungsfeld zwischen der klassischen Kartographie, der innovationsfreudigen Compu-tergraphik und dem Software Engineering versucht diese Arbeit einen Beitrag für die Wissen-

1.1 Grundlagen der Computergraphik

2

schaft zu leisten. Es wird ein Konzept für interaktive, dynamische 3D-Karten, die Software-Architektur für ein 3D-Kartensystem, ausgewählte darin integrierte Visualisierungsstrategien für raumbezogene Informationen und damit mögliche Anwendungen vorgestellt.

1.1 Grundlagen der Computergraphik Die Computergraphik befasst sich mit computerunterstützten Methoden zur Generierung (Image Synthesis), zur Verarbeitung (Image Processing) und zur Analyse von Bildern (Image Analysis). Die Hauptaufgaben, die die Bildgenerierung leisten muss, ist die Abbildung eines computergra-phischen Modells, das aus geometrischen Objekten und graphischen Attributen komponiert ist, zu einem zweidimensionalen rasterisierten Bild. Je nach Ausgabetechnik wird ein einzelnes Bild (monoskopische Ausgabe), zwei Bilder aus verschiedenen Blickwinkeln (stereoskopische Ausga-be) oder eine Vielzahl von Bildern aus unterschiedlichen Blickwinkeln (Ausgaben für Simulatoren im Bereich der Virtuellen Realität) benötigt. Zu den konkreten Aufgaben computergraphischer Systeme zählen die Unterstützung geometri-scher Modellierung, die hierarchische Modellierung von Szenen und das Rendering, wobei dort insbesondere die Beleuchtung, die Texturierung und die Schattierung von Szenen und ihren Ob-jekten von besonderer Bedeutung sind. Im Kontext von Computergraphik fallen auch die Gebiete Animation, Interaktion, Virtual Reality, Augmented Reality und Visualisierung. Aufgrund der immer komplexer werdenden computergra-phischen Systeme muss Computergraphik mehr und mehr Methoden des Software Engineering einsetzen, um diese Komplexität zu bewältigen.

1.1.1 Rendering Der Begriff Rendering bezeichnet in der Computergraphik zum einen den Prozess der Bildsynthe-se und zum anderen auch Bildsyntheseverfahren. Der Begriff wird aber weiter gefasst. Rendering ist abgeleitet von dem lateinischen Wort reddere und bedeutete „umsetzten“, „übersetzen“ oder „übertragen“. Im Bezug auf Computergraphik kann mit Rendering die Übertragung eines Modells in ein Zielmedium oder mehrere Zielmedien bezeichnet werden. Voraussetzung für interaktive Computergraphik ist das Echtzeit-Rendering. Echzeit-Rendering-Verfahren erlauben die mehrfache Erzeugung eines synthetischen Bildes pro Sekunde. Dadurch können Veränderungen an einer Szene unmittelbar visuell reflektiert und somit z. B. direkt an die Interaktion des Nutzers gebunden werden. Um die hohe Geschwindigkeit erreichen zu können, ist die Unterstützung durch die Graphikhardware eine wichtige Voraussetzung. Die am weitesten verbreiteten Echtzeit-Renderingsysteme sind der plattformübergreifende Standard OpenGL [95] und das von Microsoft entwickelte Direct3D [5]. Um die hohe Geschwindigkeit erreichen zu kön-nen, werden in den Renderingsystemen z. B. ein vereinfachtes Beleuchtungsmodell verwendet und auf globale Lichtreflexion und Schattenberechnung verzichtet; Renderingsysteme, die nicht in Echtzeit arbeiten, wie z. B. das Ray-Tracing-System PovRay, approximieren zu einem stärkeren Maße physikalische Gesetze der Beleuchtung und Schattierung. In Echtzeit-Renderingsystemen werden überwiegend polygonale geometrische Primitive wie z. B. Punkte, Linien, und Dreiecke unterstützt, die durch Eckpunkte, Eckennormalen, Eckenfarben und Texturkoordinaten definiert und beim Rendering in das Zielmedium, i.d.R. in ein Rasterbild, transformiert und abgebildet werden. Die unterschiedlichen Stufen des Rendering werden durch die Renderingpipeline beschrieben (Möller und Haines [66]). Konzeptionell besteht die Renderingpipeline in Echzeit-Rendering-Anwendungen aus drei Stufen: der Anwendungsstufe, der Geometriestufe und der Rasterisierungsstufe. Jede dieser Stufen kann

Kapitel 1 - Kartenbasierte Visualisierung

3

wiederum als Pipeline aufgefasst werden (Abbildung 1). Einzelne Abschnitte dieser Pipelines können partiell parallelisiert sein, um höhere Leistung zu erzielen.

Anwendungsstufe In der Anwendungsstufe wird das computergraphische Modell einer Szene, z. B. interaktiv durch den Anwendungsentwickler, modelliert. Zu den Aufgaben dieser Stufe zählen die algorithmische Aufbereitung von Daten, die Definition zeitlicher Abfolgen, die Behandlung von Ereignissen aus und die Rückmeldung von Zuständen an Benutzungsschnittstellen. Am Ende der Anwendungsstu-fe liegt eine Menge von graphischen Primitiven (z. B. Punkte, Linien, Dreiecke) und Attributen (z. B. Farbe, Texturkoordinate, Materialeigenschaften) vor, die zur graphischen Darstellung an die Geometriestufe weitergeleitet werden.

Geometriestufe Die Geometriestufe ist für geometrische Transformationen und Beleuchtung von graphischen Primitiven zuständig. Abbildung 2 zeigt konzeptionell die Operationen, die in der Geometriestufe stattfinden. Da im Fall polygonaler Primitive diese Operationen pro Eckpunkt ausgeführt werden, wird auch von Per-Vertex-Operationen gesprochen. Die Primitive sind im Allgemeinen in unter-schiedlichen Koordinatensystemen spezifiziert, da sie in der Anwendungsstufe meist mittels hie-rarchischer Szenenbeschreibungen spezifiziert werden. Die Aufgabe der Model-View-Transformation ist die Vereinheitlichung dieser unterschiedlichen Koordinatensysteme in das Kamerakoordinatensystem. Die Transformation erfolgt für jeden ein-zelnen Eckpunkt eines Primitives. Die Beleuchtungsstufe berechnet auf der Grundlage eines Beleuchtungsmodells Lichtintensitäts-werte und daraus resultierend Farbwerte. Die Berechnung berücksichtigt die in der Szene spezifi-zierten Lichtquellen, die Materialeigenschaften und weitere Attribute, die eine Auswirkung auf die Beleuchtung besitzen. Die Genauigkeit der Beleuchtung hängt dabei von Dichte der Eckpunk-te ab, da im Falle polygonaler Primitive die Beleuchtungsberechnung pro Eckpunkt erfolgt. Das Kamerakoordinatensystem wird in der Projektionsstufe in das kanonische Sichtvolumen transformiert. Dies kann über eine orthographische oder eine perspektivische Projektion erfolgen. Bei der orthographischen Projektion bleiben parallele Linien parallel und Winkel erhalten. Bei der perspektivische Projektion wird die Größe von Objekten in Abhängigkeit von ihrer Kamera-distanz so transformiert, dass entfernte Objekte klein und nahe Objekte groß skaliert werden; Winkel werden im Allgemeinen nicht erhalten. Ein projiziertes Primitiv wird in der Clipping-Stufe auf Schnitt mit dem Einheitswürfel überprüft: Liegt es innerhalb, wird es unverändert weitergeleitet, liegt es außerhalb, wird es nicht weiterge-leitet, schneidet es den Einheitswürfel, wird es „zurechgeschnitten“. In der Screen-Mapping-Stufe werden die verbleibenden Primitive in das Bildschirmkoordinatensystem transformiert.

Rasterisierungsstufe In der Rasterisierungsstufe werden die graphischen Primitive, deren Eckpunkte Tiefenwerte, Far-ben und ggf. Texturkoordinaten besitzen, in der zweidimensionalen Zeichenfläche rasterisiert. Die

Anwendung Geometrie Rasterisierung

Abbildung 1: Renderingpipeline unterteilt in Anwendungs-, Geometrie- und Rasterisierungsstufe.


4

Zeichenfläche besitzt einen zugeordneten Framebuffer, der Rasterdaten speichert und im Allge-meinen in Farb-, Tiefen- und Stencil-Puffer aufgeteilt wird. Jedes Pixel (picture element) des Rasters kann somit Farbwerte (kodiert als RGB-Farbe mit Transparenz), einen Tiefenwert und einen Wert im Stencil-Puffer enthalten. Rasterisierungsalgorithmen zerlegen jedes Primitiv in eine Menge von Fragmenten, deren zugeordnete graphische Attribute meist durch Interpolation der an den Ecken berechneten Beleuchtungswerte und weiterer Eckattribute bestimmt werden. Als Stan-dardverfahren zur Interpolation der Beleuchtungsintensitäten wird meist das Gouraud Shading [32] eingesetzt. In der Rasterisierungsstufe kommen Per-Fragment-Operationen zum Einsatz, die i.d.R. vollstän-dig in Hardware implementiert sind. Eine grundlegende Per-Fragment-Operation ist der Tiefen-test. Hierbei wird zu einem Fragment geprüft, ob es bezüglich der bislang rasterisierten Primitive sichtbar ist. Dazu wird sein Tiefenwert mit dem Wert im Tiefenpuffer verglichen. Liegt das Fragment näher zur Kamera, dann wird es gezeichnet, sonst wird es verworfen (Z-Buffer-Algorithmus von Catmull [16]). Durch den Einsatz der Texturierung können ein-, zwei- oder dreidimensionale Rasterdaten pixel-präzise auf geometrische Primitive projiziert werden. Unterstützt die zugrundeliegende Graphik-hardware Multitexturing, können sogar mehrere Rasterbilder gleichzeitig auf ein Primitiv proji-ziert werden. Die Lage der Rasterdaten wird über Texturkoordinaten pro Eckpunkt, die Projekti-on über eine Texturtransformationmatrix spezifiziert (Kapitel 5). Am Ende der Rasterisie-rungsstufe entsteht im Colorbuffer ein Rasterbild der projizierten 3D-Szene der Anwendungsstu-fe. In heutiger computergraphischer Hardware sind große Teile der Geometrie- und Rasterisie-rungsstufe der Renderingpipeline enthalten. Dadurch ist die Komplexität der Graphikprozessoren enorm gestiegen (GeForce-4 Graphikprozessor ca. 63 Millionen, zum Vergleich Intel Pentium 4 ca. 55 Millionen Transistoren). Komplexe 3D-Szenen können dadurch ohne starke Belastung des Hauptprozessors dargestellt werden. Derzeitige Entwicklung ermöglichen zunehmend die Konfi-guration und die Programmierung von Teilen der auf der Hardware befindlichen Geometrie- und Rasterisierungsteilstufen; diese Entwicklungen sind unter dem Schlagwort „Programmierbare Shader“ bekannt.

1.1.2 Visualisierung Der Begriff Visualisierung kommt aus dem Lateinischen und bedeutet „optisch darstellen“. Die ursprüngliche Bedeutung wird heute im wissenschaftlichen Kontext erweitert durch „Einsicht ge-winnen“. Schumann und Müller [78] definieren Visualisierung folgendermaßen:

Die wissenschaftliche Visualisierung hat die Aufgabe, geeignete visuelle Reprä-sentationen einer gegebenen Datenmenge zu erzeugen, um damit eine effektive Auswertung zu ermöglichen.

Es soll die Analyse, das Verständnis und die Kommunikation von Modellen, Konzepten und Da-ten erleichtert werden. Nicht nur das Sehen, sondern das Erkennen, Verstehen und Bewerten ste-hen im Vordergrund.

Model+View Transformation

Beleuchtung Projektion Clipping Screen Mapping

Abbildung 2: Detaillierte Unterteilung der Geometriestufe in funktionale Stufen


5

Visualisierung dient insbesondere der explorativen Analyse, der konfirmativen Analyse und der Präsentation. Bei der explorativen Analyse existieren noch keine Hypothesen über die vorhande-nen Daten, ihre Struktur und Eigenschaften. Ausgangsbasis für die Darstellung sind die „rohen“ Daten. In dieser Phase findet im Allgemeinen eine interaktive, oft ungerichtete Suche nach Infor-mationen und Strukturen statt. Es wird eine Darstellung gesucht, die eine Hypothese formulierbar macht. Während der konfirmativen Analyse wird versucht, die gewonnene Hypothese aus der explorativen Analyse mittels geeigneter Visualisierung zielgerichtet zu überprüfen und ggf. zu bestätigen. Die Präsentation dient der Kommunikation der erzielten Ergebnisse. Es liegen bestä-tigte Aussagen und Fakten aufgrund der ersten beiden Phasen vor, die durch die Präsentation Dritten vermittelt werden können, etwa in Form von Bildern, Bildsequenzen oder interaktiven A-nimationen. Dabei müssen insbesondere die Fähigkeiten und Eigenschaften der menschlichen In-formationsverarbeitung und Wahrnehmung und die Besonderheiten der Zielgruppen berücksich-tigt werden; eine ausführliche Darstellung dieser Aspekte gibt Ware in [92]. Ein allgemeines, abstraktes Modell der Visualisierungspipeline wurde von Haber und McNabb [34] entwickelt, das in Abbildung 3 dargestellt ist. Ausgehend von den gesammelten Daten wird zunächst eine Aufbereitung durchgeführt (Filtering), etwa zur Reduktion der Datenmengen oder zur Interpolation von fehlenden Werten. In der anschließenden Stufe werden die Daten in ein computergraphisches Modell, z. B. in Form einer hierarchischen Szenenbeschreibung, abgebildet (Mapping). Dabei fließt die in der explorativen Analyse entwickelte Hypothese maßgeblich ein. Das computergraphische Modell wird schließlich in ein Rasterbild umgesetzt (Rendering). Dabei kommen unter Umständen besondere Verfahren wie z. B. Level-of-Detail zum Einsatz, um gro-ßen Datenmengen gerecht zu werden.

Geovisualisierung Eine Schätzung der Geoinformatik geht davon aus, dass mindestens 80% aller in Informations-systemen gespeicherten Daten einen Raumbezug besitzen und somit grundsätzlich als Geodaten zu bezeichnen sind. Deshalb kommt der Geovisualisierung als großer Teilbereich der Visualisie-rung eine besondere Rolle zu.

Unter Geovisualisierung verstehen wir Visualisierung von raumbezogenen Daten und Prozessen.

Ziel der Geovisualisierung ist es, Einsicht in georeferenzierte Daten und Prozesse und die in ihnen vorhandenen Strukturen zu gewinnen. Als wichtigste Datenquellen dienen dabei Vektordaten (z. B. Straßenzüge, Landesgrenzen, Luftströmungsdaten) und Rasterdaten (z. B. Geländemodelle, geologische Schichtungen, Luftbildaufnahmen). Die Geovisualisierung gewinnt zunehmend an Bedeutung im Bereich der Geoinformationssysteme (GIS), der Virtuellen Realität, aber auch der Unterhaltungsindustrie, z. B. bei Videospielen. Ein Teilgebiet der Geovisualisierung ist die Geländevisualisierung. Darunter verstehen wir die Visualisierung von Geländeoberflächen und der mit ihnen assoziierten thematischen Informatio-nen. Ein wichtiger Begriff ist in diesem Zusammenhang das digitale Geländemodell:

Filtering Mapping Rendering Bild Daten

Abbildung 3: Stufen der Visualisierungspipeline beim Übergang von Daten zum Bild.


6

Ein digitales Geländemodell (DGM) bezeichnet die digitale Darstellung einer Ge-ländeoberfläche durch räumliche Koordinatentripel einer Menge von Flächen-punkten, z. B. in Form von Dreiecksnetzen oder Gittern. Aus einem DGM lassen sich z. B. Höhenlinienkarten ableiten oder Volumina und Neigungen berechnen.

Aufgabe der Geländevisualisierung ist es, digitale Geländemodelle als Flächen im dreidimensiona-len Raum darzustellen. Eine dreidimensionale Ansicht verdeutlicht im Allgemeinen anschaulicher die Zusammenhänge zwischen Geländemorphologie, topographischen Informationen und themati-schen Informationen als es zweidimensionale Abbildungen vermögen, insbesondere wenn es dar-um geht, im Kartengebrauch ungeschulte Nutzergruppen zu informieren (z. B. Entscheidungsträ-ger in der Politik oder Bürger bei Bürgerbeteiligungen). Eine dreidimensionale Ansicht gestattet außerdem den Einsatz von Techniken der Virtuellen Rea-lität, sodass der Benutzer das Gelände intuitiv wahrnehmen, darin navigieren sowie Daten explo-rieren, manipulieren und mit Informationen anreichern kann. Aufgrund der enormen Datenmengen, die in der Geovisualisierung üblich sind, kommen besonde-re Verfahren zur Repräsentation der Daten im Rechner und zur ihrer Darstellung in Echtzeit zum Einsatz. Eines dieser Verfahren ist die Multiresolutionsmodellierung.

Unter Multiresolutionsmodellierung verstehen wir die hierarchische Modellie-rung von Datenrepräsentationen unterschiedlicher Auflösungsstufen in einem Mo-dell.

Eine einzelne Auflösungsstufe wird auch als Level-of-Detail oder kurz LOD bezeichnet. Ein Mul-tiresolutionsmodell liefert in Abhängigkeit von Umgebungs- und Sichtparametern (z. B. der Ka-meraposition und -distanz) eine geeignete Repräsentation der zugrundeliegenden Daten. Im Kon-text der Geovisualisierung sind Multiresolutionsmodelle für digitale Geländemodelle und Raster-daten von großer Bedeutung.

1.1.3 Grundlagen computergraphischer Systeme Der Begriff computergraphische Systeme bezeichnet Software und Hardware, die die computer-unterstützte Modellierung realer oder imaginärer Objekte und die Bilderzeugung auf der Grund-lage dieser Modelle übernehmen. Computergraphische Systeme können als Softwarebibliotheken, die zur Entwicklung computergraphischer Anwendungen eingesetzt werden können, oder als An-wendungsprogramme, die interaktiv mit dem Benutzer arbeiten, vorliegen. Beispiele computer-graphischer Systeme sind OpenInventor von Strauss und Carey [86], Java3D von Sowizral [82], VRML von Carey [14] und VRS von Döllner und Hinrichs [18]. Computergraphische Systeme besitzen eine hohe Komplexität, weil sie Funktionalität für das Rendering, die 3D-Modellierung, die Animation und die Interaktion bereitstellen müssen. Compu-tergraphische Anwendungen nutzen diese Funktionalität und leisten darüber hinaus eine geeignete Anbindung an die durch den Anwendungsbereich gegebene Fachebene. Zur Bewältigung dieser Komplexität und der Anforderungen an Effizienz, Erweiterbarkeit und Konfigurierbarkeit sind Methoden und Techniken des Software Engineering wie Softwaremodellierung, Objektorientie-rung und Komponentenorientierung unabdingbar. Ein Framework repräsentiert eine Software-Architektur für ein bestimmte Kategorie von Anwen-dungen auf der Grundlage einer Menge kooperierender Klassen (Szyperski [88]), die eine allge-meine, generische Lösung für ähnliche Probleme in einem bestimmten Kontext vorgibt. Häufig werden einzelne Klassen eines Frameworks so offen gelegt, dass für spezielle Anwendungen spe-zialisierte Klassen abgeleitet werden können. Vererbung, polymorphe und abstrakte Methoden werden vielfach eingesetzt. Für diese Arbeit wurde auf der Basis des Virtuellen Rendering Sys-


7

tems VRS (Döllner und Hinrichs [18]) ein objektorientiertes Framework, das 3D-Kartensystem LandExplorer, entwickelt. Das 3D-Kartensystem ist mittels der objektorientierten Programmiersprache C++ (Stroustrup [87]) implementiert. Systemprogrammiersprachen wie C++ eigenen sich aufgrund der strengen Typisierung sehr gut zur Implementierung speicher- und laufzeiteffizienter Komponenten. Die Konfiguration existierender Komponenten wird allerdings durch die strenge Typisierung und den Vorgang des Kompilierens und Bindens erschwert bzw. verlangsamt (Ousterhout [70]). Die Framework-Bestandteile des 3D-Kartensystems können über eine interpretierte Skriptsprache angesprochen werden. Alle für die Anwendungsentwicklung relevanten Klassen und ihre Metho-den werden automatisiert als Erweiterung in die Skriptsprache abgebildet. Mit Skriptsprachen ist im Gegensatz zu Systemprogrammiersprachen die Entwicklung komplexer, auf Komponenten basierender Anwendungen aufgrund der schwächeren Typisierung und der interaktiven Program-mierung wesentlich vereinfacht. Ousterhout [70] legt dar: „scripting languages are designed for gluing: they assume the existence of a set of powerful components and are intended primarily for connecting components together.“ Die erweiterte Skriptsprache erlaubt die Erzeugung, Ma-nipulation und Zerstörung von C++-Objekten zur Laufzeit. Methoden können über die zusätzlich vorhandene Klassen- und Framework-Metainformation erfragt und interaktiv aufgerufen werden. Die automatische Abbildung wurde exemplarisch für die Skriptsprache Tcl/Tk (Ousterhout [69]) entwickelt. Zur Beschreibung der entwickelten Software-Architektur des 3D-Kartensystems wird die Unified Modeling Language (UML, Booch et al. [10]) verwendet, die eine graphische Notation für stati-sche, dynamische und physische Aspekte eines Software-Systems bereitstellt.

1.2 Grundlagen der Kartographie Der Begriff Kartographie hat viele unterschiedlich nuancierte Definitionen. Wir verwenden in dieser Arbeit die Definition von Hake und Grünreich [38]. Sie definieren den Begriff Kartogra-phie wie folgt:

„Ein Fachgebiet, das sich befasst mit dem Sammeln, Verarbeiten, Speichern und Auswerten raumbezogener Informationen sowie in besonderer Weise mit deren Veranschaulichung durch kartographische Darstellungen.“

Abbildung 4: Nubische Goldminenkarte 1300 v. Chr. auf Papyrus.

1.2 Grundlagen der Kartographie

8

Zu den kartographischen Darstellungen zählen insbesondere Karten und kartenverwandte Dar-stellungen (siehe unten). Die Hauptaufgabe von Karten und kartenverwandten Darstellungen ist demnach der Informationstransfer raumbezogener Information (engl. to map = abbilden). Einige Definitionen legen die Kartographie zusätzlich als „Kunst der Kartenherstellung“ fest (Internatio-nale Kartographische Vereinigung [50]) und heben damit die gestalterischen Aufgaben hervor. Die Kartographie ist demnach nicht nur mit informationstechnischen, sondern auch mit kreativen Fragestellungen befasst.

1.2.1 Karten Für den Begriff der Karte verwenden wir in dieser Arbeit die Definition von Hake [37]:

„Eine Karte ist ein maßgebundenes und strukturiertes Modell räumlicher Bezüge. Sie ist im weiteren Sinne ein digitales, graphikbezogenes Modell, im engeren Sinne ein graphisches (analoges) Modell.“

Für den Entwurf von Karten hat insbesondere die Kartographie eine Reihe von Methoden, Tech-niken und Theorien entwickelt, wie z. B. die Theorie der Visuellen Variablen von Bertin [8]. Eine ausführliche Darstellung dieser Aspekte sowie die Funktionsweise von Karten in Hinblick auf die menschliche Informationsverarbeitung findet sich bei MacEachren [60]. Eine der wichtigsten Gestaltungstechniken einer Karte ist die kartographische Generalisierung. Sie verfolgt das Ziel, das Wesentliche in einer Informationsmenge zu ermitteln und darzustellen. Zur Generalisierung finden Verfahren wie Filterung und Abstraktion Anwendung. Die kartographische Generalisie-rung wurde bereits in frühen Karten angewandt, wie etwa in der nubischen Goldminen-Karte (Abbildung 4). MacEachren [62] unterscheidet drei Achsen der Kartennutzung und illustriert diese in Form eines Würfels, des map-use-cube (Abbildung 5). Die erste Achse macht Aussagen über die Zielgruppe der Kartennutzung. Dabei wird zwischen der „privaten“ und „öffentlichen“ Kartennutzung unter-schieden. Bei der monologischen Kartennutzung (private) ist der Kartenautor alleiniger Nutzer. Er generiert eine Karte für seine eigenen Bedürfnisse und muss deshalb auch keine Rücksicht auf die Informationsübermittlung nehmen. Bei der dialogischen Kartennutzung (public) werden Kar-ten für eine große Nutzergruppe verfügbar gemacht.

public

presenting knowns

private

revealing unknowns

Human map interaction

high

low

Visualization

Communication

Abbildung 5: Der Map-Use-Cube von MacEachren [62] stellt die Kartennutzung räumlich in Form ei-nes Würfels dar.


9

Die zweite Achse macht Aussagen über den Zweck der Kartennutzung. Es wird unterschieden zwischen dem Erschließen von Unbekanntem (revealing unknown) und der Präsentation von Be-kanntem (presenting known). Die dritte Achse macht Aussagen über den Interaktionsgrad bei der Kartennutzung. Es wird un-terschieden zwischen Kartennutzung mit hoher Mensch-Karten-Interaktion (high human-map interaction), bei der der Nutzer eine Vielzahl von Veränderungen an einer Karte durchführen kann, und der Kartennutzung mit geringer Interaktion (low human-map interaction), bei der der Nutzer kaum Einfluss auf die Darstellung einer Karte besitzt. Visualisierung und Kommunikation stellt MacEachren an der Würfeldiagonalen gegenüber. Liegt der Schwerpunkt der Kartennutzung auf Visualisierung, existiert ein hoher Grad an Interaktion bei der monologischen Exploration von unbekannten Informationen. Liegt der Schwerpunkt der Kartennutzung auf der Kommunikation, existiert ein geringer Grad der Interaktion bei der öffent-lichen Präsentation von bekannten Informationen.

Kartentypen Gliedert man Karten inhaltlich, kann man zwischen topographischen und thematischen Karten unterscheiden. Topographische Karten stellen sichtbare Erscheinungen der Erdoberfläche dar, vermessen und lagerichtig kartiert im Grundriss und z.T. durch Schrift erläutert. Dazu gehören Geländeformen und Höhenverhältnisse, Bodenbewachsungen, Siedlungen und Wirtschaftsflächen, Verkehrswege und Grenzen, aber auch Einzelobjekte wie Burgen, Schlösser, Aussichtspunkte, Windmühlen etc. Sie dienen der allgemeinen Orientierung. Thematische Karten repräsentieren quantitativ und qualitativ ausgewertete, meist durch Denk-prozesse erschlossene, raumbezogene Erscheinungen. Sie zeigen Erscheinungen in ihrer räumli-chen Verbreitung übersichtlich; ihre Auswahl richtet sich ausschließlich nach der Entscheidung des Kartenautors und den Kartenverwendungszwecks. Auch thematische Karten müssen Situati-onstreue gewährleisten, wenngleich sie der verständlichen Darstellung der Thematik unterzuord-nen ist. Beispiele thematischer Karten sind Karten mit Linien gleicher Zahlenwerte (z. B. Isohypsen, Iso-thermen, Isobaren), Bevölkerungsdichtekarten, Wirtschafts- und Verkehrskarten.

Kartenverwandte Darstellungen Kartenverwandte Darstellungen sind die kartographischen Darstellungen, die den gleichen Zweck einer Karte erfüllen, aber über bestimmte Eigenschaften von Karten (z. B. orthogonale

Abbildung 6: Panoramakarte des Lenggries mit Brauneck www.lenggries.de (links) und räumli-che Abbildung von Nachrichtenereignissen abhängig von Typ und Meldungsfrequenz www.aurigin.com (rechts).

1.2 Grundlagen der Kartographie

10

Projektion) nicht verfügen, um Sachverhalte - für den bestimmten Fall - angemessener zu reprä-sentieren. Dazu zählen z. B. Globen, Panoramen (Abbildung 6 links) oder Karten, die nichträum-liche Information räumlich darstellen (Abbildung 6 rechts). Die kartographische Abstraktion als effektives Werkzeug zur Präsentation, Exploration und Ma-nipulation räumlicher und raumzeitlicher Information wird vielfach in Virtuellen Umgebungen (MacEachren et al. [64]) angewandt. Virtuelle Geo-Umgebungen, die die menschliche Sensorik und das kognitive System mittels VR Technologie einbeziehen (MacEachren et al. [63]), basieren auf digitalen Karten als fundamentales Graphikprimitiv.

1.2.2 3D-Karten Im Kontext der Computergraphik wird der Begriff „3D-Karte“ häufig im Zusammenhang mit perspektivischen 3D-Darstellungen von Geländemodellen verwendet. Was genau eine „3D-Karte“ ist, wird dabei häufig nicht geklärt (z. B. Koller et al. [56], Reddy et al. [73]). In der Kartogra-phie ist der Begriff „3D-Karte“ nicht eindeutig belegt. Der Begriff „3D-Karte“ ist sowohl bezüglich des Wortbestandteils „3D“ als auch bezüglich des Wortbestandteils „Karte“ kritisch, da

- die Darstellung nicht in der Ebene, sondern auf Grundlage eines Gelände-modells erfolgt;

- das Ausgabemedium zweidimensional ist; - das Geländemodell topologisch betrachtet zweidimensional ist; - das Geländemodell zugleich als 2½-dimensionales Höhenmodell bezeichnet

wird; - das Geländemodell in geometrischer Hinsicht im Dreidimensionalen

eingebettet ist; - die Maßstäblichkeit aufgrund der perspektivischen Darstellung nicht gilt.

Wir verwenden in dieser Arbeit trotzdem den Begriff „3D-Karte“, da er sprachlich kompakt und inhaltlich intuitiv die hier vorgestellte Art der raumbezogener Visualisierung beschreibt. Wir defi-nieren den Begriff wie folgt:

Eine 3D-Karte ist eine verkleinerte und generalisierte interaktive, perspektivische 2D-Darstellung von raumbezogenen Erscheinungen, Sachverhalten und Prozessen im Dreidimensionalen.

Wir zählen 3D-Karten zu den kartenverwandten Darstellungen, weil sie das primäre Ziel einer Karte - die Kommunikation räumlicher Information - verfolgen. 3D-Karten verzichten dabei auf eine orthogonale, maßstäbliche Aufsicht; sie bieten eine perspektivische Ansicht, die interaktiv verändert werden und dynamische Inhalte darstellen kann. Anwendungsgebiete für 3D-Karten sind allgemein in den Geowissenschaften, speziell in Naviga-tionssystemen, in Lernumgebungen für raumbezogene Aufgaben, in Tourismusinformationssys-temen oder in Anwendungen der Unterhaltungsindustrie zu finden. Softwaretechnisch betrachtet repräsentieren 3D-Karten einen Typ von Benutzungsschnittstellenelementen zur Kommunikation von und Interaktion mit raumbezogenen Informationen. Ein Beispiel hierfür findet sich in Abbildung 7. Im Folgenden meinen wir mit dem Begriff „3D-Karte“ die in dieser Arbeit beschriebene 3D-Karte. Andernfalls wird ausdrücklich darauf hingewiesen. Mit „3D-Kartensystem“ meinen wir von nun an das hier beschriebene 3D-Kartensystem mit dem Namen „LandExplorer“.


11

1.3 Aufbau der Arbeit Kapitel 2 befasst sich mit der Software-Modellierung des 3D-Kartensystems. Die darin realisier-ten 3D-Kartenbauelemente werden vorgestellt und ihre Beziehungen diskutiert. Kapitel 3 beschreibt die technischen Aspekte der Visualisierung von Geländemodellen, insbeson-dere das Rendering der Geometrie in 3D. Verwandte Arbeiten werden diskutiert und das im 3D-Kartensystem verwendete Geländemodell detailliert vorgestellt. Kapitel 4 beschreibt die technischen Aspekte der Visualisierung von Rasterdaten in 3D, insbe-sondere im Zusammenhang mit Geländemodellen. Verwandte Arbeiten werden diskutiert und das im 3D-Kartensystem verwendete Verfahren detailliert vorgestellt. Kapitel 5 beschreibt die technischen Aspekte der Visualisierung von Vektordaten, insbesondere im Zusammenhang mit Geländemodellen in 3D. Verwandte Arbeiten werden diskutiert und das im 3D-Kartensystem verwendete Verfahren detailliert vorgestellt. Kapitel 6 befasst sich mit Verfahren zur Navigation und der Unterstützung von Orientierung in 3D-Karten. Kapitel 7 stellt eine auf dem 3D-Kartensystem basierende Erweiterung einer Skriptsprache vor, die zur Konstruktion und Konfiguration von 3D-Karten eingesetzt wird. Kapitel 8 zeigt Anwendungsbeispiele von 3D-Karten am Beispiel eines Funknetzplanungswerk-zeugs und eines Werkzeugs zur Analyse von Wasserstraßen und ihrer Bodenbeschaffenheit. Kapitel 9 fasst die wesentliche Ergebnisse dieser Arbeit zusammen und skizziert mögliche weiter-führender Aspekte.

Abbildung 7: Beispiel einer 3D-Karten zur Funknetzplanung als Element einer Benutzungsschnittstelle.

13

Kapitel 2 MODELLIERUNG INTERAKTIVER, DYNAMISCHER 3D-KARTEN

In diesem Kapitel werden die Systemarchitektur und die softwaretechnischen Kernbestandteile des in dieser Arbeit entwickelten 3D-Kartensystems LandExplorer vorgestellt. Wir unterscheiden sprachlich und semantisch dabei zwischen: - dem 3D-Kartensystem als Softwaresystem zur Präsentation, Exploration, Analyse und Edi-

tierung von 3D-Karten; - den 3D-Karten als digitale Dokumente, die raumbezogene Sachverhalte, ihre zugrundeliegen-

den Geodaten und ihre Darstellung beinhalten; und - den 3D-Kartenbauelementen als Objekten, die softwaretechnisch die Bestandteile einer 3D-

Karte repräsentieren. Zugleich verwenden wir diesen Begriff für die Gesamtheit der Klassen der 3D-Kartenbauelemente. Wir unterscheiden visuelle, strukturelle und verhaltengebende 3D-Kartenbauelemente.

Die Konstruktion einer 3D-Karte erfolgt durch die Instanziierung und Komposition von 3D-Kartenbauelementen. Diese Elemente kapseln computergraphische und geo-thematische Daten und Funktionen. Sie abstrahieren dadurch von den zugrundeliegenden komplexen Softwarebasis-systemen. Die 3D-Kartenbauelemente sind als Klassen des 3D-Kartensystems realisiert. Das Baukastenprinzip ermöglicht die systematische und effektive Konstruktion von 3D-Karten. Insbesondere können durch die geeignete Wahl von Verhaltenselementen, wie z. B. durch Festle-gung anwendungsspezifischer Aufrufe für Kartenelemente oder Animation von dargestellten Ob-

2.1 Anforderungen an 3D-Karten

14

jekten, interaktive, dynamische 3D-Karten erstellt werden, die sich in ihrer Gestaltung in hohem Maß am Nutzer und an den Aufgaben orientieren.

2.1 Anforderungen an 3D-Karten In Bezug auf die Gestaltung einer 3D-Karte zählt Häberling [36] die Festlegung der Nutzergrup-pen, die Spezifikation der Nutzerbedürfnisse und die Ableitung von Anforderungen an die Kar-tensymbolik zu den wesentlichen Aspekten. Wir erreichen diese Anforderungen durch die dynami-sche Gestaltung und die Fokussierung auf Mechanismen zur Individualisierung und Konfigurati-on des 3D-Karteninhalts. In Bezug auf die computergraphischen Voraussetzungen sieht Terribilini [90] die Multiresoluti-onsrepräsentation, die echtzeitfähige Visualisierung, die Interaktivität und die hohe visuelle Quali-tät als Hauptanforderungen an 3D-Karten an. In unserem Ansatz tragen wir diesen Anforderun-gen durch Multiresolutionsmodelle für Geländegeometrie, Rasterdaten und Vektordaten Rech-nung. Die Anforderungen an eine 3D-Karte und das zugrundeliegende 3D-Kartensystem fassen wir im Folgenden zusammen. Aus der Sicht der Gestaltung beinhalten die Anforderungen:

- Hohe Darstellungsqualität: Die Darstellung soll die heute mögliche Qualität digitaler Medien im vollen Umfang ausschöpfen. Geodaten müssen visuell korrekt dargestellt wer-den, das heißt die ursprünglichen Daten müssen möglichst unverfälscht und im Bild arte-faktfrei wiedergegeben werden.

- Effiziente Verarbeitung großer Geodatenmengen: Die Darstellung muss in Echtzeit er-folgen, um die Interaktion mit dem Betrachter zu ermöglichen. Dabei sind im Allgemei-nen große Mengen an Geodaten zu bewältigen.

- Interaktive Darstellung: Mechanismen zur wechselseitigen Beeinflussung von Benutzer und 3D-Karte müssen bereitstehen, die als technische Grundlage für Werkzeuge zur Na-vigation, Exploration und Analyse der Daten dienen.

- Animierte Darstellung: Kartographische Animation für Prozesse und Erscheinungen, all-gemeiner die Darstellung dynamischer Geodaten, sollen als neue Möglichkeiten digitaler interaktiver Medien umgesetzt werden können.

- Individualisierbarkeit: Eine 3D-Karte muss in ihrer Gestaltung und ggf. auch dynamisch an Nutzer und Aufgaben angepasst werden können.

Aus den klassischen Software-Qualitätskriterien ergeben sich softwaretechnische Anforderungen an das 3D-Kartensystem. Neben der Korrektheit, der Verifizierbarkeit und der Integrität gehören dazu insbesondere:

- Hohes Maß an Erweiterbarkeit: Bestehende 3D-Karten sollen leicht erweiterbar sein, um neuen Anforderungen und Aufgaben gerecht werden zu können.

- Hohes Maß an Wiederverwendbarkeit: Die 3D-Kartenbauelemente müssen so entworfen sein, dass sie möglichst generisch und domänenübergreifend für die Konstruktion von 3D-Karten eingesetzt werden können.

- Hohe Portabilität: 3D-Karten sollen plattformübergreifend ohne Änderungen einsetzbar sein; das 3D-Kartensystem muss portabel implementiert werden.

- Benutzerfreundlichkeit: Die Entwicklung einer 3D-Karte muss ohne tiefgehende compu-tergraphische und programmiertechnische Kenntnisse möglich sein.

- Verträglichkeit mit anderen Softwarekomponenten: Eine bestehende 3D-Karte soll mög-lichst einfach mit anderen Softwarekomponenten verbunden werden können.

Kapitel 2 - Modellierung interaktiver, dynamischer 3D-Karten

15

Techniken zur Umsetzung der genannten Anforderungen werden im weiteren Verlauf der Arbeit detailliert beschrieben und diskutiert. Betrachten wir zunächst den softwaretechnischen Aufbau des 3D-Kartensystems.

2.2 Aufbau des 3D-Kartensystems Rendering-Basissystem Die Grundlage für das Rendering einer 3D-Karte bildet das 3D-Renderingsystem OpenGL [95]. OpenGL ist ein de facto Industriestandard, auf dem Entwickler echtzeitfähige 3D-Graphik- und Visualisierungsanwendungen hardwarenah und plattformübergreifend aufbauen können. OpenGL ermöglicht das effiziente Rendering geometrischer Primitive (insbesondere von Dreiecksnetzen) mit assoziierten visuellen Attributen (z. B. Farbe, Textur, Materialeigenschaf-ten). Die Programmierung erfordert Kenntnisse verschiedener Konzepte der hardwarenahen C-Programmierung (z. B. Zeiger, Callbacks) und der Computergraphik. Die Einarbeitungszeit in diese Konzepte beansprucht im Allgemeinen viel Zeit. Auch für erfahrene Entwickler ist die Kon-struktion komplexer Szenen ohne weitere Hilfsmittel aufwendig.

3D-Graphik-Basissystem 3D-Graphik-Basissysteme abstrahieren von einem zugrunde liegenden Renderingsystem und stel-len Modellierungs-, Interaktions- und Animationstechniken bereit. Beispiele solcher Basissysteme sind z. B. Java3D [83], OpenInventor [86] und VTK [76]. In der Regel wird dabei ein Szene-graph [82] zur hierarchischen Szenenbeschreibung verwendet. Das in dieser Arbeit verwendete Virtuelle Rendering System (VRS), verfügt über eine umfangrei-che Sammlung von Bausteinen zur Entwicklung von 3D-Anwendungen (Döllner und Hinrichs [18]). Zu den Bausteinen zählen unterschiedliche geometrische 3D-Objekte, graphische Attribute und innovative 3D-Renderingtechniken, wie Echtzeit-Schatten [53], Echtzeit-Reflexionen und das für 3D-Karten unverzichtbare Multitexturing. VRS bietet neben dem Szenengraph einen Verhaltensgraph zur Konstruktion interaktiver 3D-Anwendungen. Der Szenengraph spezifiziert Geometrie und Erscheinung einer 3D-Szene und wird aufgebaut aus Szenenknoten, die wiederum als Container für Knotenkomponenten dienen. Knotenkomponenten umfassen Geometrien (z. B. Kugel, Zylinder, Nurbs-Flächen), graphische Attribute (z. B. Oberflächenfarbe, Materialeigenschaften, Lichtquellen), geometrische Transfor-mationen (z. B. Rotationen, Skalierungen, Translationen) und weitere Kindknoten, die Szenenteil-graphen repräsentieren. Ein Verhaltensgraph besteht aus Verhaltensknoten, die Knotenkomponen-

3D-Renderingsystem OpenGL

3D-Graphikbibliothek VRS

3D-Karten-Bibliothek LDX

3D-Karten-Anwendung C++

C++

C++

C

3D-Renderingsystem OpenGL

3D-Graphikbibliothek VRS

3D-Karten-Bibliothek LDX

Interpreteranbindung iVRS/iLDX

3D-Karten-Anwendung Tcl

Tcl/C++

C++

C++

C

Abbildung 8: Higher-Level Schichtenmodell des 3D-Kartensystems ohne Interpreteranbindung (links) und mit Interpreteranbindung (rechts).

2.3 Visuelle 3D-Kartenbauelemente

16

ten enthalten. Für Verhaltensknoten umfassen diese Knotenkomponenten zeitliche Anforderungen, Zeittabellen und Ereignisverarbeiter z. B. zur Navigation, Selektion oder Kollisionserkennung. Dadurch wird die Konstruktion komplexer interaktiver Szenen ermöglicht. Eine 3D-Szene wird gerendert, indem der Szenengraph durch eine Rendering-Engine traversiert und die Knotenkomponenten ausgewertet werden. Die Interaktion einer Szene wird durch Senden von Ereignissen an den Verhaltensgraphen ermöglicht. VRS ist in C++ implementiert und basiert primär auf dem Renderingsystem OpenGL.

3D-Karten-Basissystem Allgemeine 3D-Graphikbibliotheken reichen wegen der fehlenden Abstraktion und wegen fehlen-der geo-spezifischer Algorithmen nicht aus, den Anforderungen der Geovisualisierung gerecht zu werden. Die LandExplorer-Bibliothek (LDX) stellt auf der Basis von VRS und OpenGL eine Sammlung von 3D-Kartenbauelementen bereit, die speziell für den Bau von 3D-Karten ausgelegt sind. 3D-Kartenbauelemente abstrahieren bestimmte Graphikprimitive, Graphikattribute und spezielle Al-gorithmen zu geeigneten Klassen. Die LDX-Bibliothek ist in C++ implementiert. In den anschließenden Abschnitten dieses Kapitels werden die unterschiedlichen 3D-Kartenbauelemente vorgestellt, unterschieden nach visuellen, strukturellen und verhaltengebenden 3D-Kartenbauelementen.

3D-Karten-Anwendung Eine 3D-Karten-Anwendung ist eine eigenständige Anwendung, die über eine graphische Benut-zungsschnittstelle und über mindestens eine eingebettete 3D-Kartenansicht verfügt. Sie kann zum einen direkt auf der Basis von VRS/LDX und einem Benutzungsschnittstellensystem (z. B. Qt oder MFC) entwickelt werden, wobei die Implementierung in der Systemprogrammiersprache C++ (Abbildung 8 links) erfolgt. Eine 3D-Karten-Anwendung kann zum anderen mittels der eigens entwickelten C++-Interpreteranbindung iVRS/iLDX in der Skriptsprache Tcl (Ousterhout [69]) entwickelt werden (Abbildung 8 rechts). Das interaktive VRS und das interaktive LDX (iVRS/iLDX) stellen eine Anbindung zwischen dem Interpreter Tcl und den C++-Bibliotheken VRS bzw. LDX bereit (Kersting und Döllner [52]). Mittels iVRS/iLDX können nahezu sämtliche C++-Klassen aus VRS/LDX über den Tcl-Interpreter angesprochen werden, das heißt Objekte können durch den Interpreter instanziiert und zerstört, Methoden aufgerufen und Objekteigenschaften abgefragt werden. Zusammen mit dem in Tcl integrierten Benutzungsschnittstellenpaket Tk können voll-ständige, plattformunabhängige 3D-Karten-Anwendungen konstruiert werden und direkt mit be-stehenden Tcl-Komponenten verknüpft werden. Die technischen Details der Interpreteranbindung werden ausführlich in Kapitel 7 diskutiert.

2.3 Visuelle 3D-Kartenbauelemente In unserem Modell wird eine 3D-Karte repräsentiert durch eine oder mehrere 3D-Kartenansichten und einer Sammlung von 3D-Kartenbauelementen zur Spezifikation des Karteninhalts, der Kar-tenstruktur und der Karteninteraktivität. Die 3D-Kartenbauelemente lassen sich drei grundsätzli-chen Kategorien zuordnen, den visuellen, strukturellen und verhaltengebenden Bauelementen. Visuelle 3D-Kartenbauelemente repräsentieren sichtbare, georeferenzierte Objekte, die über gra-phische Attribute verfügen, wie z. B. Farbe, Größe, Form oder Orientierung. Verglichen mit Pri-mitiven von 3D-Graphiksystemen sind die visuellen 3D-Kartenbauelemente auf die Bedürfnisse der 3D-Karten abgestimmt und weisen zugleich eine komplexere Struktur und Funktionalität auf.


17

In dem Klassendiagramm in Abbildung 9 sind die verschiedenen visuellen 3D-Kartenbauelemente und ihre Beziehungen untereinander dargestellt. Alle visuellen 3D-Kartenbauelemente verfügen über eine Georeferenzierung (GeoRef-Basisklasse). Sie können mit Verhalten ausgestattet und mit zusätzlicher Information strukturiert werden (siehe Abschnitt 2.3.3 und 2.4.4). Wir unter-scheiden dabei zwischen geometriebasierten (Geometry) und rasterbasierten (Texture) visuel-len Bauelementen. Ein spezielles visuelles 3D-Kartenbauelement ist das Geländemodell (Terrain).

2.3.1 Geländemodell Das Geländemodell steht im Mittelpunkt der Konstruktion einer jeden 3D-Karte, denn alle ande-ren visuellen 3D-Kartenbauelemente sind im Allgemeinen bezüglich der Geländeoberfläche posi-tioniert. Häufig erfordert die Größe der Daten, die dem Geländemodell zugrunde liegen, eine Dar-stellung in unterschiedlichen Auflösungen, um das Geländemodell in Echtzeit darstellen zu kön-nen, da selbst heute mehrere Millionen Polygone mehrfach pro Sekunde nur mit äußerst kostspie-liger Graphikhardware darstellbar sind. Bei der Aufbereitung der Geländedaten kommen Multiresolutionsmodelle zum Einsatz, die auf unterschiedliche Weise eine schnelle Auswahl der darzustellenden Polygone gewährleisten, die in Abhängigkeit bestimmter Faktoren (z. B. Kameraposition) einen möglichst geringen Darstellungsfehler garantieren. Einige bekannte Verfahren zur Multiresolutionsmodellierung sind z. B. Multitriangulation (De Floriani et al. [28]), Progressive Meshes (Hoppe [44]), Restricted Quad-Tree Triangulation (Pajarola [71]) oder der Algorithmus von Lindstrom und Pascucci

GeoRef

«singleton»Terrain TextureGeometry

Lines

Points

Polygons

Labels

Symbols

VideoTexture

LensTexture

ShadingTexture

VectorTexture

ImageTexture

HypsometryTexture

BlendingTexture

*

Curve

2

Abbildung 9: Klassendiagramm der visuellen 3D-Kartenbauelemente.


18

[58]. Ein Verfahren, das zusätzlich neben der Geometrie noch die vielseitige Nutzung von Rasterdaten und hybriden Geländedaten (Gitter zusammen mit TIN) ermöglicht, ist der von Baumann et al. [6] entwickelte Approximationsbaum, der die Grundlage der 3D-Karten-Geländemodells darstellt. Diese Multiresolutionsverfahren und im Besonderen der Approximationsbaum werden in Kapitel 3 vorgestellt. Das Multiresolutionsmodell für die Geländegeometrie wird im 3D-Kartensystem durch die Klasse Terrain gekapselt. Sie ermöglicht es, die Überhöhung des Geländes sowie Geometrie- und Tex-turfehlerschranken einzustellen; diese Parameter dienen zur Steuerung des Rendering-Algorithmus.

2.3.2 Rasterbasierte 3D-Kartenbauelemente Unter rasterbasierten 3D-Kartenbauelementen verstehen wir Elemente, deren visuelle Repräsen-tation auf Rasterbilddaten beruht. Beispiele für Rasterbilddaten ergeben sich aus Satellitenauf-nahmen, gescannten Luftbildern, gescannten Karten und Plänen, aber auch als Ergebnis von Klassifizierungen, z. B. im Fall von Landnutzungsdaten. Bei der Darstellung werden diese Ras-terbilddaten auf einen georeferenzierten Bereich des Geländemodells pixelpräzise projiziert (Tex-turierung). Eine Rasterbilddatenschicht nennen wir auch Texturschicht. Texturschichten können das gesamte Gelände oder nur Teile davon überdecken; die Geokoordinaten einer Texturschicht legen die Position und Orientierung fest. Mehrere Texturschichten können miteinander in einer 3D-Kartenansicht visuell kombiniert werden. Texturierung als eine grundlegende computergraphische Funktion wird heute von Graphikhard-ware effizient unterstützt. Die Graphikhardware legt die Maximalgröße und die Kompressions-möglichkeiten für Texturen fest. Die Beschränkung der Texturgröße durch die Hardware erfor-dert eine gesonderte Behandlung übergroßer Texturen bei ihrer Darstellung auf einer Gelände-oberfläche. Die technischen Details, die bei der Verwendung von Rasterbilddaten im Zusammen-hang mit 3D-Karten relevant sind, werden in Kapitel 4 erörtert.

Schattierungstextur OpenGL verwendet in seiner Beleuchtungsberechnung die Gouraud-Schattierung [32]: Die Be-leuchtungsintensität an einem Dreieckseckpunkt wird unter Berücksichtigung des spezifizierten Normalenvektors und der aktiven Lichtquellen bestimmt. Diese Intensitätswerte werden linear über der Dreiecksfläche interpoliert. Die Gouraud-Schattierung hat bei der Verwendung von Mul-tiresolutionsmodellen den Nachteil, dass zum Zeitpunkt des Rendering die Schattierungsinforma-tion von der momentanen Geometrie des Geländemodells abhängt und damit die Qualität der Schattierung stark variiert, wenn sich diese Geometrie ändert. Heutige Multiresolutionsverfahren

Abbildung 10: Manuell erzeugte Schummerung eines Gebirgsausschnittes nach Imhof [48].


19

berechnen jedoch meist adaptiv diese Geometrie zur momentanen Kameraposition, sodass die Ge-ometrie während der Interaktion ständigen Änderungen unterworfen ist. Da der Mensch morpho-logische Strukturen stark über die Schattierung wahrnimmt, wird er durch die resultierenden Ver-änderungen der Schattierung bei seiner Wahrnehmung der Geländemorphologie gestört. Die Verwendung einer Schattierungstextur erlaubt die pixelpräzise Projektion der Schattierungs-information des Geländemodells auf die Multiresolutionsmodell-Oberfläche. Die Schattierungsin-formation wird durch ein Rasterbild repräsentiert, das direkt aus der höchsten Auflösungsstufe des Geländemodells abgeleitet wird. Die Größe des Rasterbildes hängt dabei von der Auflösung des Geländemodells ab. Veränderungen an den Lichtquellen (z. B. Position, Farbparameter), die die Geländeoberfläche beleuchten, implizieren eine Neuberechnung des Rasterbildes. Durch die Entkopplung von Geometrie und Schattierung steigt die visuelle Qualität der Gelände-modell-Darstellung. Gleichzeitig kann im Vergleich zur Gouraud-Schattierung ein insgesamt ge-ometrisch wesentlich geringer aufgelöstes Geländemodell verwendet werden. Zudem können indi-viduelle Schattierungsverfahren zum Einsatz kommen, die nicht notwendigerweise echtzeitfähig sind oder manuell hergestellt wurden (z. B. Imhof [48], Abbildung 10). Um Schattierungsinformation aus den zugrundeliegenden Geländedaten zu generieren, dient eine Schattierungstextur (ShadingTexture). Bei der Erzeugung einer Schattierungstextur wird das momentane Geländemodell in seiner höchsten Auflösung von oben gezeichnet und das resultie-rende Rasterbild als Textur verwendet (Abbildung 11 links).

Rasterbildtextur Mittels einer Rasterbildtextur (ImageTexture) können Rasterbilddaten, die als Bilddateien (z. B. BMP oder PPM) vorliegen, in eine 3D-Karte integriert werden. Über die Georeferenzierung wird die Lage auf dem Geländemodell definiert (Abbildung 11 Mitte). Eventuelle technische Auf-bereitung der Bilddaten zur echtzeitfähigen Darstellung (Aufbau von Bildpyramiden, Bildkom-pression) werden durch die ImageTexture automatisch durchgeführt (Kapitel 4).

Hypsometrietextur Eine höhenabhängige Einfärbung, die u. a. zur Höhenmessung (=Hypsometrie) und Höhenab-schätzung dient, kann mittels einer Hypsometrietextur (HypsometryTexture) auf die Gelände-oberfläche projiziert werden (Abbildung 11 rechts). Die höhenabhängige Einfärbung definiert die Farbe eines Geländeoberflächenpunkts gemäß einer gegebenen Höhenfarbskala, die jedem Hö-

Abbildung 11: Darstellung morphologischer Information mittels Schattierungstextur (links). Dar-stellung von Befliegungsaufnahmen mittels Rasterbildtextur (Mitte). Interpolierte Einfärbung von Höhenschichten mittels Hypsometrietextur (rechts).


20

henwert eine bestimmte Farbe zuordnet. Die Höhenfarbskala definiert dabei für Höhenintervalle entweder kontinuierliche Farbverläufe oder konstante Farben.

Videotextur Eine Videotextur (VideoTexture) erlaubt die Projektion von Videosequenzen auf die Gelände-oberfläche (Abbildung 12). Sie ermöglicht u. a. die animierte Visualisierung raum-zeitlicher Pro-zesse auf der Geländeoberfläche. Benötigt wird dazu eine Videodatei (im AVI- oder MPEG-Format) mit der gewünschten Bildse-quenz. Die maximale Größe einer Videotextur ist durch die vorhandene Graphikhardware festge-legt, da keine Geländemodell-gerechte Aufbereitung der Videodaten in Echtzeit möglich ist (Ab-schnitt 4.5).

Texturlinsen Die Metapher „Linse“ wird im Kontext von Visualisierung immer dann angewandt, wenn es gilt Information zu filtern, zu fokussieren oder auszublenden (z. B. Bier et al. [9], Viega et al. [91]). Eine Texturlinse (LensTexture) ist eine spezielle Texturschicht, die die Sichtbarkeit und Kom-bination von zwei thematischen Texturschichten in einer 3D-Karte modifiziert. Auf diese Weise können visuelle Informationen in einer 3D-Karte dynamisch fokussiert und beschränkt werden. Eine Filter-Texturlinse beschränkt die Sichtbarkeit anderer thematischer Texturschichten. Sie kann zur Modifikation der visuellen Repräsentation verwendet werden, z. B. indem thematische Daten aus einer bestimmten Texturschicht innerhalb der Linse aus- bzw. eingeblendet werden

Abbildung 12: Sequenz von Bildern einer Überflutungssimulation werden mittels Videotextur auf die Geländeoberfläche projiziert.

Abbildung 13: Interaktive Analyse von Feldstärken mit Hilfe einer Filter-Texturlinse (links). Aufhel-lung von Bereichen besonderen Interesses mittels Luminanz-Texturlinse (rechts).


21

(Abbildung 13 links). Eine Luminanz-Texturlinse modifiziert die Helligkeit einer anderen thema-tischen Texturschicht (Abbildung 13 rechts). Durch die Animation einer Luminanz-Texturlinse können Anwender durch 3D-Karten geleitet werden (z. B. zur Navigationsunterstützung, Döllner und Kersting [22]). Texturlinsen erlauben es, Informationen in der Kartenansicht nur dort zu visualisieren, wo sie vom Benutzer benötigt werden, das heißt das Bild der 3D-Karte enthält oder fokussiert nur die graphischen Elemente, die im momentanen Kontext von Bedeutung sind. Dadurch lässt sich die Komplexität des Karteninhalts reduzieren und damit die kognitive Belastung des Betrachters mi-nimieren.

Verblendungstextur Eine Verblendungstextur (BlendingTexture) erlaubt die Verblendung von Texturschichten in Abhängigkeit von der Kameraentfernung. Thematische Informationsschichten unterschiedlicher Informationsdichten können so automatisch an die momentane Kameraposition angepasst werden. Auch hier sinkt die Komplexität des Karteninhalts mit der Folge, dass die kognitive Belastung für den Betrachter gesenkt wird. Abbildung 14 zeigt eine Folge von Bildern, die unter Verwendung einer Verblendungstextur er-zeugt wurden. Dabei werden eine Wegekarte, eine stark generalisierte topographische Karte und eine detaillierte topographische Karte als Texturschichten distanzabhängig ineinander verblendet. Die Wegekarte wird zur groben Orientierung auf die Geländeoberfläche projiziert, wenn die Ka-mera weit entfernt ist (Abbildung 14a). Nähert sich die Kamera der Geländeoberfläche wird in die stark generalisierte Karte überblendet (Abbildung 14b und c). Befindet sich die Kamera nah an der Geländeoberfläche wird die detaillierte Karte hinzugeblendet (Abbildung 14d). Die Verblen-dungstexturen in diesem Beispiel stellt sicher, dass nur soviel Detail auf der Geländeoberfläche dargestellt wird, wie in der momentanen Situation für den Betrachten sinnvoll ist.

Vektortextur Ein großer Teil thematischer und topographischer Informationen ist in Form von Vektordaten erfasst. Wir verstehen unter Vektordaten jede Form von analytisch beschriebenen 2D- bzw. 3D-Daten. Bei der Darstellung dieser Daten werden graphische Primitive wie Punkte (z. B. für Städte oder Sehenswürdigkeiten), Linien (z. B. für Straßennetze, Flüsse oder Küstenlinien) oder Polygo-ne (z. B. für politische Regionen oder Vegetationszonen) verwendet. Eine Vektortextur (VectorTexture) erlaubt die Verwendung von Vektordaten in einer Textur-schicht. Dabei werden durch ein hardwarebeschleunigtes Verfahren die Vektordaten in Echtzeit rasterisiert und das resultierende Rasterbild in hoher Qualität auf die Geländeoberfläche proji-

(a) (b)

(c)

(d)

Abbildung 14: Verblendung von Texturschichten unterschiedlicher Informationsintensität in Abhän-gigkeit von der Kameraentfernung.


22

ziert. Dieses Verfahren nutzt den OpenGL P-Buffer [96], um sämtliche Operation (Rasterisierung und Speicherkopieren) direkt auf der Graphikhardware ablaufen zu lassen. Die zu rasterisierenden Vektordaten werden als graphische Primitive in der Vektortextur vor-gehalten. Interaktion mit den Vektordaten kann dadurch über die Rasterrepräsentation auf dem Geländemodell erfolgen (z. B. Selektieren von graphischen Objekten in der Textur). Die techni-sche Umsetzung dieses Verfahrens wird in Kapitel 5 diskutiert.

2.3.3 Geometriebasierte 3D-Kartenbauelemente Unter geometriebasierten 3D-Kartenbauelementen verstehen wir Elemente, die sich aus geomet-rischen 3D-Primitiven (z. B. Punkten, Linien, Polygonen) aufbauen. Im Gegensatz dazu stehen die rasterbasierten 3D-Kartenbauelemente, die als Rasterpunkte auf die Geländeoberfläche proji-ziert werden (siehe Abschnitt 2.3.2). Die einfachen geometriebasierten 3D-Kartenbauelemente Punkte, Linien und Kurven (Points, Lines, Curves) verfügen jeweils über eine Menge von Positionen, die die jeweilige Form be-schreiben, eine Zeichenfarbe und eine Zeichengröße. Diese Elemente werden pixelpräzise ge-zeichnet, das heißt die Zeichengröße wird in Pixel angegeben. Ist z. B. die Punktgröße 10, werden unabhängig von der Entfernung des Punktes für jeden Punkt 10*10=100 Pixel eingefärbt. Polygone (Polygons) verfügen über eine Menge von Positionen, die die Polygonkanten festlegen sowie eine Zeichenfarbe. Überschneidungen der Polygonkanten sind möglich und werden berück-sichtigt. Textmarkierungen (Labels) sind 3D-Kartenbauelemente, die zur Integration von Kartenschrift in einer 3D-Karte dienen. Die Textinformation, die Schriftart, -größe und -farbe sowie die Aus-richtung können festgelegt werden. Textmarkierungen sind i.d.R. zur Kamera ausgerichtet, um bestmögliche Lesbarkeit zu gewährleisten (Abbildung 15 links). In Kombination mit Vektortextu-ren bieten sich neue Möglichkeiten zur Gestaltung von Textmarkierungen (Abschnitt 5.6). Symbole (Symbols) sind geometriebasierte 3D-Kartenbauelemente, die Container für beliebige 3D-Objekte (SceneNode) darstellen. Die 3D-Objekte können durch Symbole in einer 3D-Karte einfach oder mehrfach platziert werden. Symbole können z. B. als Landmarken zum Aufzeigen von Wegen und Richtungen (3D-Thumbnails von Elvins et al. [25]), zur Markierung diskreter Geo-Objekte und -Positionen (Abbildung 15 Mitte und rechts) oder zur Abbildung von Themati-ken als 3D-Objekte (Emaps von Ervin [26]) eingesetzt werden. Wie die zuvor erwähnten geomet-riebasierten 3D-Kartenbauelemente verfügen Symbole über eine Menge von Positionen, eine Zei-

Abbildung 15: Symbole und Textmarkierung zur Repräsentation der Sehenswürdigkeit „Marienburg“ (links), Landmarken zur Navigationsunterstützung (Mitte) und Symbole zur Markierung bebauter Ge-biete und Waldgebiete (rechts).


23

chenfarbe und eine Zeichengröße, die in Form eines Skalierungsvektors in Objektkoordinaten an-gegeben werden kann. Alle geometriebasierten 3D-Kartenbauelemente haben gemein, dass sie unter Umständen mit der dargestellten geometrischen Geländeoberfläche aufgrund einer groben Approximation kollidieren können. Zur Minimierung dieses Effektes können alle geometriebasierten 3D-Kartenbauelemente mittels eines geometrischen Versatzes über der Geländeoberfläche positioniert werden. Die Posi-tion wird allerdings auf diese Weise nicht korrekt wiedergegeben (Schweben über dem Gelände). In Kapitel 5 wird ein rasterbasierter Ansatz beschrieben, der diese Probleme für visuelle 3D-Kartenbauelemente löst, die direkt auf der Geländeoberfläche liegen. Abbildung 16 zeigt eine konzeptuelle Sicht auf eine typische 3D-Karte und deren visuelle 3D-Kartenbauelemente; sie bestehen aus Geländemodell, rasterbasierten und geometriebasierten 3D-Kartenbauelementen.

Textur Kombination

Schattierungstextur

Anwendung auf

Visualisierung

Rasterbildtextur Symbole Labels

Geländemodell

Kartenansicht

Visualisierung

Vektortextur

Rasterisierung

Vektordaten Vektordaten Vektordaten Vektordaten

Abbildung 16: Kartenansicht einer konkreten 3D-Karte und die ihr zugrundeliegenden geometriebasierten und texturbasierten 3D-Kartenbauelemente.

2.4 Strukturelle 3D-Kartenbauelemente

24

2.4 Strukturelle 3D-Kartenbauelemente Strukturelle 3D-Kartenbauelemente werden eingesetzt, um 3D-Kartenbauelemente konzeptionell zu ordnen und um Beziehungen zwischen ihnen auszudrücken. Strukturelle 3D-Kartenbauelemente erlauben dem Benutzer große, individuelle Sammlungen von 3D-Kartenbauelementen zu klassifizieren und zu organisieren.

2.4.1 Gruppe Gruppen (Group) sind Kartenbauelemente, die andere Kartenbauelemente hierarchisch ordnen. Eine Gruppe besteht aus einer Menge von typhomogenen oder typinhomogenen Kartenbauelemen-ten. Gruppen können Hierarchien bilden, das heißt Gruppen können Untergruppen enthalten. Ein Kartenbauelement kann grundsätzlich nur einer Gruppe angehören. Zum Beispiel kann die Gruppe „Straßen“ alle Kartenbauelemente, z. B. Vektordaten und 3D-Objekte, enthalten, die Straßen repräsentieren. Untergruppen für Autobahnen, Bundes- und Lan-desstraßen können eine weitere Unterteilung darstellen. Gruppen behandeln visuelle 3D-Kartenbauelemente in besonderer Weise: Es wird aus den enthal-tenen 3D-Kartenbauelementen ein Szenengraph aufgebaut, der eventuelle Auswirkungen von E-lementen untereinander berücksichtig (z. B. geometriebasierte Kartenbauelemente ohne aktivier-ten Tiefentest werden zum Schluss gezeichnet), das heißt der Kartenentwickler kann Querbezie-hungen bzgl. des Renderings vernachlässigen.

2.4.2 Kategorie Kategorien (Category) sind 3D-Kartenbauelemente, die anderen Kartenbauelementen zusätzli-che Semantik zuzuweisen. Ein Kartenbauelement kann mehreren Kategorien angehören; eine Ka-tegorie kann homogen oder inhomogen sein, das heißt nur mit Kartenbauelementen eines Typs oder beliebigen Typs assoziiert werden. Zum Beispiel kann die homogene Kategorie „Wegweiser“ ausschließlich Landmarken enthalten. Die inhomogene Kategorie „Planungsvorschlag-1“ kann visuelle Kartenbauelemente zusammen fassen, die zu einer bestimmten Planungsvariante gehören. Kategoriegesteuert können Kartenbauelemente selektiert, aktiviert, deaktiviert oder in anderer Weise ausgewertet werden.

2.4.3 Attributtabelle Eine Attributtabelle (AttributTable) dient als Datencontainer für zusätzliche thematische In-formationen, die einem oder mehreren visuellen 3D-Kartenbauelementen zugeordnet werden kön-nen. Diese Informationen beeinflussen in der Regel die Darstellung visueller 3D-Kartenbauelemente nicht, sondern machen beschreibende Aussagen. Die Informationen können z. B. aus Datenbanken oder XML-Dateien ausgelesen werden. Dabei besteht ein Eintrag aus ei-nem beliebigen Schlüssel und einem Wert z. B. ("MY_ID", "XYZ1234") oder ("WWW", "www.myweb.com"). Es können beliebig viele Einträge in einer Attributtabelle abgelegt sein.

2.4.4 Projekt Das 3D-Kartenprojekt verwaltet alle zu einer 3D-Karte komponierten 3D-Kartenbauelemente. Es speichert Kontextinformationen zu einer 3D-Karte, wie Name der Karte, Erstellungsdatum oder Autor. Im 3D-Kartenprojekt kann nach Elementen mit bestimmten Eigenschaften (z. B. Katego-rie, Elementtyp) gesucht werden. Der Inhalt eines Projektes kann persistent auf einen Datenspei-cher geschrieben und von dort wieder eingelesen werden. Der Austausch von 3D-Karten als digi-tale, in sich geschlossene Dokumente über Rechnergrenzen hinweg wird dadurch ermöglicht.


25

2.5 Verhaltengebende 3D-Kartenbauelemente Verhaltengebende 3D-Kartenbauelemente dienen dazu, Interaktivität in einer 3D-Karte zu realisieren. Sie umfassen Ereignistypen und Objekte, die bestimmte Ereignistypen auslösen oder die auf bestimmte Ereignistypen reagieren. Um visuellen 3D-Kartenbauelementen ein von ihrer Klasse unabhängiges Verhalten zuordnen zu können, werden verhaltengebende 3D-Kartenbauelemente separat modelliert. Das anwendungsspezifische Verhalten wird durch die Assoziation von visuellen mit verhaltengebenden 3D-Kartenbauelementen definiert (Abbildung 17).

2.5.1 Ereignistypen Die Kommunikation zwischen 3D-Kartenbauelementen erfolgt über Ereignisse (Event). Ereig-nisse werden von verhaltengebenden 3D-Kartenbauelementen ausgesandt, wenn bestimmte Um-stände eintreffen, die mitgeteilt werden sollen (z. B. „Gelände wird selektiert“). Zu jedem auftre-

Event

TimeEvent

RedrawEvent

DistanceEvent

SelectEvent

VisibleEvent

BehaviorNode

Navigation

EventTable

Animation

GeoRef

*

AttributeTable

Group Category

RayQuery

<<send>>

<<send>>

<<send>>

*

*

*

*

Projekt

CollisionEvent<<send>>

*

*

*

Abbildung 17: Klassendiagram der verhaltengebenden und strukturellen 3D-Kartenbauelemente.

2.5 Verhaltengebende 3D-Kartenbauelemente

26

tenden Ereignis wird ein Ereignisobjekt mit der entsprechenden Kontextinformation erzeugt und durch den Verhaltensgraphen von VRS geleitet. Im Verhaltensgraphen registrierte Ereignisver-werter (BehaviorNode) erhalten das Ereignis mitgeteilt und reagieren ggf. auf selbiges. Es gibt folgende Typen von Ereignissen: Benutzerbezogene Ereignisse werden durch Interaktion des Benutzers ausgelöst.

ButtonEvent: Mausknopf wird durch den Benutzer in der 3D-Kartenansicht gedrückt. Mausposition und gedrückter Knopf werden im Ereignisobjekt gespeichert. MotionEvent: Die Maus wird über die 3D-Kartenansicht bewegt. Momentane Position der Maus wird im Ereignisobjekt gespeichert.

Systembezogene Ereignisse werden automatisch vom 3D-Kartensystem generiert. TimeEvent: Periodisch auftretendes Ereignis, das nach einer einstellbaren Zeitdauer auftritt. Der Zeitpunkt des Auftretens wird im Ereignisobjekt gespeichert. RedrawEvent: Der Inhalt der 3D-Kartenansicht wird neu gezeichnet. Die zugehörige Kartenansicht und der Zeitpunkt werden im Ereignisobjekt gespeichert.

Bauelementbezogene Ereignisse sind higher-level Ereignisse, die direkt mit visuellen 3D-Kartenbauelementen zusammenhängen und unter Umständen aus vorherigen Ereignissen resultie-ren. Klickt der Benutzer zum Beispiel mit der Maus auf die Geländeoberfläche, wird ein ButtonEvent und – wegen der Selektion der Geländeoberfläche – zusätzlich ein SelectEvent erzeugt.

SelectEvent: Ein visuelles 3D-Kartenbauelement wird durch den Benutzer mit der Maus selektiert. Das getroffene Bauelement und der Treffpunkt werden im Ereignisobjekt gespeichert. VisibleEvent: Ein visuelles 3D-Kartenbauelement ändert seinen Sichtbarkeitsstatus im Sichtvolumen der Kamera, das heißt das Bauelement wird sichtbar und war vorher unsichtbar oder es wird unsichtbar und war vorher sichtbar. Der aktuelle Sichtbarkeits-status wird im Ereignisobjekt gespeichert. DistanceEvent: Der momentane Abstand von der Kamera zu einem visuellen 3D-Kartenbauelement hat sich geändert. Die Entfernung zur Kamera wird im Ereignisobjekt gespeichert. CollisionEvent: Die Kamera wird gegen ein visuelles 3D-Kartenbauelement navi-giert. Das getroffene Bauelement und die Position werden im Ereignisobjekt gespeichert.

2.5.2 Ereignissender Benutzerbezogene und systembezogene Ereignisse werden durch das graphische Benutzungs-schnittstellensystem registriert und an den VRS-Verhaltensgraph weitergeleitet (VRS Event Map-ping). Elementbezogene Ereignisse hingegen werden von speziellen 3D-Kartenbauelementen ge-neriert und an den Verhaltensgraphen gesendet.

Strahlentest Objekte innerhalb einer 3D-Karte können mittels eines Strahlentests (RayQuery) analytisch er-fragt werden. Ein Strahl wird dabei durch Ursprung und Richtung spezifiziert. Beim Strahlentest werden sämtliche visuellen 3D-Kartenbauelemente auf Intersektion untersucht. Trefferergebnisse werden dabei durch das Selektionsereignis SelectEvent mitgeteilt, das heißt an den VRS-Verhaltensgraph weitergeleitet. Mit Hilfe des Strahlentests wird so z. B. die interaktive Identifika-tion von 3D-Kartenbauelementen ermöglicht.


27

Kollisionserkennung Die Kollisionserkennung erfolgt über das 3D-Kartenbauelement Navigation, das für die Navi-gation in der 3D-Karten zuständig ist (siehe Abschnitt 2.5.4 und 6.5.2). Kollisionen der Kamera mit visuellen 3D-Kartenbauelementen werden dort registriert und als CollisionEvent an den Verhaltensgraph weitergeleitet.

Sichtbarkeits- und Abstandsveränderung Neben der Strukturierung von 3D-Kartenbauelementen dienen Gruppen auch als Sender für Sichtbarkeits- und Abstandsereignisse. Die Sichtbarkeitsinformation von visuellen 3D-Kartenbauelementen wird in der Gruppe (Group) berechnet, um unsichtbare Elemente ausfindig zu machen und damit die Darstellungsgeschwindigkeit zu erhöhen. Ändert sich die momentane Sichtbarkeit im Vergleich zum vorherigen Renderingdurchlauf, wird eine Sichtbarkeitsereignis an den VRS-Verhaltensgraph gesendet.

2.5.3 Ereignistabelle Ereignistabellen (EventTable) sind generische verhaltengebende 3D-Kartenbauelemente, die Ereignisse mit Aktionen assoziieren. Mögliche Ereignistypen sind die in den vorangegangenen Abschnitten beschriebenen Ereignistypen. Unterschiedliche visuelle 3D-Kartenbauelemente kön-nen gemeinsam eine Ereignistabelle und damit ein einheitliches Verhalten besitzen. Aktionen werden durch Callbacks, die auf eine benutzerdefinierte Anwendungsfunktion verwei-sen, mit Ereignissen verknüpft. Als Argument erwartet die Anwendungsfunktion das Ereignisob-jekt, aus dem die Kontextinformation über das Ereignis genommen wird. Anwendungsfunktionen können sowohl direkt in C++ oder – dank der Interpreteranbindung iVRS – in Tcl implementiert werden (Abschnitt 7.3.6). Die Spezifikation von „Verhaltensanweisungen“ in Form von Tcl Skripten ermöglicht eine Individualisierung des Verhaltens einer 3D-Karte, die zur Laufzeit erfol-gen kann. Wir unterscheiden zwischen globalen und lokalen Ereignistabellen. Diese Unterscheidung erlaubt eine spezielle Verhaltensspezifikation in lokalen und eine allgemeine Verhaltensspezifikation in globalen Ereignistabellen. Globale Ereignistabellen verarbeiten alle eingehenden elementbezoge-nen Ereignisse, unabhängig davon, ob die konkrete Ereignistabelle zu einem 3D-Kartenbauelement assoziiert ist oder nicht (z. B. „die Sichtbarkeit aller 3D-Kartenbauelemente soll überwacht werden“) . Lokale Ereignistabellen reagieren nur auf die elementbezogenen Ereig-nisse, die sich auf assoziierte visuellen 3D-Kartenbauelemente beziehen (z. B. „die Sichtbarkeit spezieller 3D-Kartenbauelemente soll überwacht werden“).

2.5.4 Navigation Das 3D-Kartenbauelement Navigation stellt unterschiedliche Funktionalitäten zur Navigation durch 3D-Karten bereit. Es reagiert auf Zeit- und Mausereignisse. Einschränkungen der Bewe-gungsfreiheit der Kamera vereinfachen dabei die Navigation in der 3D-Karte, z. B. führt die Kol-lisionserkennung mit dem Geländemodell zur automatischen Korrektur der Kameraposition. Zu den bereitgestellten Navigationsmetaphern zählen: Panning, Zooming, Flyer, Kugel- und Ke-gel-Metapher. Diese Navigationsmetaphern werden in Kapitel 6 erläutert.

2.5.5 Animation Hinter der Animation (Animation) steht eine automatisierte Steuerung der Kameraparameter (z. B. Position und Blickrichtung) in Abhängigkeit festzulegender Animationspfade und der Zeit. Die Animationsgeschwindigkeit, die Dauer und Anzahl der Schleifendurchläufe sind dabei frei wählbar.

2.6 Zusammenfassung

28

Bei der Erzeugung einer Kameraanimation wird eine Kurve (Curve) Cfrom für die Spezifikation der Kameraposition und ggf. eine Kurve Cto für die Spezifikation der Kamerablickrichtung fest-gelegt. Während der Animation wird in Abhängigkeit der Zeit die momentane Kameraposition mittels der Kurve Cfrom und die momentane Kamerablickrichtung mittels der Kurve Cto errechnet. Die resultierende Animation kann in einen Video im AVI-Format abgelegt werden.

2.5.6 3D-Kartenansichten Eine 3D-Kartenansicht (3DView) repräsentiert das physikalische Fenster in eine 3D-Karte. Eine 3D-Kartenansicht spezifiziert, in welchem Bereich (Canvas) der graphischen Benutzungsober-fläche der Inhalt der 3D-Karte gezeichnet wird und welche Kameraparameter (LookAt, Perspective) für diese Sicht gewählt werden. Zusätzlich verfügt eine 3D-Kartenansicht über eine Gruppe, in die darzustellende visuelle 3D-Kartenbauelemente eingefügt werden (Abbildung 18). Ein 3D-Karte des vorgestellten 3D-Kartensystems enthält zwingend ein 3D-Kartenansichtsbauelement und ein Geländemodellbauelement. Im Allgemeinen enthält die 3D-Karte darüber hinaus eine Vielzahl von rasterbasierten und geometriebasierten Bauelementen, die die jeweils fachspezifischen Daten repräsentieren. Die 3D-Kartenansicht delegiert die 3D-Kartenbauelemente anhand des Typs entweder an die zugehörige Gruppe oder an den Verhaltens-graphen.

2.6 Zusammenfassung Das 3D-Kartensystem stellt eine Sammlung von 3D-Kartenbauelementen bereit, die die Kon-struktion von 3D-Karten ermöglichen. 3D-Karten können aus einer relativ überschaubaren Menge von Bauelementtypen aufgebaut werden, die dank der Unterteilung in visuelle, strukturelle und verhaltengebende 3D-Kartenbauelemente zueinander große Orthogonalität besitzen und meist anwendungs- und domänenübergreifende Leistungsmerkmale besitzen. Das zugrunde liegende Multiresolutionsgeländemodell erlaubt eine qualitativ hochwertige und effiziente Darstellung von Geländedaten, Rasterdaten und Vektordaten. Rasterdaten können mit-

Group

View

Canvas LookAt Perspective

1 1 1

1

GeoRef*

«singleton»Terrain

Projekt

*

*

Abbildung 18: Klassendiagramm der 3D-Kartenansicht und zugeordnete Klassen weiterer 3D-Kartenbauelemente.


29

tels Texturschichten pixelpräzise und hardwareunterstützt auf die Geländeoberfläche projiziert werden. Die Verwendung mehrerer Texturschichten sowie deren Überlappung ermöglicht die vi-suell komplexe Gestaltung einer 3D-Karte. Der modulare Aufbau des 3D-Kartensystems und die integrierte Interpreteranbindung, ermögli-chen es, 3D-Karten-Anwendungen mit unterschiedlichen Schwerpunkten zu entwickeln (z. B. In-tegration von Datenbankanbindung oder Webdiensten durch Tcl). Der Zustand einzelner 3D-Kartenbauelemente ist über die Interpreteranbindung zur Laufzeit skriptgesteuert änderbar. Ins-besondere lässt sich über die Interpreteranbindung die Funktionalität der 3D-Kartenbauelemente leicht erschließen und erlernen.

31

Kapitel 3 VISUALISIERUNG VON DIGITALEN GELÄNDEMODELLEN

Ein digitales Geländemodell (DGM) beschreibt die Oberfläche eines realen (oder gedachten) Ge-ländes annäherungsweise durch eine Menge diskreter Punkte im Raum. Die Raumpunkte werden in den Geowissenschaften oft in Gauß-Krüger-Koordinaten oder in universalen transversalen Mercator-Koordinaten spezifiziert. Die durch das Modell beschriebene Oberfläche, kurz Gelän-deoberfläche genannt, liegt im Allgemeinen als Menge von Polygonen vor, die von der Graphik-hardware dargestellt wird. Die Oberfläche wird aus den Raumpunkten des DGM abgeleitet, z. B. durch Delaunay-Triangulation [72]. Digitale Geländemodelle werden im Allgemeinen durch Gitter- oder TIN-Strukturen beschrieben. Ein Gitter (GRID) ist ein Satz von rechtwinkligen Zellen oder von Punkten, die in Zeilen und Spalten angeordnet sind, wobei die Zellen bzw. Punkte i.d.R. äquidistant verteilt sind (Abbildung 19 links). Ein Triangulated Irregular Network (TIN) stellt eine irreguläre Tessellation der Ge-ländeoberfläche basierend auf Dreiecken dar, die auf einen Satz unregelmäßig verteilter Punkte zurückzuführen sind (Abbildung 19 Mitte). Das TIN wird durch eine willkürliche Verteilung von Punkten erstellt, die zu Dreiecken verbunden werden. Hierfür wird zumeist die Delaunay-Triangulation verwendet. Für jeden Punkt werden die (x,y,z)-Koordinaten explizit abgespeichert. Im Unterschied zum Gitter erlaubt das TIN eine hohe Informationsdichte in komplexen Bereichen und geringe Informationsdichte in homogenen Bereichen (Abbildung 20 links): Ein Gebirgskamm wird mit vielen Dreiecken nachgebildet um die Morphologie möglichst gut wiederzugeben. Ein Gitter speichert ein Höhenmodell i.d.R. effizienter als ein TIN, weil nur die Höhe zu jedem Punkt gespeichert werden muss. Die anderen Koordinaten lassen sich aus der Gitterweite und der Gitterposition errechnen. Allerdings wird die gesamte Geländeoberfläche in der gleichen Auflö-sung approximiert, was bei der Darstellung homogener Geländebereiche unnötige Ressourcen verbraucht (Abbildung 20 rechts), z. B. ergäbe die Darstellung einer ebenen Fläche durch 10x10

3.1 Rendering von TIN- und Gitterdaten

32

Gitterpunkte 200 zu zeichnende Dreiecke. Zudem können morphologische Strukturen, wie etwa ein Gebirgskamm, durch das äquidistante Gitter nur ungenau wiedergegeben werden. Um die Vorteile beider Strukturen zu vereinen, wurde von Buziek und Kruse [13] eine hybride Struktur entwickelt, die TINs zur detaillierten Repräsentation morphologischer Strukturen und Gitter für homogene Bereiche der Geländeoberfläche verwendet. Das gesamte Geländemodell liegt als Gitterrepräsentation vor, wobei einzelne Gitterzellen zusätzlich über Feinstrukturen ver-fügen (Abbildung 19 rechts). Der Speicherverbrauch ist dadurch geringer als eine vollständige TIN-Repräsentation und die Qualität der Repräsentation ist höher als die einer reinen Gitter-Repräsentation.

3.1 Rendering von TIN- und Gitterdaten Die Darstellung der Geländegeometrie erfolgt in der Regel durch Dreiecke bzw. Dreiecksstreifen. Dreiecksstreifen nutzen Nachbarschaftsinformationen von Dreiecken aus, um die Anzahl der zur Graphikhardware zu übertragenden Eckpunkte zu reduzieren und damit die Darstellungsge-schwindigkeit zu erhöhen. Um n Dreiecke einzeln zu übertragen, benötigt man 3⋅n Punkte. Kön-nen die Dreiecke als Dreiecksstreifen übertragen werden, benötigt man nur noch n+2 Punkte (Abbildung 21). Gitter lassen sich auf diese Weise sehr effizient zeilenweise mit Dreiecksstreifen darstellen. Da TINs auf einzelnen Dreiecken basieren, können Dreiecksstreifen nur durch zusätz-lichen Rechenaufwand daraus abgeleitet werden; ein Streifenermittlungsverfahren wird z. B. in Speckmann und Snoeyink [84] vorgestellt. Die Darstellung eines Geländemodells, dass durch ein 1000 × 1000 Zellen großes Gitter repräsen-

(a)

(b)

(c)

Abbildung 19: Repräsentation einer Geländeoberfläche erfolgt durch Gitter (a), durch Triangulated Irregular Network (TIN) (b) oder durch eine hybride Struktur, die Gitter und TINs kombiniert (c).

Abbildung 20: Geländeoberfläche dargestellt als reguläres Gitter (links) und als TIN (rechts).

Kapitel 3 - Visualisierung von digitalen Geländemodellen

33

tiert wird, erfordert 1000 × 1000 × 2 = 2.000.000 Dreiecke. Um ein interaktives Arbeiten mit dem Geländemodell zu erreichen, muss das Modell mindestens 10 mal pro Sekunde gezeichnet werden können, das heißt pro Sekunde müssen 20 Millionen beleuchtete, texturierte Dreiecke dargestellt werden. Das ist allerdings mit heutiger handelsüblicher Graphikhardware noch nicht zu erzielen. Eine besondere Aufbereitung der Geometriedaten zum Rendering ist somit notwendig.

3.2 Level-of-Detail-Modellierung Die Anforderungen der Echtzeit-Visualisierung machen eine Reduktion der zur Visualisierung nötigen Geodaten unumgänglich. Die geometrische Komplexität lässt sich durch die Level-of-Detail-Modellierung (LOD-Modellierung) senken. Durch die perspektivische Projektion eines Geländemodells bei der Darstellung erscheinen gleichgroße Dreiecke, die in der Nähe der virtuel-len Kamera liegen, größer als solche, die weit von der Kamera entfernt sind. Diese Tatsache ma-chen sich Multiresolutionsmodelle zu nutze. Ein Multiresolutionsmodell stellt unterschiedliche LODs der Geländegeometrie bereit, die zur Laufzeit in Abhängigkeit von Kamera- oder Kontext-parametern passend generiert oder ausgewählt werden, wobei „passend“ von dem im jeweiligen Verfahren implementierten Fehlerkriterium abhängt. In der Nähe der Kamera werden hoch aufge-löste und in größerer Entfernung schwächer aufgelöste Oberflächenausschnitte gewählt. Die visu-elle Qualität der Darstellung verhält sich dabei antiproportional zur Geschwindigkeit des Bildauf-baus.

3.3 Anforderungen im Kontext von 3D-Karten Das Geländemodell ist ein wesentlicher Bestandteil der Bildgenerierung im 3D-Kartensystem. Im Kontext von 3D-Karten ergeben sich folgende Anforderungen an das zu verwendende Gelände-modell:

- Die Darstellungsqualität muss ausreichen, um morphologische Strukturen der Gelände-oberfläche detailliert wiederzugeben.

- Die Darstellungsgeschwindigkeit muss ausreichen, um ein interaktives Arbeiten mit um-fassenden Datenmengen zu ermöglichen.

- Die Skalierbarkeit von Darstellungsqualität und -geschwindigkeit ist gefordert, um für die zugrundeliegende Graphikhardware optimale Leistung zu erreichen.

- Das Darstellungsverfahren muss sowohl für Geometrie- als auch für Rasterdaten (z. B. Satellitenaufnahmen, Landnutzungsdaten, Orthophotos) ausgelegt sein. Insbesondere muss die Verwendung von umfangreichen, multiplen, unter Umständen überlappenden Rasterdatenschichten möglich sein.

P1

P0

P2

P3

P4 P5

P1

P0 P2

P3

P4

P5

Abbildung 21: Dreiecksstreifen reduzieren die Anzahl der an die Graphikhardware zu übertragenden Eckpunkte.

3.4 Verwandte Arbeiten zur Geländemodellierung

34

3.4 Verwandte Arbeiten zur Geländemodellierung In den vergangenen Jahren wurden eine Vielzahl an LOD-Geländemodellen für den Einsatz in unterschiedlichen Anwendungsgebieten (z. B. Geowissenschaften, Unterhaltungsindustrie, Mul-timedia) entwickelt. Man kann dabei zwischen TIN- (z. B. Hoppe [46], De Floriani et al. [28]) und Gitter-basierten (z. B. Falby et al. [27]) Geländemodellen unterscheiden. Die Gitter-basierten Multiresolutionsmodelle wurden in der jüngeren Vergangenheit erweitert, um beim Rendering kontinuierliche Geländeoberflächen zu ermöglichen (z. B. Lindstrom und Pascucci [57] sowie Pajarola [71]). Im Folgenden werden drei repräsentative LOD-Geländemodelle diskutiert. Zum einen das Pro-gressive Mesh von Hoppe [46], das eine aus TINs bestehende stetige Geländeoberfläche model-liert, der Restricted Quadtree von Pajarola [71], der sich besonders für große DGM eignet, und der Algorithmus von Lindstrom und Pascucci [57], der sehr kompakt beschrieben werden kann und auf Gittern basiert.

3.4.1 Progressive Mesh Hoppe hat zur auflösungsvarianten Modellierung allgemeiner polygonaler Oberflächen das Pro-gressive-Mesh-Verfahren entwickelt, das eine kontinuierliche Darstellung der Oberfläche in Ab-hängigkeit der Kameraparameter [46] garantiert. Das Verfahren wurde speziell für Geländeober-flächen optimiert [44]. Ein Progressive-Mesh ist eine Datenstruktur, die eine Sequenz von Verfeinerungsoperationen ausgehend von einem grob aufgelösten Anfangsmodell festlegt. Bei einer Verfeinerungsoperation werden aus einem Knoten des momentanen Modells zwei Knoten generiert. Auf diese Weise wer-den eine neue Kante und zwei neue Dreiecke eingefügt (Abbildung 22). Die Verfeinerungsopera-tion wird auch vertex-split-Operation genannt. Die Sequenz der vertex-split-Operationen {vs0, vs1, ... vsn-1} wird in einem Vorberechnungs-schritt generiert. Dabei wird die vertex-split-Operation so gewählt, dass das Model Mi nach se-quenziellem Abarbeiten der ersten i vertex-split-Operationen das höchstaufgelöste Model besser approximiert als Mi-1. Werden sämtliche vertex-split-Operationen angewandt, erhält man das höchstaufgelöste Modell Mn. Um das Modell Mn auf ein gröber aufgelöstes Modell zurückzufüh-ren, werden die zur vertex-split-Operation inversen edge-collapse-Operationen ausgeführt (Abbildung 22). Hoppe zeigt, dass die Folge der vertex-split-Operationen eine eindeutige Knotenhierarchie defi-niert. Diese Hierarchie erlaubt es, selektiv verfeinerte Progressive-Mesh-Modelle zu erzeugen, die

Abbildung 22: Edge-collapse-Operation werden zur Vereinfachung des Modells und vertex-split-Operation zur Verfeinerung des Modells verwendet.


35

nicht in der Folge M0, ..., Mn enthalten sind. Ein selektiv verfeinertes Progressive-Mesh-Modell wird dabei durch eine Ecken-Front in der Knotenhierarchie repräsentiert. Die Ecken-Front wird durch die inkrementelle Anwendung von vertex-split-Operationen und edge-collapse-Operationen generiert. Bei der Darstellung eines Progressive-Mesh wird ausgenutzt, dass sich aufeinander fol-gende Bilder Fj und Fj+1 i.d.R. durch geringe Änderungen der Kamera auszeichnen (frame-to-frame coherence). Durch diese Annahme kann das Modell Fj+1 inkrementell aus dem Modell Fj durch Anwendung von wenige vertex-split- und edge-collapse-Operationen hergeleitet werden. Zur Minimierung von visuellen Störungen beim Übergang von einem Modell zum nächsten ent-wickelte Hoppe Geomorphs [45]. Ein Geomorph animiert eine vertex-split- oder eine edge-collapse-Operation für eine festlegbare Zeitdauer, durch lineare Interpolation zwischen den beteiligten Eckpunkten. Das Progressive-Mesh-Verfahren ist ein allgemeines Verfahren, dass nicht nur auf digitale Ge-ländemodelle ausgelegt ist, sondern auf allgemeine polygonale 3D-Objekte angewandt werden kann. Zusätzlich können visuelle Attribute, wie z. B. Eckpunktfarben oder -normalen, in dem Verfahren berücksichtigt werden; die Verwendung multipler Texturschichten ist möglich (Sander et al. [75]). Allerdings wird die Unterstützung nur beschrieben für Rasterbilder, die den Anforde-rungen von OpenGL genügen und damit z. B. Größenbeschränkungen unterliegen (Abschnitt 4.1.1).

3.4.2 Restricted Quadtree Pajarola [71] entwickelte seine adaptive Restricted-Quadtree-Triangulation (RQT) für Gitter mit Hilfe einer Quadtree-Datenstruktur (Samet [74]). Das Verfahren eignet sich insbesonders für große digitale Geländemodelle, die nicht vollständig im Hauptspeicher gehalten werden können, da nicht benötigte Bereiche (Patches) des Geländemodells ausgelagert werden können. Für jeden einzelnen Patch wird eine RQT bereitgestellt, wobei das zugrundeliegende Gitter quadratisch sein und aus (2n+1) × (2n+1) Stützpunkten bestehen muss. Bei einem allgemeinen Quadtree treten an den Grenzen zwischen Auflösungsstufen Unstetigkeits-stellen der Geländeoberfläche auf (Abbildung 23). Zur Erzeugung einer RQT wird deshalb ein Abhängigkeitsgraph für die durch das Gitter definierten Punkte generiert. Der Abhängigkeits-graph speichert für jeden in einer RQT enthaltenen Gitterpunkt die Gitterpunkte, die in der RQT enthalten sein müssen, damit keine Unstetigkeitsstellen auftreten (Abbildung 24). Bei der rekursiven Traversierung des Quadtrees wird anhand eines Fehlerkriterium entschieden, welche Gitterpunkte pi in der RQT dargestellt werden sollen. Zusätzlich zu den pi werden alle Gitterpunkte pk, von denen ein pi abhängt, mit berücksichtigt. Der Abhängigkeitsgraph gewähr-leistet, dass sich beim Zeichnen die Höhen benachbarter Quadtree-Knoten höchstens um eine Stu-fe unterscheiden, so dass eine stetige RQT konstruiert werden kann.

Abbildung 23: Bei einem allgemeinen Quadtree treten an den Grenzen zwischen Auflösungsstufen Unste-tigkeitsstellen der Geländeoberfläche auf, die die Darstellungsqualität mindern

3.4 Verwandte Arbeiten zur Geländemodellierung

36

Die Restricted-Quadtree-Triangulation unterstützt eine effiziente Darstellung der Geländeoberflä-che durch Dreiecksstreifen, die aus dem Abhängigkeitsgraphen extrahiert werden können. Da nicht das gesamte Geländemodell durch einen RQT repräsentiert wird, ist eine Übersicht des Ge-ländemodells nicht ohne weiteres möglich. Die Unterstützung für Texturschichten ist nicht be-schrieben.

3.4.3 Algorithmus von Lindstrom Lindstrom und Pascucci [57][58] nutzen für ihr gitterbasiertes Geländemodell ebenfalls eine Quadtree-Datenstruktur (Samet [74]). Der beschriebene Algorithmus ist sehr kompakt, erzeugt dennoch eine kontinuierliche Geländeoberfläche, das heißt er vermeidet Störungen beim Übergang zwischen Auflösungsstufen (continuous level of detail, CLOD). Die Knoten des Quadtree werden als Blöcke bezeichnet und umfassen jeweils 3 × 3 Stützpunkte. Für jeden Block wird die maximale Abweichung der Höhe zwischen der vereinfachten Triangulie-rung des 3 × 3 Blocks und der Triangulierung aller Punkte gespeichert, die von dem Block über-deckt werden. Zur Darstellung des Geländemodells wird der Quadtree rekursiv durchlaufen und für jeden Block die bestimmte maximale Abweichung auf die Sichtebene projiziert. Die projizierte Abweichung dient als Maß für die visuelle Qualität. Ist die visuelle Qualität ausreichend, wird die Rekursion angehalten. Andernfalls wird mit den vier Kind-Blöcken fortgefahren. Die Verknüp-fung der Randpunkte eines Blocks mit denen des Nachbarblocks ermöglicht eine stetige, sichtab-hängige, auflösungsvariante Geländeoberfläche (Abbildung 25).

Abbildung 24: Der Abhängigkeitsgraph legt fest, welche Gitterpunkt zusätzlich gezeichnet werden müssen, um eine stetige Geländeoberfläche zu gewährleisten.

Abbildung 25: Eine stetige Darstellung der Geometrie-Hierarchie wird mittels zusammenhängender Dreiecksstreifen erzielt.


37

Das Verfahren ermöglicht die Reduktion der geometrischen Komplexität der Geländeoberfläche; stellt jedoch keine explizite Funktionalität zur Verwaltung und zur Darstellung von Geländetextu-ren bereit. Ein weiterer Nachteil ist, dass das zugrundeliegende reguläre Gitter quadratisch sein und aus (2n+1) × (2n+1) Stützpunkten bestehen muss, damit es als Quadtree repräsentiert werden kann. Die vorangegangenen Verfahren erfüllen die ersten drei Anforderungen Darstellungsgeschwindig-keit und -qualität sowie der Skalierbarkeit zu genüge. Allerdings wird bei keinem der Verfahren die Verwendung von Rasterdaten ausreichend berücksichtigt: Die Verwendung multipler, sich überlappender und gleichzeitig übergroßer Rasterdaten ist nicht möglich. Das nun folgende Ver-fahren erfüllt sämtliche aufgestellte Anforderungen und fand aus dem Grund seinen Einsatz im 3D-Kartensystem.

3.5 3D-Karten Geländemodell-Geometrie Der Approximationsbaum von Baumann et al. [6] ist ein Multiresolutionsgeländemodell, das LOD-Mechanismen sowohl für Geometrie- als auch für Rasterdaten bereitstellt. Die exakte Repräsentation der Geländemorphologie wird durch die Kombination von regulären Gitterdaten und TIN-Daten, die Regionen von besonderem Interesse verfeinert modellieren, er-reicht. Als Ausgangsdaten können neben reinen TIN- oder Gitterdaten auch hybride Daten, wie in Abbildung 19 gezeigt, verwendet werden. Das daraus resultierende hybride Geländemodell er-laubt die präzise Wiedergabe morphologischer Detailinformation und die effiziente Speicherung homogener Geländebereiche (Abbildung 26). Der komplementäre Texture-Tree (Döllner et al. [20]) implementiert ein Multiresolutionsmodell für 2D-Geländetexturen. Mehrere Texturbäume lassen sich mit einem Approximationsbaum assoziieren. Dies erlaubt es, in 3D-Karten mehrere mitunter überlappende Rasterdaten darzustellen (Kapitel 4).

3.5.1 Geometrierepräsentation Der Approximationsbaum basiert auf einer Quadtree-ähnlichen hierarchischen Datenstruktur. Die Geländeoberfläche wird hierarchisch in achsenparallele Geometrieflicken (TGeometryPatch) eingeteilt. Der von einem Geometrieflicken G abgedeckte Bereich der Geländeoberfläche wird als D(G) bezeichnet. Jeder Geometrieflicken Gparent besitzt 0, 2 oder 4 Kindflicken, die den vom Vater abgedeckten Bereich D(Gparent) wieder vollständig abdecken, das heißt bei vier Kindflicken gilt D(Gparent) = D(Gchild 1) ∪ D(Gchild 2) ∪ D(Gchild 3) ∪ D(Gchild 4). Der oberste Wurzelflicken Groot

Abbildung 26: Darstellung eines hybriden Geländemodells mit Gittern (links) und zusätzlichen TIN-Feinstrukturen (rechts).

3.5 3D-Karten Geländemodell-Geometrie

38

deckt den gesamten Geländebereich ab. Die Vereinigung aller Flicken einer Stufe Li deckt die vollständige Geländeoberfläche ab. Wieviele Kinder ein Geometrieflicken erhält, hängt von sei-nem Seitenverhältnis ab; längliche Flicken werden in zwei Kindflicken unterteilt, um annähernd quadratische Geometrieflicken zu gewinnen. In Abbildung 27 ist eine Geometrieflickenhierarchie dargestellt, bei der jeder Flicken über 0 oder 4 Kinder verfügt. Bei der Erzeugung der Geometrieflickenhierarchie wird jede geometrische Repräsentation eines Flickens aus einer vorgegebenen, festen Anzahl an Dreiecken zusammengesetzt. Aufgrund der zunehmenden Anzahl von Geometrieflicken mit jeder Stufe, stellt die Geometrieflickenhierarchie eine hierarchische Datenstruktur mit unterschiedlichen Auflösungsstufen der Geländeoberfläche dar. Die geometrische Auflösung von Li+1 ist dadurch größer als die von Li. Die gröbste Auflö-sung der Geländeoberfläche stellt die Stufe L0 dar, die nur aus dem Wurzelflicken Groot besteht.

3.5.2 Renderingalgorithmus Der Renderingalgorithmus reduziert die für eine Ansicht notwendige geometrische Komplexität des Geländemodells soweit, dass es den Anforderungen des Echtzeit-Rendering genügt. Die Ein-bindung von Rasterdaten in den Algorithmus wird im anschließenden Kapitel diskutiert. Jeder Geometrieflicken stellt eine geometrische Repräsentation des abgedeckten Bereiches bereit. Die geometrische Repräsentation kann durch ein Gitter (TGridPatch), ein TIN (TTinPatch)

L0

L1

L2

L3

Abbildung 27: Räumliche Abbildung einer Quadtree-Datenstruktur. Kindflicken decken den gesamten Bereich des Elternflickens ab.

TTerrain TGeometryPatch

TTinPatch

0..4

TGridPatchTHybridPatch

1

Abbildung 28: Klassendiagramm der technischen Geländemodellbestandteile.


39

oder hybrid aus TIN und Grid (THybridPatch) erfolgen. Der Approximationsbaum (TTer-rain) enthält also durch einen Wurzelflicken die vollständige Flickenhierarchie (Abbildung 28). Zur Darstellung des Geländemodells wird die Geometrieflicken-Hierarchie vom Wurzelflicken ausgehend rekursiv durchlaufen. In Abhängigkeit von den Kameraparametern, der Fensterauflö-sung und der Projektion des maximalen Fehlers eines Geometrieflicken zum genauen Geländemo-dell wird ein Fehlermaß ermittelt. Das Fehlermaß legt fest, ob die Qualität der Darstellung eines Geometrieflicken ausreicht oder ob seine Kindflicken zur Erhöhung der Qualität herangezogen werden müssen. Auf diese Weise wird für jede Kameraeinstellung eine LOD-Darstellung des Ge-ländemodells durch zusammengesetzte Geometrieflicken erreicht (Abbildung 29): Das Gelände-modell wird nur dort hoch aufgelöst gerendert, wo es aufgrund der Kameraparameter notwendig ist. Liegt der achsenparallele, minimale Umgebungsquader (Boundingbox) eines Geometrieflicken vollständig außerhalb des Sichtvolumens, wird er und damit alle seine Kinder von weiteren Be-trachtungen ausgeschlossen; die Weitergabe der Geometriedaten an die Graphikhardware der nicht sichtbaren Geländebereiche wird unterbunden (view-frustum culling). Die unstetigen Übergänge zwischen den Auflösungsstufen werden durch senkrechte Polygone geschlossen. Der Renderingalgorithmus für die Geländegeometrie ist in Abbildung 30 skizziert.

L0

L1

L2

L3

Abbildung 29: Die Geländeoberfläche wird durch die ermittelten Geometrieflicken repräsentiert (links). Die Mehrzahl der Geometrieflicken ist daran unbeteiligt (rechts).

void render(TGeometryPatch* geo) {// Sichtbarkeit überprüfenif (isVisible(geo)) {

if (quality(geo) > threshold) {// bei unzureichender visueller Qualität// Geometrieflicken-Kinder rendernfor (int i = 0; i < geo->children(); i++) {

render(geo->child(i));}

} else {// bei ausreichender visueller Qualität// aktuellen Geoemtrieflicken rendern.draw(geo);

}}

}

Abbildung 30: Rekursiver Renderingalgorithmus für die Geländegeometrie.

3.6 Zusammenfassung

40

3.6 Zusammenfassung Wir haben einen Überblick über aktuelle Algorithmen zur Darstellung der Geometrie digitaler Geländemodelle gewonnen. Grundlage bilden jeweils Multiresolutionsmodelle, die auf die geo-metrische Darstellung der Geländegeometrie ausgerichtet sind. Der vorgestellte Approximationsbaum stellt eine robuste Lösung für die Darstellung der Gelän-degeometrie dar. Die Aufteilung in Geometrieflicken ermöglicht eine Approximation der Gelän-degeometrie und eine exakte Wiedergabe der Geländemorphologie. Der hierarchische Aufbau durch rechtwinklige Geometrieflicken ermöglicht die vielseitige Verwendung von Rasterdaten.

41

Kapitel 4 VISUALISIERUNG VON RASTERDATEN

Rasterdaten stellen eine wichtige Gruppe von Daten in der Geovisualisierung dar. Sie eignen sich gut zur Speicherung von Bilddaten mit flächenfüllenden Darstellungen und kontinuierlichen Farbverläufen, wie etwa bei Satellitenbildern oder Befliegungsaufnahmen. Eine weitere Anwen-dung ist die Speicherung diskreter Information, die in Form regulärer Raster erfasst oder berech-net werden (z. B. Landnutzungsinformation). Nachteilig gegenüber analytisch beschriebenen Vektordaten (Kapitel 5) ist der hohe Speicherbe-darf von Rasterdaten. Ein Rasterbild, dessen Pixel als Rot-Grün-Blau-Farbwerte kodiert sind, und einer Auflösung von 10.000 × 10.000 Bildpunkten erfordert 300 Megabyte an Speicher, auch dann wenn z. B. große Gebiete innerhalb des Raster die gleichen Farbwerte aufweisen. Rasterbil-der sind nicht auf Rot-, Grün-, Blaukanäle beschränkt; es lassen sich für ein Rasterbild grund-sätzlich eine beliebige Zahl von Kanälen definieren, z. B. ein Transparenz- oder Objektidentitäts-kanal. Jedoch liegen im Allgemeinen für übliche Rasterdaten solche zusätzlichen Informationen nicht direkt vor, sondern werden durch Berechnung aus den Farbinformationen ermittelt. Wegen des einfachen Datenformates, der dadurch bedingten unkomplizierten Datenweitergabe und der vielseitigen Datenmanipulationsmöglichkeiten (z. B. 2D-Bildoperationen) stellen Rasterdaten ei-nen großen Teil von in GIS gespeicherten Daten dar. Die computergraphische Verwendung von Rasterbildern wird durch das Prinzip der Texturierung ermöglicht. Unter Texturierung versteht man die Projektion von Rasterbildern auf geometrische Primitive (Haeberli und Segal [35]). In diesem Kontext spricht man anstelle von Rasterbild auch von 2D-Textur. In der Echtzeit-Computergrafik wird Texturierung seit über einem Jahrzehnt ge-nutzt und hat vielseitige Anwendungen gefunden. So dienen Texturen heute z. B. zur Berechnung von Schatten, nicht-planaren Lichtreflexionen und aufwendigeren Beleuchtungsmodellen (Gooch et al. [30], Heidrich und Seidel [41]). Die Texturierung kann neben der einfachen Abbildung von Daten auch zur dynamischen Gestal-tung eingesetzt werden. Die Realisierung effizienter visueller Werkzeuge zur Präsentation, Explo-ration und Manipulation von raumbezogenen Daten wird dadurch ermöglicht. Den steigenden

4.1 Texturierungstechnik

42

Anforderungen an Benutzungsschnittstellen im Bereich der Geovisualisierung (Kraak [55]) etwa in virtuellen Geoumgebungen (MacEachren et al. [64]), Lernumgebungen (Asche und Herrmann [1], Cartwright [15]), Geoinformationssystemen und 3D-Karten (Döllner und Kersting [19]) wird dadurch Rechnung getragen.

4.1 Texturierungstechnik 4.1.1 Texturierung von Primitiven Eine OpenGL 2D-Textur ist ein rechteckiges Rasterbild der Größe 2i × 2j mit i,j ∈ {1, 2, ...}. Die einzelnen Pixel einer Textur werden als Texel (texture elements) bezeichnet. Jede Textur ist mit einem Texturraum T assoziiert. In der Regel wird T = [0, 1] × [0, 1] gewählt. Der Wert (0, 0) ∈ T entspricht dabei der linken unteren Ecke des Rasterbildes und (1, 1) ∈ T der rechten oberen Ecke. Neben 2D-Texturen sind auch 1D-Texturen (2i × 1 Pixel) und 3D-Texturen (2i × 2j × 2k Pixel) in OpenGL anwendbar. Die genaue Maximalgröße einer Textur hängt von der zugrunde-liegenden Graphikhardware ab. Die Größe von 2D-Texturen ist in der Regel auf 1024 × 1024 bzw. 2048 × 2048 beschränkt. In der Rasterisierungsstufe werden die Texturkoordinaten der Primitivecken für jedes Fragment linear interpoliert. Die interpolierte Koordinate wird dann auf Texels des Texturbildes abgebildet, über die die Farbe aus dem Texturrasterbild ermittelt und mit dem momentanen Fragment ver-knüpft wird. Abbildung 32 links zeigt das zu texturierende Dreieck mit Texturkoordinaten. In Abbildung 32 Mitte ist die Abbildung der Texturkoordinaten auf ein Rasterbild dargestellt. In Abbildung 32 rechts sieht man das resultierende Bild des rasterierten und texturierten Dreiecks. Zu speziellen Themen wie Texturkoordinatengenerierung, Texturmatrizen, Texturfilterung und

Abbildung 31: Geometrische Tesselation einer Kugel durch Dreiecke (links) und die Texturierung derselben mit einer Rasteraufnahme der Erdoberfläche (rechts).

0 10

1

(0.3,0.1)

(0.8,0.5)

(0.3,0.8)

(0.3,0.1) (0.8,0.5)

(0.3,0.8)

analytisches Dreieck mit Texturkoordinaten

Texturkoordinaten auf Rasterbild abgebildet

texturiertes und rasterisiertes Dreieck

Abbildung 32: Projektion einer 2D-Textur auf ein Dreieck mittels Texturkoordinaten.

Kapitel 4 - Visualisierung von Rasterdaten

43

Texturierungsfunktionen wird auf Woo et al. [95] verwiesen.

4.1.2 Multitexturing Mittels Multitexturing können auf ein OpenGL Primitiv während eines Renderingdurchlaufs meh-rere Texturen angewandt werden. Ohne Multitexturing wären dazu mehrfache Renderingdurch-läufe notwendig, das heißt mehrfaches Zeichnen des Primitives würde die Darstellungsgeschwin-digkeit verlangsamen. Die Anzahl der gleichzeitig anwendbaren Texturen hängt von der zugrun-deliegenden Graphikhardware ab. Heutige Graphikkarten unterstützen in der Regel vier unabhän-gige Textureinheiten (z. B. GeForce3), einige sechs (z. B. ATI Radeon 9700) und angekündigte acht (z. B. GeForceFX). Unterstützt die Hardware k unabhängige Textureinheiten, so können pro Renderinglauf k unab-hängige Texturen angewendet werden, sodass sich die Gesamtzahl der notwendigen Rendering-durchläufe für n Texturen auf bis zu n/k reduzieren lässt.

4.1.3 Darstellungsqualität Eine Textur wird pixelpräzise auf seine Referenzgeometrie abgebildet, das heißt für jedes Frag-ment der Referenzgeometrie wird aus der Textur ein zugehöriges Texel berechnet. Die Genauig-keit der Darstellung einer Textur hängt direkt mit der Auflösung des zugrundeliegenden Raster-bildes zusammen. In Abbildung 33 ist eine Geländeoberfläche mit Texturen unterschiedlicher Größen dargestellt. In der oberen Zeile ist ein Ausschnitt der Geländeoberfläche zu sehen. Die markierten Ausschnitte in der oberen Zeile sind zur Verdeutlichung der Qualitätsunterschiede vergrößert in der unteren Zeile dargestellt.

(a)

(

(b)

(c)

Abbildung 33: Darstellung eines Ausschnitts einer Geländeoberfläche, auf die Texturen der Auflö-sungen 10242 (a), 40962 (b) und 655362 (c) projiziert sind. In der unteren Reihe ist der markierte De-tailausschnitt vergrößert dargestellt.

4.2 Verwandte Arbeiten zur Geländemodell-Texturierung

44

Um in dem Detailausschnitt den genauen Verlauf der einzelnen Autobahnspuren zu erkennen, bedarf es der höchsten Auflösung von 655362 Bildpunkten. Die geringeren Auflösungen lassen diese Details nicht erkennen. Zur Speicherung einer Bilddatei von 655362 Bildpunkten benötigt man 65536 · 65536 · 3 Byte das entspricht in etwa 12.9 Gigabyte. Die Verarbeitung solcher gro-ßen Datenmengen erfordert auf 32-Bit Betriebssystemen besondere Verfahren, da der Speicher-bedarf den adressierbaren Bereich überschreitet.

4.2 Anforderungen im Kontext von 3D-Karten Im Kontext von 3D-Karten ergeben sich folgende Anforderungen an die Behandlung von Raster-daten:

- Um eine bestmögliche Darstellungsqualität zu erzielen, müssen sehr große Rasterbilder als Texturen eingesetzt werden können.

- Die Darstellungsgeschwindigkeit muss ausreichen, um ein interaktives Arbeiten mit gro-ßen Rasterdaten zu ermöglichen.

- Es müssen mehrere, überlappende Rasterbilder gleichzeitig angezeigt werden können. - Die Speicheranforderungen müssen durch ein effektives Speichermanagement minimiert

werden. - Unterstützung von unterschiedlichen Verknüpfungsoperationen für die kombinierte

Darstellung mehrerer Texturschichten.

4.3 Verwandte Arbeiten zur Geländemodell-Texturierung Die in Kapitel 3 vorgestellten Verfahren zur Darstellung von Geländemodellen konzentrieren sich – mit Ausnahme des Approximationsbaums – primär auf die Geländegeometrie. Die Darstellung von übergroßen Texturen und mehreren Texturen gleichzeitig auf der Geländeoberfläche bleibt unberücksichtigt. Zur Texturierung von Geländemodellen können die Rasterbilder direkt mit dem von OpenGL zur Verfügung gestellten Mechanismus verwendet werden, deren Ausdehnungen unterhalb der hard-warespezifischen Größenbeschränkung liegen (z. B. 1024 × 1024). Das Rasterbild wird dazu komplett auf die Graphikhardware übertragen und wie in Abschnitt 4.1.1 beschrieben auf die Ge-ländegeometrie projiziert. In den Geowissenschaften reichen diese Rasterbildauflösungen zumeist nicht aus. Großflächige Satellitenbilder oder Befliegungsaufnahmen erfordern unter Umständen mehrere Gigabyte an

16 × 16 8 × 8 4 × 4

Abbildung 34: Texturpyramide bestehend aus drei Auflösungsstufen.


45

Speicher. Die Verwendung von Rasterbildern, deren Ausdehnungen oberhalb der hardwarespezi-fischen Größenbeschränkung liegen (z. B. 10.000 × 7.000), erfordert den Einsatz von Multireso-lutionsmodellen für Rasterdaten.

4.3.1 Bildpyramiden Eine Bildpyramide ist eine hierarchische Anordnung von Rasterbildern. Ausgehend von dem ur-sprünglichen Rasterbild werden durch sukzessives Halbieren der Auflösung abgeleitete Auflö-sungsstufen erzeugt (Abbildung 34). Dabei werden zur Steigerung der Qualität der abgeleiteten Rasterbilder Interpolationsverfahren eingesetzt (z. B. lineare Interpolation). Beträgt der Speicherbedarf für das ursprüngliche Rasterbild M, so gilt für den Speicherbedarf der gesamten Bildpyramide Mges mit n abgeleiteten Auflösungsstufen unter Anwendung der geometri-schen Reihe folgende Abschätzung:

34

4111

41

0⋅=

−⋅<

⋅= ∑

=MMMM

nn

iges

Trotz des erhöhten Speicherbedarfs von 33% wurden Bildpyramiden schon früh in der Compu-tergraphik zur Steigerung der Darstellungsqualität eingesetzt, z. B. zur Mipmap-Filterung (Willi-ams [94]). Man spricht dabei auch von Mipmap-Pyramiden. Dabei wird zur Reduktion störender Artefakte die zu verwendende Mipmap-Ebene in Abhängigkeit von der projizierten Größe eines Texel bestimmt (Abbildung 35).

4.3.2 FlyAway System Das FlyAway-System von Hüttner und Strasser [47] verwendet für jedes Rasterbild eine Bildpy-ramide, die vollständig im Speicher liegt. Das Rasterbild unterliegt dabei den Einschränkungen des verwendeten Renderingsystems. Die Verwendung übergroßer Rasterbilder ist dadurch nicht möglich. Das Verfahren eignet sich besonders zum Einsatz in Webapplikationen, bei denen das Nachladen der Daten über das Netz erfolgt. Die Größe der Texturdaten und damit die Qualität steht dabei weniger im Vordergrund als ihre effiziente Übertragung.

4.3.3 Clipmap Die Clipmap von Tanner et al. [89] ist eine von spezieller SGI Graphikhardware unterstützte Me-thode, die die Verwendung von extrem großen Texturen ermöglicht. Dazu wird die große Textur zunächst in eine Art „abgeschnittener Mipmap-Pyramide“, die Clipmap, transformiert. Aus allen Mipmap-Ebenen werden Bereiche beschränkter Größe in den Graphikkartenspeicher transferiert (Abbildung 36 links). Bewegt sich die Kamera und noch nicht übertragenen Bereiche der Clipmap werden sichtbar, werden die noch fehlenden Bereiche inkrementell nachgeladen (Abbildung 36

Abbildung 35: Texturiertes Primitiv ohne (links) und mit Mipmap-Filterung (rechts).

4.4 3D-Karten Geländemodell-Texturierung

46

rechts). Das Verfahren arbeitet sehr effizient, ist aber aufgrund der sehr speziellen Hardwarean-forderungen nicht allgemein einsetzbar.

4.3.4 Weitere Verfahren Lindstrom und Pascucci [58] wählen einen zum FlyAway-System ähnlichen Ansatz zur Darstel-lung von Rasterdaten, bei gleichen Einschränkungen in Hinblick auf Texturgröße und Multitextu-ring. Sander et al. [75] erweitern das allgemeine Progressive-Mesh von Hoppe [44] um die Mög-lichkeit, Texturkoordinaten mit an die vereinfachte Geometrie zu binden. Dadurch ist die Ver-wendung von mehreren Texturen grundsätzlich möglich, wird aber nicht weiter ausgeführt. Cline und Egbert [17] stellen eine Cache-Hierarchie zur Verwaltung großer Geländetexturen vor, die insbesondere die beschränkte Bandbreite bei der Texturübertragung berücksichtigt. Der Einsatz überlappender, übergroßer Texturen bleibt bei jeder dieser Arbeiten unberücksichtigt.

4.4 3D-Karten Geländemodell-Texturierung Die in Abschnitt 4.3 vorgestellten Verfahren ermöglichen die Kombination von einfachen Textur-schichten und Geländemodellen. Eine umfassende Lösung, bei der mehrere Texturschichten gleichzeitig und überlappend auf der Geländeoberfläche dargestellt werden können, blieb bisher aus. Das Verfahren zur Texturierung von Geländemodellen in 3D-Karten basiert auf dem in Abschnitt 3.5 vorgestellten Approximationsbaum (Döllner et al. [20]). Die Grundidee des Verfahrens bildet eine „Divide and Conquer“-Strategie: Das Problem der Texturierung der Geländegeometrie wird auf die Texturierung der Geometrieflicken reduziert.

4.4.1 Texturbaum Eine Texturschicht besteht – analog zum Geländemodell – aus einzelnen Flicken, so genannten Texturflicken. Ein Texturflicken T assoziiert einen achsenparallelen georeferenzierten Bereich der Geländeoberfläche D(T) mit einem Rasterbild R. Ein Texturflicken kann über 0 bis 4 Kinder-Texturflicken verfügen. Der von Texturflicken Tparent abgedeckte Bereich D(Tparent) wird von den Kindern von Tparent voll-ständig abgedeckt, das heißt bei vier Kindern gilt: D(Tparent) = D(Tchild 1) ∪ D(Tchild 2) ∪ D(Tchild 3) ∪ D(Tchild 4). Die Rasterbilder Rchild i verfügen in der Summe über die doppelte Rasterauflösung wie Rparent, die Texel-Anzahl ist viermal so hoch. Auf diese Weise wird ein Multiresolutionsmo-dell für Texturen spezifiziert. Im weiteren Verlauf sprechen wir dabei von einem Texturbaum.

notwendig

abgeschnitten

abgeschnitten abgeschnitten

nachzuladen

Abbildung 36: Clipmap mit notwendigen und abgeschnittenen Bereichen. Abgeschnittene Bereiche wer-den dynamisch nachgeladen.


47

Die Rasterbilder Ri genügen sämtlichen Anforderungen von OpenGL, das heißt ihre Größe liegt unterhalb der vorgegebenen hardwareabhängigen Größe (z. B. 1024 × 1024) und beträgt 2n × 2m. Soll ein Geometrieflicken G dargestellt werden, wird in der Texturschicht nach einem Texturfli-cken T gesucht, für den gilt D(G) ⊂ D(T) gilt und die Qualität von T ausreichend in Bezug auf die momentanen Kameraparameter ist. Gilt diese Aussage, kann der Texturflicken T auch für alle Kinder des Geometrieflicken G verwendet werden. In Abbildung 37 ist die Beziehung des Geometriebaums aus Abschnitt 3.5.1 zu einem Textur-baum dargestellt, bei dem zu jedem Geometrieflicken genau ein Texturflicken existiert. Die maximale Rasterbildauflösung, die mit einem gegebenen Geometriebaum dargestellt werden kann, errechnet sich aus der Tiefe des Geometriebaums maxG und der für alle Ri festgelegten Auflösung 2n × 2m und beträgt somit (2n · 2maxG) × (2m · 2maxG). In der Regel ist die Tiefe des Tex-turbaumes maxT kleiner als die Tiefe des zugehörigen Geometriebaumes maxG. Für die Tiefe des Texturbaumes gilt: maxT ist das minimale i ∈ {0, 1, … ,maxG} für das gilt, dass das zugrunde-liegende Rasterbild R vollständig in einem Rasterbild der Größe (2n · 2i) × (2m · 2i) Pixel gespei-chert werden kann. Für das Beispiel aus Abbildung 37 gilt maxT = maxG = 3. So ergibt sich aus der Formel bei einer festen Auflösung von 2048 × 2048 für alle Ri eine maximale Rasterbildauflösung von 16384 × 16384 Bildpunkten, was in etwa 800 Megabyte entspricht. Soll bei gleichem Geometrie-baum ein Rasterbild der Größe 3000 × 3000 dargestellt werden und alle Ri eine feste Auflösung von 2048 × 2048 Pixel besitzen, genügt ein Texturbaum mit maxT = 1.

L0

L1

L2

L3

L0

L1

L2

L3

Texturbaum

Geometriebaum

Abbildung 37: Beziehungen zwischen den Texturflicken aus dem Texturbaum und den Geometriefli-cken aus dem Geometriebaum.


48

In der Praxis liegt die Tiefe des Geometriebaumes maxG häufig zwischen 4 und 10, so dass die Unterstützung sehr großer Texturschichten und damit eine hohe Darstellungsqualität von Raster-daten gewährleistet ist.

4.4.2 Renderingalgorithmus Spezialisierte Texturschichten (abgeleitete von TTerrainTexture) geben spezialisierte Textur-flicken (abgeleitet von TTexturePatch) beim Aufruf der request()-Methode für den momen-tanen Geometrieflicken zurück (Abbildung 38). Es hängt von der konkreten Texturschicht-Klasse ab, wie der zurückzugebende Texturflicken generiert wird. Wir betrachten jetzt die konkrete Tex-turschicht TLODTexture, die einen Texturbaum basierend auf Rasterdaten mit unterschiedlichen Auflösungsstufen repräsentiert. Um den Bezug zu der Rasterdaten-Basis zu unterstreichen, spre-chen wir von einem Rasterdaten-Texturbaum. Wir benötigen dieses Wissen, um in Kapitel 5 die Funktionsweise der Texturschicht TVectorTexture verstehen zu können, die zur Darstellung von Vektordaten verwendet wird. Zur Erzeugung eines TLODTexture-Objektes genügt ein beliebig großes Rasterbild (siehe vorhe-rigen Abschnitt). Intern wird bei der Erzeugung aus dem Rasterbild eine gefilterte Bildpyramide aufgebaut. Aus dieser wird dann, für jeden möglichen Geometrieflicken passend, ein OpenGL-konformes Rasterbild fester Größe (z. B. 1024 × 1024) zurechtgeschnitten und eindeutig benannt auf die Festplatte geschrieben. Wird nun beim Rendering nach einem Texturflicken für einen Geometrieflicken geo gefragt, wird in der TLODTexture::request()-Methode zunächst der interne Cache überprüft, und ggf. das abgelegte TLODTexturPatch-Objekt verwendet. Ist kein Objekt im Cache vorhanden und exis-tiert kein passendes Rasterbild zu geo, wird versucht den Texturflicken des Vaters von geo zu verwenden. Dies wird ebenfalls versucht, wenn der visuelle Texturfehler für geo kleiner ist als die festgelegte Texturfehlerschranke. Dadurch kann Speicherplatz und Ladezeit eingespart wer-den, ohne visuelle Qualität einzubüßen. Bei der Berechnung der Texturqualität werden die mo-mentanen Kameraparameter und die Auflösung der zugeordneten Rasterbilder berücksichtigt. Ist die visuelle Texturqualität passend und existiert das benötigte Rasterbild, wird falls nötig der Cache bereinigt und ein neues TLODTexturPatch-Objekt erzeugt. Bei der Erzeugung wird das entsprechende Rasterbild von der Festplatte geladen. Die Implementierung der TLODTexture::request()-Methode sieht vereinfacht wie folgt aus:

request(geo:TGeometryPatch):TTexturePatch*

TTerrainTexture


TLODTextureTLODTexturePatch

*0..4

TRasterImage TTexturePatch

1

Abbildung 38: Wichtige Klassen der spezialisierten Texturschicht TLODTexture.


49

TTexturPatch* TLODTextur::request(TGeometryPatch* geo) {// Falls bereits ein passender Texturflicken existiert// wird dieser verwendet.if (cache->contains(geo)) { return cache->get(geo); }// Existiert zu 'geo' kein Rasterbild oder ist der// visuelle Texturfehler kleiner als die// Texturfehlerschranke wird der Texturflicken vom// Vater von 'geo' verwendet.if (geo->parent() && (checkForImage(geo) == false ||

textureError(geo) < TEXTURE_ERROR_THRESHOLD)) {return request(geo->parent());

}// Falls Cache zu groß, werden alte Texturflicken entferntif (cache->size() > MAX_PATCHES) { cache->removeOld(); }// Texturflicken erzeugen, im Cache eintragen, zurückgebenTTexturPatch* patch = new TLODTexturPatch(geo);cache->insert(geo, patch);return patch;

}

Das Nachladen der Rasterbilder kann nebenläufig erfolgen. Solange ein zu ladendes Rasterbild noch nicht vollständig im Speicher vorliegt, kann der Elterntexturflicken des zum Rasterbild ge-hörenden Texturflicken verwendet werden. Dadurch bleibt eine 3D-Karteanwendung auch beim Nachladen von Rasterbildern - bei nahezu gleich bleibender Darstellungsgeschwindigkeit - inter-aktiv bedienbar. Der Renderingalgorithmus für das Geländemodell aus Abschnitt 3.5.2 ändert sich durch die Integration der Texturierung folgendermaßen:

void render(TGeometryPatch* geo) {if (isVisible(geo)) {

if (quality(geo) > geometryErrorThreshold) {for (int i = 0; i < geo->children(); i++) {

render(geo->child(i));}

} else {// von allen aktiven Texturen zu ‘geo’// passende Texturflicken erfragen.for (int j = 0; j < textures->size(); j++) {

TTexture* cur = textures->get(j);TTexturePatch* tpatch = cur->request(geo);apply(tpatch);

}draw(geo);

}}

}

Die Erzeugung einer TLODTexture kostet einmalig Vorberechnungszeit, die je nach Größe der Rasterdaten zwischen wenigen Sekunden und einigen Minuten variieren kann. Die Darstellungs-geschwindigkeit bleibt davon allerdings unberührt, da nur die vergleichsweise kleinen Rasterbil-der Ri eingeladen werden müssen. Das Laden und das Übertragungen der Rasterbilder auf die


50

Graphikhardware können durch Kompression während der Vorberechnung noch beschleunigt werden. Dies ist insbesondere bei Verwendung multipler Texturschichten empfehlenswert.

4.4.3 Rasterdaten-Kompression Um eine Textur auf Primitive anwenden zu können, muss das zur Textur gehörige Rasterbild in den Graphikkartenspeicher kopiert werden. OpenGL unterscheidet dabei zwischen dem externem Bild- und internem Texturformat. Beim Kopieren vom Haupt- in den Graphikkartenspeicher wird, wenn sich die Formate unterscheiden, eine Formatkonvertierungen durchgeführt. Eine Konvertie-rung wird häufig verwendet, um den Speicherbedarf für Texturen auf der Graphikhardware zu reduziert. Dafür stellt OpenGL unterschiedliche Texturkompressionsverfahren zur Verfügung (Tabelle 1). Häufig eingesetzte Texturkompressionsverfahren sind die Packed-Pixels-Kompression oder die von S3 entwickelte S3TC-Kompression. Die Packed-Pixels-Kompression reduziert die Anzahl der Bits pro Farbe durch einfache Bit-Shift-Operationen, z. B. wird bei der Konvertierung eines GL_RGB Bildes in ein GL_R3_G3_B2 nur die drei größten Bit vom Rotanteil, die drei größten Bit vom Grünanteil und die zwei größten Bit vom Blauanteil der ursprünglichen Farbe berück-sichtigt. Bei der S3TC-Kompression wird eine Textur in 4 × 4 Texel große Blöcke unterteilt. Zu einem Block werden zwei repräsentative Farben im RGB565 Format (16 Bit) gespeichert. Zwischen den beiden Farben werden zwei Mischfarben durch lineare Interpolation gewonnen, die nicht explizit abgespeichert werden. Jeder Block verfügt somit über eine Vierfarbtabelle. Jedes Texel wird nun durch einen 2-Bit Index der Farbtabelle repräsentiert. In der Summe ergibt sich pro Block ein Speicherverbrauch von 64 Bit gegenüber 512 Bit eines unkomprimierten RGB-Blocks. Das ergibt

Internes Format Bit pro Pixel RGB Textur 20482 Texel GL_RGB 24 12.582,91KB GL_R5_G6_B5 16 8.388,61KB GL_RGB4 12 6.291,46KB GL_R3_G3_B2 8 4.194,30KB GL_RGB_S3TC 4 2.097,15KB

Tabelle 1: Speicherverbrauch einer 20482 großen Textur bei unterschiedlichen internen Formaten.

(a) (b)

(c)

Abbildung 39: Unterschiedliche interne Texturformate mit entsprechender visueller Qualität am Bei-spiel einer gleichmäßigen höhenabhängigen Färbung im Vergleich: GL_RGB (a), GL_R3_G3_B2 (b), GL_RGB_S3TC (c).


51

eine Speicherersparnis von 87,5%. Obwohl die Formatkonvertierung i.d.R. von der Graphikhardware übernommen werden kann, sind die auftretenden Verzögerungen beim ersten Verwenden der Textur subjektiv wahrnehmbar. Um diese Verzögerung zu umgehen, können Texturen bereits extern als komprimierte Texturen gespeichert werden. Dadurch beschleunigt sich nicht nur der Transfer zur Graphikhardware (weil keine Konvertierung erfolgen muss), sondern auch das Laden der Texturen vom Speichermedium. Der einzige Nachteil ist, dass die Bilder nicht mehr von Standardgraphikanwendungen angezeigt werden können. Die oben beschriebenen Kompressionsverfahren sind verlustbehaftet, das heißt die visuelle Quali-tät verschlechtert sich je nach Kompressionsgrad. Gleichmäßige Farbverläufe werden härter ab-gestuft und Farben werden näherungsweise wiedergegeben (Abbildung 39b und c). Der visuelle Qualitätsunterschied hängt stark vom zugrundeliegenden Rasterbild ab. Bei Rasterbilder ohne Farbverläufe (z. B. gescannte Straßennetzkarten) fallen die Qualitätsunterschiede weniger auf, so dass der durch die Kompression ermöglichte Speicher- und Geschwindigkeitsvorteil genutzt wer-den kann. Eine weitere Möglichkeit, Rasterdaten speichersparend einzusetzen, sind Palettentexturen. Eine Palettentextur definiert ein Rasterbild mittels einer Farbtabelle und einem Raster von Indizies, die die einzelnen Texel repräsentieren. Jeder Index (in der Regel ein 8 Bit Wert) verweißt auf einen Wert in der Farbtabelle, der beim Rendering für das jeweilige Texel verwendet wird. OpenGL unterstützt Palettentexturen durch die Erweiterung GL_EXT_paletted_texture. Der Vorteil im Vergleich zu RGB-Texturen liegt darin, dass anstelle eines RGB Wertes (24 Bit) nur ein Indexwert (8 Bit) und die Farbtabelle zur Graphikhardware übertragen werden muss. Bei großen Texturen ergibt sich somit ein Speichervorteil. Ändert sich die Farbtabelle, kann diese unabhängig von den Indexwerten an die Graphikhardware übertragen werden; die vorherige Farb-tabelle wird überschrieben und die Indextabelle wird mittels der neuen Farbtabelle dargestellt. Auf diese Weise können unterschiedliche (nicht überschneidende) Thematiken sehr effizient farb-lich verändert oder ausgeblendet werden.

4.5 Darstellung dynamischer Rasterdaten Bisher wurde die Darstellung statischer Rasterdaten beschrieben, nicht jedoch die Darstellung dynamischer Rasterdaten. Letzteres soll Inhalt dieses Abschnittes sein. MacEachren erweitert in [61] die kartographischen Variablen um die Zeit, die in animierten Kar-ten als Mittel zur Gestaltung eingesetzt werden kann. Als wesentliche dynamische Variablen nennt er die Dauer, den Grad der Veränderung, die Reihenfolge und die Phase einer Animation. Eine Form der Repräsentation von Animationen ist die als Sequenz diskreter Rasterbilder, wie

0 0 0 1 1 0 0 00 0 1 2 2 1 0 00 1 2 2 2 2 1 01 2 2 2 2 2 2 11 2 2 2 2 2 2 10 1 2 2 2 2 1 00 0 1 2 2 1 0 00 0 0 1 1 0 0 0

0 1 2

0 1 2

Abbildung 40: Durch die explizite Spezifikation von Thematiküberlagerungen können unterschiedliche Thematiken in einer Palettentextur gespeichert werden.

4.6 Zusammenfassung

52

z. B. bei Strömungs- oder Überflutungsanimationen üblich (Abbildung 41). Die Speicherung ei-ner solchen Folge in einem digitalen Videoformat wie AVI oder MPEG ist dabei möglich. Das Abspielen kann dann über übliche Multimedia-Player erfolgen. Das Abspielen eines solchen Videos auf der Geländeoberfläche bietet die spezielle Texturschicht TVideoTexture. Die TVideoTexture::request()–Methode arbeitet ähnlich der TLODTexture::request()–Methode, außer dass anstelle eines einzelnen Rasterbildes von der Festplatte ein Rasterbild aus einem Videostream extrahiert wird. Die Größe der einzelnen Bilder des Videostreams dürfen die maximal von OpenGL unterstütze Auflösung nicht überschreiten, weil der Aufbau eines Texturbaums nicht mehr in Echtzeit erfolgen kann. Das ist keine wirkliche Einschränkung, denn aktuelle Codecs (z. B. DivX 5.0) unterstützen momentan noch keine Auflö-sungen der Größe 2048 × 2048. Durch Darstellung von Prozessen in einer 3D-Karte auf der Geländeoberfläche wird die räumli-che Einordnung durch den Kartennutzer verglichen mit der einfachen Videowiedergabe erleichtert (vgl. Ursprungsdaten in Abbildung 41 und 3D-Visualisierung in Abbildung 12). Der Weg über ein vorberechnetes Video eignet sich besonders für Prozesse, deren Berechnung der einzelnen Zeitschritte nicht echtzeitfähig sind (Döllner et al. [21]). Sollte das Verfahren zur Generierung der einzelnen Zeitschritte echtzeitfähig sein, können die re-sultierenden Rasterbilder auch ohne Umweg auf die Geländeoberfläche projiziert werden. Eine sehr effiziente Methode zur Strömungsvisualisierung stellt die von Stalling et al. [85] entwi-ckelte Line-Integral-Convolution–Methode (LIC) dar. Das Verfahren arbeitet so schnell, dass in Echtzeit Rasterbilder generiert werden können. Das Beispiel in Abbildung 42 zeigt eine Strö-mungssimulation der Ausbreitung eines fiktiven Ölteppichs, der durch eine auf dem Meeresgrund verlaufenden defekte Pipeline verursacht wurde. Aufgrund der Echtzeitgenerierung kann die Lage des Defekts interaktiv manipuliert und das Ergebnis des Strömungsverlaufs unmittelbar betrach-tet werden.

4.6 Zusammenfassung Die „Divide and Conquer“-Strategie für die Texturierung des gesamten Geländemodells auf die Texturierung der einzelnen Geometrieflicken zu reduzieren, erlaubt ein effiziente und vielseitige Anwendung von Texturschichten, die die OpenGL Größenbeschränkungen übersteigen. Multitex-turing und mehrfaches Rendering werden nur auf die Geometrieflicken angewandt, die sie tat-

Abbildung 41: Darstellung einer Überflutungssimulation als Folge von Rasterbildern.


53

sächlich benötigen. Dadurch können Überlappungen von Texturschichten effizient realisiert wer-den (Döllner et al. [20]). Die Darstellungsqualität von Texturschichten ist aufgrund der Unterstützung auch großer Auflö-sungen sichergestellt. Eine hohe Darstellungsgeschwindigkeit ist auch bei großen Texturschichten durch die hierarchische Struktur des Texturbaumes und das inkrementelle, nebenläufige Nachla-den der darzustellenden Rasterbilder gewährleistet. Durch das Auslagern des Texturbaumes und die Kompressionsunterstützung ist die Belastung des Hauptspeichers gering. Im folgenden Kapitel diskutieren wir ein Verfahren, welches es erlaubt, Vektordaten in Form von Rasterbildern über das Geländemodell zu legen, und dabei vielfältige Gestaltungsmöglichkeiten bietet.

Abbildung 42: Strömungssimulation der Ausbreitung eines Ölteppichs, der durch einen auf dem Meeresgrund verlaufenden defekten Pipeline verursacht wurde.

55

Kapitel 5 VISUALISIERUNG VON VEKTORDATEN

Ein großer Teil thematischer und topographischer Informationen ist in Form von Vektordaten erfasst. Wir verstehen unter Vektordaten im Kontext von 3D-Karten jede Form von analytisch beschriebenen 2D- bzw. 3D-Daten. Bei der Darstellung dieser Daten werden graphische Primitive wie Punkte (z. B. für Positionen von Städten oder Sehenswürdigkeiten), Linien (z. B. für Stra-ßennetze, Flussverläufe oder Küstenlinien) oder Polygone (z. B. für politische Regionen oder Ve-getationszonen) verwendet. Durch die Möglichkeit Vektordaten direkt auf graphische Primitive abzubilden, ist die graphische Darstellung sehr präzise und im Gegensatz zu Rasterdaten auch robust gegenüber affinen Transformationen (z. B. Skalierung, Rotation). Ein Datensatz benötigt im Allgemeinen in vektorieller Form wesentlich weniger Speicher als in rasterisierter Form. Vek-torielle Datenformate, wie z. B. Scalable Vector Graphics (SVG) [24], finden zunehmend auch allgemein Einsatz bei der Informationsdarstellung, z. B. für 2D-Karten im Internet. Wir unter-scheiden die folgenden Formen von Vektordaten:

- 2D-Vektordaten legen pro Geoposition zwei Koordinaten (z. B. Breitengrad, Längengrad). Es liegen keine Informationen über die Höhe vor.

- 2½D-Vektordaten legen pro Geoposition zwei Koordinaten fest. Als Höhe wird implizit die Geländehöhe an der beschriebenen 2D-Position angenommen. Vek-tordaten, die drei Koordinaten beschreiben, wobei die dritte Koordinate die Ge-ländehöhe darstellt, werden von uns auch als 2½D-Vektordaten aufgefasst. 2½D-Vektordaten dienen zur Beschreibung von Objekte, die auf der Geländeoberflä-che liegen (z. B. Straßenzüge).

- 3D-Vektordaten legen pro Geoposition drei Koordinaten fest, die unabhängig von der Geländehöhe sein können. Dadurch werden Objekte beschrieben, die aus der Geländeoberfläche heraustreten (z. B. Gebäude), über der Geländeoberfläche lie-gen (z. B. Emissionswolken) oder sich unterhalb der Geländeoberfläche befinden (z. B. Gesteinsschichten).

5.1 Darstellung von Vektordaten in 3D

56

5.1 Darstellung von Vektordaten in 3D Im Kontext von 3D-Karten unterscheiden wir zwei unterschiedliche Formen der Darstellung von Vektordaten: die geometriebasierte Darstellung und die texturbasierte Darstellung.

5.1.1 Geometriebasierte Darstellung Die geometriebasierte Darstellung von Vektordaten in 3D ist sehr einfach zu realisieren, da eine direkte Abbildung der Vektordaten auf graphische 3D-Primitive möglich ist (OpenGL unterstützt z. B. Polygone, Linien und Punkte). Die graphischen 3D-Primitive werden einzeln gezeichnet und sind so auch als einzelne Objekte identifizierbar. In Verbindung mit einem Multiresolutionsmodell zur Darstellung der Geländeoberfläche können aber an Schnittstellen zwischen Primitiven der Vektordaten und Geländeoberfläche aufgrund der starken Änderungen einer sich dynamisch anpassenden Level-of-Detail-Geländeoberfläche Arte-fakte auftreten (Abbildung 43a). Insbesondere bei Primitiven, die koplanar zur Geländeoberfläche liegen, verstärkt der dann nur ungenaue Tiefentest diese Störungen (Abbildung 43b). Diese Arte-fakte könnten nur durch eine geometrische Verschiebung der Primitive über das Geländemodell unterdrückt werden. Allerdings leidet darunter die visuelle Qualität des Bildes („Polygon schwebt über Gelände“-Effekt) und die Verschiebung würde von der Genauigkeit des verwendeten Tiefen-puffers, das heißt auch von der Graphikhardware, abhängen. In Abbildung 44 wird die Problematik anhand des Beispiels einer Linie aufgezeigt. Die Linie ist durch ihren Anfangs- und Endpunkt definiert (blau dargestellt). Die direkte Verbindung der Punk-te würde in 2D ausreichen, die Linie korrekt darzustellen; in 3D wird die Linie die Geländeober-fläche durchstoßen (Abbildung 44a). Eine mögliche Lösung wäre die Erweiterung der Line zu einem Polygonzug durch die Hinzunahme zusätzlicher Stützpunkte (grün dargestellt), um sich der Geländeoberfläche anzunähern (Abbildung 44b). Aufgrund der dynamischen Anpassung der Ge-ländeoberfläche müsste diese Anpassung für alle Auflösungsstufen berechnet werden, um ein er-neutes Durchstoßen beim Wechsel des LOD zu vermeiden (Abbildung 44c).

5.1.2 Texturbasierte Darstellung Die geometriebasierte Darstellung erlaubt die Visualisierung von Vektordaten mit den beschrie-benen qualitativen Einschränkungen. Ein Großteil aller Vektordaten ist aber als 2D- oder 2½D-Vektordaten aufzufassen, die mit Hilfe von Texturen auf der Geländeoberfläche dargestellt wer-den können.

(a) (b)

(c)

Abbildung 43: Vektordaten repräsentiert als Polygon auf einer LOD-Geländeoberfläche in Liniendar-stellung (a), dargestellt als gefülltes Polygon mit z-Buffer Artefakten (b) und als Textur auf die Gelän-deoberfläche ohne Artefakte projiziert (c).

Kapitel 5 - Visualisierung von Vektordaten

57

Bei der texturbasierten Darstellung von Vektordaten werden die geometrischen Primitive in ei-nem Vorberechnungsschritt gerastert und das resultierende Bild wie in Kapitel 4 beschrieben als Textur auf die Geländeoberfläche projiziert. Die Vektordaten können so ohne Tiefentest-Artefakte (Abbildung 43c) über das Geländemodell gelegt werden. Ungewollte Schnitte mit der Gelände-oberfläche werden somit vermieden (Abbildung 44d). Allerdings werden für die Vorberechnung Zeit und Speicher benötigt und die Qualität der Darstellung hängt von der Auflösung der vorbe-rechneten Textur ab. Eine Änderung der Auflösung oder eine Veränderung von Inhalten ist nur durch eine komplette Neuberechnung und damit mit Zeitverzögerung zu erreichen. Im Gegensatz zur geometriebasierten Darstellung sind die in die Textur gerasterten Objekte nicht selektierbar, da nur Bildinformationen und keine Objektinformationen in der Textur gespeichert werden.

5.2 Anforderungen im Kontext von 3D-Karten Unter Berücksichtung der beschriebenen Möglichkeiten stellen wir folgende Anforderungen an die Darstellung von Vektordaten im Kontext von 3D-Karten auf:

- Hohe Darstellungsqualität von Vektordaten, auch wenn diese direkt auf der Geländeoberfläche liegen.

(a)

(b)

(c)

(d)

Abbildung 44: Abbildung von Vektordaten auf die Geländeoberfläche eines Multiresolutionsmodells: geometriebasierte Abbildung (a-c) und texturbasierte Abbildung (d).

5.3 Verwandte Arbeiten zur Darstellung von Vektordaten

58

- Die Darstellungsgeschwindigkeit muss ausreichen, um ein interaktives Arbei-ten zu ermöglichen.

- Die objektbasierte Interaktion (z. B. Selektion) mit Vektordaten muss gewähr-leistet sein.

5.3 Verwandte Arbeiten zur Darstellung von Vektordaten Zur Darstellung überschaubarer Mengen von Vektordaten bedarf es keiner besonderer Verfahren. Heutige Graphikhardware erlaubt die Echtzeit-Darstellung von mehreren 100.000 Polygonen und Linien mit interaktiven Bildwiederholraten. Übersteigt die darzustellende Menge die Leistungsfä-higkeit der Hardware, kommen Simplifizierungsalgorithmen zum Einsatz; die geometrische Komplexität eines Objektes wird unter Berücksichtigung der ursprünglichen Form reduziert. Die Simplifizierung von 3D-Oberflächen wurde unter anderem von Garland und Heckbert [30], Hop-pe [44] und Schroeder et al. [77] untersucht. Diese Verfahren liefern zu einem gegebenen Fehler-maß ein simplifiziertes Modell der 3D-Oberfläche. Da in vielen Fällen die visuelle Qualität des simplifizierten Modells aus einer bestimmten Sicht als Fehlermaß dient, wurden unter anderem von Hoppe [46] sowie Luebke und Erikson [59] sichtabhängige (view-dependent) Verfahren ent-wickelt. Sester und Klein [79] untersuchten die regelbasierte Generalisierung von Gebäudemodel-len, bei denen nicht nur die geometrische Simplifizierung, sondern auch die Erhaltung wichtiger Gebäude und Gebäudeteile berücksichtigt wird. Das Problem der Darstellung von 2D- und 2½D-Vektordaten in Zusammenhang mit 3D-Multiresolutionsgeländemodellen ist bisher wenig untersucht. Um Artefakte, wie in Abschnitt 5.1 aufgeführt, zu vermeiden, werden 2D- bzw. 2½D-Vektordaten in die Höhe verschoben (Terribili-ni [90]) oder durch Extrusion zu 3D-Objekten erweitert (Häberling [36]). Die Darstellungsquali-tät sinkt in beiden Fällen, insbesondere dann, wenn die Objekte von der Seite betrachtet werden („schwebende“ und blickverstellende Objekte).

Texturflicken L1

Texturflicken L3

Texturflicken L2

Abbildung 45: Assoziation von Textur- und Geometrieflicken.


59

Browne et al. [12] haben ein Multiresolutionsmodell für Linen entwickelt, das von dem zugrunde liegenden Multiresolutionsmodell für die Geländegeometrie abhängt. Dazu wird eine Linie in Li-niensegmente unterteilt und für jeden Liniensegmentpunkt die genaue Höhe der momentanen Ge-ländeoberfläche ermittelt. Ist die Länge der Liniensegmente klein genug, liegt die approximierte Linie genau über der Geländeoberfläche. Allerdings treten aufgrund der Koplanarität von Linie und Geländeoberfläche die in Abschnitt 5.1 beschriebenen Tiefenpuffer-Artefakte trotzdem auf. Das Verfahren ist sehr rechenaufwändig, insbesondere dann, wenn es auf Polygone erweitert würde.

5.4 Hardwareunterstützte Rasterisierung von Vektordaten Um die Vorteile der geometriebasierten und der texturbasierten Darstellung von Vektordaten zu kombinieren, müssen wir effizient Vektordaten rasterisieren können. Wir halten dazu die Vektor-

Hauptspeicher

Grafikkartenspeicher

PBuffer

Cache

Analytische Vektordaten

Hauptspeicher

Grafikkartenspeicher

AGP Bus

Cache

Rasterisierte Vektordaten

(a) (b)

Grafikkarten Bus

1 GB/s

AGP Bus 1 GB/s

10 GB/s

Vektordaten Szenengraph

11.1 1.0

1.2 1.3 1.0.1

1.0.2 1.0.1 1.1.0

1

1.1 1.0

1.2 1.3 1

1.1 1.0

1.2 1.3

Rasterdaten-Texturbaum Vektordaten-Texturbaum

Abbildung 46: Datenhaltung im Hauptspeicher und Datentransfer zum Graphikkartenspeicher im Vergleich zwischen Rasterdaten-Texturbaum (a) und Vektordaten-Texturbaum (b).

5.4 Hardwareunterstützte Rasterisierung von Vektordaten

60

daten in einem Vektordaten-Szenengraph im Hauptspeicher vor. Ein Vektordaten-Szenengraph ist ein Szenengraph, der 2D- und 2½D-Vektordaten repräsentiert. Wir haben bei der Diskussion des Algorithmus zur Darstellung der Geländegeometrie gesehen, dass ein Grossteil der verfügbaren Geometrieflicken für die Darstellung unberücksichtigt bleiben können (Abbildung 29). Dies machen wir uns zu Nutze, indem wir zur Laufzeit für jeden darzu-stellenden Geometrieflicken den zugehörigen Texturflicken auf Anfrage generieren bzw. rasteri-sieren (Kersting und Döllner [51]). Auf diese Weise ist keine bzgl. ihres Definitionsbereichs voll-ständige Rasterisierung der Vektordaten notwendig, das heißt es existiert nur eine partieller Tex-turbaum (Abbildung 45). Das entlastet den Hauptspeicher und spart die sonst nötige Vorberech-nungszeit ein. Wir nennen diesen Texturbaum Vektordaten-Texturbaum im Gegensatz zum Ras-terdaten-Texturbaum aus Abschnitt 4.4.1. Im Folgenden werden wir die technischen Aspekte des Vektordaten-Texturbaums näher erläutern und Vektordaten synonym mit 2D- bzw. 2½D-Vektordaten verwenden.

5.4.1 Rasterisierungstechnik Für die effiziente Rasterisierung verwenden wir den OpenGL P-Buffer. Der P-Buffer (Pixel-Buffer) [96] ist ein vollwertiger Framebuffer (Colorbuffer, Depthbuffer), der nicht an ein Fenster der Benutzungsoberfläche gekoppelt ist; ein P-Buffer wird daher auch als off-screen canvas be-zeichnet. Der P-Buffer wird wie jedes on-screen canvas im Speicher der Graphikkarte angelegt und verfügt damit über die volle Hardwarebeschleunigung. Der Inhalt des P-Buffers kann sehr effizient direkt oder nach vorherigem Kopieren als Textur Verwendung finden, wobei keine Daten aus dem schnellen Graphikkartenspeicher über den AGP-Bus in den Hauptspeicher kopiert wer-den müssen und umgekehrt. Bei intensiven Kopieraktionen vom Haupt- in den Graphikkartenspeicher und zurück stellt der AGP-Bus einen Flaschenhals dar. Die Speichertransferrate liegt je nach Version bei ca. 500 MB/s (AGP 2x) bzw. 1000 MB/s (AGP 4x) [49]. Die Speichertransferrate des internen Bus auf der Graphikkarte ist erheblich höher, z. B. erreicht eine NVidia GeForce 4 Ti 4600 bis zu 10.400 MB/s. Zur Rasterisierung der Vektordaten werden die zugehörigen geometrischen Primitive zusammen mit ihren graphischen Attributen auf die Graphikhardware übertragen. Der AGP-Bus muss also nur analytische Ecken-, Normalen-, Texturkoordinaten und Farbinformationen transportieren. Die Rasterisierung der Primitive erfolgt hardwareunterstützt im P-Buffer. Die resultierenden Texturen werden auf der Graphikkarte zur wiederholten Verwendung zwischengespeichert (Texturobjekte [95]). Im Gegensatz zum in Abschnitt 4.4.1 vorgestellten Rasterdaten-Texturbaum müssen hier keine Vorberechnung zum Aufbau der Bildpyramide und des Texturbaums geleistet, keine Rasterdaten


TTerrainTexture


TVectorTextureTVectorTexturePatch

*

TTexturePatch

1 SceneNode

Vektordaten-Szenengraph

Abbildung 47: Klassendiagramm der Klassen, die mit TVectorTexture in Verbindung stehen.


61

im Hauptspeicher oder externen Medien gehalten und keine Übertragung von Rasterdaten über den AGP-Bus durchgeführt werden (Abbildung 46).

5.4.2 Renderingalgorithmus Beim Rendering eines Geometriebaums, der mit einem Vektordaten-Texturbaum assoziiert ist, wird nur für jeden wirklich darzustellenden Geometrieflicken ein Texturflicken erzeugt (Abbildung 45). Jeder Texturflicken verfügt über eine fixe Größe der Form 2n × 2m wobei n und m fest sind (vgl. Abschnitt 4.4.1). Die spezielle Texturschicht, die den Vektordaten-Texturbaum verwaltet, ist die Klasse TVectorTexture. Objekte dieser Klasse generieren aus dem aggregier-ten Vektordaten-Szenengraph spezialisierte Texturflicken vom Typ TVectorTexturePatch (Abbildung 47).

Statische Vektordaten Wir nehmen zunächst an, dass die im Vektordaten-Szenengraph enthaltenen Vektordaten statisch sind, das heißt sich nicht im Laufe der Zeit oder in Abhängigkeit von Umgebungsparametern (z. B. Kameraposition) ändern. Diese Annahme ermöglicht ein effektives Caching über aufeinan-der folgende Renderingdurchläufe hinweg. Um den Graphikkartenspeicher zu entlasten, wird die maximale Anzahl zwischenzuspeichernder Texturflicken Nmax festgelegt. Zudem besteht die Mög-lichkeit die Tiefe des Vektordaten-Texturbaums maxVT kleiner als die des Geometriebaums maxG zu wählen. Die Implementierung der TVectorTexture::request()-Methode für statische Vektordaten sieht vereinfacht wie folgt aus:

TTexturPatch* TVectorTexture::request(TGeometryPatch* geo){// falls maximale Vektordaten-Texturbaum-Tiefe// überschritten oder der visuelle// Texturfehler kleiner als die Texturfehlerschranke ist,// wird der Texturflicken vom Vater von 'geo' verwendet.if (geo->parent() && (geo->depth() > MAX_VT ||

textureError(geo) < TEXTURE_ERROR_THRESHOLD)) {return request(geo->parent());

}// falls bereits ein Texturflicken existiert// selbigen verwendenif (cache->contains(geo)) { return cache->get(geo); }// Cache-Größe überwachenif (n > N_MAX) { cache->cleanup(); }// Erzeugung eines neuen Texturflickens unter// Berücksichtigung des Geometrieflickens ‘geo’// und des Vektordaten-Szenengraphs ‘vdata’TTexturPatch* patch = new TVectorTexturePatch(geo,vdata);cache->insert(geo,patch);return patch;

}

Beim Konstruktoraufruf der Klasse TVectorTexturePatch wird die Rasterisierung der Vek-tordaten aus dem Vektordaten-Szenengraphen, die innerhalb der Boundingbox des Geometriefli-ckens liegen, im P-Buffer durchgeführt. Der Inhalt des P-Buffers wird auf der Graphikhardware in ein OpenGL Texturobjekt kopiert und an das TVectorTexturePatch-Objekt gebunden.


62

Wird das TVectorTexturePatch-Objekt zerstört, wird auch der belegte Speicher des Textur-objektes wieder freigegeben.

Optimierung für statische Vektordaten Die Anzahl der TVectorTexturePatch-Objekte, die pro Renderingdurchlauf erzeugt werden können, hängt von der Leistungsfähigkeit der Graphikhardware ab, insbesondere von der Im-plementierung des P-Buffers. Tabelle 2 zeigt die Bildwiederholfrequenzen, die auf einem Rechner mit Pentium 4, 1.3 GHz Rechner, 512 MB Hauptspeicher und einer NVidia GeForce 2MX mit 32 MB Texturspeicher gemessen wurden. Wir haben zum einen die Größe des P-Buffers und da-mit die Größe der Texturflicken variiert und zum anderen die Anzahl der Texturflicken, die wäh-rend eines Renderingdurchlaufs neu erzeugt werden, unterschiedlich beschränkt. Die Größe des P-Buffers hatte dabei kaum Einfluss auf die Bildwiederholfrequenz. Das Kopieren innerhalb des Graphikkartenspeichers stellt somit keinen Flaschenhals dar. Der Anstieg der Tex-turflicken, die während eines Renderingdurchlaufs generiert werden, beeinflusst die Bildwieder-holfrequenz hingegen stark. Diese Messung wurde genutzt, um die Bildwiederholfrequenz zu optimieren. Wir unterscheiden dafür beim Rendering zwischen einer sich bewegenden und einer stillstehenden Kamera. Ist die Kamera in Bewegung, wird die Zahl der TVectorTexturePatch-Objekte, die pro Ren-deringdurchlauf neu erzeugt werden dürfen, eingeschränkt. Dadurch werden überwiegend bereits erzeugte Texturflicken verwendet und nur wichtige neu erzeugt. Aufgrund der Bewegung der Kamera fällt die daraus resultierende schlechtere visuelle Qualität kaum auf. Ist die Kamera im Ruhezustand, wird die Zahl der TVectorTexturePatch-Objekte, die pro Renderingdurchlauf neu erzeugt werden dürfen, hoch gesetzt und das Bild solange wiederholt ge-zeichnet, bis alle für das momentane Bild notwendigen TVectorTexturePatch-Objekte erzeugt wurden. Die visuelle Qualität des Bildes nimmt inkrementell zu.

Dynamische Vektordaten Wir nehmen nun an, dass die im Vektordaten-Szenengraph enthaltenen Vektordaten dynamisch sind, das heißt sie sich im Laufe der Zeit oder in Abhängigkeit von Umgebungsparametern (z. B. Kameraposition) ändern. Diese Annahme verhindert ein effektives Caching über aufeinander fol-gende Renderingdurchläufe hinweg. Nimmt man an, dass die Geländegeometrie zweier aufeinan-der folgender Renderingdurchläufe Fn und Fn+1 ähnlich ist (frame-to-frame coherence), kann man auch für dynamische Vektordaten hohe Bildwiederholraten erreichen. Während des Renderingdurchlaufs für Fn+1 errechnet man zunächst aus den in Fn gerenderten Geometrieflicken einen minimalen, achsenparallelen Umgebungsquader boxlast, der alle abgedeck-ten Bereiche der in Fn verwendeten Geometrieflicken enthält. Dann wird ein

Texturflicken Auflösung Flicken pro Bild Bilder pro Sekunde 0 0 48,5

2562 2 44.2 10242 2 43,11 2562 4 33,1

10242 4 32,4 2562 8 23,7

10242 8 19,1

Tabelle 2: Vergleich der Bildwiederholfrequenz bei variierender Anzahl zu generierender Texturfli-cken und Auflösung.


63

TVectorTexturePatch-Objekt Tdynamic erzeugt, dass die Vektordaten genau für boxlast rasteri-siert. Tdynamic wird für alle Geometrieflicken verwendet, die während eines Renderingdurchlaufs für Fn+1 gezeichnet werden. Für den Renderingdurchlauf Fn+2 wird Tdynamic zerstört und aus den im Renderingdurchlauf für Fn+1 verwendeten Geometrieflicken ein neues Tdynamic erzeugt. Die visuelle Qualität der Darstellung hängt mit der Größe von boxlast zusammen: Je kleiner der Bereich ist, den die Geometrieflicken im vorangegangenen Renderingdurchlauf abgedeckt haben, um so höher ist die visuelle Qualität. Die Implementierung der TVectorTexture::request()-Methode für dynamische Vektorda-ten sieht vereinfacht wie folgt aus:

TTexturPatch* TVectorTexture::request(TGeometryPatch* geo) {// ein Texturflicken für alle Geoemtrieflickenstatic TVectorTexturePatch* T_dynamic = NULL;// ist true beim ersten Aufruf von request()// für einen neuen Frameif (isNewFrame()) {

// alten Texturflicken zerstörendelete T_dynamic;// Boundingbox aus vorherigen Geometrieflicken// errechnenIterator<TGeometryPatch*>* itr = lastDrawn();Bounds box_last;for (int i = 0; i < itr->size(); i++) {

box_last += itr->get(i)->boundingBox();}// Texturflicken passend für box_last erzeugenT_dynamic = new TVectorTexturePatch(box_last);

}return T_dynamic;

}

Optimierung für dynamische Vektordaten Enthält der Vektordaten-Szenengraph ausschließlich Vektordaten, die nur von den Kamerapara-metern abhängen und nicht zeitlich variieren, kann bei stillstehender Kamera die gleiche Optimie-rung wie bei statischen Vektordaten mit stillstehender Kamera angewandt werden. Dadurch steigt die visuelle Qualität insbesondere dann, wenn die Kamera sich nah an der Geländeoberfläche be-findet, aber trotzdem große Bereiche der Geländeoberfläche einsehbar sind.

5.4.3 Sichtbarkeitsoptimierung


64

Wenn Vektordaten sich nur auf kleine Bereiche der Geländeoberfläche beziehen, kann eine geometrische Vorauswahl die Darstellungsgeschwindigkeit des Vektordaten-Texturbaums erhö-hen. Wenn ein TVectorTexturPatch-Objekt für einen bestimmten Bereich der Geländeober-fläche erzeugt werden soll, wird durch die Überprüfung von Schnitten zwischen Sichtvolumen und den minimalen, achsenparallelen Umgebungsquadern der Vektordaten überprüft, ob in dem Bereich überhaupt Vektordaten dargestellt werden müssen. Ist dies nicht der Fall, kann auf die Rasterisierung des Bereichs verzichtet werden. Wird die Geländeoberfläche größtenteils von Vektordaten abgedeckt (z. B. eine diagonale Linie über die gesamte Geländeoberfläche), erübrigt sich die Sichtbarkeitsoptimierung, da kaum Tex-turflicken ausgeschlossen werden können: Die Ermittlung von Schnitten mit dem Sichtvolumen wäre aufwändiger als die Erzeugung einzelner leerer Texturflicken. Die Verallgemeinerung in VRS von achsenparallelen Umgebungsquadern auf allgemeine Umgebungsvolumen bestehend aus z. B. beliebigen Quadern und Kugeln würde hierbei noch Optimierungspotenzial bieten.

5.4.4 Speicherabschätzung Bei einem Vektordaten-Texturbaum ist der Speicherverbrauch drastisch niedriger als bei einem klassischen Rasterdaten-Texturbaum. Dadurch, dass nur für die tatsächlich sichtbaren Geomet-rieflicken ein Texturflicken erzeugt und im Speicher gehalten werden muss, wird der Speicher nicht mit „unsichtbaren“ Texturflicken belegt. Die wirkliche Belegung des Speichers hängt beim Vektordaten-Texturbaum von der Höhe des zugrundeliegenden Quadtree, der festgelegten Größe des P-Buffers und den tatsächlich sichtbaren Geometrieflicken ab (Tabelle 3).

Texturflicken Auflösung

Quadtree Tiefe

min./durschnittl. Geometrieflicken

min./durschnittl. Verbrauch MB

Auflösung 2D-Rasterbild

Verbrauch MB

2562 4 10/14 2.0/2.8 40962 66 5122 4 10/14 7.9/11 81922 268 2562 6 16/20 3.1/3.9 163842 1073 5122 6 16/20 12.6/15.7 327682 4295 2562 8 22/25 4.3/4.9 655362 17180 5122 8 22/25 17.3/19.7 1310722 68719

Tabelle 3: Vergleich des Speicherverbrauchs von Rasterdaten- und Vektordaten-Texturbaum.


65

Bei einem Quadtree der Höhe 8 und einem P-Buffer der Größe 512 × 512 Pixel wird – hochge-rechnet – die gleiche visuelle Qualität einer 131.072 × 131.072 Texel großen Texturschicht er-reicht. Ein Rasterdaten-Texturbaum muss dabei mit allen Auflösungsstufen eingerechnet fast 69 GB verwalten. Ein Vektordaten-Texturbaum benötigt dafür je nach Sicht auf das Geländemo-dell zwischen 17 MB und 20 MB. Hierbei ist nicht eingerechnet, dass die Texturdaten für den Graphikkartenspeicher zusätzlich noch komprimiert werden können.

5.5 Interaktion mit Vektordaten Einen Nachteil rein rasterbasierter Darstellungsverfahren für Vektordaten war der Verlust der Objektidentität. In Rasterbildern werden nur Farben und keine Objektidentitäten abgelegt. Da in einem Vektordaten-Texturbaum die Vektordaten noch analytisch vorgehalten werden, kann die Objektinteraktion durch analytische Verfahren erfolgen. In VRS und damit im 3D-Kartensystem wird die 3D-Interaktion durch Picking-Operationen un-terstützt. Dabei wird ein 3D-Strahl ausgehend von der Sichtebene durch das Sichtvolumen gesen-det und mit enthaltenen 3D-Szenenobjekten analytisch auf Intersektion getestet. Im Gegensatz zu farbbasierten Ansätzen (Woo et al. [95]) können durch die analytischen Berechnungen auch ver-deckte Szenenobjekte auf Intersektion überprüft werden. Eine Picking-Operation besteht aus einem primären und einem sekundären Strahlentest (Abbildung 48). Beim primären Strahlentest können kein, ein oder mehrere 3D-Szeneobjekte ge-troffen werden. Wird ein Objekt getroffen, so wird der Intersektionspunkt und die zugehörige Ob-jektidentität festgehalten. Als Ergebnis des Strahlentests wird eine Liste der getroffenen Objekte zusammen mit den Intersektionspunkten geliefert. Nach dem primären Strahlentest sind allerdings noch keine Objekte registriert, die sich im Vektordaten-Szenengraph befinden.

P1

2D Sichtebene 3D-Szene

Vektordaten-Szene Ergebnisse

P2

P3

P4

P1

P2

P3

P4

PrimärerStrahlen-

test

Strahlen-test

Ergebnisse

SekundärerStrahlen-

test

Texturtiefe

Abbildung 48: Intersektionsstrahlen werden von der 3D-Szene in die Vektordaten-Szene umgeleitet.

5.6 Erweiterte Gestaltungsmöglichkeiten

66

Ist beim primären Strahlentest die Geländeoberfläche getroffen worden, dann wird ein sekundärer Strahlentest durchgeführt, bei dem ein Strahl vom Intersektionspunkt mit dem Gelände aus senk-recht in die Vektordaten-Szene gesandt wird. Intersektionsobjekte und -punkte werden zum Er-gebnis des primären Strahlentests hinzugefügt (Abbildung 48). Auf diese Weise sind als Rasterbilder dargestellte Vektordatenobjekte eindeutig identifizierbar. Sogar unsichtbare überdeckte Vektordatenobjekte können eindeutig identifiziert werden.

5.6 Erweiterte Gestaltungsmöglichkeiten Ein Rasterdaten-Texturbaum basiert auf einem statischen Rasterbild, das heißt Thematiken sind fest in Farben und Pixeln kodiert. Die Änderung von Thematiken (z. B. Verschiebung eines Flusslaufes, Löschen einer Thematik) erfordert in jedem Fall eine zeitaufwändige Neuberechnung des gesamten Rasterbildes. Das impliziert auch eine Neuberechnung des Rasterdaten-Texturbaums. Durch die Anwendung von Vektordaten-Texturbäumen ergeben sich erweiterte Gestaltungsmög-lichkeiten für den Texturinhalt, weil die Rasterisierung zur Laufzeit durchgeführt und zur Lauf-zeit gesteuert werden kann. Dadurch wird ein kontextsensitiver Texturinhalt, also auch ein kon-textsensitiver Karteninhalt, ermöglicht. Ein Beispiel für kontextsensitiven Texturinhalt ist die automatische Ausrichtung von Karten-schrift innerhalb einer Texturschicht. Kartenschriften sind in klassischen Karten nach Norden ausgerichtet, um die Lesbarkeit zu erhöhen. In 3D-Karten kann die Kameraposition und -blickrichtung allerdings frei im Raum und damit auch eine Sicht von Norden nach Süden ge-wählt werden. Nach Norden ausgerichtete Kartenschriften wären dann nur auf den Kopf gestellt zu lesen. Bei der automatischen Ausrichtung werden Kartenschriften immer in Abhängigkeit von der momentanen Kameraposition zur Kamera ausgerichtet und mittels des Vektordaten-Texturbaums für jedes Bild neu berechnet (Abbildung 49). Das „auf-dem-Kopf-stehen“ von Kar-tenschrift wird vermieden. Ein weiteres Beispiel für kontextsensitiven Texturinhalt ist die Kombination von geometrie- und texturbasierter Darstellung von visuellen 3D-Kartenbauelementen. Als Beispiel dienen Karten-schriften, die sich in Abhängigkeit vom Winkel zwischen Kartenschrift- und Kameraposition auf-stellen (z. B. bei einem Winkel > 30°) bzw. einebnen (z. B. bei einem Winkel < 30°). Die Lesbar-keit der Kartenschrift bleibt auf diese Weise immer gewährleistet (Abbildung 50).

Abbildung 49: Texturbasierte, automatische Ausrichtung von Textmarkierungen in einer Textur-schicht. Schriftzüge werden in der Textur mit einem transparenten Rand freigestellt.


67

5.7 Zusammenfassung In diesem Kapitel wurden die Probleme bei der Darstellung von Vektordaten in Verbindung mit Multiresolutionsmodellen für die Geländegeometrie diskutiert. Die Vor- und Nachteile der geo-metriebasierten und der texturbasierten Darstellung wurden dargelegt. Die hybride Verwendung von Vektordaten in Form von Vektordaten-Texturbäumen ermöglicht die Kombination der Vorteile und den Ausschluss der Nachteile der reinen geometriebasierten und der reinen texturbasierten Darstellung. Vektordaten sind auf diese Weise in hoher Qualität, bei drastisch reduzierten Speicherverbrauch, auf der Geländeoberfläche darstellbar und zugleich ana-lytisch durch den Vektordaten-Szenengraph mit ihrer Identität bekannt. Veränderungen am Vek-tordaten-Szenengraph können direkt auf der Geländeoberfläche visuell nachvollzogen werden; eine aufwändige Neuberechnung zur Rasterisierung der Vektordaten entfällt. Die Fähigkeit, dynamische Vektordaten direkt auf der Geländeoberfläche darstellen zu können, erlaubt erweiterte Gestaltungsmöglichkeiten, die mit statischen Rasterbildern nicht zu realisieren sind.

Abbildung 50: Automatisierte Einebnung bzw. Aufstellung von Textmarkierungen in Abhängigkeit vom Blickwinkel. Städtenamen werden flach in der Textur (links) oder senkrecht auf dem Gelände als geometrische Objekte dargestellt (rechts).

69

Kapitel 6 ORIENTIERUNG UND NAVIGATION

Die Unterstützung von Orientierung und Navigation in 3D-Karten spielt eine wesentliche Rolle, um die effektive Kommunikation von 3D-Karteninhalt zu gewährleisten. In diesem Kapitel wird untersucht, wie eine effektive Orientierung und Navigation des Benutzers in 3D-Karten durch Wahl geeigneter Metaphern, durch Bereitstellung geeigneter interaktiver Werkzeuge und durch eine dynamische Gestaltung des Karteninhalts erreicht werden kann. Den Begriff „Orientierung“ definieren wir in unserem Kontext wie folgt:

Unter Orientierung verstehen wir die Fähigkeit, Lage und Position in einer räum-lichen virtuellen Umgebung eindeutig zu bestimmen.

Der Mensch orientiert sich mit Hilfe der Augen, des Gleichgewichtssinns, der Ohren und des Tastsinns. Das Gehirn sammelt die unterschiedlichen Sinneseindrücke und fertigt ein mentales Bild von der Umgebung. Das mentale Bild wird sukzessive durch weitere Eindrücke angepasst. Zu stark vom mentalen Bild abweichende Eindrücke erfordern eine „Neuberechnung“ des menta-len Bildes: Der Mensch ist vorübergehend orientierungslos (z. B. plötzliches Auftreten eines Rehs vom Auto). Einen ausführlichen Überblick über wahrnehmungstheoretische Grundlagen finden sich bei Neisser und Aebli [67]. Bei der Unterstützung der Orientierung des Benutzers in einer interaktiven Geovisualisierungs-umgebung muss darauf geachtet werden, dass die kognitive Belastung für den Menschen mög-lichst gering gehalten wird. Dazu dient ein Beispiel: In den Siebziger Jahren begannen Flugzeug-hersteller damit, Cockpits mit digitalen numerischen Anzeigen auszustatten, um eine präzisere Darstellung der momentanen Flugparameter mitzuteilen. Es stellte sich aber heraus, dass Piloten die Interpretation der numerischen Werte aufwändiger war als das Ablesen von Zeigerstellungen, so dass heute immer noch analoge Zeigerinstrumente oder digitale Nachahmungen der analogen Instrumente die Instrumententafeln dominieren.

6.1 Verwandte Arbeiten zur Orientierung und Navigation

70

Orientierung ist die Vorraussetzung für die Kommunikation räumlicher Information. Ohne zu wissen, wo sich der eigene Betrachtungsstandort in einer virtuellen Umgebung befindet, kann die dargestellte Information nicht korrekt räumlich eingeordnet werden. Die Orientierung des Betrachters muss auch bei der Navigation berücksichtigt werden. Wir definieren den Begriff „Navigation“ in unserem Kontext wie folgt:

Unter Navigation verstehen wir die kontrollierte Bewegung des Betrachters von einem Punkt zu einem anderen in einer räumlichen virtuellen Umgebung.

Der Fokus liegt hier auf der kontrollierten Bewegung, die der Betrachter selbst steuert. Der Be-trachter hat z. B. jederzeit die Möglichkeit, vorher eingeschlagene Routen zu korrigieren ohne dabei die Orientierung zu verlieren.

6.1 Anforderungen im Kontext von 3D-Karten Im Kontext von 3D-Karten ergeben sich folgende Anforderungen:

- Sicherstellung der Orientierung trotz reduzierter wahrnehmender Sinne: Die Orientie-rung des Kartennutzers erfolgt primär über visuelle Eindrücke. Werkzeuge zur Unter-stützung der Orientierung müssen hauptsächlich auf das Sinnesorgan Auge ausgelegt werden. Die Orientierung muss jederzeit gewährleistet sein.

- Sichere Navigation mit Standardeingabemedien: Die Navigation erfolgt mittels 2D-Maus und Tastatur.

- Dynamischer Karteninhaltsentwurf: Der Karteninhalt einer 3D-Karte muss dem Kontext angemessen sein, um die Orientierung durch eine unangemessene Darstellung, z. B. zu hohe Informationsdichte, nicht zu vermindern.

- Geringe kognitive Belastung: Der Kartennutzer muss durch Orientierungs- und Naviga-tionswerkzeuge eine möglichst geringe kognitive Belastung erfahren, um seine Aufmerk-samkeit hauptsächlich auf die Aufgabenerfüllung, z. B. die Analyse und Exploration von Geoinformationen, richten zu können.

6.2 Verwandte Arbeiten zur Orientierung und Navigation Für virtuelle Umgebung existieren eine Fülle von Ein- und Ausgabegeräten. Zu ihnen zählen ste-reoskopische Ausgabegeräte [4], z. B. die Virtual Workbench [68], die durch haptische Eingabe-medien, z. B. Forced-Feedback-Geräte [3] und räumliche Eingabemedien wie z. B. optische und magnetische Tracking-Systeme [23], ergänzt werden können. Virtuelle Umgebungen bieten trotz-dem nicht die Fülle an Reizen, die in einer realen Umgebung auf den Menschen eintreffen. Die Interaktion mit einer virtuellen Umgebung gestaltet sich deshalb grundsätzlich unterschiedlich im Vergleich zur Interaktion in einer realen Umgebung, weil eine Reihe von Sinneswahrnehmungen durch die beschriebenen Geräte nur unzureichend simuliert werden können. Bowman et al. [11] benennen mögliche Bewertungsmaßstäbe für die Qualität von Navigations-werkzeugen. Dazu zählen (1) die Geschwindigkeit zur Lösung einer bestimmten Aufgabe, (2) die Genauigkeit zum Erreichen eines bestimmten Ziels, (3) die Aufrechterhaltung der räumlichen O-rientierung, (4) die Erlernbarkeit, (5) die Benutzbarkeit, (6) das Potential der Informationssamm-lung während der Bewegung, (7) der Grad des Eintauchens in die Umgebung und (8) der Benut-zungskomfort, der sich antiproportional zur „Simulator Sickness“ verhält. Die Priorität der Be-wertungsmaßstäbe variiert mit der zu erfüllenden Aufgabe (z. B. Fußgänger- und Flugsteuerung). Der Benutzungskomfort und die Benutzbarkeit leiden häufig unter der vollständigen Bewegungs-freiheit in virtuellen Umgebungen. Aus diesem Grund schränken Hanson und Wernert [39] die

Kapitel 6 - Orientierung und Navigation

71

Navigation durch Constraint-Oberflächen ein und erlauben dadurch nur kontrollierte Bewegun-gen der virtuellen Kamera: Der Nutzer wird bei der Navigation durch die virtuelle Umgebung geführt. Die Kollisionserkennung ist eine wichtige Funktionalität, die bei der Navigation innerhalb virtuel-ler Umgebungen gewährleistet sein muss, da sie grundlegend in unserer Erfahrung bei der Navi-gation in physischen Räumen vorkommt. Im Kontext von 3D-Karten bedeutet das, dass der Bet-rachter z. B. die Geländeoberfläche nicht durchstoßen oder unter die Geländeoberfläche gelangen darf. In der Algorithmische Geometrie wurden eine Vielzahl an Lösungen für das Problem entwi-ckelt (z. B. HCollide von Gregory et al. [33], k-dops von Klosowski et al. [54] oder die Multi-Point Kollision von Snyder et al. [81]). Neben der aktiven Unterstützung der Orientierung und Navigation durch entsprechende Werk-zeuge spielt die „passive“ Unterstützung durch die geeignete Gestaltung des Karteninhalts eine wichtige Rolle (Döllner und Kersting [22]). Durch dynamische Anpassung des Karteninhalts wird der kognitiven Überladung durch überzählige Details entgegengewirkt oder die Aufmerksamkeit des Betrachters gezielt gelenkt. Als Werkzeuge dienen dabei z. B. Textur-Linsen (Abschnitt 6.6).

6.3 Virtuelle Kamera Die Sicht auf eine 3D-Karte wird durch die virtuelle Kamera (Abbildung 51) festgelegt, die ein Bild einer 3D-Szene in perspektivischer Projektion erzeugt. Die virtuelle Kamera besitzt ein Sichtvolumen in der Form eines Pyramidenstumpfes. Alle geometrischen Objekte innerhalb des Sichtvolumens sind potential im Bild der Kamera sichtbar, alle Objekte außerhalb sind im Bild nicht sichtbar. Um ein eindeutiges Kamerakoordinatensystem festzulegen, wird die Kameraposition (from), die Kamerablickrichtung (to) und die Kamerahöhenrichtung (up) festgelegt. Das Kamerakoordina-tensystem wird neben to und up durch den Kamerarechtsrichtung aufgespannt, der implizit durch das Kreuzprodukt von to und up gegebenen ist (vgl. Foley et al. [29]). Das Koordinaten-system muss nicht notwendigerweise orthogonal sein.

from to

up

near

far

α

β

Abbildung 51: Beschreibung des Sichtvolumens durch Kameraposition from, Kamerablickrichtung to und Kamerahöhenrichtung up, Abstand zur vorderen Clipebene near und zur hinteren Clipebene far sowie Höhenwinkel α und Breitenwinkel β.

6.4 Orientierungswerkzeuge

72

Der Höhenwinkel α und der Breitenwinkel β legen die Öffnungswinkel der Kamera vertikal und horizontal fest. In der Regel sind die beiden Winkel gleichgesetzt; man spricht dann von Field-of-View (fov). Da der Tiefentest den Tiefenpuffer nur mit einer festgelegten Präzision verwenden kann (z. B. 24 Bit pro Pixel), wird das Sichtvolumen durch die Festlegung einer vorderen (near) und einer hinteren (far) Clipebene auf einen Pyramidenstumpf reduziert. Der Wertebereich des Tiefenpuffers wird auf diese Weise optimal ausgenutzt. Technisch legt das Modell der virtuellen Kamera die grundsätzlichen Freiheitsgrade der Navigati-on fest. Die Parameter der virtuellen Kamera werden in Form einer Projektions- und einer Sicht-transformationsmatrix dem Renderingsystem übermittelt.

6.4 Orientierungswerkzeuge Wir verstehen Orientierungswerkzeuge hier als Bestandteile virtueller Umgebungen oder Benut-zungsschnittstellen, die durch meist visuelle Hilfestellungen die Orientierung unterstützen. Wir werden im folgenden einige Orientierungswerkzeuge diskutieren, die den Anforderungen aus Ab-schnitt 6.1 genügen.

6.4.1 Horizont Der natürliche Horizont bezeichnet die Linie, an der sich Himmel und Erde (oder Meer) zu be-rühren scheinen. Der natürliche Horizont trennt den sichtbaren Teil der Himmelskugel vom un-sichtbaren Teil. Ein zum Horizont orthogonaler Vektor zeigt demnach zum Himmel. Dies macht sich der Mensch zu nutze, um seine Lage zu definieren. Fehlt die freie Sicht auf den Horizont z. B. in sehr dichtem Wald, fällt es dem Menschen schwer, nur auf visuelle Eindrücke beschränkt z. B. zwischen aufsteigendem und absteigendem Wegverlauf zu unterscheiden. Aus diesem Grund ist ein künstlicher Horizont fester Bestandteil einer 3D-Karte. Im 3D-Kartensystem existiert dazu die Klasse Sky, die neben der Funktionalität für den Himmel, noch die für Sonnen- und Sonnenreflexionen bereitstellt. Der Sonnenstand kann dabei aus der aktuellen Uhrzeit und dem Breitengrad errechnet werden. In der 3D-Karte wird der Horizont nicht immer durch den „Schnitt“ von Himmel und Gelände-modell ersichtlich, sondern durch einen himmelstypischen Farbverlauf im Hintergrund angedeutet (Abbildung 52 links). Zusätzliche „Anzeigegeräte“ sind nicht notwendig; die kognitive Belastung zur Wahrnehmung des Horizonts ist gering. Liegt der Horizont nicht waagerecht (Abbildung 52 rechts), bedarf es mehr Aufwand seitens des Nutzers, seine Lage zu bestimmen. Oft neigt der Betrachter den Kopf zu Seite, um die Szene zu

Abbildung 52: 3D-Karte mit waagerechtem Horizont (links) und mit schrägem Horizont (rechts).


73

betrachten. Dies ist in vielen Videospielen gewünscht zur Steigerung der Bewegungsintensität und der Orientierungslosigkeit. Im Kontext von 3D-Karten ist dies kontraproduktiv und wird durch die entsprechenden Navigationsmetaphern (Abschnitt 6.5) unterbunden. Es gilt also immer up = (0,1,0).

6.4.2 Kompass Klassische 2D-Karten sind „genordet“, das heißt implizit ist die Nord-Richtung in Richtung der oberen Kartenkante. In einer interaktiven 3D-Karte sind der Bewegung der Kamera zunächst kei-ne Grenzen gesetzt. Deshalb muss die Himmelsrichtung auf anderem Wege vermittelt werden. Eines der ältesten technischen Hilfsmittel zur Richtungsbestimmung ist der Kompass Die Kom-passnadel zeigt in der Regel Richtung Norden, so dass daraus die eigene relative Ausrichtung hergeleitet werden kann. Im 3D-Kartensystem existiert dazu die Klasse Compass, die die beschriebene Funktionalität be-reitstellt. Der Kompass erscheint an einer festzulegenden Position in der Sichtebene und kann un-terschiedlich transparent dargestellt werden (Abbildung 53 links). Exemplarisch wurde eine Kodierung der Himmelsrichtungen in Farben untersucht, die in Abhän-gigkeit der Himmelsrichtung den Himmel entsprechend färben. Obwohl die Farbe „nebenbei“ aufgenommen werden konnte verstärkte die Verwendung die kognitive Belastung, denn dem Nut-zer fiel es schwer die gegebene Richtung aus den Farben abzuleiten.

6.4.3 Landmarken Landmarken sind ein Mittel zur Unterstützung der Orientierung in virtuellen Umgebungen da-durch, dass sie explizit Positionen in einer virtuellen Umgebung repräsentieren. Sie sind geeignet, leicht vom Betrachter wahrgenommen und erinnert zu werden. Zu den klassischen Landmarken von Karten gehören Kirchen, Brücken und allgemein Monumente. In 3D-Karten verstehen wir unter Landmarken auch solche Objekte, die aufgabenbezogen eine wesentliche Information ver-körpern, z. B. Abbiegungen bei einer Routenplanung. Landmarken können insbesondere die Suche nach Standorten optimal unterstützen. Elvins et al. [25] empfehlen Die Verwendung von geometrischen 3D-Objekte innerhalb virtueller Umgebun-gen, um die Wiedererkennung von Regionen und Position zu verbessern. Als Beispiel hierfür dient der in vielen Wettervorhersagen verwendete „Wetterflug“: Städte werden dabei durch Landmarken in Form markanter Bauwerke repräsentiert, z. B. Berlin durch das Brandenburger Tor. Eine Navigation zu ausgezeichneten Positionen über Auswahl von Menüpunkten oder Lis-

Abbildung 53: In die 3D-Kartenansicht integrierter Kompass (links) und Golden-Gate-Bridge als Landmarke (rechts) zur Unterstützung der Orientierung.

6.5 Navigationswerkzeuge

74

teneinträgen soll komplementär zur Verfügung stehen, besitzt aber nicht die gleiche Wirksamkeit wie die Repräsentation durch Landmarken. Im 3D-Kartensystem existiert zur Verwendung von Landmarken die Klasse Symbol (Abschnitt 2.3.3, Abbildung 53 rechts).

6.4.4 Übersichtskarte Die Lage des Sichtvolumens in einer 3D-Karte wird durch die in Abschnitt 6.3 beschriebenen Parameter der virtuellen Kamera festgelegt. Durch die numerischen Werte allein ist die Kamera wenig intuitiv für den Benutzer zu erkennen und einzustellen. Aus diesem Grund kommen Übersichtskarten zum Einsatz, die als klassische 2D-Karten dem Nutzer vertraut sind und durch die zusätzliche Einblendung des auf die Geländefläche projizierten Sichtvolumens in Form eines Vierecks oder vereinfacht als Dreieck die Orientierung unterstützen (Abbildung 54). Die darge-stellte Thematik in der Übersichtskarte ist von der der eigentlichen Hauptansicht unabhängig und erlaubt so z. B. eine unterschiedliche Generalisierung der dargestellten Information. Im 3D-Kartensystem existiert zur Verwendung einer Übersichtskarte die Klasse MetaView, die es erlaubt unterschiedliche Rasterthematiken als Hintergrund zu verwenden. Neben der reinen Orientierungsunterstützung erlaubt ein MetaView auch die Manipulation des Kamerastandpunk-te und der Kamerarichtung durch Verschieben des Sichtvolumens mittels der Maus.

6.5 Navigationswerkzeuge Wir verstehen Navigationswerkzeuge hier als Bestandteile virtueller Umgebungen, die dem Be-nutzer die gezielte Navigation von einem Punkt der virtuellen Umgebung zu einem anderen er-möglichen. Fester Bestandteil eines Navigationswerkzeuges ist die Navigationsmetapher, die das mentale Modell der Navigation beschreibt. Bekannteste Navigationsmetapher in 3D-Umgebungen ist die Flug-Metapher. Dabei besitzt der Nutzer die Möglichkeit, die virtuelle Kamera ähnlich einem Flugzeug mit konstanter Geschwindigkeit durch die 3D-Umgebung zu bewegen. Diese Metapher eignet sich sehr gut zur Präsentation, allerdings weniger zur Exploration und Analyse, denn die Fokussierung auf einzelne Bereiche der Geländeoberfläche ist damit sehr umständlich. Im Fol-

Abbildung 54: Übersichtskarte unterstützt die Orientierung durch einblenden Sichtvolumens in eine generalisierte Draufsicht.


75

genden befassen wir uns mit zwei Navigationsmetaphern, die sich für die Exploration und Analy-se von Punkten besonderen Interesse gut eignen.

6.5.1 Kugel- und Kegel-Navigationsmetapher Die Kugel-Navigationsmetapher bildet die x- und y-Achse der Mausebene auf eine Kugelober-fläche ab. Der Mittelpunkt dieser Kugel ist durch from+to und der Radius durch die Länge |to| definiert. Radius und Mittelpunkt bleiben unverändert. Die x-Achse der Mausebene wird auf die Breitengrade und die y-Achse auf die Längengrade abgebildet (Abbildung 55). Die Metapher eignet sich besonders zur präzisen Navigation um einen Punkt besonderen Interes-ses. Die Orientierung bleibt auch während der Bewegung gesichert, da der Fokuspunkt immer sichtbar ist. Die Kugeloberfläche stellt eine Constraint-Oberfläche dar, die leicht verständlich ist. Die Kegel-Navigationsmetapher bildet die x- und y-Achse der Mausebene auf eine Kegeloberflä-che ab. Die Spitze dieses Kegels ist durch from+to und der Abstand durch die Länge |to| defi-niert. Die Spitze bleibt unverändert. Die x-Achse der Mausebene wird auf den Rotationswinkel um den Vektor (0,1,0) abgebildet. Die y-Achse der Mausebene wird auf den Abstand zur Kegel-spitze abgebildet (Abbildung 56). Die Metapher eignet sich besonders zur präzisen Navigation um die Umgebung eines Punktes besonderen Interesses. Wie bei der Kugel-Metapher bleibt die Orientierung auch während der Bewegung gesichert, da der Fokuspunkt immer sichtbar ist. Die Kegeloberfläche stellt eine Constraint-Oberfläche dar, die leicht verständlich ist.

from

to

up x-Achse

y-Achse

Abbildung 55: Kugel-Metapher zur Navigation mit fixem Abstand um einen fokussierten Punkt.

to

from

up

x-Achse

y-Achse

Abbildung 56: Kegel-Metapher zur Navigation mit fixem Winkel um einen fokussierten Punkt.

6.5 Navigationswerkzeuge

76

Im 3D-Kartensystem existiert zur Verwendung der hier vorgestellten unterschiedlichen Navigati-onsmetaphern die Klasse Navigation. Nach Assoziation eines festzulegenden Mausknopfes ist die Navigationsmetapher aktiv. Darüber hinaus überwacht die Klasse Navigation die Kollision mit der Geländeoberfläche zur Unterstützung der Orientierung.

6.5.2 Kollisionserkennung Wie bereits in Abschnitt 5.5 beschrieben verfügt das Virtuelle Rendering System über einen Me-chanismus zum Test auf Strahlenintersektion. Dies kann zum einen genutzt werden zur Identifika-tion von Objekten in einer 3D-Karte, zum anderen zur Erkennung von Kollisionen. Dank der hie-rarchischen Anordnung der Geländegeometrie (Abschnitt 3.5) kann ein Strahlentest sehr effizient durch Ausschluss nicht relevanter Geländeoberflächenbereiche durchgeführt werden. Folgende Überprüfung wird bei jeder Änderung der Kameraposition durch ein Navigation Objekt durch-geführt. Vor jeder Änderung der alten Kameraposition fromold zur neuen Kameraposition fromnew wird ein Strahl ausgehend von fromold in Richtung von fromnew ein Strahlentest durchgeführt. Wird das Geländemodell nicht getroffen, wird die Kamera auf die neue Position verschoben; eine Kollision mit dem Gelände kann nicht eintreten. Wird das Geländemodell in dem Punkt hit getroffen, müs-sen zwei Fälle unterschieden werden. Im ersten Fall ist der Abstand d1 von fromold zu hit größer als der Abstand d2 von fromold zu fromnew (Abbildung 57). Die neue Kameraposition ist somit zulässig, weil sie über der Gelände-oberfläche liegt. Im zweiten Fall ist der Abstand d1 von fromold zu hit kleiner als der Abstand d2 von fromold zu fromnew (Abbildung 58). Die neue Kameraposition ist unzulässig, da sie unterhalb

fromold d1

hit fromnewd2

d1>d2

Abbildung 57: Schnittpunkt mit dem Geländemodell ist nicht zwischen fromold und fromnew.

fromoldd1

hit

fromnew

d2

fromnew’

d1<d2

Abbildung 58: Schnittpunkt mit dem Geländemodell liegt zwischen fromold und fromnew. Eine neue Ka-meraposition fromnew’ wird errechnet.


77

der Geländeoberfläche liegt. Ausgehend von dem Punkt fromnew wird nun durch einen zweiten senkrechten Strahl eine zulässige Kameraposition fromnew’ auf der Geländeoberfläche bestimmt. Tritt eine Berührung des Geländemodells auf, wird ein CollisionEvent erzeugt und an den Verhaltensgraphen weitergeleitet (Abschnitt 2.5.1).

6.5.3 Beschränkte Navigation Ein Form der Beschränkung der Navigation ist die automatische Kameraanimation. Bei der Kameraanimation wird die Kameraposition und -blickrichtung in Abhängigkeit der Zeit entlang vordefinierter Pfade bewegt. Die Interaktion des Nutzers ist hier unterbunden. Die semiautoma-tische Kameraanimation erlaubt entweder die Manipulation der Kameraposition oder der Kamerablickrichtung während einer Kamerafahrt. Der jeweils andere Wert wird durch einen Pfad vorgegeben. Im 3D-Kartensystem wird diese Funktionalität durch die Klasse Animation reali-siert. Eine allgemeine Form zur Implementierung von Beschränkungen der Navigation lässt sich mittels spezieller Ereignistabellen (Abschnitt 2.5.3) erreichen. Über einen benutzerdefinierten Callback, der in ein Ereignistabelle für RedrawEvent-Objekte registriert wird, können die momentanen Kameraeinstellungen erfragt, auf bestimmte Beschränkungen hin untersucht und ggf. korrigiert werden. Auf diese Weise können z. B. die Constraint-Oberflächen von Hanson und Wernert [39] realisiert werden.

6.6 Dynamischer Entwurf des Karteninhalts Die Benutzbarkeit von 3D-Karten steht in enger Verbindung zum Entwurfs des Karteninhalts: Darstellungsart, Intensität und Verteilung von räumlicher und raumzeitlicher Information müssen an die Benutzeranforderungen und die Bildauflösung adaptiert werden. 3D-Karten unterstützen dies, weil sie leistungsfähige und flexible Methoden zum Entwurf des Karteninhalts und die Um-setzung von Entwürfen in Echtzeit bieten (Abschnitte 4.4, 4.5, 5.4 und 5.6). Mehrfache Textur-schichten sind das Hauptkonstrukt, um Techniken zur Fokussierung, Restriktion und Adaption von Information in 3D-Karten umzusetzen. Die dynamische Gestaltung einer 3D-Karte vereinfacht die Implementierung von Techniken zur Unterstützung von Orientierung und Navigation, weil dadurch sowohl die visuelle Präzision als auch die kognitive Belastung des 3D-Karteninhalts an den Kontext und den Benutzer angepasst werden können. Beide Faktoren haben einen hohen Einfluss auf die Verwendbarkeit der Karte, weil sie die präzise und effektive Nutzung des Bildraums erlauben.

6.6.1 Wahrnehmung der Geländemorphologie Die genaue Wahrnehmung der Geländemorphologie ist eine Voraussetzung für effektive Orientie-rung und Navigation. Wir nehmen die Morphologie eines Geländes, das auf ein zweidimensiona-les Fenster projiziert wird, über die Schattierung und die Silhouette war. Arbeiten aus der Psy-chophysik zeigen, dass das Erkennen einer dreidimensionalen Figur allein über seine Schattierung eine grundlegende präkognitive Fähigkeit darstellt. In unserem Ansatz benutzen wir topographi-sche Texturen zur Schattierung des Geländes, das heißt wir ersetzen die übliche geometriebasierte Schattierung des Geländemodells durch eine Schattierungstextur aus zweierlei Gründen. Zum einen ist die Schattierung dadurch unabhängig von der Geländegeometrie, zum anderen bieten sich dadurch erweiterte Gestaltungsmöglichkeiten, da nicht echtzeitfähige Schattierungsverfahren (z. B. Selbstschattierung mittels Raytracing) oder sogar manuelle Verfahren (z. B. Imhof [48]) eingesetzt werden können.

6.6 Dynamischer Entwurf des Karteninhalts

78

6.6.2 Linsen zur Fokussierung von Information Durch die Kontrolle eines visuellen Fokus in der 3D-Karte kann die Orientierung und Navigation unterstützt werden, indem wir die Aufmerksamkeit des Betrachters durch die Karte und die in ihr dargestellten oder stattfindenden Prozesse lenken. Technisch werden zu diesem Zweck Texturlin-sen verwendet, die die visuelle Fokuskontrolle implementieren. Texturlinsen können an Benutzer-aktionen geknüpft werden, das heißt sie werden unmittelbar durch Benutzeraktionen gesteuert. Zwei mögliche Anwendungen dieser visuellen Fokussierung sind im folgenden kurz illustriert. Luminanz-Texturlinsen erlauben die Beschreibung raumzeitlicher Prozesse durch die Animation des visuellen Fokus, wie z. B. das Wandern entlang eines Weges (Abbildung 59). Zum anderen erlauben sie das Aufhellen räumlicher Positionen, wie z. B. Kartenpunkte und Kartenregionen. Filter-Texturlinsen erlauben die Reduktion der Inhaltskomplexität durch die visuelle Restriktion von Informationen: Information nur wird dort sichtbar, wo der Benutzer die Information sehen möchte. Die Orientierung wird dadurch erhöht, da nur solche Elemente in der Gestaltung aufge-nommen werden und damit sichtbar sind, die für den momentanen Kontext und die konkrete Auf-gabe von Bedeutung sind. Zum anderen erlauben Filter-Texturlinsen die visuelle Assoziation unterschiedlicher Thematiken. Abbildung 60 zeigt zwei unterschiedliche Thematiken aus dem Bereich der Funknetzplanung. In Abbildung 60 links wird zur Orientierung die Landnutzungsinformation und die Feldstärke als lokal zu untersuchende Thematik dargestellt. Entlang des Linsenrandes können beide Thematiken assoziiert und Unterschiede gut wahrgenommen werden. So fällt z. B. auf, dass der Flussverlauf sich in den beiden Rasterdatenschichten unterscheidet, das heißt die Georeferenzierung von min-destens einer Schicht nicht korrekt ist. Die umgekehrte Darstellung der Thematiken beeinflusst

Abbildung 59: Unterstützung der Wegfindung durch animierte Helligkeitslinse.

Abbildung 60: Darstellung der Landnutzung und Fokussierung der Feldstärke eines Funknetzes mittels Filter-Texturlinse (links) sowie die inverse Darstellung der Thematiken (rechts).


79

die Orientierung negativ, weil die Feldstärke - im Gegensatz zur Landnutzung - dem ungeschulten Nutzer keine verwertbaren Hinweise auf seine Lage gibt (Abbildung 60 rechts)

6.7 Zusammenfassung Die Unterstützung der Orientierung und Navigation wird durch spezifische Werkzeuge erreicht. Die vorgestellten Orientierungswerkzeuge erleichtern die Bestimmung von Lage und Position in 3D-Karten, ohne die kognitive Belastung nennenswert zu erhöhen. Die vorgestellten Navigati-onswerkzeuge erlauben die zielgerichtete Navigation Mit Hilfe von speziellen 3D-Kartenbauelementen können benutzerspezifische und anwendungs-spezifische Funktionalität in die Karte integriert werden, die die Navigation des Benutzers kon-trollieren und unterstützen. Zur Unterstützung der Orientierung und Navigation kann der dynamische Inhaltsentwurf in einer 3D-Karte eingesetzt werden. Die Mechanismen zur visuellen Fokussierung, Restriktion und A-daption von Informationen verfolgen das Ziel, die kognitive Belastung einer Karte zu optimieren und die Aufmerksamkeit des Benutzers zu lenken. Dieses Ziel wird insbesondere durch überlagerungsfähige, dynamische Texturschichten erreicht.

81

Kapitel 7 KONFIGURATION VON 3D-KARTEN

Mit Skriptsprachen (z. B. Perl, Phyton oder Tcl) ist im Gegensatz zu Systemprogrammierspra-chen (z. B. C, C++, Pascal) die Entwicklung komplexer, auf Komponenten basierender Anwen-dungen aufgrund der schwächeren Typisierung und der Möglichkeit zur interaktiven Programmie-rung wesentlich vereinfacht. Aus diesem Grund werden die Framework-Bestandteile des 3D-Kartensystems als Erweiterung einer Skriptsprache bereitgestellt. Dafür werden alle für die Anwendungsentwicklung relevanten Klassen – genauer ihre Schnittstel-len - automatisiert als Erweiterung in eine Skriptsprache abgebildet. Die so erweiterte Skriptspra-che erlaubt zur Laufzeit die Erzeugung, Manipulation und Zerstörung von C++-Objekten sowie die Erfragung von Klassen- und Framework-Metainformationen durch den Interpreter. Dies ermöglicht eine interaktive Programmierung von 3D-Kartenanwendungen zur Laufzeit und die Spezifikation von Verhalten für 3D-Kartenbauelemente durch Skripte. Durch diesen hybriden Ansatz von Systemprogrammier- und Skriptsprache stellen wir ein Höchstmaß an Geschwindig-keit und Effizienz für die graphische Darstellung und zugleich bestmögliche Flexibilität bei der Entwicklung von 3D-Kartenanwendungen (rapid prototyping) sicher. Im weiteren Verlauf dieses Kapitels befassen wir uns mit der automatischen Abbildung des Pro-grammierschnittstellen der C++-Klassenbibliotheken VRS und LDX in die Skriptsprache Tcl (Ousterhout [69]). Tcl dient hierbei als Beispiel, denn der Abbildungsmechanismus ist so allge-mein gehalten, dass auch andere Interpreter angebunden werden können. Tcl zeichnet sich durch die leichte Erlernbarkeit der Syntax, das integrierte Benutzungsschnittstellen-Toolkit Tk und die zahlreichen Erweiterungen (Harrison [40], Welch [93]) aus. Die Interpreteranbindungen werden im Folgenden als interactive VRS (iVRS) bzw. interactive LDX (iLDX) bezeichnet.

7.1 Anforderungen im Kontext von 3D-Karten Im Kontext von 3D-Karten ergeben sich folgende Anforderungen an die Tcl-Interpreteranbindung der C++-Bibliotheken VRS/LDX:

7.1 Anforderungen im Kontext von 3D-Karten

82

- Automatisierte Anbindung: Die Anbindung der VRS/LDX-Klassen an Tcl muss automati-siert erfolgen, so dass Änderungen an VRS/LDX ohne manuellen Aufwand der Interpreteran-bindung zur Verfügung stehen.

- Keine Veränderung der C++-Klassen: Die anzubindenden C++-Klassen sollen in ihrer Schnittstelle und Implementierung unverändert an den Interpreter angebunden werden kön-nen, so dass sich für eine ausschließlich in C++ implementierte Anwendung keine Nachteile und Zusätze ergeben.

- Automatische Argumentkonvertierung: Die Tcl-Anbindung erfordert einen effektiven Me-chanismus zur Identifikation und zum Aufruf von C++-Methoden. String-Argumente müssen automatisch interpretiert und in C++-Argumenttypen umgewandelt werden können und C++-Argumenttypen müssen automatisch in String-Argumente umgewandelt werden können.

- Stimmige Abbildung von C++-Konzepten: Die Verwendung von C++-Klassen und C++-Objekten durch den Interpreter darf sich nicht wesentlich von der Verwendung in C++ unter-scheiden. Über den Interpreter müssen C++-Objekte erzeugt, manipuliert und zerstört werden können (Abbildung 61). Folgende Aspekte müssen berücksichtigt werden:

o Die Vererbung als ein elementares Konzept der objektorientierten Programmierung muss durch die Interpreteranbindung abgebildet werden können. Die Berücksichti-gung von Vererbungshierarchien insbesondere bei Konvertierungen muss gewährleis-tet sein.

o Polymorphe und abstrakte Methoden müssen durch die Interpreteranbindung unter-stützt werden, um ein korrektes Objektverhalten zu garantieren.

o Die VRS-Basisklasse SharedObj implementiert eine Referenzzählung zur semi-automatischen Speicherverwaltung. Die Referenzzierung und Dereferenzzierung ei-nes SharedObj-Objektes wird registriert und gespeichert. Wird ein Objekt von kei-nem anderen Objekt referenziert, wird es automatisch zerstört. Die Tcl-Anbindung kann und muss diese Technik nutzten, um Speicherlöcher zu vermeiden und eine komfortable Speicherverwaltung zu ermöglichen.

o Objekte mit Identität und Objekte als Werte: Viele Klassen sind von der Basisklasse SharedObj abgeleitet, die untereinander gemeinsam genutzte, dynamisch allokierte Objekte repräsentiert. Diese Objekte besitzen eine Identität. Klassen, deren Objekte wie Werte aufgefasst werden (by-Value Aufrufe) sind nicht von SharedObj abgelei-tet. Diese Klassen umfassen z. B. numerische Klassen wie Vector oder Matrix. Die Anbindung muss beide Kategorien von Objekten handhaben können.

o Methodenüberladung findet in vielen Klassen der 3D-Kartenbibliothek Verwendung. Wenn zwei Methoden gleichen Namens sich in der Anzahl der Argumente unter-scheiden, können sie beim Aufruf eindeutig zugeordnet werden. Falls sie aber die gleiche Anzahl an Argumenten verwenden, muss die Tcl Anbindung in der Lage sein,

C++-Code Tcl-Code

A* a = new A(12.0);a->setValue(3.0);delete a;

set a [new A 12.0]$a setValue 3.0delete $a

Abbildung 61: Gegenüberstellung von C++- und Tcl-Quellcode zur Erzeugung, Manipulation und Zerstörung von Objekten.

Kapitel 7 - Konfiguration von 3D-Karten

83

die Methoden anhand der Argumenttypen zu unterscheiden, obwohl Tcl keine strenge Typisierung bereitstellt.

o Template-Klassen werden in VRS/LDX zur Datenhaltung (z. B. Array, List, Queue) und zum Datenaustausch (z. B. Iterator, Iterator2D) eingesetzt. Eini-ge Template-Klassen basieren auf der Standard Template Library [2]. Die Instanzi-ierungen der Template-Klassen müssen erkannt und durch die Tcl-Anbindung ver-fügbar gemacht werden.

o Des weiteren müssen Default-Argumente, Aufzählungen (enum), deren logische Kombination sowie statische Klassenelemente abzubilden sein, um eine praktikable Verwendung der C++ Klassenbibliotheken zu gewährleisten.

Die Interpreter-Anbindung von iVRS/iLDX muss konkret 392 Klassen, darunter 51 Template-Klassen, 55 abstrakte Klassen und 14 nicht SharedObj-Klassen in Tcl einbetten. Dabei müssen 3884 Methoden, darunter 537 statische, 84 abstrakte, 98 überladene und 989 polymorphe Me-thoden angebunden werden.

7.2 Verwandte Arbeiten zur C++-Interpreteranbindung Tcl ist ursprünglich eine prozedurale Programmiersprache, die vollständig in C geschrieben ist. C-Funktionen können deshalb direkt über das C-API von Tcl durch Registrierung von Callbacks eingebunden werden. Direkte Unterstützung für C++-Klassen wird nicht bereitgestellt. Objektorientierte Konzepte müssen deshalb nachgebildet werden. Es existieren einige objektorientierte Erweiterungen, die Konzepte objektorientierter Sprachen direkt in die Sprache Tcl integrieren. Zu nennen wären hier die am weitesten verbreitete Erweite-rung [incr Tcl] von McLennan [65]. [incr Tcl] erlaubt die Verwendung von Klassen, Methoden, Polymorphie, Konstruktoren. Mehrfachvererbung und Überladen von Methoden ist nicht möglich. Die Erweiterung Tclpp von Sinnige [80] ist ähnlich mächtig, ist von der Syntax allerdings an C++ angelehnt. Es existieren einige Werkzeuge zur Abbildung von C++-Klassenhierarchien in adäquate Kon-strukte von Tcl. Ein allgemeiner C++-Tcl-Mapper ist SWIG (Simplified Wrapper and Interface Generator von Beazley [7]). SWIG kann C, C++, and Objective-C APIs in eine Vielzahl anderer Sprachen abbilden (z. B. Tcl, Phyton, Java). Dazu werden die benötigten C++-Header-Dateien und spezielle manuell zu erstellende Interface-Dateien analysiert und der zugehörige Wrapper-Code für die Zielsprache erzeugt. Ursprünglich war SWIG für C entwickelt worden, so dass C++-Konstrukte nachträglich hinzugefügt und zum Teil umständlich oder gar nicht zu verwenden sind (überladene Methoden, Smartpointer zur Referenzzählung, komplexe Templateklassen). Der Itcl++-Mapper (Heidrich et al. [42]) basiert auf [incr Tcl]. Itcl++ parst C++-Header, generiert C++ Wrapper-Code und verknüpft diese mit ebenfalls generierten [incr Tcl]-Klassen. Die Vererbungsbeziehung zwischen Klasse bleibt erhalten, so dass neue [incr Tcl] Klassen von den generierten [incr Tcl] Klassen abgeleitet werden können. Als Beispiel hatten die Autoren das komplette C++-API der 3D-Graphikbibliothek OpenInventor (Strauss und Carey [86]) abgebildet. Abgesehen von dem sehr aufwendigen Generierungsprozess (zwei komplette Vererbungshierarchien) fehlt die Unterstützung für abstrakte Klassen und überladene Methoden. In unserem Ansatz verzichten wir auf eine Abbildung des C++ APIs in eine objektorientierte Er-weiterung von Tcl. Damit verhindern wir zwar die nachträgliche Erweiterung der Vererbungshie-rarchie durch Tcl-eigene Klassen, reduzieren aber den Ressourcenverbrauch. Anzumerken ist, dass im Fall interaktiver 3D-Graphik kaum eine sinnvolle Spezialisierung denkbar ist, da diese

7.3 Technik der verwendeten Interpreteranbindung

84

weder auf das zugrundeliegende 3D-Renderingsystem zugreifen könnte noch die erforderliche Geschwindigkeit anbieten könnte. Wir konzentrieren uns auf die „usability-critical“ Eigenschaf-ten des C++-APIs, wie überladene Methoden, Objektverwaltung, Speicherverwaltung und Klassenreflexion.

7.3 Technik der verwendeten Interpreteranbindung Unsere Abbildungstechnik konzentriert sich auf die objektorientierten Fähigkeiten von C++ und bildet als Basiskonstrukte ausschließlich C++-Klassen nach Tcl ab. Konstrukte wie Strukturen, global Variablen oder globale Funktionen werden nicht unterstützt. Um die nötigen Klassen-Informationen zu extrahieren, wurde zum einen ein Parser entwickelt, der die gewünschten C++-Header-Dateien untersucht, und zum anderen ein Generator, der aus den analysierten Informationen die zugehörigen C++-Wrapper-Klassen erzeugt. Eine Wrapper-Klasse kann virtuelle und nicht-virtuelle Methoden, Konstruktoren, statische Me-thoden, arithmetische Operatoren und Aufzählungen verfügbar machen. Momentan wird direkter Zugriff auf öffentliche Attribute, nicht konstante Referenzen, Namensräume, verschachtelte Klas-sen und Mehrfachvererbung nicht unterstützt. Diese C++-Sprachkonstrukte kommen selten in VRS/LDX vor und wurden deshalb noch nicht abgebildet.

7.3.1 Wrapper Klassen Zur Anbindung der VRS/LDX-Klassen an Tcl werden zu jeder abzubildenden C++-Klasse (Wrapped-Klasse) spezielle Wrapper-Klassen erzeugt, die in den generischen Wrapper-Mechanismus eingebunden werden. Dadurch können die Wrapped-Klassen unverändert in den generischen Wrapper-Mechanismus aufgenommen werden (Abbildung 62). Wrapper-Klassen reflektieren die Methoden der ursprünglichen Wrapped-Klassen durch Wrap-per-Methoden, die über eine einheitliche Signatur für String-Argumente verfügen. Zu jeder

Wrapper-Mecahnismus

Spezielle Wrapper Original Klassen

Wrapper«Singleton»

CallManager

«Singleton»WrapperManagerMethodTable

A

B C

AWrap

BWrapCWrap

1

1

1

EnumTable

1

0..1

*

Abbildung 62: Gruppierung von Klassen für den Wrapper-Mechanismus, der spezielle Wrapper und der original Klassenhierarchie.


85

Wrapper-Methode existiert genau eine ursprüngliche Methode (Wrapped-Methode). Eine Wrap-per-Methode konvertiert eingehende String-Argumente in die nötigen C++-Datentypen und wan-delt Rückgabewerte in Strings um. Die Zuordnung von Wrapper-Methoden und Wrapped-Methoden, sowie die Speicherung von Signatur-Informationen übernimmt die Wrapper-Methodentabelle, die für jede Wrapper-Klasse genau einmal angelegt wird (Abbildung 63). Die Klasse Wrapper ist die Basisklasse aller Wrapper-Klassen. Sie stellt Methoden zur Erzeu-gung neuer Wrapper-Objekte (Prototyp-Pattern), zur Initialisierung und zum Aufruf von Metho-den von enthaltenen Wrapped-Objekten bereit. Darüber hinaus verfügt ein Wrapper-Objekt über eine eindeutige Typidentität, die abgeleitete Wrapper-Klassen entsprechend ihrer zugeordneten Wrapped-Klasse spezialisieren. Die Typidentität erlaubt das Erfragen der kompletten Verer-bungshierarchie sowohl von der Basisklasse zu den Kindklassen als auch umgekehrt. Abgeleitete Wrapper-Klassen stellen spezielle Wrapper-Methoden bereit, die als Eingabe einen Array von Zeichenketten erwarten. Die Elemente dieses Arrays werden dann bei einem Aufruf in die gewünschten Argumente umgewandelt, eventuelle Default-Argumente aufgefüllt, die Wrap-ped-Methode aufgerufen und ihr Rückgabewert wieder in einen String konvertiert und zurückge-geben. Die Template-Funktion str2type<TYPE> konvertiert einen String in den C++-Zieldatentyp TYPE und type2str konvertiert ausgehend vom C++-Datentyp in einen String. Kann str2type die angegebene Zeichenkette nicht dem Typ entsprechend konvertieren, wird eine ConvertException geworfen. Diese kann dann vom Aufrufmechanismus sonderbehandelt werden (siehe Abschnitt 7.3.5). Die einfache Wrapper-Methode _getValue der Klasse AWrap aus dem Beispiel in Abbildung 63 gibt einen double-Wert zurück. Der C++-Code dazu sieht wie folgt aus:

char* AWrap::_getValue(int argc, char** argv){// call wrapped methoddouble res = obj->getValue();// convert return type to char*return type2str(res);

}

+ A(v:double=1.0)+ double:getValue()+ setValue(v:double,b:bool=true)+ modified() {virtual}

A

+ _A_double(argc:int,argv:char**):char*+ _getValue(argc:int,argv:char**):char*+ _setValue_double_bool(argc:int,argv:char**):char*+ _modified(argc:int,argv:char**):char*+ wrapperInfo():TypeInfo

- obj:A*

AWrap0..1 1

+ newWrapper():Wrapper*+ initializeWrapper(argc:int,argv:char**)+ callMethod(argc:int,argv:char**):char*+ wrapperInfo():TypeInfo

Wrapper

+ findMethod(argc:int,name:char*):MethodIterator+ findCtor(argc:int):CtorIterator

MethodTable1

Abbildung 63: Beziehung zwischen Wrapped-Klasse A und Wrapper-Klasse AWrap.


86

Die Wrapper-Methode _setValue_double_bool der Klasse AWrap erhält zwei Argumente, berücksichtigt ein Default-Argument für den zweiten Aufrufparameter und gibt keinen Wert zu-rück:

char* AWrap::_setValue_double_bool(int argc, char** argv) {// convert argument 0double arg0 = str2type<double>(argv[0]);// convert argument 1// handle default argumentbool arg1 = (argc <= 1) ? true : str2type<bool>(argv[1]);// call wrapped methodobj->setValue(arg0,arg1);// no return value (void)return NULL;

}

7.3.2 Wrapper-Methodentabelle Eine Wrapper-Methodentabelle speichert Signaturinformationen über die zugehörige Wrapped-Klasse und deren Methoden. Zu jeder Wrapper-Klasse existiert genau eine Wrapper-Methodentabelle (Abbildung 63). Zu jeder Wrapped-Methode wir der Name der Methode, die Argumenttypen, die Argumentnamen, die Default-Argumente, die minimale und maximale Anzahl der Argumente (ergibt sich aus der Anzahl der Default-Argumente), Methodeneigenschaften (z. B. Konstruktor oder statisch) und schließlich dem Zeiger auf die zuständige Wrapper-Methode gespeichert. Die Information wird zum einen dazu benötigt die korrekte Auswahl der aufzurufenden Methode zu garantieren und zum anderen dazu die Information zur Laufzeit abrufbar vorzuhalten. In Tabelle 4 ist eine Methodentabelle der Klasse AWrap dargestellt. Zu gegebenem Methodennamen und gegebener Argumentzahl liefert die Wrapper-Methodentabelle einen Iterator über alle möglicherweise passenden Methoden zurück. Wenn ü-berladene Methoden erfragt werden, enthält der Methoden-Iterator mehrere Methoden gleichen Namens.

7.3.3 Call Manager Die Verbindung zwischen dem Tcl-Interpreter und den C++-Bibliotheken VRS/LDX erfolgt über den CallManager. Der CallManager ermöglicht das Erzeugen von Objekten, das Aufrufen von Methoden und das Zerstören von Objekten. Er erkennt, welches Wrapper-Objekt angespro-chen werden soll und delegiert den Aufruf an selbiges. Dazu werden zunächst die Skriptspra-chenkommandos new und delete mit entsprechenden statischen Methoden create bzw. destroy des CallManager verknüpft. Beim Aufruf dieser Kommandos werden sämtliche Ar-gumente als Strings an die entsprechenden Methoden weitergeleitet. Der WrapperManager as-soziiert Tcl-Objektnamen mit dem Zeiger auf das zugehörige Wrapper-Objekt sowie den Zeiger

Name Argumente Min Max Methodenzeiger “A” “double” 1 1 AWrap::_A_double

“setValue” “double bool” 1 2 AWrap::_setValue_double_bool

“getValue” “” 0 0 AWrap::_getValue

“modified” “” 0 0 AWrap::_modified

Tabelle 4: Wrapper-Methodentabelle der Klasse AWrap.


87

auf das Wrapped-Objekt mit dem zugehörigen Wrapper-Objekt. Die Erzeugung eines C++-Objektes über die Tcl-Anbindung ist in dem Sequenzdiagramm in Abbildung 64 dargestellt. Zunächst wird der Aufruf vom Tcl-Interpreter an den CallManager weitergeleitet. Der CallManager versucht im WrapperManager einen zum ersten String-Argument (hier “A”) passenden Wrapper-Prototyp zu finden. Gelingt dies, wird mittels newWrapper eine Kopie des Prototyps erzeugt und über initializeWrapper mit den einge-gangenen Argumenten initialisiert. Der neu erzeugte Wrapper erfragt dann passende Konstruktor-Wrapper-Methoden aus der Methodentabelle und iteriert über diese. Die Wrapper-Methode, die alle Argumente konvertieren kann, ruft den wirklichen Konstruktor der Klasse A auf. Der Zeiger auf das resultierende Objekt a wird im Wrapper w abgelegt. Der CallManager registriert dann ein neues Tcl-Kommando mit eindeutigem Namen für den neuen Wrapper (z. B. "objA1") beim Tcl-Interpreter. Dabei wird die call()-Methode des CallManager an das Kommando gebunden und der Zeiger auf das Wrapper-Objekt als ClientData-Zeiger mitgegeben. Über den ClientData-Zeiger liegt das Wrapper-Objekt bei jedem Aufruf des zugehörigen Kommandos direkt vor. Der Wrapper w und das Wrapped-Objekt a werden in den WrapperManager mit Namen und jeweiliger Adresse eingetragen. Abschließend gibt der CallManager den eindeutigen Namen an den Tcl-Interpreter zurück. Der Aufruf einer Methode eines C++-Objektes über Tcl verläuft ähnlich zur Konstruktion eines Objektes (Abbildung 65). Der CallManager erhält beim Aufruf der call()-Methode aus ClienData das assoziierte Wrapper-Objekt und leitet diesem die erhaltenen Stringargumente weiter. Der Wrapper w erfragt durch Anzahl der Argumente und den Namen der Methode den Iterator der möglichen Methoden von seiner Methodentabelle und iteriert über diese. Die Wrap-per-Methode, die alle Argumente konvertieren kann, ruft die ursprüngliche Methode der Klasse A

CallManager

w:AWrap

initializeWrapper(argc,argv)

m:MethodTable

findCtor(argc,argv)

iterator

_A_double(argc,argv)

a:A

new(17.0)

prototype:AWrap

newWrapper()

w

new

create(argc,argv)

WrapperManager

findPrototype(argv[1])

prototype

Tcl-Aufruf :new A 17.0

Tcl-Rückgabe:objA1

Abbildung 64: Erzeugung eines Wrapper-Objektes und des zugehörigen Wrapped-Objektes.


88

auf. Der Rückgabewert der Wrapped-Methode getValue wird in String konvertiert, zunächst an den CallManager und dann an den Tcl-Interpreter zurückgegeben. Erst durch die Iteration über Methoden gleichen Namens lässt sich die einfache Handhabung von überladenen Methoden über Tcl erreichen. Andere Techniken verzichten auf überladene Metho-den komplett (Heidrich et al. [42] und McLennan [65]) oder sie erlauben den Zugriff nur über umbenannte Methodennamen, die den Argumenttypen enthalten (Beazley [7]). Spätestens wenn Templates als Argumenttypen Verwendung finden, führt dies zu schwer lesbarem Programmkode.

7.3.4 Vererbung und polymorphe Methoden Vererbung von Klassen und polymorphe Methoden können durch Kopieren der Methodentabelle der Basisklasse und Erweitern bzw. Überschreiben von Einträgen realisiert werden. Sei A die Basisklasse von B, wie in Abbildung 66 dargestellt. Dann ist BWrap die zu B gehörige Wrapper-Klasse. Die Klasse BWrap wird von der Klasse AWrap abgeleitet und dadurch die ur-sprüngliche Vererbungshierarchie nachgebildet. Bei der Erzeugung der Wrapper-Methodentabelle von BWrap werden alle Einträge aus der Me-thodentabelle von AWrap in die von BWrap kopiert. Einträge für Konstruktoren werden dabei nicht kopiert. Beim Eintragen einer Wrapper-Methode von BWrap wird überprüft, ob ein Eintrag mit der gleichen Signatur und dem gleichen Namen bereits vorhanden ist. Falls ja, wird dieser Eintrag mit der neuen Wrapper-Methode überschrieben. Auf diese Weise werden polymorphe Methoden berücksichtigt. Existiert kein Eintrag mit gleichem Namen und gleicher Signatur, wir der neue Methodeneintrag ohne Veränderung vorheriger Einträge eingefügt. Dies gilt natürlich

CallManager w:AWrap

callMethod(argc,argv)

m:MethodTable

findMethod(argc,argv[1])

iterator

_getValue(argc,argv)

resultString

a:A

getValue()

result

resultString

call(argc,argv)

Tcl-Aufruf :objA1 getValue

Tcl-Rückgabe :17.0

Abbildung 65: Aufruf einer C++-Methode einer Wrapped-Klasse über den Wrapper-Mechanismus.

Name Argumente Min Max Methodenzeiger “B” “” 0 0 BWrap::_B

“setValue” “double bool” 1 2 AWrap::_setValue_double_bool

“setValue” “int” 1 1 BWrap::_setValue_int

“getValue” “” 0 0 AWrap::_getValue

“modified” “” 0 0 BWrap::_modified

Tabelle 5: Wrapper-Methodentabelle der Klasse BWrap mit geerbten Einträgen der Klasse AWrap.


89

insbesondere für Konstruktoren (siehe Tabelle 5).

7.3.5 Konvertierung von Argumenten Die Konvertierung von Datenwerten zwischen Tcl und C++ erfolgt über die Template-Funktionenstr2type bzw. type2str. Die Funktion type2str wandelt von streng getypten Datentypen in den Datentyp String. Diese Umwandlung ist immer eindeutig. Bei der Konvertierung vom Daten-typ String in einen strengen Datentyp mittels str2type können jedoch Mehrdeutigkeiten auftre-ten.

str2type<double>(“1”) // ok

str2type<int>(“1”) //ok

str2type<A*>(“objA1”) //ok

str2type<B*>(“objA1”) // eventuell Fehler

str2type<C*>(“objA1”) // Fehler Für eingebaute Datentypen (z. B. char, int, double) sind Konverterfunktionen bereits einge-baut. Abgeleitete Datentypen wie double*** sind nur als void-Zeiger zu verwenden, die intern als einfache Wrapper-Objekte mit dem Typ void* gehalten werden. Eine Dereferenzzierung solcher Typen ist nicht möglich. Die Konvertierung von Objektreferenzen (Zeiger) erfolgt über den WrapperManager. Dort ab-gelegte Wrapper-Objekte und Wrapped-Objekte können dank der im Wrapper enthaltenen Typin-formation typsicher konvertiert werden. Objekte die von der VRS Klasse SharedObj abgeleitet sind, können dank der vorhandenen Run Time Type Information (RTTI) in den korrekten Typ konvertiert werden.

Wertbestimmte Objekte Numerische Klassen wie Vektoren, Matrizen oder Strahlen finden häufig Verwendung in VRS/LDX. Objekte dieser Klassen sind wertbestimmt, das heißt sie werden by-value benutzt, im Gegensatz zu den Klassen, die by-reference verwendet werden (z. B. alle Klassen, die von SharedObj abgeleitet sind). Für Klassen wertebestimmter Objekte gibt es zusätzlich zur explizi-

+ A(v:double=1.0)+ double:getValue()+ setValue(v:double,b:bool=true)+ modified() {virtual}

A

+ _A_double(argc:int,argv:char**):char*+ _getValue(argc:int,argv:char**):char*+ _setValue_double_bool(argc:int,argv:char**):char*+ _modified(argc:int,argv:char**):char*+ wrapperInfo():TypeInfo

- obj:A*

AWrap0..1 1

+ B()+ setValue(i:int)+ modified() {virtual}

B

+ _A(argc:int,argv:char**):char*+ _setValue_int(argc:int,argv:char**):char*+ _modified(argc:int,argv:char**):char*+ wrapperInfo():TypeInfo

- obj:B*

BWrap0..1 1

Abbildung 66: Vererbungsbeziehungen werden in die Wrapper-Klassenhierarchie abgebildet.


90

ten Erzeugung mittels new die implizite Erzeugung durch direkte Angabe der Werte Zum Beispiel können drei zusammengehaltene Fleißkommawerte als ein 3D-Vektor interpretiert werden:

% $mysphere setCenter {1 2 3} Die Zeichenkette „1 2 3“ wird bei der Konvertierung als Vector-Objekt erkannt und ord-nungsgemäß konvertiert.

Aufzählungen Aufzählungen repräsentieren ganzzahlige Konstanten durch symbolische Namen und erleichtern damit den Umgang mit Konstanten. Aufzählungen können in iVRS/iLDX ähnlich wie in C++ verwendet werden: Klassenname::Enumeration. Eine mehrdimensionale Abbildungstabelle, die jedem Wrapper zugeordnet ist, wenn seine Wrapped-Klasse eine Enumeration enthält, erlaubt das Setzten und Abfragen von Enumerationswerten.

% set polygon [new PolygonSet PolygonSet::Quads]

% $polygon getType

PolygonSet::Quads

Mehrdeutige Aufrufe Einige Strings können nicht anhand ihres Wertes unterschieden werden, z. B. der String "7" kann als int, char oder string interpretiert werden. In diesem Fall würde bei der Konvertierung in einen der möglichen Typen kein Fehler auftreten. Würden zwei überladene Methoden gleichen Namens mit gleicher Argumentanzahl sich gerade nur in diesem möglichen Typen unterscheiden, wäre der Aufruf über den CallManager nicht mehr eindeutig. Obwohl dieser Fall in VRS/LDX nicht vorkommt, kann er in iVRS/iLDX entschärft werden, indem beim Aufruf über den Interpre-ter der explizite Typ an den Methodennamen angehängt wird, um etwa die Methode mit dem Ar-gumenttyp char zu forcieren

$obj setValue:char 7 oder um die Methode mit dem Argumenttyp string zu verwenden

$obj setValue:string 7

Der explizite Aufruf ist schneller als ein Aufruf, bei dem der CallManager die passende Funkti-on suchen muss, allerdings leidet darunter die Lesbarkeit des Skript-Quellcodes.

7.3.6 Callbacks Wichtige Programmierkonstrukte bei der Erstellung interaktiver Anwendungen sind Callbacks. Sie dienen der flexiblen Verknüpfung von anwendungsspezifischen Programmteilen mit dem 3D-Kartensystem. In VRS und LDX sind Callbacks über C++-Callback-Klassen realisiert, die zum Teil als Template-Klassen implementiert sind. Tabelle 6 gibt einen Überblick über die eingebau-ten Callback-Typen. Um Tcl-Programmcode mit Callbacks in den Programmablauf zu integrieren (z. B. zur Rückmel-dung von Ereignissen, die in VRS/LDX erzeugt wurden), bedarf es spezieller Callback-Klassen,

Klasse Argumente Rückgabe Beispielsignatur Callback void void f()

CallbackR<RETURN> void RETURN int f()

Callback1<ARG1> ARG1 void void f(SharedObj*)

CallbackR1<RETURN,ARG1> ARG1 RETURN Vector f(float)

CallbackR2<RETURN,ARG1,ARG2> ARG1,ARG2 RETURN string f(int,char)

Tabelle 6: Beispiele für VRS/LDX Callback-Klassen ggf. mit Templateparametern.


91

die den Aufruf von Tcl-Prozeduren und die nötigen Typkonvertierungen und -überprüfungen si-cherstellen. Die dazu benötigten speziellen Callback-Klassen sind in Abbildung 67 dargestellt. Die C++-Implementierung der spezialisierten callback()-Methode ohne Rückgabewert der Klasse TclCallback1<ARG> sieht z. B. wie folgt aus:

template <class ARG>class TclCallback1<ARG> : public Callback1<ARG1> {

void callback(ARG a) {// Konvertierung des Arguments in Stringchar* str = type2str<ARG>(a);// Aufruf des Callback-Skripts ‘skript’ durch// den Tcl-Interpreter mit ‘str’ als Argument.TclTool::eval(skript,str);

}};

Die C++-Implementierung der spezialisierten callback()-Methode mit Rückgabewert der Klasse TclCallbackR1<RETURN,ARG1> umfasst zusätzlich noch eine Typkonvertierung für den Ergebnisstring:

template <class RETURN, class ARG1>class TclCallbackR1<RETURN,ARG1> :

public CallbackR1<RETURN,ARG1> {RETURN callback(ARG1 a) {

// Konvertierung des Arguments in Stringchar* str = type2str<ARG1>(a);// Aufruf des Callback-Skripts ‘skript’ durch// den Tcl-Interpreter mit ‘str’ als Argument und// Speicherung des Rückgabewerts.char* result = TclTool::eval(skript,str);// Konvertierung des Rückgabewerts in Stringreturn str2type<RETURN>(result);

}

+ TclCallbackR1(skript:string)+ callback(a:ARG):RETURN

- skript:string

TclCallbackR1RETURN, ARG

+ callback(a:ARG):RETURN

CallbackR1RETURN, ARG

+ TclCallback1(skript:string)+ callback(a:ARG)

- skript:string

TclCallback1

+ callback(a:ARG)

Callback1ARG

ARG

Abbildung 67: Spezialisierte Callback-Klassen ohne Rückgabewert (links) und mit Rückgabewert (rechts) zum Aufruf von Tcl-Prozeduren durch C++-Callbacks.


92

};

Als Beispiel für den Callback-Mechanismus in 3D-Karten eignet sich die Ereignistabelle (Ab-schnitt 2.5.3). Das folgende Tcl-Beispiel zeigt die Verknüpfung einer Tcl-Prozedur an das Auf-treten eines Selektionsereignisses. Als Argument wird der Tcl-Prozedur das SelectEvent-Objekt übergeben, aus dem der Selektionspunkt ausgelesen wird.

# ‘onSelect’ gibt Selektionspunkt ausproc onSelect { selectevent } { puts [$selectevent getHit] }

# Erzeugung des Callbacks mit auszuführendem Skriptset selectcb [new TclCallback1<SharedObj*> onSelect]

# Erzeugung der Ereignistabelle mit Select-Callbackset eventtable [new EventTable $selectcb]

Geschwindigkeitsverhalten Als Hardwaregrundlage zur Geschwindigkeitsmessung von interpretierten Tcl-Callbacks dient das System aus Abschnitt 5.4.2. Zu Beginn der Messung wird kein Tcl-Callbacks verwendet, das heißt die Traversierung aller Objekte des Szenengraphs und des Verhaltensgraphs findet nur in C++-Programmteilen statt. Die Bildwiederholfrequenz beträgt in dieser Situation etwa 65 Bilder pro Sekunde. Bei den beiden folgenden Testverfahren wird von dieser Situation ausgegangen. Im ersten Verfahren wird nach jedem Renderingdurchlauf eine bestimmte Anzahl von Tcl-Callbacks ausgeführt. Die Anzahl der auszuwertenden Tcl-Callbacks wird sukzessive erhöht. Bei 220 aufzurufenden Tcl-Callbacks pro Renderingdurchlauf beträgt die Bildwiederholrate immer noch 50 Bilder pro Sekunde, das heißt pro Sekunde werden neben dem Szenen-Rendering 11.000 Tcl-Callbacks ausgewertet. Erst ab 500 aufzurufenden Tcl-Callbacks pro Renderingdurchlauf

0,00

10,00

20,00

30,00

40,00

50,00

60,00

70,00

20 220 420 620 820 1020 1220

ausgeführte TclCallbacks

Bild

er/s

0,00

10,00

20,00

30,00

40,00

50,00

60,00

70,00

40 290 540 790 1040 1290 1540

TclCallback Codelänge

Bild

er/s

Abbildung 68: Veränderung der Bildwiederholfrequenz bei steigender TclCallback-Anzahl (links) und bei steigender Codekomplexität (rechts).


93

fällt die Bildwiederholrate unter die kritische Marke von 20 Bildern pro Sekunde (Abbildung 68 links). Im zweiten Verfahren wird die Anzahl der auszuführenden Tcl-Anweisungen genau eines Tcl-Callbacks sukzessive erhöht. Das Skript umfasst zu Beginn eine Anweisung, der dann im Laufe des Tests neue Anweisung angehängt werden. Erst ab 1500 Tcl-Anweisungen sinkt die Bildwie-derholrate unter 12 Bilder pro Sekunde (Abbildung 68 rechts). Zum Vergleich: der komplette LandExplorer-Prototyp ist mit 1450 Anweisungen programmiert.

7.3.7 Metainformation Die Wrapper-Typinformation, die Wrapper-Methodentabellen und der WrapperManager sind zur Laufzeit über Tcl abfragbar. Dadurch sind folgende Metainformationen verfügbar:

- Sämtliche verfügbaren Klassen und Objekte, - Basisklasse und Kindklassen einer konkreten Klasse, - Konstruktoren einer Klasse mit vollständiger Signatur und Default-Werten, - Methoden einer Klasse mit vollständiger Signatur und Default-Werten, - Enumerationen einer Klasse.

Diese Informationen können vom Entwickler genutzt werden, um zur Laufzeit API-Informationen abzurufen, um interaktiv das System kennen zu lernen oder um generische GUI-Komponenten zu bauen. Wir haben auf der Basis der Metainformation eine prototypische Entwicklungsumgebung implementiert, die über farbliche Syntaxhervorhebung für Klassen, Methoden und Enumeratio-

Abbildung 69: Entwicklungsumgebung für 3D-Karten mit Klassen-Browser, Klassen-Informations-fenster, Editor mit farblicher Syntaxhervorhebung und momentan laufender 3D-Kartenanwendung.

7.4 Skriptbeispiele

94

nen, einen Klassenhierarchie-Browser, einen Syntaxüberprüfer und einen Laufzeit-Objekt-Browser verfügt. Abbildung 69 zeigt einen Snapshot der Anwendung.

7.4 Skriptbeispiele In diesem Abschnitt werden eine Reihe von Skriptbeispielen vorgestellt, die die Funktionsweise und Syntax von iVRS verdeutlichen sollen. Des weiteren soll das praktisch Zusammenspiel zwi-schen C++ und Tcl aufgezeigt werden.

7.4.1 Minimale 3D-Karte Eine minimale 3D-Karte lässt sich mittels weniger Zeilen erzeugen. Wesentliche Bestandteile sind dabei eine Zeichenfläche (TclCanvas), eine 3D-Kartenansicht (View), ein Multiresolutionsge-ländemodell (Terrain), eine Schattierungstextur (ShadingTexture) und eine Navigationsme-tapher (Navigation).

# Erzeugung der Tk-Zeichenflächeset canvas [new TclCanvas .canvas 320 240 ]# Einbetten der Zeichenfläche in das Tk GUIpack .canvas -side right -expand yes -fill both# Erzeugung der 3D-Kartenansicht mit# Kameraposition {1 1 1} und Fokuspunkt {0 0 0}set mapview [new View $canvas {1 1 1} {0 0 0}]# Hinzufügen des Geländemodells zur 3D-Kartenansichtset terrain [Terrain loadTerrain demo.vrs]$mapview add $terrain# Hinzufügen einer Schattierungstextur zur 3D-Kartenansichtset shading [new ShadingTexture 1024 1024]$mapview add $shading# Hinzufügen einer Navigationsmethapher zur 3D-Kartenansicht$mapview add [new Navigation $mapview Navigation::Cone]

Abbildung 70: Interaktiver Zylinder zur Analyse der Geländehöhe. Lokale Maxima innerhalb des Zy-linder werde grün markiert und die zugehörige Höhe wird in das Bild eingeblendet.


95

7.4.2 Interaktive Höhenanalyse Das folgenden Beispiel beschreibt die Implementierung eines Werkzeuges zur interaktiven Hö-henanalyse. Ein transparenter Zylinder soll mittels Maus über die Geländeoberfläche bewegt, da-bei die maximalen Höhenpunkte farbig markiert und die maximale Höhe als Text eingeblendet werden (Abbildung 70). Zur Realisierung des Werkzeuges wird zunächst eine Gruppe gebaut, die die visuellen 3D-Kartenbauelemente Symbol, Label und Points umfasst und zur Darstellung des Zylinders und der Ergebniswerte dient.

# Anlegen einer neuen Gruppeset myGroup [new Group]$mapview add $myGroup# Symbol mit Cylinder erzeugen mit Position, Shape und Farbeset mySymbol [new Symbol {0 0 0} [new Cylinder] {0 0 1 0.5}]$myGroup add $mySymbol# Punkte für Ergebnis erzeugen mit der Größe und Farbeset myPoints [new Points 4 {0 1 0 1}]$myGroup add $myPoints# Textmarkierung für Ergebnis erzeugen mit Schriftnamenset myLabel [new Label arial.ttf]$myGroup add $myLabel

Die Prozedur invokeAnalysis berechnet ausgehend von der Position des Mauszeigers einen Intersektionsstrahl, der mit Hilfe der Klasse RayQuery in die 3D-Kartenansicht gesendet wird (Abschnitt und 2.5.2 und 5.5). Wird ein Objekt getroffen, erfolgt die Berechnung der maximalen Punkte innerhalb des Zylinders und die Anpassung der visuellen 3D-Kartenbauelemente.

proc invokeAnalysis { motionevent } {# globale Variablen verfügbar machenglobal canvas myPoints mySymbol myLabel# Strahl in Kamerakoordinaten spezifizierenset myRay “{[$motionevent x] [$motionevent y] 0} {0 0 1}”# Strahlentest durchführenif {[RayQuery query $myRay $canvas] == true} {

# Punkt in Weltkoordinaten auslesenset point [$myRaytest pointWorldCoords]# Anfrage der Maximalen Punkte innerhalb des Zylindersset radius [$mySymbol getSize]set iterator [QueryOperations Maximum $point $radius]# Szene ggf. Aktualisieren und neuzeichnen$myPoints setPoints $iterator$mySymbol setPosition $pointCanvas postAllForRedisplay

}}

7.5 Zusammenfassung

96

Damit die Prozedur invokeAnalysis auf Bewegungsereignisse reagiert, wird eine Ereignista-belle (EventTable) mit einem Callback für Mausbewegungen ausgestattet und in die 3D-Kartenansicht eingefügt.

# Erzeugung der Ereignistabelleset myEventTable [new EventTable]# Erzeugung des Callbacks mit Tcl-Callback-Prozedurset myCallback [new TclCallback1<SharedObj*> invokeAnalysis]# Verknüfung von Callback und Ereignistabelle$myEventTable setMotionCallback $myCallback# Hinzufügen der Ereignistabelle zur 3D-Kartenansicht$mapview add $eventTable

7.5 Zusammenfassung Mittels iVRS/iLDX können 3D-Kartenanwendungen vollständig entwickelt werden. Die Konfigu-ration einer bestehenden 3D-Karte wird ebenso ermöglicht, wie die Integration von komplexen Verhaltensbeschreibungen durch Ereignistabellen und Tcl-Callbacks. 3D-Kartenbauelemente können interaktiv auf ihre Eigenschaften hin abgefragt und unterstützte Operationen können ohne Verzögerungen ausprobiert werden (rapid prototyping). Durch die C++-ähnliche Syntax können in iVRS/iLDX entwickelte 3D-Kartenanwendungen relativ leicht in C++ überführt werden. Die Tcl-Anbindung iVRS/iLDX beeinflusst die Darstellungsgeschwindigkeit einer 3D-Karte kaum, da die zeitkritischen Teile, wie die Traversierung des Szenengraphen und das Einlesen von Daten, weiterhin in C++ ausgeführt werden (Kersting und Döllner [52]). Für zukünftige Arbeiten ist die Anbindung an weitere Interpretersprachen z. B. Perl oder Phyton ebenso denkbar, wie die Integration eines einfachen Kommandozeilen Interpreters zu Konfigura-tion eines bestehenden C++-Softwaresystems. Die Integration von Kommentaren aus den C++ Klassendefinitionen in die zur Laufzeit abrufbare Metainformation wäre besonders in Hinblick auf die Bedienbarkeit von iVRS/iLDX ein wichtiger Schritt. Die automatische Dokumentations-erzeugung Doxygen (van Heesch [43]) bietet dabei Unterstützung.

97

Kapitel 8 ANWENDUNGSBEISPIELE

Die in dieser Arbeit vorgestellten Konzepte wurden in Form des 3D-Kartensystems LandExplorer implementiert. Dieses System dient als Framework für Anwendungen auf der Basis von 3D-Karten. Zur Anwendungsentwicklung wird das 3D-Kartensystem im Allgemeinen durch anwen-dungsspezifische Klassen erweitert und in eine graphische Benutzungsschnittstelle integriert. Als wesentliche Voraussetzungen für den Einsatz des 3D-Kartensystems in der Praxis haben sich folgende Leistungsmerkmale als entscheidend herausgestellt:

- Verarbeitung von Geodaten in einer Fülle von Standardformaten, - Verarbeitung von Raster- und Vektordaten, - Verarbeitung von großen Mengen von Geodaten, - Interaktive Visualisierung der Geodaten in Echtzeit auf Standard-Rechnern, - Anpassungsfähigkeit an Benutzeranforderungen.

Die in diesem Kapitel vorgestellten Anwendungsbeispiele kommen aus dem Bereich der Wasser- und Schifffahrtsverwaltung und der mobilen Kommunikation.

8.1 Visualisierung hydrographischer Daten Gegenstand dieser Anwendung ist die Visualisierung hydrographischer und topographischer Geo-daten. Im Mittelpunkt dieser Geodaten stehen Geländemodelle, die insbesondere Wasserstrassen und angrenzende Gelände repräsentieren. Die Anwendung visualisiert Wasserstrassen einschließ-lich der in ihr befindlichen Objekte wie z. B. Pipelines und stellt Funktionalitäten zur Analyse der Geländeoberfläche bereit (Abbildung 71). Darüber hinaus ermöglicht die Anwendung die Visuali-sierung zeitlicher Veränderungen von Sedimenten und die interaktive Simulation von Sedimentab-lagerungsprozessen. Die Anwendung wird von der Wasser- und Schifffahrtsverwaltung des Bundes in Aurich einge-setzt. Die Hauptaufgabe liegt im Monitoring von Veränderungen des Fluss- und Meeresgrundes im Emsmündungsbereich. Hier existieren sogenannte Klappstellen, das heißt räumlich definierte Flächen, auf denen Sand aus Baggerungen des Fahrwassers abgelagert (verklappt) wird. Diese Klappstellen werden seit Jahrzehnten verwendet und werden jährlich vermessen, um die Verände-

8.1 Visualisierung hydrographischer Daten

98

rungen zu dokumentieren. Abbildung 72 zeigt einen Ausschnitt aus einer solchen Folge von den Jahren 1985 bis 1997. Die Modellberechnung der Geländeoberfläche beruht auf Fächerlot-Daten. In einer 3D-Karte lassen sich Klappstellen interaktiv markieren, benennen und attributieren; Abbildung 71 zeigt ein Beispiel. Die Veränderungen des Flussbettes und der Klappstellen können animiert auf der Geländeoberfläche visualisiert werden. Die Anwendung wurde um spezielle Kartenkomponenten zur Spezifikation und Darstellung von Pipelines erweitert. Diese Pipelines repräsentieren die vor einigen Jahren im Emsmündungsbe-reich verlegten Erdgasleitungen zwischen Deutschland und den Niederlanden. Die Eingrabungs-tiefe einer Pipeline ist abhängig von der Wassertiefe. Eine Pipeline hat im Übergangsbereich vom Fahrwasser auf die sogenannte Paapsandplate (höher gelegene Sandbank) eine Überdeckung in Form einer Steinschüttung. Diese Steinschüttung schrumpft im Laufe der Jahre in Folge der Strömung und muss ggf. neu aufgebaut werden. Zur Unterstützung dieser Aufgaben können die Pipelines im Geländemodell betrachtet werden. Durch interaktive Höhenanalyse können insbesondere die o. g. Übergangsbereiche untersucht werden. Abbildung 73 zeigt eine teils unterirdisch verlaufende Pipeline, für die ein alternativer Verlauf gesucht wird. Eingeblendete Höhenprofile können Rückschlüsse auf einen möglichen neu-en Pipelineverlauf geben. Mit dieser Kartenanwendung können Planer räumliche Situationen interaktiv explorieren, diese bewerten und Entscheidungen für weitere Maßnahmen ableiten sowie deren Grundlagen doku-mentieren. Die Arbeit der Planer, aber auch die Kommunikation von Entscheidungen zu einem

Abbildung 71: 3D-Karte zu Analyse der Klappstellenentwicklung im Emsmündungsbereich.

1985

1990

1997

Abbildung 72: Veränderungen des Flussbettes des Ems von 1985 bis 1997.

Kapitel 8 - Anwendungsbeispiele

99

nichtfachlichen Publikum konnte durch die dreidimensionale und als anschaulicher erlebte Dar-stellung wesentlich vereinfacht und präzisiert werden. Die nächste Version der Anwendung wird um eine Komponente zur Strömungsvisualisierung er-weitert (Abschnitt 4.5). Die Visualisierung der Strömungsverhältnisse soll den Prozess der Sedi-mentablagerung im Flussbett zeigen und Zusammenhänge mit der Strömungsgeschwindigkeit aufzeigen. Die Strömungsvisualisierung beruht auf inkrementellen Berechnungen des Partikel-transports mit 2D-Texturen. Die „Partikel“ sind gefärbt und geben einen Eindruck des Strö-mungsverhaltens wieder; sie können interaktiv ausgesetzt werden und ermöglichen somit die un-mittelbare Beobachtung und Exploration des Strömungsverhaltens über dem realen Geländemo-dell. In Zukunft ist eine Visualisierung von Offshore-Gebieten für den Bau von Windkraftanlagen auf See als Erweiterung denkbar.

8.2 Interaktive Visualisierung von Funknetzen Gegenstand dieser Anwendung ist die Visualisierung von Funknetzplanungsdaten. Zu diesen Da-ten gehören Grunddaten wie z. B. Geländemodelle, Stadtmodelle, Verkehrswege, Landnutzung und Bevölkerungsdaten sowie Funknetzdaten wie z. B. Angaben zu Sendeanlagen, Beziehungen zwischen Sendeanlagen, Funknetzzellen und Versorgungsstärken (Abbildung 74). Die Anwen-

Abbildung 73: Analyse der Geländeoberfläche durch Höhenprofilmessung.

Abbildung 74: Interaktive Darstellung von Funkantennen, deren Ausrichtungen und Nachbarschafts-beziehungen zwischen Standorten.

8.2 Interaktive Visualisierung von Funknetzen

100

dung visualisiert Grund- und Funknetzdaten, ermöglicht die interaktive Exploration der Daten und ihrer Zusammenhänge und die Konfiguration von Funknetzeinstellungen. Die Anwendung stellt einen Teil des Funknetzplanungssystems Pegasos der T-Mobile dar und ist in diesem System und seiner Benutzungsschnittstelle vollständig integriert (Abbildung 74). Das Pegasos-System mit dem integrierten 3D-Kartensystem wird in der nächsten Version als Pegasos-3D in allen Funknetzplanungsstellen eingesetzt werden. Das 3D-Kartensystem übernimmt die Rolle der visuellen Schnittstelle zwischen Funknetzplanungsdatenbanken und den Funknetzpla-nern, die mit ihm bestehende Funknetze in ihrer Funktionsweise und Konfiguration analysieren und überwachen, Einstellungen in den an einem Funknetz beteiligten Sendeanlagen verändern, neue Standorte planen und Entscheidungsvarianten ermitteln und dokumentieren. Besonderer Schwerpunkt dieser Anwendung des 3D-Kartensystems bildet die interaktive Manipu-lation von Objekten aus der Funknetzplanungsdatenbank und die Kontrolle durch die unmittelbare visuelle Rückmeldung in der Darstellung. Die dreidimensionale Darstellung zeigt nicht nur das Geländemodell in seiner 3D-Geometrie, die für die Funktionsweise und Planung eines Funknetzes entscheidend ist, sondern ermöglicht auch die Integration eines 3D-Stadtmodells (Abbildung 75). Gerade das Zusammenspiel zwischen Geländemorphologie und Bebauung ist ein kritisches Ele-ment bei der Entscheidungsfindung für Sendeanlagen. In der 3D-Kartenansicht des Pegasos-Systems können topographische und thematische Geodaten zur Visualisierung ausgewählt werden. Mehrere Informationsschichten lassen sich erzeugen und visuell kombinieren. Bei der Visualisierung kommt der Darstellung von Vektordaten eine beson-dere Rolle zu, da insbesondere Verkehrswege, Gemeindegrenzen und Funkzellen als Vektordaten vorliegen und präzise in 3D visualisiert werden müssen. Die Anforderungen an die Effizienz der Visualisierung sind besonders hoch, da für die Texturierung und die Geländemodelle große Da-tenmengen zu verarbeiten sind. Der verwendete Pegasos-Datensatz besteht aus einem 3.000 × 3.500 Stützpunkten umfassenden Geländemodell, was 21 Millionen darzustellenden Dreiecken entspricht, Rasterdaten unterschiedlicher Thematiken, die von 30 MB bis 410 MB va-riieren, 1.500 Senderstandorte mit 4.500 Antennen, 120.000 Liniensegmenten zur Beschreibung von Verkehrswegen und 44.132 Gebäude bestehend aus 284.311 Polygonen. Als eine besondere Herausforderung im Bereich Software Engineering war es notwendig, das ge-samte 3D-Kartensystem plattformübergreifend und portabel hinsichtlich der Benutzungsschnitt-stelle als Komponente zu gestalten und es als Komponente in das Pegasos-System zu integrieren. Eine Reihe anwendungsspezifischer Kartenbauelemente wurde erarbeitet, die die Funknetzpla-

Abbildung 75: Geometrische Darstellung des 3D-Stadtmodells der Frankfurter Innenstadt.

Kapitel 8 - Anwendungsbeispiele

101

nungsdaten repräsentieren. Beispiele hierfür sind Kartenbauelemente für Sendeanlagen und Nachbarschaftsbeziehungen zwischen Funkzellen.

103

Kapitel 9 ZUSAMMENFASSUNG UND AUSBLICK

Diese Arbeit stellt ein Konzept für interaktive, dynamische 3D-Karten vor. Zugleich werden As-pekte der statischen, dynamischen und physischen Software-Architektur des zugehörigen 3D-Kartensystems erklärt. Eine Reihe von Visualisierungsstrategien für raumbezogene Informationen vervollständigen das Ausgangskonzept. Die geschaffenen Grundlagen ermöglichen es, anwen-dungs- und aufgabenspezifische Systeme zur Kommunikation von raumbezogenen Informationen systematisch zu konstruieren. Das 3D-Kartensystem konstituiert einen Framework, der insbesondere 3D-Kartenbauelemente enthält, die die Konstruktion einerseits von einzelnen 3D-Karten, andererseits von 3D-Kartenanwendungen systematisieren und unterstützen. Die einzelnen Bauelementtypen können einer von drei grundlegenden Kategorien, den visuellen, strukturellen und verhaltengebenden Bau-elementen, zugeordnet werden und besitzen zueinander weitestgehend Orthogonalität hinsichtlich ihrer Leistungsmerkmale, die anwendungs- und domänenübergreifend entworfen wurden. Das Fundament von 3D-Karten repräsentieren Geländemodelle, die mit Multiresolutionsmodellie-rung eine qualitativ hochwertige und effiziente Darstellung der Geländegeometrie sicherstellen. Das eingesetzte Geländemodell wird durch Algorithmen und Datenstrukturen repräsentiert, die im Konzept des Approximationsbaums zusammengefasst sind. Der Approximationsbaum erlaubt die Darstellung von umfangreichen Geländemodellen, konzentriert sich auf die exakte Wiedergabe der Geländemorphologie und ist ausgerichtet auf den massiven Einsatz von Texturierung zur Ges-taltung der resultierenden auflösungsvarianten Geländeoberflächen, die sich aus Geometrieflicken zusammensetzen. Als zweites Fundament von 3D-Karten dient der Texturbaum, dessen Algorithmen und Daten-strukturen Rasterdaten als Texturschichten aufbereiten und darstellen. Rasterdaten können da-durch pixelpräzise und hardwareunterstützt auf die auflösungsvariante Geländeoberfläche proji-ziert werden. Die Verwendung mehrerer Texturschichten, deren Überlappung und bildbasierte Kombination führen zu visuell komplexen Gestaltungsmöglichkeiten für 3D-Karten.

8.2 Interaktive Visualisierung von Funknetzen

104

Die im Texturbaum angewandte Texturierungsstrategie, die Texturen pro Geometrieflicken zu betrachten, ermöglicht es, selbst umfangreiche Texturschichten in Echtzeit zu visualisieren. Mul-titexturing und das ggf. notwendige mehrfache Rendering werden nur auf die Geometrieflicken angewandt, die dieses auch tatsächlich benötigen. Dadurch können Überlappungen von Textur-schichten effizient von der Renderingpipeline verarbeitet werden. Hinsichtlich der Größe einer Textur besteht keine Einschränkung, sodass mit hochaufgelösten Texturen eine hohe Darstel-lungsqualität erreicht werden kann. Die hierarchische Strukturierung einer Textur durch den Tex-turbaum sorgt für die notwendige Effizienz im Rendering. Das Auslagern von Teilen einer im Texturbaum abgelegten Textur und die auf sie anwendbare Datenkompression optimieren den Hauptspeicherbedarf. Als besonderes Leistungsmerkmal können Vektordaten dynamisch zur Laufzeit rasterisiert und mit Texturschichten visualisiert werden. Dadurch lassen sich die Vorteile einer texturbasierten Darstellung nutzen, wie z. B. die pixelpräzise Projektion oder die Anwendung von Bildoperatio-nen in Verbindung mit weiteren Texturschichten. Vektordaten sind auf diese Weise in hoher Qua-lität bei im Vergleich zu konventionellen Ansätzen drastisch weniger Speicherverbrauch visuali-sierbar. Da die Vektordaten analytisch in Form von Vektordaten-Szenengraphen spezifiziert sind, kann die Semantik eines in einer Texturschicht enthaltenen Objekts ermittelt werden. Dies bildet die Voraussetzung zur Umsetzung interaktiver Manipulationsmechanismen für Vektordaten. Die Interaktion zwischen 3D-Karte und Nutzer stellt hohe Anforderungen an die Orientierung und die Navigation in einer virtuellen Umgebung. Die vorgestellten Orientierungswerkzeuge erleich-tern die Bestimmung von Lage und Position in 3D-Karten, ohne die kognitive Belastung nen-nenswert zu erhöhen. Die vorgestellten Navigationswerkzeuge erlauben die zielgerichtete Naviga-tion in 3D-Karten. Mit Hilfe von verhaltengebenden 3D-Kartenbauelementen können benutzer-spezifische und anwendungsspezifische Funktionalitäten in die Karte integriert werden, die die Navigation des Benutzers kontrollieren und unterstützen. Zur Unterstützung der Orientierung und Navigation kann der dynamische Inhaltsentwurf in einer 3D-Karte eingesetzt werden. Die Me-chanismen zur visuellen Fokussierung, Restriktion und Adaption von Informationen verfolgen das Ziel, die kognitive Belastung des Benutzers zu optimieren und dessen Aufmerksamkeit zu lenken. Dieses Ziel wird unter anderem durch überlagerungsfähige, dynamische Texturschichten erreicht. Der modulare Aufbau des 3D-Kartensystems und die integrierte Interpreteranbindung ermögli-chen es, Anwendungen mit 3D-Karten in der Rolle interaktiver visueller Schnittstellen für raum-bezogene Informationen zu entwickeln. Bei einer Anwendung, die mit der erweiterten Skriptspra-che erstellt wurde, kann die Funktionalität einzelner 3D-Kartenbauelemente über die Interpreter-anbindung zur Laufzeit genutzt werden. Insbesondere lassen sich über die Interpreteranbindung die Schnittstellen der 3D-Kartenbauelementklassen unmittelbar erschließen und somit leicht erler-nen. Die Konfiguration einer bestehenden 3D-Karte zur Laufzeit wird, ebenso wie die Integration von Verhaltensbeschreibungen für 3D-Kartenbauelemente ermöglicht. Die Interpreteranbindung beeinflusst die Darstellungsgeschwindigkeit einer 3D-Karte kaum, da die zeitkritischen Teile wei-terhin in C++ ausgeführt werden. Zukünftige Entwicklungen im 3D-Kartensystem konzentrieren sich auf den Einsatz von 3D-Karten im Internet. Insbesondere können hierfür inkrementelle Kodierungs- und Übertragungsver-fahren für raumbezogene Daten entwickelt und eingesetzt werden. Darüber hinaus kann der Um-fang der Kartenbauelement ergänzt werden, z. B. durch Bauelemente, die umfangreiche 3D-Stadtmodelle als Multiresolutionsmodelle repräsentieren.

105

LITERATUR

[1] H. Asche, C. Herrmann: „Designing Interactive Maps for Planning and Education“, In: A. MacEachren, D. Fraser Taylor (Eds.), Visualization in Modern Cartography, Pergamon, S. 215-242, 1994.

[2] M. Austern: Generic Programming and the STL, Addison-Wesley, 1998. [3] R. Avila, L. Sobierajski: „A Haptic Interaction Method for Volume Visualization“,

IEEE, S. 197-204, 1996. [4] M. Bach: „Räumlich durchs Auge – Wie kommt die greifbare Welt in den Kopf”, C’t

Heft 7/99, S. 158-163, 1999. [5] B. Bargen, T. Donnelly: Inside Directx, Micrososft Press, 1998. [6] K. Baumann, J. Döllner, K. Hinrichs, O. Kersting: „A Hybrid, Hierarchical Data

Structure for Real-Time Terrain Visualization”, IEEE Proceedings Computer Graphics International '99, S. 85-92, 1999.

[7] D. Beazley: „SWIG Reference Manual“, Department of Computer Science, University of Utah, www.swig.org/Doc1.1/PDF/Reference.pdf, 1997.

[8] J. Bertin: Graphics and Graphic Information Processing, Walter de Gruyter, 1981. [9] E. Bier, M. Stone, K. Pier, W. Buxton, T. DeRose: „Toolglass and magic lenses: The

see-through interface“, Proceedings of ACM SIGGRAPH 1993, S. 73-80, 1993. [10] G. Booch, I. Jacobson, James Rumbaugh, Jim Rumbaugh: The Unified Modeling

Language User Guide - 1st edition, Addison-Wesley; 1998. [11] D. Bowman, E. Davis, A. Badre, L. Hodges: „Maintaining Spatial Orientation during

Travel in an Immersive Virtual Environment“, Presence: Teleoperators and Virtual Environments, 8(6), S. 618-631, 1999.

[12] S. Browne, J. Willmott, L. Wright, A. Day, D. Arnold: „Modelling & Rendering Large Urban Environments“, http://www.charismatic-project.com/MODELL.PDF, 2002.

[13] G. Buziek, I. Kruse: „The DTM-System TASH in an Interactive Environment“, EARSeL Advances in remote sensing, 1(3), S. 129-134, 1993.

[14] R. Carey, G. Bell: The Annotated Vrml 2.0 Reference Manual, Addison-Wesley, 1997. [15] W. Cartwright: „The Development of a Hybrid Discrete/Distributed Interactive

Multimedia Package for Teaching Geographical Concepts by Exploration“, Conference Proceedings Ottawa ICA/ACI 1999, S. 679-689, 1999.

[16] E. Catmull: „Computer Display of Curved Surfaces“, Proceedings of the IEEE Conference on Computer Graphics, Pattern Recognition and Data Structures, S. 11-17, 1975.

106

[17] D. Cline, P. Egbert: „Interactive Display of Very Large Textures“, Proceedings IEEE Visualization '98, S. 343-350, 1998.

[18] J. Döllner, K. Hinrichs: „A Generic Rendering System“, IEEE Transactions on Visualization and Computer Graphics, 8(2), S. 99-118, 2002.

[19] J. Döllner, O. Kersting: „Dynamic 3D Maps as Visual Interfaces for Spatio-Temporal Data“, Proceedings of ACM GIS 2000, S. 115-120, 2000.

[20] J. Döllner, K. Baumann, K. Hinrichs: „Texturing Techniques for Terrain Visualization“, Proceedings IEEE Visualization 2000, S. 207-234, 2000.

[21] J. Döllner, O. Kersting, K. Hinrichs: „Programmierbare, interaktive 3D-Karten zur Kommunikation raumbezogener Information“, Umweltinformation für Planung, Politik und Öffentlichkeit Bd. 1 (Hrsg. A.B.Cremers, K. Greve), Metropolis Verlag, S. 131-145, 2000.

[22] J. Döllner, O. Kersting: „Visuelle Unterstützung von Navigation und Orientierung in Interaktiven 3D-Karten“, Proceedings User Guidance in Virtual Environments (Hrsg. V. Paelke, S. Volbracht), ShakerVerlag, S. 41-51, 2000.

[23] D. Ebert, C. Shaw, A. Zwa, C. Starr: „Two-handed interactive Stereoscopic Visualization“ Proceedings IEEE Visualization ´96, S. 205-210, 1996.

[24] J. Eisenberg: SVG Essentials, O’Reilly, 2002. [25] T. Elvins, D. Nadeau, D. Kirsh: „Worldlets – 3D Thumbnails for Wayfinding in Virtual

Environments“, Proceedings of the ACM Symposium on User Interface Software and Technology, S. 21-30, 1997.

[26] S. Ervin: „Landscape Visualization with Emaps“, IEEE Computer Graphics & Applications, S. 28-33, 1993.

[27] J. Falby, M. Zyda, D. Pratt, R. Mackey: „NPSNET: Hierarchical data structures for real-time three-dimensional visual simulation“, Computers and Graphics, 17(1), S. 65-69, 1993.

[28] L. De Floriani, P. Magillo, E. Puppo: „Efficient Implementation of Multi-Triangulations”, Proceedings IEEE Visualization '98, S. 43-50, 1998.

[29] J. Foley, A. Van Dam, S. Feiner, J. Hughes, R. Phillips: Introduction to Computer Graphics - 1st Edition, Addison-Wesley, 1993.

[30] M. Garland, P. Heckbert: „Surface simplification using quadric error metrics“, Proceedings of ACM SIGGRAPH '97, S. 209-216, 1997.

[31] A. Gooch, B. Gooch, P. Shirley, E. Cohen: „A Non-Photorealistic Lighting Model For Automatic Technical Illustration“, Proceedings of ACM SIGGRAPH ´98, S. 447-52, 1998.

[32] H. Gouraud: „Continous Shading of Curved Surfaces“, IEEE Transactions on Computers, C(20), S. 623-629, 1971.

[33] A. Gregory, M. Lin, S. Gottschalk, R. Taylor: „HCollide: A framework for fast and accurate collision detection for haptic interaction“, Proceedings of Virtual Reality Conference 1999, S. 38-45, 1999.

[34] R. Haber, D. McNabb: „Visualization Idioms: A conceptual model for scientivic Visualization Systems“, In B. Shriver, G. Nielson, L. Rosenblum (eds): Visualization in Scientific Computing, IEEE ComputerSociety Press, S. 74-93, 1990.

[35] P. Haeberli, M. Segal: „Texture Mapping as a Fundamental Drawing Primitive“, Proceedings of the 4th Eurographics Workshop on Rendering, M. Cohen, C. Puech, F. Sillion (Eds.), S. 259-266, 1993.

107

[36] C. Häberling: “Symbolization in topographic 3D maps: Conceptual Aspects for User-Oriented Design”, Conference Proceedings Ottawa ICA/ACI 1999, S. 1037-1044, 1999.

[37] G. Hake: „Gedanken zu Form und Inhalt heutiger Karten“, Kartographische Nachrichten, Nr. 38, S.65-72, 1988.

[38] G. Hake, D. Grünreich: Kartographie - 7. Auflage, DeGryter, 1994. [39] A. Hanson, E. Wernert: „Constrained 3D Navigation with 2D Controllers“, Proceedings

IEEE Visualization '97, S. 175-182, 1997. [40] M. Harrison: Tcl/Tk Tools, O'Reilly & Associates, 1997. [41] W. Heidrich, H.-P. Seidel: „Realistic, Hardware-accelerated Shading and Lighting“,

Proceedings of ACM SIGGRAPH '99, S. 171-178, 1999. [42] W. Heidrich, P. Slusallek, H.-P. Seidel: „Using C++ class libraries from an interpreted

language“, Proceedings of TOOLS USA '94, S. 397-408, 1994. [43] D. van Heesch: www.doxygen.org, 2002. [44] H. Hoppe: „Progressive Meshes“, Proceedings of ACM SIGGRAPH '96, S. 99-108,

1996. [45] H. Hoppe: „Smooth View-Dependent Level-of-Detail Control and its Application to

Terrain Rendering”, Proceedings Visualization '98, S. 35-42, 1998. [46] H. Hoppe: „View-Dependent Refinement of Progressive Meshes“, Proceedings of

SIGGRAPH '97, S. 189-198, 1997. [47] T. Hüttner, W. Strasser: „FlyAway: A 3D TerrainVisualization System using

Multiresolution Principles“, Computer & Graphics, S. 479-485, 1999. [48] E. Imhof: Kartographische Gelände-Darstellung, Walter de Gruyter & Co, 1965. [49] Intel Corporation: „Accelerated Graphics Port Interface Specification, Revision 2.0“,

www.intel.com/technology/agp/agp_index.htm, 2002. [50] Internationale Kartographische Vereinigung: Mehrsprachiges Wörterbuch

kartographischer Fachbegriffe, 1973. [51] O. Kersting, J. Döllner: „Interactive 3D Visualization of Vector Data in GIS“, 10th

International Symposium of ACM GIS, S. 107-112, 2002. [52] O. Kersting, J. Döllner: „Interactively Developing 3D Graphics in Tcl“, Usenix Annual

Technical Conference, S. 1-12, 2002. [53] M. Kilgard: „Improving Shadows and Reflections via the Stencil Buffer“, NVIDIA White

Paper, 2000. [54] J. Klosowski, M. Held, J. Mitchell, H. Sowizral, K. Zikan: „Efficient collision detection

using bounding volume hierarchies of k-dops“, IEEE Transactions on Visualization and Computer Graphics, 4(1), S. 21-36, 1998.

[55] M.-J. Kraak: „Interactive Modelling Environment for Three-dimensional Maps: Functionality and Interface Issues.“, in A.M. MacEachren, D.R. Fraser Taylor (Eds.), Visualization in Modern Cartography, Pergamon, S. 269-285, 1994.

[56] D. Koller, P. Lindstrom, W. Ribarsky, L. Hodges, N. Faust, G. Turner: „Virtual GIS: A Real-Time 3D Geographic Information System“, Proceedings of the Conference on Visualization 95, S. 94-100, 1995.

[57] P. Lindstrom, V. Pascucci: „Terrain Simplification Simplified: A General Framework for View-Dependent Out-of-Core Visualization“, IEEE Transactions on Visualization and Computer Graphics, 8(3), S. 239-254, 2002.

108

[58] P. Lindstrom, V. Pascucci: „Visualization of Large Terrains Made Easy“, Proceedings IEEE Visualization 2001, S. 363-370, 2001.

[59] D. Luebke, C. Erikson: „View-dependent simplification of arbitrary polygonal environments“, In ACM Computer Graphics Proceedings, Annual Conference Series, S. 199-207, 1997.

[60] A. MacEachren: How Maps Work: Representation, Visualization and Design, Guilford Press, 1995.

[61] A. MacEachren: „Time as a Cartographic Variable”, Visualisation in Geographical Information Systems, H. M. Hearnshaw and D. J. Unwin (Eds.), John Wiley & Sons, S. 115-130, 1994.

[62] A. MacEachren: „Visualization in Modern Cartography: Setting the Agenda“, In: A. MacEachren, D. Fraser Taylor (Eds.), Visualization in Modern Cartography, Pergamon, S. 1-12, 1994.

[63] A. MacEachren, R. Edsall, D. Haug, R. Baxter, G. Otto, R. Masters, S. Fuhrmann, L. Qian, “Exploring the Potential of Virtual Environments for Geographic Visualization,” Association of American Geographers, 1999.

[64] A. MacEachren, M.-J. Kraak, E. Verbree: „Cartographic issues in the design and application of geospatial virtual environments” Conference Proceedings Ottawa ICA/ACI 1999, S. 657-665, 1999.

[65] M. McLennan: „[incr Tcl] - Object Oriented Programming in TCL“, Proceedings of Tcl/Tk Workshop 1993, 1993.

[66] T. Möller, E. Haines: Real-Time Rendering, A. K. Peters, 1999. [67] U. Neisser, H. Aebli: Kognition und Wirklichkeit: Prinzipien und Implikationen der

kognitiven Psychologie, 2. Auflage, Klett-Cotta, 1996. [68] U. Obeysekare, C. Williams, J. Durbin, L. Rosenblum, R. Rosenberg, F. Grinstein, R.

Ramamurti, A. Landsberg, W. Sandberg: „Virtual Workbench: A Non-Immersive Virtual Environment for Visualizing and Interacting with 3D Objects for Scientific Visualization“, Proceedings of the Conference on Visualization 96, S. 345-350, IEEE, 1996.

[69] J. Ousterhout: Tcl/Tk, Addison-Wesley, 1994. [70] J. Ousterhout: „Scripting: Higher Level Programming for the 21st Century”, IEEE

Computer, 31(3), S. 23-30, 1998. [71] R. Pajarola: „Large Scale Terrain Visualization Using The Restricted Quadtree

Triangulation“, Proceedings IEEE Visualization '98, S. 19-24, 1998. [72] F. Preparata, M. Shamos: „Computational Geometry: An Introduction“, Springer-

Verlag, 1985. [73] M. Reddy, Y. Leclerc, L. Iverson, N. Bletter: „Terra Vision II: Visualizing Massive

Terrain Databases in VRML“ IEEE Computer Graphics and Applications, März/April 1999, S. 30-38, 1999.

[74] H. Samet: „The Quadtree and Related Hierarchical Data Structures“, ACM Computing Surveys, 16(2), S. 187-260, 1984.

[75] P. Sander, J. Snyder, S. Gortler, H. Hoppe: „Texture mapping progressive meshes“, Proceedings ACM SIGGRAPH 2001, S. 409-416, 2001.

[76] W. Schroeder, K. Martin, B. Lorensen: The Visualization Toolkit - An Object-Oriented Approach To 3D Graphics, Prentice Hall, 1997.

109

[77] W. Schroeder, J. Zarge, W. Lorenson: „Decimation of Triangle Meshes“. Proceedings ACM SIGGRAPH '92, S. 65-70, 1992.

[78] H. Schumann, W. Müller: Visualisierung – Grundlagen und allgemeine Methoden, Springer, 2000.

[79] M. Sester, A. Klein: „Rule Based Generalization of Buildings for 3D-Visualization”, Conference Proceedings Ottawa ICA/ACI 1999, S. 773-783, 1999.

[80] S. Sinnige: Tclpp: An Object-Oriented Extension to Tcl www.geocities.com/SiliconValley/Network/2836/projects/tclpp/, 2000.

[81] J. Snyder, A. Woodbury, K. Fleischer, B. Currin, A. Barr: „Interval Methods for Multi-Point Collisions between Time-Dependent Curved Surfaces“, Proceedings ACM SIGGRAPH '93, S. 321-334, 1993.

[82] H. Sowizral: „Scene Graphs in the New Millennium“, IEEE Computer Graphics and Applications, 20(1), S. 56-57, 2000.

[83] H. Sowizral, K. Rushforth, M. Deering: The Java 3D API Specification, Addison Wesley, 1997.

[84] B. Speckmann, J. Snoeyink: „Easy triangle strips for TIN terrain models“, Proceedings of 9th CCCG, S. 239-244, 1997.

[85] D. Stalling, H.-C. Hege: „Fast and resolution independent line integral convolution“, Proceedings of ACM SIGGRAPH '95, S. 249-256, 1995

[86] P. Strauss, R. Carey: „An Object-Oriented 3D Graphics Toolkit“, Proceedings ACM SIGGRAPH '92, 26(2), S. 341-349, 1992.

[87] B. Stroustrup: The C++ Programming Language (Special 3rd Edition), Addison-Wesley, 2000.

[88] C. Szyperski: Component Software Beyound Object-Oriented-Programming, Addison-Wesley, 1998.

[89] C. Tanner, C. Midgal, M. Jones: „The Clipmap: A Virtual Mipmap“, Proceedings of ACM SIGGRAPH ´98, S. 151-158, 1998.

[90] A. Terribilini: „Maps in transition: development of interactive vector-based topographic 3D-maps”, Conference Proceedings Ottawa ICA/ACI 1999, S. 993-1001 1999.

[91] J. Viega, M. Conway, G. Williams, R. Pausch: „3D Magic Lenses”, Proceedings of the ACM Symposium on User Interface Software and Technology, S. 51-58, 1996.

[92] C. Ware: Information Visualization – Perception for Design, Academic Press, 1999. [93] B. Welch: Practical Programming in Tcl and Tk (3rd Edition), Prentice Hall, 1999. [94] L. Williams: „Pyramidal Parametrics“, Proceedings of SIGGRAPH '83, 17(3), S. 1-11,

1983. [95] M. Woo, J. Neider, T. Davis, D. Shreiner: OpenGL Programming Guide - 3rd ed,

Addision-Wesley, 1999. [96] C. Wynn: „Using P-Buffers for Off-Screen Rendering in OpenGL“, Nvidia Technical

Paper, 2002.

Hiermit erläre ich Oliver Patrick Kersting, dass diese Arbeit bisher an keiner anderen Hochschule als der Universität Potsdam eingereicht worden ist sowie selbständig und ausschließlich mit den angegebenen Mitteln angefertigt wurde. Oliver Patrick Kersting

Interaktive, dynamische 3D-Karten zur Kommunikation ... · Interaktive, dynamische 3D-Karten zur...

Documents

Transcript of Interaktive, dynamische 3D-Karten zur Kommunikation ... · Interaktive, dynamische 3D-Karten zur...