Interaktive Visualisierung der Speziellen Relativitätstheorie auf ...

www2.cs.upb.de

Interaktive Visualisierung der Speziellen Relativitätstheorie auf ...

Fakultät für Elektrotechnik, Informatik und

Mathematik

Institut für Informatik

Fachgruppe: Algorithmen und Komplexität

Diplomarbeit

Interaktive Visualisierung der

Speziellen Relativitätstheorie auf

programmierbarer Grafikhardware

von

Oliver Sudmann

Erstgutachter:

Prof. Dr. Friedhelm Meyer auf der Heide

Universität Paderborn

Zweitgutachter:

Priv.Doz. Dr. habil. Daniel Weiskopf

Institutsverbund Informatik der Universität Stuttgart

Paderborn, 29. November 2005


Interaktive Visualisierung der

Speziellen Relativitätstheorie auf

programmierbarer Grafikhardware

von

Oliver Sudmann

Diplomarbeit im Fachgebiet Informatik

Universität Paderborn

Fakultät für Elektrotechnik, Informatik und Mathematik

Institut für Informatik

Fachgruppe: Algorithmen und Komplexität

Paderborn, 29. November 2005

Zusammenfassung

In dieser Arbeit wird ein Softwaresystem zur interaktiven Visualisierung

der geometrischen Effekte der Speziellen Relativitätstheorie entwickelt.

Durch die Umsetzung eines beschleunigten Beobachters kann sich

der Benutzer interaktiv in Szenen, bestehend aus unabhängigen, gleichförmig

bewegten Objekten, bewegen. Die relativistische Darstellung wird

in Form eines Vertex Shader Programmes direkt auf der Grafikhardware

durchgeführt. Dabei wird unter anderem deren Fähigkeit zur hardwarebeschleunigten

Verarbeitung von 4x4-Matrizen ausgenutzt, die gewöhnlich

für die effiziente Unterstützung von dreidimensionalen, homogenen Koordinaten

dient; bei einer relativistischen Darstellung kann diese Fähigkeit

jedoch auch für die effiziente Verarbeitung der Lorentz-Transformation

eingesetzt werden. Zusammen mit der Realisierung des relativistischen T-

Buffers mit Hilfe des hardwareunterstützten Z-Buffer, können im Ergebnis

auch große Szenen mit 20 Bildern pro Sekunde dargestellt werden.

Schlüsselbegriffe: Spezielle Relativitätstheorie, interaktive Visualisierung, programmierbare

Grafikhardware, Vertex Shader, T-Buffer, ”

Relativator“.

i


Inhaltsverzeichnis

1 Einleitung und Überblick 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Programmierbare Grafikhardware 5

2.1 Rendering Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Vertex Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Pixel Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Portabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 NVIDIA Cg . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.2 OpenGL Shading Language . . . . . . . . . . . . . . . . . 7

3 Die spezielle Relativitätstheorie 9

3.1 Bezugssysteme und Minkowski Diagramme . . . . . . . . . . . . 9

3.2 Die Lorentz-Transformation . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Hintereinanderausführung von Lorentz-Transformationen 11

3.3 Visuelle Effekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 Geometrische Effekte . . . . . . . . . . . . . . . . . . . . . 12

3.3.2 Doppler- und Suchscheinwerfereffekt . . . . . . . . . . . . 13

4 Aktueller Forschungsstand und Ziele der Arbeit 15

4.1 Relativistisches Walkthrough in statischen Szenen . . . . . . . . 15

4.1.1 Der ”

Viewer“ . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.2 Die Software ”

Virtual Relativity“ . . . . . . . . . . . . . . 16

4.1.3 Das ”

relativistische“ Fahrrad . . . . . . . . . . . . . . . . 17

4.2 Relativistisches Walkthrough in dynamischen Szenen . . . . . . . 18

4.2.1 Steuerung in interaktiven, relativistischen Szenen . . . . . 19

5 Relativistisches Polygonrendering in dynamischen Szenen 21

5.1 Der T-Buffer Algorithmus . . . . . . . . . . . . . . . . . . . . . . 21

5.1.1 Statische Szenen mit dem T-Buffer Algorithmus . . . . . 21

5.1.2 Dynamische Szenen mit dem T-Buffer Algorithmus . . . . 24

5.2 Beschleunigter Beobachter in relativistischen Szenen . . . . . . . 25

5.2.1 Beschleunigter Beobachter und statische Szenen . . . . . 25

5.2.2 Beschleunigter Beobachter und dynamische Szenen . . . . 27

6 Implementierung auf der Grafikhardware 31

6.1 Die Lorentz-Transformation und Grafikprogrammierung . . . . . 31

6.2 Effiziente Implementierung auf CPU und GPU . . . . . . . . . . 31

6.2.1 Der T-Buffer Algorithmus auf der Grafikhardware . . . . 32

6.3 Austauschbare Implementierung des T-Buffer Algorithmus . . . . 34

iii


7 Analyse der Messergebnisse 35

7.1 Das Messverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.2 Untersuchte Szenen . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.2.1 Modellierung von Szenen zur relativistischen Darstellung 36

7.2.2 Relativistisches Haus . . . . . . . . . . . . . . . . . . . . . 38

7.2.3 Relativistische Raumschiffe . . . . . . . . . . . . . . . . . 39

7.2.4 Relativistische Industriehalle . . . . . . . . . . . . . . . . 40

7.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.3.1 Unabhängigkeit der Framerate vom Beobachterstandpunkt 41

7.3.2 Unabhängigkeit der Ergebnisse von den Szenen . . . . . . 44

7.3.3 Vergleich zwischen Grafikkarten von NVIDIA und ATI . . 45

7.3.4 Darstellungsmodi im Zusammenhang mit GPU und CPU 46

7.3.5 Leistungsvergleich der verschiedenen relativistischen Darstellungsimplementierungen

. . . . . . . . . . . . . . . . . 48

7.3.6 Vergleich von relativistischem mit nicht-relativstischem

Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.3.7 Vergleich von Relativator“ und Virtual Relativity“ . . . . 49

” ”

7.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8 Ausblick 53

8.1 Doppler- und Suchscheinwerfereffekt . . . . . . . . . . . . . . . . 53

8.2 Beschleunigte Objekte . . . . . . . . . . . . . . . . . . . . . . . . 53

8.3 Relativistisches Culling . . . . . . . . . . . . . . . . . . . . . . . . 55

9 Modellverzeichnis 57

10 Verzeichnis verwendeter Programmbibliotheken 57

11 Literaturverzeichnis 59

12 Erklärung und Danksagung 61

12.1 Erklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

12.2 Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

iv


Abbildungsverzeichnis

1 Rendering Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Beispiele für Minkowski-Diagramme . . . . . . . . . . . . . . . . 9

3 Hintereinanderausführung mehrerer Lorentz-Transformationen . 12

4 Auswirkungen der Geometrischen Effekte . . . . . . . . . . . . . 13

5 Auswirkungen des Doppler- und Suchscheinwerfereffektes [WeisDis] 14

6 Kristallstruktur visualisiert mit dem Viewer“ . . . . . . . . . . . 16


7 Szene visualisiert mit Virtual Relativity“ . . . . . . . . . . . . . 17


8 Fahrt mit dem relativistischen“ Fahrrad [BorKra05] . . . . . . . 18


9 Ausgangssituation für die Darstellung einer statischen Szene . . . 22

10 Dynamische Szenen und der T-Buffer Algorithmus . . . . . . . . 24

11 Beschleunigter Beobachter in statischen Szenen . . . . . . . . . . 25

12 Beschleunigter Beobachter in dynamischen Szenen . . . . . . . . 28

13 Ablaufdiagramm für die relativistische Darstellung in dynamischen

Szenen mit beschleunigtem Beobachter . . . . . . . . . . . 29

14 Aufteilung der Berechnungen auf CPU und GPU. . . . . . . . . . 32

15 Der T-Buffer Algorithmus auf der Grafikhardware. . . . . . . . . 33

16 Messung der Bilder pro Sekunde mit Virtual Relativity“. . . . . 35


17 Auswirkungen unterschiedlicher Gittergrößen beim relativistischen

Rendering mit dem T-Buffer Algorithmus. . . . . . . . . . . . . . 37

18 Gesamtansicht des relativistischen Hauses. . . . . . . . . . . . . . 38

19 Überblick über eine relativistische Szene mit vielen unabhängigen,

gleichförmig bewegten Raumschiffen. . . . . . . . . . . . . . 39

20 Ansichten der relativistischen Industriehalle. . . . . . . . . . . . . 40

21 Verlauf der Framerate in der Raumschiffszene bei der relativistischen

Darstellung mit NVIDIA Cg. . . . . . . . . . . . . . . . . . 41

22 Mittlere Framerate bei den drei Szenen. . . . . . . . . . . . . . . 43

23 Vergleich der mittleren Framerate von NVIDIA und ATI Grafikkarten

bei der Raumschiffszene. . . . . . . . . . . . . . . . . . . . 45

24 Abhängigkeit der Framerate von der CPU und der Grafikkarte

in verschiedenen Darstellungsmodi. . . . . . . . . . . . . . . . . . 47

25 Leistungsvergleich verschiedener Implementierungsvarianten des

relativistischen Renderings auf NVIDIA Grafikkarten. . . . . . . 48

26 Nicht-relativistisches und relativistisches Rendering. . . . . . . . 50

27 Leistungsvergleich zwischen dem Relativator (NVIDIA Cg) und

Virtual Relativity“. . . . . . . . . . . . . . . . . . . . . . . . . . 51


28 Prinzip zur relativistischen Visualisierung eines beschleunigten

Beobachters mit beschleunigten Objekten. . . . . . . . . . . . . . 54

29 Probleme beim relativistischen Frustum-Culling. . . . . . . . . . 55

30 Probleme beim relativistischen Occlusion-Culling. . . . . . . . . . 56

v


1 Einleitung und Überblick

1.1 Motivation

Ohne die, von Albert Einstein 1905 entdeckte, Relativitätstheorie wären viele

Alltagsgegenstände heute gar nicht denkbar. So entscheidet die Relativitätstheorie

über die Genauigkeit von Satellitenbahnen und somit über die Verfügbarkeit

von Fernsehen und Telekommunikation. Auch die heute immer mehr eingesetzten

Navigationssysteme(GPS) wären ohne Einbeziehung der Relativitätstheorie

sehr ungenau und somit für den Nutzer unbrauchbar (vgl. [Giulini05]).

Obwohl die Relativitätstheorie in Form von Alltagsgegenständen, Einzug in das

alltägliche Leben gefunden hat, ist die Theorie selbst für die Mehrheit der Menschen

schwer zu verstehen. Die Ursache für die schwere intuitive Verständlichkeit

der Relativitätstheorie liegt wohl darin, dass sie scheinbar unseren alltäglichen

Erfahrungen widerspricht: Strecken werden objektiv kürzer oder länger, Zeitabstände

verändern sich abhängig vom Standpunkt des Betrachters und Massen

werden größer oder kleiner. Für die bislang vergleichweise langsam bewegte

Menschheit sind diese nur bei sehr hohen Geschwindigkeiten auftretende Effekte

im Alltag kaum sichtbar und entziehen sich daher der Vorstellungskraft.

Bereits bei der Entdeckung der Relativitätstheorie wurde versucht, den Menschen

die Theorie mit Bildern verständlicher zu machen. Doch erst mit Hilfe

von Computern ist es möglich, einen realitätsnahen Einblick in die Relativitätstheorie

zu erhalten. Mussten noch vor wenigen Jahren große Supercomputer

eingesetzt werden um relativistische Effekte offline zu simulieren, so ist es

heute, insbesondere durch die rasante Entwicklung der Grafikhardware, mit nahezu

jedem herkömmlichen PC möglich eine interaktive Reise in die Welt der

Speziellen Relativitätstheorie zu machen.

Die besondere Motivation und Herausforderung dieser Arbeit besteht in der

Ausnutzung der heute sehr leistungsstarken und flexiblen Grafikhardware, um

einer möglichst breiten Masse von Menschen ein besseres Verständnis für die

Spezielle Relativitätstheorie zu ermöglichen.

1.2 Ziele

Ziel dieser Arbeit ist die Erweiterung der Ansätze von Hsiung, Thibadeau,

Weiskopf und Wu, im Hinblick auf große dynamische Szenen. Konkret ergeben

sich daher drei Ziele für diese Arbeit:

1. Erweiterung der Verfahren von Hsiung, Thibadeau, Weiskopf und

Wu auf dynamische Szenen bestehend aus unabhängigen, gleichförmig

bewegten Objekten, mit einem interaktiven, beschleunigten Beobachter.

2. Implementierung der relativistischen Visualisierung sowohl ausschließlich

auf der CPU als auch mit Hilfe programmierbarer Grafikhardware in dem

zu dieser Arbeit entwickelte Softwaresystem ”

Relativator“.

3. Bewertung der Leistungsfähigkeit, speziell bei der Implementierung auf

der Grafikhardware, anhand von Messungen.

1


Diese Diplomarbeit umfasst sowohl einen schriftlichen Anteil, als auch einen

praktischen Anteil. Der schriftliche Teil entspricht dem vorliegenden Text und

umfasst insbesondere die theoretischen Grundlagen zur relativitischen Visualisierung

dynamischer Szenen, bestehend aus unabhängigen, gleichförmig bewegten

Objekten mit einem interaktiven, beschleunigten Beobachter auf programmierbarer

Grafikhardware, sowie die Analyse der mit dem Softwaresystem

Relativator“ ermittelten Messwerte.


Das Ziel des praktischen Teils dieser Arbeit ist die Entwicklung der Software

Relativator“die, neben der Aufzeichnung von Messwerten für die Bewertung der


Leistungsfähigkeit einer Realisierung auf der Grafikhardware, weitere für diese

Arbeit bedeutende Ziele beinhaltet:

Interaktive Navigation durch relativistische Szenen mit beschleunigtem

Beobachter.

Visualisierung relativistischer, dynamischer Szenen mit unabhängigen, gleichförmig

bewegten Objekten aus der Sicht eines beschleunigten Beobachters.

Visualisierung der geometrischen Effekte der Speziellen Relativitätstheorie.

• Darstellung großer, komplexer Szenen in Echtzeit durch Umsetzung auf

der Grafikhardware mit Hilfe von

– NVIDIA Cg.

der OpenGL Shading Language.

• Implementierung auch ohne Grafikhardwareunterstützung direkt auf der

CPU zum Vergleich.

• Nicht-Relativistische Darstellung zum Vergleich.

Eine wichtige Aufgabe der Software im Hinblick auf die Ziele dieser Arbeit, ist

das Erfassen von Messwerten mit verschiedenen Szenen, unterschiedlicher Hardware

und verschiedener Implementierungen für die Darstellung der Szenen. Ziel

dieser Messungen ist eine Bewertung der Leistung einer Implementierung der

relativistischen Visualisierung auf programmierbarer Grafikhardware. In diesem

Zusammenhang werden mit der Software ”

Relativator“ Messungen durchgeführt,

die in Kapitel 7 bei folgenden Vergleichen herangezogen werden:

• Vergleich von Szenen unterschiedlicher Größe/Komplexität und mit verschiedener

Anzahl unabhängig bewegter Objekte.

• Vergleich mit unterschiedlicher Hardware (Grafikhardware, Prozessor).

• Vergleich verschiedener Implementierungen auf der Grafikhardware mit

einer rein CPU-basierten Implementierung.

• Vergleich mit der nicht-relativistischen Darstellung.

• Vergleich mit der von Daniel Weiskopf entwickelten Software ”

Virtual

Relativity“.

2


1.3 Ergebnisse

Durch Kombination der Ansätze für die Darstellung unabhängiger, gleichförmig

bewegter Objekte mit dem T-Buffer Algorithmus aus [Hsiung90] und der Simulation

eines beschleunigten Beobachters aus [WeisVirt00] wurde in dieser Arbeit

ein Verfahren entwickelt, um dynamische Szenen, bestehend aus unabhängigen,

gleichförmig bewegten Objekten und einem beschleunigten Beobachter, relativistisch

in Echtzeit zu visualisieren.

Wegen der Besonderheit der Grafikhardware 4 × 4-Matrizen und vierdimensionale

Vektoren zu unterstützen, lässt sich die für die relativistiche Visualisierung

wichtige Allgemeine Lorentz-Transformation besonders einfach und effizient auf

programmierbarer Grafikhardware umsetzen. Entsprechend den Ausführungen

aus [WeisVirt00] kann der in [Hsiung90] beschriebene Time-Buffer (T-Buffer)

durch den Z-Buffer der Grafikkarte ersetzt werden. Insgesamt lässt sich der

T-Buffer Algorithmus daher effizient mit Hilfe moderner, programmierbarer

Grafikhardware realisieren.

In Kapitel 7 kann gezeigt werden, dass die Berechnung auf der Grafikhardware,

insbesondere mit NVIDIA gestützten Grafikkarten, zu sehr guten Ergebnissen

führen. Auf diese Weise ist es möglich, große, komplexe Szenen in Echtzeit und

somit interaktiv darzustellen. Es zeigt sich außerdem, dass eine Implementierung

auf der Grafikkarte deutlich bessere Leistung als eine rein auf der CPU

basierende Implementierung aufweist.

Ein Vergleich mit der Software ”

Virtual Relativity“ von Daniel Weiskopf

zeigt nicht nur, dass die Software ”

Relativator“ gut mit anderen Umsetzungen

der geometrischen Effekte der Speziellen Relativitätstheorie konkurrieren kann,

sondern auch, dass eine Implementierung direkt auf der Grafikhardware zu anderen

effizient programmierten Ansätzen deutliche Performancevorteile bietet.

Die nicht-relativistische Darstellung ist erwartungsgemäss leistungsfähiger. Allerdings

kann der Leistungsnachteil einer relativistischen Darstellung bei Implementierung

auf der Grafikhardware leicht durch ein Upgrade der Grafikkarte

kompensiert werden.

1.4 Gliederung der Arbeit

Bevor in dieser Arbeit das Verfahren zur Darstellung der Speziellen Relativitätstheorie

dargelegt wird, werden in Kapitel 2 und Kapitel 3 die Grundlagen

dieser Arbeit erörtert. Dazu werden insbesondere die für diese Arbeit wichtigen

Merkmale programmierbarer Grafikhardware beschrieben. Da sich diese Arbeit

besonders an Informatiker wendet, werden im Anschluss die wichtigsten Begriffe

der Speziellen Relativitätstheorie eingeführt.

In Kapitel 4 werden zunächst die aktuellen Erkenntnisse für die Visualisierung

der Speziellen Relativitätstheorie anhand verschiedener echtzeitfähiger Softwaresysteme

vorgestellt. Im Anschluss daran werden in diesem Kapitel auch die

Ziele dieser Arbeit genau formuliert.

Aufbauend auf den Grundlagen der ersten Kapitel wird in Kapitel 5 ein Algorithmus,

auf der Basis der Arbeiten von Hsiung, Thibadeau, Weiskopf

und Wu, für die relativistische Visualisierung eines beschleunigten Beobachters

3


in dynamischen Szenen entwickelt. Im darauf folgenden Kapitel 6 wird gezeigt,

auf welche Weise sich der entwickelte Algorithmus mit programmierbarer Grafikhardware

umsetzen lässt.

Die Algorithmen aus Kapitel 5 und die Umsetzungsansätze aus Kapitel 6 werden

im Softwaresystem ”

Relativator“ verwirklicht. Mit dieser Software wird in

Kapitel 7 mit Hilfe von Messungen die Leistungsfähigkeit einer Implementierung

mit programmierbarer Grafikhardware untersucht.

Zuletzt wird mit dem Kapitel 8 auf offene Fragen und mögliche Weiterentwicklungen

des hier vorgestellten Ansatzes eingegangen.

4


Eingabe

3D-Primitive,

Licht, usw.

1. Stufe

Geometrie

2. Stufe

Clipping

3. Stufe

Rasterung

4. Stufe

Texturen

5.Stufe

Pixel Operationen

Ausgabe

Frame-Buffer

Vertex-Shader

Fragment-/Pixel-Shader

Abbildung 1: Rendering Pipeline

2 Programmierbare Grafikhardware

Die Grafikhardware entwickelt sich derzeit, insbesondere durch die hohen Anforderungen

von 3D-Spiele, derart rasant, dass ihre Leistung schneller zunimmt

als die Leistung der CPUs. Neben der immer höheren Performance ist die aktuelle

Grafikhardware teilweise programmierbar. Dies bietet 3D-Spielen nicht nur

erhöhte Flexibilität, sondern ermöglicht auch die Lösung von Problemen direkt

auf der Grafikhardware, welche zuvor auf der CPU gelöst werden mussten.

Insbesondere bei parallelisierbaren Problemen führt dies nicht nur zur Entlastung

der CPU, sondern zudem zu einem Performancegewinn. Betrachtet man

diese Leistungsfähigkeit im Zusammenhang mit dem Preis, so zeigt sich, dass

die aktuelle Grafikhardware für viele Probleme eine preiswerte Alternative zu

Mehrprozessorsystemen darstellt.

Innerhalb der Rendering Pipeline aktueller Grafikhardware gibt es hauptsächlich

zwei programmierbare Einheiten: Zum einen den sogenannten Vertex Shader

und zum anderen den Fragment- bzw. Pixel Shader. Soweit es für das Verständnis

dieser Arbeit erforderlich ist, werden diese Komponenten im folgenden

genauer vorgestellt werden.

2.1 Rendering Pipeline

Die Rendering Pipeline beschreibt die Umwandlung der 3D-Modelldaten in ein

zweidimensionales Bild. Dabei dient die Ausgabe einer Stufe der Pipeline als

Eingabe für die nächste Stufe. Mit Hilfe der Rendering Pipeline lässt sich gut

darstellen, an welchen Stellen der Bilderzeugung der Vertex Shader und der

Pixel Shader Einfluss nehmen.

In der ersten Stufe der Rendering Pipeline werden die dreidimensionalen Szenendaten

durch verschiedene Koordinatentransformationen in eine zweidimensionale

Projektion umgewandelt (siehe Abbildung 1). In der Regel werden an dieser

Stelle auch die Beleuchtungseffekte berechnet. Auf aktueller Grafikhardware ist

die erste Stufe, in Form von Vertex Shader Programmen, frei programmierbar.

Die zweite und dritte Stufe sind das Clipping und die Rasterung (siehe Abbildung

1). Beim Clipping werden nicht darzustellende Bereiche (z.B. Bereiche

außerhalb des angezeigten Fensters) entfernt und somit nicht an die nächste

Stufe weitergeleitet. Bei der Rasterung werden die verschiedenen Daten mit

einzelnen Pixeln verknüpft.

Die letzten beiden Stufen (vier und fünf) dienen zur Ermittlung des endgültigen

5


Farbwertes eines jeden Pixels (siehe Abbildung 1). Auf heutiger Grafikhardware

lässt sich auch dieser Bereich frei programmieren. Programme für diesen Bereich

heißen Fragment- oder auch Pixel Shader Programme.

2.2 Vertex Shader

Der Vertex Shader stellt einen programmierbaren Teil der Grafikhardware dar.

Im Vertex Shader kann Einfluss auf die Geometrie der darzustellenden Objekte

genommen werden. So lassen sich zum Beispiel Positionen der Objekte verändern.

Aber auch der Farbwert eines Objektes kann hier manipuliert werden.

Dies wird insbesondere für die Berechnung der Beleuchtungseffekte im Vertex

Shader genutzt.

Neben benutzerdefinierten Parametern als Eingabe, erhält ein Vertex Shader

Programm einen sogenannten Vertex als Eingabe. Ein Vertex beschreibt einen

Eckpunkt eines Polygons durch Position, Farbe und meist auch einer Normalen.

Die Normale repräsentiert die Ausrichtung des zugehörigen Polygones.

Zur Ausgabe eines Vertex Shader Programmes gehören insbesondere die auf

zwei Dimensionen projizierte Position und die Farbe des Vertex.

Ein Vertex Shader Programm wird in der Regel nicht nur für einen Vertex

verwendet, sondern für eine Vielzahl von Vertizes. 1 Die oben erwähnten benutzerdefinierten

Parameter werden meist für komplette Objekte konstant gehalten

und ändern sich nicht von Vertex zu Vertex. Somit ändern sich nur die Parameter

der einzelnen Vertizes.

Die Hauptaufgabe des Vertex Shaders besteht in der Transformation der Geometrie.

Daher dominieren in Vertex Shader Programmen Vektor- und Matrizen-

Operationen. Da die Grafikhardware speziell für diese Operationen konstruiert

ist, lassen sich Vektor- und Matrizen-Operationen auf der Grafikhardware deutlich

schneller als auf der CPU ausführen. Aus speziellen Gründen, die an dieser

Stelle nicht näher erörtert werden müssen, werden im Vertex Shader nicht dreidimensionale

Vektoren verwendet, sondern vierdimensionale Vektoren und 4x4-

Matrizen. Wie in Kapitel 6.1 gezeigt werden wird, hat dies für die Darstellung

relativistischer Szenen besondere Vorteile.

2.3 Pixel Shader

Ähnlich wie der Vertex Shader, lässt sich der Pixel Shader (häufig auch Fragment

Shader genannt) als programmierbaren Teil der Grafikhardware bezeichnen.

Der Pixel Shader befindet sich am Ende der Rendering Pipeline und bestimmt

hauptsächlich den Farbwert der Objekte. Daher lassen sich mit Hilfe von

Pixel Shader Programmen besonders gut Materialeigenschaften modellieren.

Während beim Vertex Shader ein Programm auf viele Vertizes angewendet wird,

wird ein Pixel Shader Programm auf eine große Zahl einzelner Pixel angewendet.

1 Dieses Prinzip ist in der Rechnerarchitektur als SIMD-Modell bekannt. Programmierbare

Grafikhardware wird daher häufig auch als SIMD-System abstrahiert.

6


2.4 Portabilität

Neben dem Problem der Plattformunabhängigkeit, das sich immer bei der Erstellung

eines Programmes ergibt, erhält man bei der Programmierung von

Grafikhardware schnell zusätzliche Portabilitätsproblem. Dies ergibt sich vor

allem durch die rasante Entwicklung der Grafikhardware, wodurch eine enorme

Bandbreite an unterschiedlichster Hardware entstanden ist. So unterscheiden

sich die Schnittstellen und Features der Hardware und Treiber nicht nur von

Hersteller zu Hersteller, sondern sogar von Grafikkarte zu Grafikkarte ein und

desselben Herstellers. Hinzu kommt, dass Vertex- und Pixel Shader meist durch

einen unübersichtlichen assemblerartigen Code programmiert werden müssen.

Um diese Probleme zu lösen gibt es mittlerweile verschiedene Shader-Hochsprachen,

die einheitliche Schnittstellen für verschiedenste Hardware bieten. Zwei

dieser Hochsprachen sind NVIDIA Cg und die OpenGL Shading Language. Beide

werden in dieser Arbeit genutzt und sollen daher kurz vorgestellt werden.

2.4.1 NVIDIA Cg

NVIDIA Cg ist eine von der Firma NVIDIA entwickelte Shader-Hochsprache.

Cg ist eine Abkürzung und steht für ”

C for Graphics“. Dieser Name beinhaltet

bereits, dass diese Sprache C-ähnlich ist. Eine Einführung in diese Sprache findet

sich zum Beispiel in [NVCg04].

Mit NVIDIA Cg lassen sich sowohl Vertex Shader Programme als auch Pixel

Shader Programme formulieren. Die C-ähnlichen Programme werden mit Hilfe

einer vom Cg-Toolkit mitgelieferten Bibliothek in hardwarespezifischen Code

übersetzt.

Auf diese Weise ist es möglich, einen hardwareunabhängigen Code zu erzeugen,

der auf nahezu jeder NVIDIA-gestützen Grafikkarte umsetztbar ist. Die

Programme laufen sogar auf Grafikhardware, die noch keine hardwaregestützte

Shaderunterstützung besitzt. In solchen Fällen sorgt der Grafikkartentreiber

dafür, dass der Code mit Hilfe der CPU umgesetzt wird. Man verliert an dieser

Stelle natürlich sofort den Performancevorteil.

Die Bibliotheken aus dem NVIDIA Cg Toolkit unterstützen sowohl Microsofts

DirectX Schnittstelle, als auch den OpenGL Standard. Da es zudem Implementierungen

für Linux und für Windows gibt, ist NVIDIA Cg auf vielen Systemen

lauffähig.

NVIDIA Cg kann als eine hardwareübergreifende Shader-Hochsprache bezeichnet

werden, jedoch nicht als herstellerübergreifend. Insbesondere auf Grafikhardware

mit Grafikchips des Konkurenzherstellers ATI sind Cg-Programme

häufig nicht lauffähig. Einen herstellerunabhängigen Standard bietet hingegen

die OpenGL Shading Language.

2.4.2 OpenGL Shading Language

Die OpenGL Shading Language ist eine, in den OpenGL-Standard eingebettete,

C-ähnliche Shader-Hochsprache. Genau wie NVIDIA Cg kann diese Shader-

Hochsprache sowohl Vertex Shader Programme als auch Pixel Shader Programme

umsetzen. Im Gegensatz zu NVIDIA Cg wird der C-ähnliche Code jedoch

7


nicht mit Hilfe einer externen Bibliothek für die Hardware umgesetzt, sondern

es werden von OpenGL Schnittstellen bereitgestellt, die von den Herstellern der

Grafikhardware implementiert werden.

Gegenwärtig gibt es sowohl für NVIDIA gestützte Grafikhardware, als auch

für ATI gestützte Grafikhardware entsprechende Implementierungen für die

OpenGL Shading Language. Somit ist diese Shader-Hochsprache nicht nur hardwareübergreifend,

sondern kann auch als herstellerübergreifend bezeichnet werden.

Eine nähere Beschreibung der verschiedenen Spezifikationen der OpenGL Shading

Language findet sich in [OGSL04].

8


3 Die spezielle Relativitätstheorie

Dieses Kapitel beschreibt die physikalischen Grundlagen dieser Arbeit. Es kann

und soll jedoch nicht als vollständige Einführung in die spezielle Relativitätstheorie

dienen. Statt dessen werden für diese Arbeit wichtige Begriffe und Zusammenhänge

eingeführt und erklärt. Für eine ausführlichere Einführung in die

spezielle Relativitätstheorie im Zusammenhang mit der Visualisierung sei auf

[WeisDis] und auf [Sudm04] verwiesen. Für eine allgemeine Einführung in die

spezielle Relativitätstheorie sei auf [Møller72] und [Rindler82] verwiesen.

Die spezielle Relativitätstheorie beschreibt die physikalischen Effekte bei sehr

großen Geschwindigkeiten. Sie basiert auf der experimentell gut bestätigten

Erkenntnis, dass sich Licht in jedem gleichförmig bewegten Bezugssystem mit

einer konstanten Geschwindigkeit von 299792, 458 km s

ausbreitet.

Aus der Konstanz der Lichtgeschwindigkeit ergibt sich, dass sich Werte anderer

Größen, wie zum Beispiel Länge, Zeit und Masse, abhängig von ihrem Bezugssystem

verändern müssen, damit die Naturgesetze unabhängig vom Bezugssystem

ihre Gültigkeit behalten. Dies führt dazu, dass die Relativitätstheorie nicht

intuitiv verständlich ist.

3.1 Bezugssysteme und Minkowski Diagramme

a) b)

ct

Weltlinie eines

ruhenden Objektes

ct

Weltlinie für

Objekt mit

Geschwindigkeit v

c)

ct

Weltlinie eines beschleunigten

Objektes

x

x

x

d)

ct

ct’

Weltlinie für

Objekt mit

Geschwindigkeit v

x’

S’

x

S

Abbildung 2: Beispiele für Minkowski-Diagramme

9


In der Speziellen Relativitätstheorie werden die meisten Zusammenhänge relativ

zu verschiedenen Bezugssystemen betrachtet. Daher wird der Begriff Bezugssystem

zunächst genauer erklärt. In der Physik versteht man unter einem

Bezugssystem ein System, in dem die physikalischen Gesetze Gültigkeit haben.

Im Falle der Speziellen Relativitätstheorie bedeutet dies, dass ein Bezugssystem

kein beschleunigtes System sein kann, sondern ein gleichförmig bewegtes sein

muss.

Im folgenden wird ein Bezugssystem mit Hilfe eines Koordinatensystems mit

Raum- und Zeitachse dargestellt. Ein Punkt in einem solchen System wird auch

Ereignis genannt. In der Wirklichkeit ist beispielsweise durch den Zeitpunkt und

den Aussendungsort eines Lichtsignals ein derartiges Ereignis beschrieben.

In der Realität müssen normalerweise drei Raumrichtungen und die Zeit berücksichtigt

werden. Somit erhält man ein vierdimensionales Koordinatensystem.

Für eine anschauliche Betrachtung genügt aber meist eine Raumrichtung

und die Zeit, so dass eine zweidimensionale Darstellung ausreicht. Eine solche

Darstellung wird auch als Minkowski-Diagramm bezeichnet.

Die Bewegung eines Objektes kann in einem solchen Koordinatensystem in Form

einer sogenannten Weltlinie dargestellt werden. In Abbildung (2) sind verschiedene

Beispiele für Weltlinien zu sehen.

Ein Objekt, das gegenüber seinem Bezugssystem ruht, wird durch eine Parallele

zur Zeitachse dargestellt (Abb. 2a). Ein solches Bezugssystem wird auch als

Ruhesystem für das Objekt bezeichnet.

Ein gleichförmig bewegtes Objekt hat eine Gerade als Weltlinie (Abb. 2b),

während ein beschleunigtes Objekt eine gekrümmte Weltlinie hat (Abb. 2c).

Betrachtet man zwei zueinander gleichförmig bewegte Bezugssysteme (Abb.

2d), so lassen sich Ereignisse von einem System in das andere überführen. Eine

solche Koordinatentransformation wird mit Hilfe der sogenannten Lorentz-

Transformation durchgeführt.

3.2 Die Lorentz-Transformation

Die Lorentz-Transformation beschreibt den Zusammenhang zwischen zwei Bezugssystemen

S 1 und S 2 , die sich relativ zueinander mit einer Geschwindigkeit

⃗v bewegen (vgl. Abb. 2d). Um eine gute Übersichtlichkeit, insbesondere bei der

Betrachtung vieler Bezugssysteme, zu ermöglichen, wird nun eine, speziell in

dieser Arbeit verwendete, Notation für die Darstellung von Ereignissen und der

Lorentz-Transformation eingeführt.

Wird ein Ereignis e in einem Bezugssystem S dargestellt, wird das jeweilige

Bezugssystem als Index in Klammern an das Ereignissymbol geschrieben. Ein

Ereignis e, dargestellt in einem Bezugssystem S, wird somit in der Form e (S)

geschrieben.

Bezieht sich ein Ereignis auf kein bestimmtes Bezugssystem wird kein Index

mit Klammern angefügt.

Werden mit Hilfe einer Lorentz-Transformation L Ereignisse von einem System

S 1 in ein System S 2 überführt, so wird die Richtung der Überführung durch die

Indizes S 1 und S 2 beschrieben. Die oben genannte Lorentz-Transformation wür-

10


de also als L S1 S 2

dargestellt.

Fallen die Ursprünge zweier Systeme S 1 und S 2 zusammen, ist also x = x ′ =

0; y = y ′ = 0; z = z ′ = 0; t = t ′ = 0, so gilt die Allgemeine Lorentz-Transformation,

wie in Gl. (1) beschrieben.


(γ − 1)n 2 ⎞

x + 1 (γ − 1)n x n y (γ − 1)n x n z −βγn x

L S1 S 2

= ⎜ (γ − 1)n x n y (γ − 1)n 2 y + 1 (γ − 1)n y n z −βγn y


⎝ (γ − 1)n x n z (γ − 1)n y n z (γ − 1)n 2 z + 1 −βγn z

⎠ (1)

−βγn x −βγn y −βγn z γ

mit c : Lichtgeschwindigkeit ; β = |⃗v|

c ; γ = 1


1 − β 2

; ⃗n : Richtungsvektor von ⃗v

Ein Ereignis e (S1 ) in S 1 lässt sich unter den oben geforderten Bedingungen in

das entsprechende Ereignis e (S2 ) in S 2 überführen:

e (S2 ) = L S1 S 2 · e (S1 ) (2)

Um ein Ereignis von S 2 nach S 1 zu überführen, kann eine ähnliche Gleichung

wie die Lorentz-Transformation aus Gl. (1) verwendet werden. Dabei ist jedoch

zu beachten, dass aus Sicht eines Beobachter in S 2 , das System S 1 eine

Geschwindigkeit von −⃗v hat.

3.2.1 Hintereinanderausführung von Lorentz-Transformationen

Die oben vorgestellte Allgemeine Lorentz-Transformation ist sehr hilfreich, um

ein Ereignis von einem Bezugssystem in ein anderes zu überführen, wenn die

Beziehung zwischen beiden Bezugssystemen bekannt ist. Es gibt jedoch Situationen,

in denen die Beziehungen zwischen zwei Bezugssystemen nur indirekt,

also durch Beziehungen zu anderen Bezugssystemen beschrieben sind. In einem

solchen Fall kann eine Hintereinanderausführung der entsprechenden Lorentz-

Transformationen hilfreich sein, wie das folgende Beispiel zeigen wird.

In Abbildung (3) gibt es drei Bezugssysteme. Dabei bewegt sich S 2 aus der Sicht

eines Beobachters in S 1 mit der Geschwindigkeit v 1 und S 3 aus der Sicht eines

Beobachters in S 1 mit der Geschwindigkeit v 2 . S 2 und S 3 stehen somit indirekt

über das Bezugssystem S 1 in Beziehung.

Um ein Ereignis e (S2 ) aus dem Bezugssystem S 2 in das Bezugssystem S 3 zu

überführen, muss das Ereignis zunächst in S 1 überführt werden und kann erst

dann in das System S 3 überführt werden, da die Geschwindigkeit und somit die

Lorentz-Transformation zwischen S 2 und S 3 nicht gegeben ist. 2 e (S3 ) ergibt sich

daher zu:

e (S3 ) = L S1 S 3 · (L S2 S 1 · e (S2 )) (3)

2 Bei der Verwendung von drei Raumrichtungen genügt es in der Regel nicht, eine relativistische

Geschwindigkeitsaddition durchzuführen. Die aus der relativistischen Geschwindigkeitsaddition

resultierende Allgemeine Lorentz-Transformation muss nicht zu der Hintereinanderausführung

der entsprechenden Lorentz-Transformationen äquivalent sein.

11


ct S

v 1

ct

1 S2

ct

1 S3

ct S

v 2

x S2

S 2

x

S 1

S 1

x S3

S 3

x

S 1

S 1

Abbildung 3: Hintereinanderausführung mehrerer Lorentz-Transformationen

Aufgrund der mathematischen Natur der Lorentz-Transformation lässt sich

die Hintereinanderausführung zweier Lorentz-Transformationen mittels Matrizenmultiplikation

zu einer neuen Lorentz-Transformation zusammenfassen, die

äquivalent zu der Hintereinanderausführung ist. Für das Beispiel ergibt sich

somit:

L S2 S 3

= L S1 S 3 · L S2 S 1

(4)

3.3 Visuelle Effekte

Im Hinblick auf die Visualisierung schnell bewegter Objekte ergeben sich aus der

Speziellen Relativitätstheorie und der Tatsache, dass die Lichtgeschwindigkeit

einen endlichen Wert hat, verschiedene Konsequenzen. Im Folgenden wird dies

anhand von Beispielen kurz erläutert. Eine genaue Betrachtung dieser Effekte

wird zum Beispiel in [Sudm04] (Seiten 17-24) oder [WeisDis] durchgeführt.

3.3.1 Geometrische Effekte

Betrachtet man eine Szene bestehend aus Objekten mit hoher Geschwindigkeit

zum Beobachter, so wirken sich die Veränderungen der Länge, die sogenannte

Längenkontraktion (vgl. [Sudm04], Seiten 10,11,17), aus. Dies führt dazu, dass

die Geometrie der Objekte verzerrt zu sehen ist.

Neben der Längenkontraktion muss bei hohen Geschwindigkeiten zudem berücksichtigt

werden, dass Licht nicht umgehend beim Beobachter eintrifft, sondern

eine bestimmte Zeit braucht, um die Strecke vom Objekt bis zum Beobachter

zurückzulegen. Dies führt dazu, dass der Beobachter Licht von verschiedenen

Aussendungszeitpunkten empfängt (vgl. [Sudm04], Seiten 17-18) . Dieser Effekt

der endlichen Lichtlaufzeit bewirkt ebenfalls geometrische Verzerrungen.

In Abbildung (4) sind die Auswirkungen der geometrischen Effekte dargestellt.

Abbildung (4a) zeigt die Szene in Ruhe, während sich das Hochregal in Ab-

12


a) b)

c)

Abbildung 4: Auswirkungen der Geometrischen Effekte

bildung (4b) mit 99 Prozent der Lichtgeschwindigkeit auf den Beobachter zu

bewegt.

Eine gute Darstellung der Auswirkungen von der Kombination aus endlicher

Lichtlaufzeit und Längenkontraktion ist in Abbildung (4c) zu erkennen. Ein

Raumschiff fliegt mit 95 Prozent der Lichtgeschwindigkeit, während alle anderen

Raumschiffe in Ruhe sind. Obwohl alle Raumschiffe in die gleiche Richtung

ausgerichtet sind, erscheint das bewegte Raumschiff gedreht.

3.3.2 Doppler- und Suchscheinwerfereffekt

Neben den oben erwähnten geometrischen Effekten bei Objekten mit hoher

Geschwindigkeit ergeben sich zudem Veränderungen der Farben (genauer: der

Wellenlängen des emittierten Lichtes) und der Helligkeitsintensität.

Die Veränderung der Farbe ist Folge des relativistischen Doppler-Effektes. Dieser

Effekt ist verwandt mit dem Doppler-Effekt aus der Akustik, der eine Frequenzveränderung

zur Folge hat. So nimmt ein Beobachter eine höhere Tonhöhe

wahr, wenn sich beispielsweise ein Martinshorn nähert. Entfernt sich dieses Martinshorn

vom Beobachter, so sinkt die Tonhöhe aus der Sicht des Beobachters.

Dieser Effekt lässt sich auf Licht übertragen. Interpretiert man Licht als Welle,

13


a) b) c)

Abbildung 5: Auswirkungen des Doppler- und Suchscheinwerfereffektes

[WeisDis]

so entspricht die Farbe einer bestimmten Frequenz. Relativ zu einem Beobachter

bewegte Objekte senden somit, aus der Sicht des Beobachters, Licht mit

einer anderen Frequenz aus, als wenn dieselben Objekte relativ zum Beobachter

ruhen würden (vgl. [Sudm04], Seiten 19 und 20).

Die Veränderung der Helligkeitsintensität ist Folge der sogenannten relativistischen

Aberration des Lichtes. Bei hohen Geschwindigkeiten erscheint das Licht

für den Beobachter abgelenkt. Das Licht wird aus der jeweiligen Bewegungsrichtung

kommend wahrgenommen. Im Extremfall, nämlich gerade bei Lichtgeschwindigkeit,

scheint das Licht nur noch von einem Punkt zu kommen. Die

Folge dieser Ablenkung ist eine Zunnahme der Helligkeitsintensität in Bewegungsrichtung,

da aus Sicht des Beobachters von dort mehr Licht eintrifft (vgl.

[Sudm04], Seite 21). Dieser Effekt ähnelt der Beleuchtung mit einem Suchscheinwerfer

und wird daher als Suchscheinwerfereffekt bezeichnet.

In Abbildung (5) sind die Auswirkungen des Doppler- und Suchscheinwerfereffektes

dargestellt. Abbildung (5a) zeigt die Szene relativ zum Beobachter in

Ruhe, während sich der Beobachter in Abbildung (5b und 5c) mit 90 Prozent

der Lichtgeschwindigkeit auf die Szene zu bewegt.

In Abbildung (5b) sind zunächst nur die Auswirkungen des Doppler-Effektes

zu sehen. Hier ist besonders gut zu erkennen, dass sich die Farbe der Szene zu

blauen Farbwerten verschiebt. Würde der Beobachter sich von der Szene weg

bewegen, ergäbe sich eine Verschiebung ins Rote.

Fügt man den Suchscheinwerfereffekt hinzu, so erhält man die Darstellung in

Abbildung (5c). Während der Rand des Bildes dunkel ist, lässt sich zur Mitte

eine Helligkeitszunahme verzeichnen.

14


4 Aktueller Forschungsstand und Ziele der Arbeit

Nach den technischen und physikalischen Grundlagen werden in diesem Kapitel

die Ziele dieser Arbeit formuliert. Um diese Arbeit von vorangegangenen Arbeiten

abzuheben, wird in diesem Kapitel auch der aktuelle Stand der Forschung

dargestellt.

Die Anfänge der Visualisierung von relativistischen Szenen sind bereits Anfang

bis Mitte des 20. Jahrhunderts zu finden. Allerdings beschränkten sich diese

Darstellungen meist auf einzelne Spezialfälle. Erst mit Hilfe des Computers

wurde es möglich, vollständige Szenen bei hohen Geschwindigkeiten darzustellen.

Dies wurde vor allem mit Hilfe von relativistischen Ray-Tracing Systemen

durchgeführt (siehe [Sudm04], Seiten 28-32 oder [WeisDis], Seiten 27-29 oder

[Hsiung89]). Ein großer Nachteil des Ray-Tracing ist jedoch, dass es mit sehr

hohem Rechenaufwand verbunden ist und daher höchstens auf großen Spezialrechnern

in Echtzeit realisierbar ist.

Mit dem Aufkommen leistungsstarker und gleichzeitig preiswerter Grafikhardware

in den letzten Jahren haben sich jedoch neue Möglichkeiten für die Darstellung

der Speziellen Relativitätstheorie ergeben. So ist es nun möglich, relativistische

Szenen in Echtzeit darzustellen. In der Regel lassen sich diese Systeme

auf zwei Ansätze zurückführen: Dem von Hsiung, Thibadeau und Wu entwickelten

T-Buffer Algorithmus (siehe [Hsiung90]) oder dem von Weiskopf

entwickelten bildbasierten Ansatz (siehe [WeisImg00] und vgl. [WeisTex99]). In

dieser Arbeit wird der T-Buffer Algorithmus verwendet (siehe Kapitel 5.1).

Ein weiterer Entwicklungsschritt vollzieht sich derzeit mit dem Entstehen der

programmierbaren Grafikhardware. Während die ersten Implementierungen des

T-Buffer Algorithmus einen Großteil der Berechnungen auf der CPU durchgeführt

haben, ist es nun möglich, rechenaufwändigen Anteile des Algorithmus

an die Grafikhardware zu delegieren (siehe Kapitel 6.2.1). Neben einer Entlastung

der CPU verspricht man sich durch diese Verlagerung vor allem einen

Performancegewinn. Dies zu belegen, ist ein wichtiges Ziel dieser Arbeit.

Während alle in dieser Arbeit betrachteten Softwaresysteme zur interaktiven

Visualisierung der Speziellen Relativitätstheorie nur statische Szenen darstellen

können, ist das zweite Ziel dieser Arbeit die Entwicklung eines Softwaresystems,

das auch die Darstellung dynamischer Szenen ermöglicht. Im folgenden werden

die Begriffe statisch und dynamisch anhand der verschiedenen Softwaresysteme

genauer beschrieben.

4.1 Relativistisches Walkthrough in statischen Szenen

Beim relativistischen Walkthrough in statischen Szenen werden solche Szenen

relativistisch dargestellt, die selbst zwar keine Bewegung beinhalten, aber durchaus

einen bewegten Beobachter haben können.

Um einen Überblick über den Umfang und die Leistungsfähigkeit aktueller Visualisierungen

für die spezielle Relativitätstheorie zu erhalten, werden nun drei

Softwaresysteme vorgestellt, die statische Szenen in Echtzeit relativistisch visualisieren

können.

15


4.1.1 Der ”

Viewer“

Das Schlankeste der drei Systeme ist das von Axel Niese, Gernot Saul und

Martin Schrodt entwickelte Programm ”

Viewer“, welches unter der Anleitung

von Daniel Weiskopf in einem Softwaretechnik-Praktikum entstanden ist.

Mit dem auf XML basierenden Dateiformat lassen sich Szenen, bestehend aus

verschiedenen geometrischen Formen (z.B. Kugeln, Flächen, Zylinder), beschreiben.

Diese Szenen werden mit Hilfe eines Vertex Shader Programmes, welches

den T-Buffer Algorithmus implementiert, durch den ”

Viewer“ für eine bestimmte

Geschwindigkeit dargestellt. Auf diese Weise können mit dem Programm die

geometrischen Effekte der Speziellen Relativitätstheorie visualisiert werden. Mit

Hilfe einer Maussteuerung lässt sich die Position und die Blickrichtung des Beobachters

variieren. Eine wirklichkeitsnahe Steuerung ist in diesem Programm

jedoch nicht vorgesehen (vgl. Kapitel 4.2.1).

Abbildung 6: Kristallstruktur visualisiert mit dem ”

Viewer“

Der ”

Viewer“ eignet sich besonders gut zur Darstellung von Kristallstrukturen

bei hohen Geschwindigkeiten. Ein Beispiel hierfür findet sich in Abbildung (6).

Die linke Abbildung zeigt die Szene in Ruhe und die rechte Abbildung zeigt

die Auswirkungen der geometrischen Effekte in dieser Szene bei 90 Prozent der

Lichtgeschwindigkeit.

4.1.2 Die Software ”

Virtual Relativity“

Das von Daniel Weiskopf entwickelte Programm ”

Virtual Relativity“ stellt

die Referenzsoftware zu dem in dieser Arbeit entwickeltem System dar. Das in

[WeisVis97] beschriebene System visualisiert zunächst nur die geometrischen Effekte

der Speziellen Relativitätstheorie. Das Besondere von ”

Virtual Relativity“

besteht in der Erweiterung des T-Buffer Algorithmus um einen beschleunigten

Beobachter. Dies ist die Vorraussetzung, um wirklichkeitsnah durch die Szene

navigieren zu können.

Die Steuerung basiert auf der Vorstellung eines virtuellen Raumfahrzeuges. Es

lässt sich daher sowohl das Raumfahrzeug als auch die Blickrichtung des Beobachters

in dem Raumfahrzeug mit Hilfe der Maus steuern. Das Raumfahrzeug

16


kann beschleunigt und abgebremst werden. Um die Flugrichtung festzulegen,

können Kurven geflogen werden.

Abbildung 7: Szene visualisiert mit ”

Virtual Relativity“

Durch die Verwendung von VRML 1.0 als Szenendateiformat wird ”

Virtual Relativity“

nicht nur kompatibler zu gängigen Modellierungstools für dreidimensionale

Modelle, sondern auch sehr viel flexibler als der oben vorgestellte ”

Viewer“.

Dies zeigt auch die Beispielszene in Abbildung (7), die mit Hilfe von ”

Virtual

Relativity“ ein komplettes Haus bei 95 Prozent der Lichtgeschwindigkeit aus

verschiednenen Blickwinkeln visualisiert.

Obwohl die Szene 262 604 Dreiecke beinhaltet, lässt sich noch in Echtzeit durch

die Szene navigieren. Dies unterstreicht erneut die Leistungsfähigkeit des T-

Buffer Algorithmus.

4.1.3 Das ”

relativistische“ Fahrrad

Die aktuellste Umsetzung für eine interaktive Visualisierung der Speziellen Relativitätstheorie

ist das sogenannte ”

relativistische“ Fahrrad, das derzeit in verschiedenen

Museen im Rahmen des Einstein Jahres 2005 von jedem Besucher

ausprobiert werden kann. Den Namen hat das ”

relativistische“ Fahrrad aufgrund

seiner außergewöhnlichen Steuerung, die mit Hilfe eines Trimmrades erfolgt.

Im Gegensatz zu den zuvor vorgestellten Systemen, basiert dieses System nicht

auf dem T-Buffer Algorithmus, sondern arbeitet nach dem oben erwähnten bildbasierten

Prinzip. Für das bildbasierte Verfahren wird eine komplette Rundumsicht

aus Sicht eines ruhenden Beobachters benötigt. Diese Ansicht entspricht

aber gerade einer Rundumsicht, die sich aus einem klassischen Renderingprozess

ergibt. Um diese Rundumsicht zu erzeugen, kann man eine sogenannte Cubemap

generieren. Dazu wird die Szene aus der Sicht des Beobachters in sechs

Richtungen, die den Normalen der Seiten eines virtuellen Würfels entsprechen,

gerendert. Die auf diese Weise erzeugte Rundumsicht kann als Eingabe für ein

bildbasiertes Verfahren dienen, wie es in [WeisImg00] beschrieben ist.

Nach [BorKra05] kann das sechsfache Rendern zum Erzeugen der Cubemap

und die nötigen Rechnungen für die Erzeugung der relativistischen Ansicht auf

einem einzelnen High-End Rechner in Echtzeit ausgeführt werden.

17


Der Vorteil eines solchen Systems ist, dass sich der Doppler- und der Suchscheinwerfereffekt

leicht integrieren lassen. Daher werden, neben den geometrischen

Effekten, auch diese Effekte mit dem ”

relativistischen“ Fahrrad sichtbar gemacht

(vgl. Abb. 8c).

a) b) c)

Abbildung 8: Fahrt mit dem ”

relativistischen“ Fahrrad [BorKra05]

In Abbildung (8) sind verschiedene Darstellungen aus [BorKra05] zusammengefasst

und geben nochmals einen Überblick über die visualisierten Effekte.

In Abbildung (8a) ist die Szene in Ruhe dargestellt, während in Abbildung (8b)

und Abbildung (8c) der Beobachter mit 95 Prozent der Lichtgeschwindigkeit

auf die Szene zu bewegt wird. Die geometrischen Effekte sind besonders gut

in Abbildung (8b) zu erkennen. Abbildung (8c) zeigt alle erwähnten Effekte.

Besonders gut ist hier der Suchscheinwerfereffekt zu erkennen, der durch die

Helligkeitskonzentration in Bewegungsrichtung die Farbverschiebung des relativistischen

Dopplereffektes und die geometrischen Verzerrungen nur erahnen

lässt.

4.2 Relativistisches Walkthrough in dynamischen Szenen

Im vorangegangenen Teil wurden verschiedene Softwaresysteme vorgestellt, die

in der Lage sind, statische Szenen aus der Sicht eines Beobachters relativistisch

darzustellen. Ziel dieser Arbeit ist es nun, ein System zu entwickeln, welches

auch dynamische Szenen relativistisch darstellen kann. Unter dynamischen Szenen

sind solche Szenen zu verstehen, die aus verschiedenen, unabhängig voneinander

bewegten Objekten bestehen. 3

Ein Beispiel für eine dynamische Szene ist bereits in Kapitel 3.3 in Abbildung

(4c) zu sehen. Ein Teil der Raumschiffe ist in Ruhe, während ein Raumschiff

an ihnen vorbei fliegt. In dieser Beispielszene ist deutlich der Vorteil der Visualisierung

von dynamischen Szenen zu erkennen: Erst durch Objekte mit unterschiedlichen

Geschwindigkeiten wird der Effekt der Drehung durch Lichtlaufzeit

und Lorentzkontraktion wirklich deutlich.

Obwohl der erwähnte bildbasierte Ansatz die Möglichkeit besitzt, den Dopplerund

den Suchscheinwerfereffekt zusätzlich neben den geometrischen Effekten

darzustellen, wird für diese Arbeit der T-Buffer Algorithmus verwendet. Dies

3 Statische Szenen sind somit ein Spezialfall von dynamischen Szenen, die aus nur einem

bewegten Objekt bestehen.

18


hängt vor allem damit zusammen, dass es nur schwer oder sogar unmöglich ist,

dynamische Szenen mit einem bildbasierten Verfahren umzusetzen. Der Grund

hierfür ist vor allem in den unterschiedlichen Eingabedaten zu suchen. Während

beim bildbasierten Verfahren das einfallende Licht für einen Beobachter

als Eingabe dient, werden dem T-Buffer Algorithmus die kompletten dreidimensionalen

Szenendaten zur Verfügung gestellt. Um jedoch dynamische Szenen

darstellen zu können, muss bei Bildpunkten von Objekten mit unterschiedlichen

Geschwindigkeiten ermittelt werden, welcher Bildpunkt angezeigt wird und welcher

verdeckt wird. Dies ist jedoch nur entscheidbar, wenn Informationen über

die Geometrie der Szene vorliegen. Das ist für den bildbasierten Ansatz jedoch

nicht der Fall. Die Folge der Entscheidung für den T-Buffer Algorithmus ist

jedoch, dass der Doppler- und der Suchscheinwerfereffekt deutlich aufwändiger

umzusetzen sind und daher in dieser Arbeit zunächst nicht betrachtet werden.

Damit auch in großen Szenen die Navigation in Echtzeit möglich ist, werden die

relativistischen Transformationen mit Hilfe programmierbarer Grafikhardware

durchgeführt. Dies setzt voraus, dass der dafür verwendete Algorithmus auf der

Grafikhardware effizient umsetzbar ist. Ein weiteres Ziel dieser Arbeit ist daher

zum einen die Realisierbarkeit des Systems mit Hilfe programmierbarer Grafikhardware,

und zum anderen der experimentelle Beleg, dass die Verlagerung der

Transformationen auf die Grafikhardware einen Performancevorteil gegenüber

der Berechnung auf der CPU mit sich bringt.

4.2.1 Steuerung in interaktiven, relativistischen Szenen

Für eine interaktive Visualisierung der Speziellen Relativitätstheorie müssen

neben Methoden zur Darstellung relativistischer Szenen auch Methoden zur

Bewegung in relativistischen Szenen entwickelt werden. Dies führt zu der Frage

nach einer für den Benutzer sinnvollen Steuerung. Obwohl das Hauptaugenmerk

dieser Arbeit auf der Visualisierung liegt, wird diese Frage speziell im

Hinblick auf die Erfahrbarkeit der Speziellen Relativitätstheorie im Folgenden

kurz erörtert.

Die besondere Herausforderung bei der Modellierung einer Steuerung für eine

interaktive Visualisierung der Speziellen Relativitätstheorie besteht sowohl darin,

eine ebenso wirklichkeitsnahe und damit auf physikalischen Grundlagen basierende

Steuerung zu modellieren, als auch eine benutzerfreundliche Steuerung

zu entwickeln. In dieser Arbeit wird daher als Modellvorstellung ein virtuelles

Raumfahrzeug verwendet, das durch verschiedene Steuerdüsen in unterschiedliche

Richtungen beschleunigt werden kann (vgl. auch [WeisVirt00] Kapitel 6).

Prinzipiell genügt dieses Modell für eine physikalisch modellierte Steuerung.

Für den Benutzer ist diese Art der Steuerung jedoch sehr schwer zu handhaben,

da insbesondere bei Richtungsänderungen in verschiedene Richtungen unterschiedlich

stark beschleunigt werden muss. Derartige Steuerungen sind sogar

im nicht-relativistischen Fall so schwer zu handhaben, dass sie in den Spielen

” Asteroids“ und Lunar Lander“ die besondere Schwierigkeit ausmachen.


Um eine möglichst benutzerfreundliche und einfache Steuerung zu erhalten,

wird dem Benutzer daher gleichzeitig ermöglicht, die aktuelle Flugrichtung mit

Hilfe der Maus zu bestimmen. Dabei dient die jeweilige Blickrichtung als neue

19


Flugrichtung des virtuellen Raumfahrzeuges. Aus physikalischer Sicht ist eine

derartige Steuerung eine starke Näherung, die jedoch aus der Sicht der Informatik,

im Hinblick auf die Benutzerfreundlichkeit, durchaus vertretbar ist.

Ähnlich wie die Position oder die Geschwindigkeit, hängt auch der Wert der bei

der Steuerung eingegebenen Beschleunigung vom Bezugssystemen ab. Da der

Benutzer seine Steuerungseingaben aus seiner Sicht und somit aus der Sicht des

Beobachters eingeben wird, sind alle Eingaben zunächst in Bezug zum Ruhesystem

des Beobachters zu verstehen. An dieser Stelle lässt sich bereits erahnen,

dass die Umsetzung der Beschleunigung für die Steuerung im relativistischen

Fall nicht so trivial ist wie im nicht-relativitischen Fall. Deshalb wird in Kapitel

5.2 auf die Thematik der Beschleunigung des Beobachters genauer eingegangen.

20


5 Relativistisches Polygonrendering in dynamischen

Szenen

In diesem Kapitel wird eine Methode beschrieben, mit der die geometrischen

Effekte der Speziellen Relativitätstheorie für mehrere unabhängige, gleichförmig

bewegte Objekte in Echtzeit visualisiert werden können. Dazu wird zunächst

der von Hsiung, Thibadeau und Wu entwickelten T-Buffer Algorithmus im

Hinblick auf die Visualisierung mehrerer unabhängiger, gleichförmig bewegter

Objekte, näher erläutert. Anschließend wird in Anlehnung an [WeisVis97] und

[WeisVirt00] beschrieben, wie sich ein beschleunigter Beobachter in statische

Szenen integrieren lässt.

Auf der Basis des T-Buffer Algorithmus und der Verfahren in [WeisVis97] und

in [WeisVirt00] wird am Ende ein neues Verfahren für die Visualisierung dynamischer

Szenen mit mehreren unabhängigen, gleichförmig bewegten Objekten

und einem beschleunigten Beobachter vorgestellt.

5.1 Der T-Buffer Algorithmus

Der T-Buffer Algorithmus ist ein Verfahren für die Visualisierung der geometrischen

Effekte der Speziellen Relativitätstheorie. Wie in [WeisVis97] beschrieben

ist, lässt sich der in [Hsiung90] ursprünglich als Ray Tracing Verfahren entwickelte

T-Buffer Algorithmus leicht in ein echtzeitfähiges Polygonrendering Verfahren

abändern. Hierzu werden die darzustellenden dreidimensionalen Objekte

durch Polygone angenähert. Bei der relativistischen Visualisierung werden dann

nur die Eckpunkte (Vertizes) der Polygone betrachtet und nicht wie beim Ray

Tracing Verfahren alle Punkte. Alle anderen dargestellten Punkte der Objekte

werden zwischen den Eckpunkten interpoliert und sind somit nur annähernd

relativistisch korrekt. 4

In der ursprünglichen, von Hsiung, Thibadeau und Wu vorgeschlagenen Variante

des T-Buffer Algorithmus, entscheidet der sogennante T-Buffer, ob ein

Bildpunkt von einem anderen verdeckt wird. Dabei wird, in Analogie zum Z-

Buffer, im T-Buffer der Zeitpunkt der Lichtaussendung des Bildpunktes gespeichert.

Nach [WeisVirt00] lässt sich der T-Buffer auf heutiger Grafikhardware

mit Hilfe des normalen Z-Buffers realisieren.

Im Folgenden werden nun die für diese Arbeit wichtigen Teile des T-Buffer

Algorithmus eingeführt. Zunächst wird der Algorithmus für statische Szenen

beschrieben und danach auf dynamische Szenen mit unabhängigen, gleichförmig

bewegten Objekten erweitert. Eine umfassende Beschreibung des T-Buffer

Algorithmus ist in [Hsiung90] zu finden.

5.1.1 Statische Szenen mit dem T-Buffer Algorithmus

Eine statische Szene lässt sich in zwei, zueinander relativ bewegte, Objekte unterteilen:

Eine Kamera, mit der die Szene betrachtet wird und die Szene selbst.

4 Der Begriff T-Buffer Algorithmus bezeichnet im Folgenden genau dieses zum klassischen

Polygon Rendering kompatible Näherungsverfahren und nicht das Ray Tracing Verfahren.

21


Für den T-Buffer Algorithmus werden beide Objekte in ihrem Ruhesystem beschrieben.

In den folgenden Ausführungen werden daher zwei Bezugssysteme

betrachtet, die sich relativ zueinander mit der Geschwindigkeit ⃗v bewegen: Das

Kamerabezugssystem K und das Szenenbezugssystem S. Damit die Allgemeine

Lorentz-Transformation aus Gl. (1) anwendbar ist, werden die Bezugssysteme

K und S derart definiert, dass sie sich zum Zeitpunkt t K = t S = 0 im Ursprung

treffen.

ct

S

ct

K

Weltlinie eines Vertex

der Szene

Bilderzeugung (e Kamera )

Lichtkegel

x

x

K

S

K (Kamera)

S (Szene)

Aussendung des Lichtes

zur Kamera (e )

Aussendung

Abbildung 9: Ausgangssituation für die Darstellung einer statischen Szene

Bei der Erzeugung eines Bildes werden die bei der Kamera eintreffenden Lichtsignale

zu einem Bild zusammengefügt. Die Lichtsignale brauchen aufgrund der

endlichen Lichtlaufzeit eine bestimmte Zeit ∆t, um vom Ort ihrer Aussendung

bis zur Kamera zu gelangen. Diese Zeit ∆t ergibt sich aus der Lichtgeschwindigkeit

c und der Entfernung ∆s zwischen der Position der Kamera und der

Position der Signalaussendung:

∆s = c∆t (5)

Da sich die Szene relativ zur Kamera bewegt, ändert sich die Position für die

Signalaussendung ständig. Für die Darstellung der Szene muss daher für jeden

darzustellenden Punkt (Vertex) der Szene die Position des Punktes ermittelt

werden, von der ein Lichtsignal gerade soviel Zeit benötigt, dass es zum Zeitpunkt

der Bilderzeugung bei der Kamera angekommen ist.

Dieser Zusammenhang ist in Abbildung (9) illustriert. Es ist zu erkennen, dass

sich das Aussendungsereignis e Aussendung für ein Lichtsignal aus dem Schnittpunkt

des Lichtkegels des Bilderzeugungsereignises e Kamera mit der Weltlinie

des darzustellenden Objektpunktes (Vertex) der Szene ergibt. Mathematisch

lässt sich die Berechnung des Schnittpunktes wie folgt erfassen:

22


Das Bilderzeugungsereignis e Kamera(K) wird im Kameraruhesystem K durch die

Position P Kamera(K) = (x Kamera(K) , y Kamera(K) , z Kamera(K) ) T der Kamera und den

Zeitpunkt t Bilderzeugung beschrieben:

e Kamera(K) =





x Kamera(K)

y Kamera(K)

z Kamera(K)

t Bilderzeugung(K)


⎠ (6)

Mit Hilfe der Allgemeinen Lorentz-Transformation aus Gl. (1) lässt sich das

Bilderzeugungsereignis e Kamera(K) in das Szenenruhesystem S überführen:

e Kamera(S) = L KS · e Kamera(K) =





x Kamera(S)

y Kamera(S)

z Kamera(S)

t Bilderzeugung(S)


⎠ (7)

Im Szenenruhesystem lässt sich die Berechnung des Schnittpunktes besonders

einfach durchführen. Da das Bilderzeugungsereignis e Kamera(S) bekannt ist und

die Position der Objektpunkte (Vertizes) im Szeneruhesystem S immer gleich

ist, bleibt als einzige Unbekannte der Zeitpunkt der Lichtaussendung t Aussendung(S) .

Es ergibt sich daher folgender Zusammenhang:


(x Kamera(S) − x Vertex(S) ) 2 + (y Kamera(S) − y Vertex(S) ) 2 + (z Kamera(S) − z Vertex(S) ) 2

} {{ }

Entfernung zwischen Kamera und Vertex

(8)

= |c (t Bilderzeugung(S) − t Aussendung(S) ) |

} {{ }

Zeit des Lichtes

Durch Umformung und Normierung der Lichtgeschwindigkeit auf c = 1 m s erhält

man den Aussendungszeitpunkt des Lichtsignals t Aussendung(S) :


t Aussendung(S) = t Kamera(S) − (x Kamera(S) − x Vertex(S) ) 2 . . . (9)

Zusammen mit der Position des Vertex lässt sich nun das Aussendungsereignis

e Aussendung(S) im Szenenruhesystem definieren:

e Aussendung(S) =





x Vertex(S)

y Vertex(S)

z Vertex(S)

t Aussendung(S)


⎠ (10)

Für die Darstellung des Objektpunktes (Vertex) muss das Aussendungsereignis

nun noch zurück in das Kameraruhesystem transformiert werden. Dazu kann

ebenfalls die Allgemeine Lorentz-Transformation aus Gl. (1) verwendet werden.

Allerdings ist zu beachten, dass sich die Richtung der Geschwindigkeit ⃗v

23


ei dieser Rücktransformation gerade umkehren muss. Man erhält dann das

Aussendungsereignis e Aussendung(K) im Kameraruhesystem:

e Aussendung(K) = L SK · e Aussendung(S) (11)

Zur endgültigen Darstellung des Objektpunktes können nun die Ortskoordinaten

des Aussendungsereignisses e Aussendung(K) als Eingabe für ein klassisches

Polygon-Rendering Verfahren verwendet werden. Ein spezielles relativistisches

Hidden-Surface Removal Verfahren ist nicht notwendig. Dieser Schritt lässt sich

nach [WeisVirt00] mit Hilfe des klassischen Z-Buffer Algorithmus durchführen.

Somit erweitert der T-Buffer Algorithmus die klassische Rendering Pipeline um

eine relativistische Stufe.

5.1.2 Dynamische Szenen mit dem T-Buffer Algorithmus

Das Prinzip des T-Buffer Algorithmus lässt sich sehr leicht für dynamische

Szenen mit unabhängig, gleichförmig bewegten Objekten anpassen, wie bereits

in [Hsiung90] angedeutet wird. Im folgenden sollen die nötigen Modifikationen

näher erläutert werden.

ct

a) b)

K

ct

ct ct

K

v 1

O 1

1

ct O2

O (Objekt 1)

O 1

1

v 1

v 2

O (Objekt 2)

x O 2

2

O 1

x

(Objekt 1)

O

x K (Kamera)

K

ct

K

x

x

O

K

1

K (Kamera)

v 2 O 2(Objekt 2)

x O 2

ct O2

K (Kamera)

x

K

Abbildung 10: Dynamische Szenen und der T-Buffer Algorithmus

Der Unterschied zwischen einer statischen Szene und einer dynamischen Szene

besteht darin, dass in dynamischen Szenen Objekte mit unterschiedlichen

Geschwindigkeiten auftreten können. Diese Objekte haben somit jedoch auch

verschiedene Ruhesysteme. Insgesamt ergibt sich damit eine Situation wie in

Abbildung (10a) gezeigt: Ein Kameraruhesystem und eine Menge von Objektruhesystemen,

die sich zueinander mit verschiedenen Geschwindigkeiten bewegen.

Auf diese Situation ist der oben beschriebene T-Buffer Algorithmus zunächst

nicht anwendbar. Betrachtet man jedoch die Objektruhesystem einzeln zum

Kameraruhesystem, so ergibt sich dieselbe Ausgangssituation wie bei einer statischen

Szene (siehe Abb. (10b)). Werden alle sich aus den Objekten ergebenden,

statischen Szenen in ein und dasselbe Bild projiziert, ergibt sich eine relativistische

Darstellung der dynamischen Szene.

24


5.2 Beschleunigter Beobachter in relativistischen Szenen

Um eine wirklichkeitsnahe Steuerung, wie sie in Kapitel 4.2.1 beschrieben ist, zu

ermöglichen, muss auf der Basis der Speziellen Relativitätstheorie eine beschleunigte

Bewegung simuliert werden. Die Simulation einer beschleunigten Bewegung

für ein virtuelles Raumfahrzeug, das vom Benutzer gesteuert wird, entspricht

der Darstellung relativistischer Szenen mit einem beschleunigten Beobachter.

In [WeisVis97] und in [WeisVirt00] sind Methoden für die Visualisierung

derartiger Szenen beschrieben. In den folgenden Ausführungen werden zunächst

die für diese Arbeit wichtigsten Probleme und Methoden aus [WeisVis97] und

aus [WeisVirt00] zusammengefasst dargestellt, um die Verfahrensweisen anschliessend

auf dynamische Szenen mit beschleunigtem Beobachter zu übertragen.

5.2.1 Beschleunigter Beobachter und statische Szenen

ct

S

ct S

Trans

Weltlinie eines

Vertex der Szene

ct K

x K

K

Nächstes

Bilderzeugungsereignis

Weltlinie des

Beobachters

S

x STrans

Trans

Letztes

Bilderzeugungsereignis

Lichtsignal

x

S

S

Aussendungsereignis

Abbildung 11: Beschleunigter Beobachter in statischen Szenen

Für die Darstellung der Sicht eines beschleunigten Beobachters in statischen

Szenen wird in [WeisVis97] und in [WeisVirt00] die Weltlinie des Beobachters

in das Szenenruhesystem projiziert (vgl. Abb. 11). Auf der Basis dieser Weltlinie

kann dann mit dem T-Buffer Algorithmus die Szene dargestellt werden (vgl.

Abb. 11).

Der erste Schritt besteht somit darin, die Weltlinie des Beobachters zu berechnen.

Wie jedoch in Kapitel 4.2.1 bereits angedeutet, ist die Berechnung einer

beschleunigten Bewegung im relativistischen Fall nicht so einfach wie im klassischen,

nicht-relativistischen Fall. Dies hängt vor allem mit der Veränderbarkeit

der Grundgrößen, wie Raum und Zeit, zwischen den verschiedenen Bezugssystemen

zusammen. Zum besseren Verständnis dieses Problems wird nun kurz

auf die physikalische Definition der Beschleunigung eingegangen. Hierzu wird

25


zunächst der klassische, nicht-relativistische Fall erläutert und danach der relativistische

Fall.

In der klassischen Physik ist die Beschleunigung a definiert durch:

a =··s= d2 s

dt 2 (12)

wobei s : Strecke ; t : Zeit

Aus Gl. (12) ist ersichtlich, dass, im klassischen Fall, für die Berechnung der

zurückgelegten Wegstrecke s in der Zeit t eine zweifache Integration genügt:

s = 1 2 · a · t2 (13)

Im relativistischen Fall ist die Gleichung für die Beschleunigung ähnlich. Allerdings

muss dem Umstand Rechnung getragen werden, dass die Zeit t abhängig

vom jeweiligen Bezugssystem dargestellt werden muss. Es gilt daher:

wobei dτ =

dt

γ(v(t))

a =··s= d2 s

dτ 2 (14)

: Eigenzeit ; v = ·s=

ds

dτ : Geschwindigkeit

An dieser Stelle ist ersichtlich, dass es im Gegensatz zur klassischen Gl. (12)

eine Kopplung zwischen der momentanen Geschwindigkeit v, der Eigenzeit τ

und der Beschleunigung a gibt. Da es sich bei der Beschleunigung a und der

Geschwindigkeit v im Grunde um Ableitungen des Weges s nach der Eigenzeit

τ handelt, ergibt sich ein gekoppeltes differentielles Gleichungssystem (DFG),

welches gelöst werden muss, um den zurückgelegten Weg (bzw. die Weltlinie für

das beschleunigte Objekt) zu berechnen.

Für die Berechnung der Beobachterweltlinie werden in [WeisVis97] und in [WeisVirt00]

zur Lösung des DFG Eulers-Methode und das Runge-Kutta Verfahren angegeben.

Bei beiden Methoden handelt es sich um numerische Verfahren, mit denen

die Weltlinie angenähert werden kann. 5

Auf der Basis der oben genannten Verfahren zur Berechnung der Weltlinie eines

beschleunigten Beobachters wird nun der Ablauf für die Darstellung eines

beschleunigten Beobachters in relativistischen, statischen Szenen eingeführt.

Bevor der T-Buffer Algorithmus angewendet werden kann, muss zunächst das

Bilderzeugungsereignis und die aktuelle Geschwindigkeit des Beobachters (bzw.

der Kamera) ermittelt werden. Das Bilderzeugungsereignis ergibt sich aus dem

Zeitpunkt der Bilderzeugung und der Position des Beobachters (bzw. der Kamera).

Der Zeitpunkt des nächsten Bilderzeugungsereignis und des letzten Bilderzeugungsereignis

stehen aus der Sicht des Beobachters fest (vgl. Abb. 11). Die

Position des Beobachters ergibt sich aus dem Verlauf der Weltlinie. Die Weltlinie

muss daher, nach den oben vorgestellten Methoden, für die vom Benutzer

5 Die Software zu dieser Arbeit verwendet das Runge-Kutta Verfahren 4.Ordnung.

26


eingegebenen Beschleunigung ⃗a und der Zeit ∆t (K) , des Zeitintervalls zwischen

dem letzten und dem folgenden Bilderzeugungsereignis, in das Szenenruhesystem

projiziert werden. Neben dem nächsten Bilderzeugungsereignis lässt sich

auch die Geschwindigkeit zwischen Szenenruhesystem und Kamerasystem in

dieser Phase berechnen.

Steht die Position und Geschwindigkeit des Beobachters im Szenenruhesystem

fest, kann die Szene mit Hilfe des T-Buffer Algorithmus dargestellt werden.

Dazu muss jedoch zunächst die Kameraposition im Kameraruhesystem definiert

sein. Zudem müssen sich Kameraruhesystem und Szenenruhesystem zum

Zeitpunkt t K = t S = 0 im Ursprung treffen, so dass Gl. 1 Gültigkeit erlangt.

Wie in Abbildung (11) gezeigt, lassen sich beide Bedingungen erfüllen, indem

zunächst die Kameraposition auf den Ursprung des Kameraruhesystem festgelegt

wird und der Zeitpunkt der Bilderzeugung im Kameraruhesystem auf

t K = 0 gelegt wird. Der Ursprung des Kameraruhesystems befindet sich dann

genau an der errechneten Kameraposition. Wird nun das Szenenruhesystem S

auf diesen Punkt verschoben, sind die Ursprünge beider Systeme (K und S Trans )

zum Zeitpunkt t K = t S = 0 gleich und die Allgemeine Lorentz-Transformation

gilt.

5.2.2 Beschleunigter Beobachter und dynamische Szenen

Bei der Erweiterung des T-Buffer Algorithmus auf dynamische Szenen, war das

Hauptprobleme durch die unabhängig bewegten Objekte gegeben. Bei einer Erweiterung

auf dynamische Szenen mit einem beschleunigten Beobachter muss

jedoch zusätzlich berücksichtigt werden, dass die vom Benutzer herbei geführten

Geschwindigkeitsänderungen aus der Sicht der verschiedenen Szenenobjekte

eine ständige Änderung des Kameraruhesystem hervorrufen. Die Probleme für

die Visualisierung eines beschleunigten Beobachters in dynamischen Szenen ergeben

sich also aus einer Kombination der Problemstellung bei der Erweiterung

des T-Buffer Algorithmus auf dynamische Szenen und der Problemstellung bei

der Erweiterung von statischen Szenen um einen beschleunigten Beobachter. Es

liegt daher nahe die Erweiterung auf dynamische Szenen mit einem beschleunigten

Beobachter auf die Lösungsansätze beider Probleme aufzubauen.

Bei der Erweiterung auf einen beschleunigten Beobachter ist der wichtigste Ansatz

die Projektion der Beobachterweltlinie in das Szenenruhesystem. Da es

jedoch im dynamischen Fall kein ausgezeichnetes Szenenruhesystem mehr gibt,

wird ein zusätzliches Bezugssystem G definiert. Ein solches Bezugssystem kann

obendrein dazu genutzt werden, die verschiedenen Geschwindigkeiten der Szenenobjekte

unabhängig vom Kamerabezugssystem zu definieren. In Abbildung

(12) ist zudem gezeigt, dass die verschiedenen Objektruhesysteme zum System

G definiert sind. Das Kamerabezugssystem K kann entsprechend der aktuellen

Kameraposition und Geschwindigkeit an die Beobachterweltlinie angepasst werden.

Das zusätzliche Bezugssystem G dient außerdem dazu, die verschiedenen

Lösungsansätze miteinander zu verknüpfen, wie im Folgenden genauer gezeigt

werden wird. 6

6 Das Bezugssystem G stellt ein Hilfssystem dar, das auf den ersten Blick ein absolutes Bezugssystem

zu sein scheint, da eine Vielzahl der Szenenparameter (Geschwindigkeiten, Welt-

27


ct

G

ct

ct O2

O (Objekt 1)

ct K

x K

K

O 1

1

Weltlinie des

Beobachters

O (Objekt 2)

x O2

2

x

O

1

x

G

G

Abbildung 12: Beschleunigter Beobachter in dynamischen Szenen

Der Ablauf bei der Visualisierung einer dynamischen Szene mit beschleunigtem

Beobachter lässt sich zunächst in zwei grobe Schritte gliedern: Die Projektion

der Weltlinie, wie in Kapitel 5.2.1 beschrieben. Danach die Darstellung mit dem

T-Buffer Algorithmus, wie in Kapitel 5.1.2 beschrieben. Im Detail ergibt sich

dann der in Abbildung 13 angegebene Ablauf. Die Schritte für die Projektion

der Beobachterweltline entsprechen den Schritten aus Kapitel 5.2.1, mit der

Ausnahme, dass die Projektion nicht in das Szenenruhesystem, sondern in das

zusätzliche System G durchgeführt wird.

Da alle Systeme und Geschwindigkeiten zu G definiert sind, müssen noch einige

Berechnungen durchgeführt werden (vgl. Abb. 13), damit die einzelnen

Objekte mit dem T-Buffer Algorithmus dargestellt werden können. Um das

Kameraruhesystem und das Objektruhesystem wie in Kapitel 5.2.1 verarbeiten

zu können, muss zunächst das Bilderzeugungsereignis aus dem System G

in das jeweilige Objektruhesystem transformiert werden. Da die Beziehung zwischen

beiden Systemen bekannt ist, lässt sich dies mit der Allgemeinen Lorentz-

Transformation aus Gl. (1) durchführen. Die beiden folgenden Schritte sind

analog zu den in Kapitel 5.2.1 beschriebenen Schritte.

Für die Darstellung mit Hilfe des T-Buffer Algorithmus müssen nun nur noch

die Lorentz-Transformationen zwischen dem Kameraruhesystem und dem jeweiligen

Objektruhesystem berechnet werden. Da die Geschwindigkeiten alle

relativ zum zusätzlichen Bezugssystem G definiert sind, ergibt sich gerade die

in Kapitel 3.2.1 beschriebene Situation. Die Lorentz-Transformationen zwischen

einem Kameraruhesystem K und einem Objektruhesystem O sind daher gegelinien)

gegenüber G definiert sind. Diese Darstellung der Szenenparameter dient jedoch

nur der besseren Überschaubarkeit, prinzipiell könnte jedes andere Bezugssystem für die

Darstellung dieser Größen herangezogen werden. G ist daher zu allen anderen Systemen

gleichberechtigt und somit kein globales und absolutes Bezugssystem. Auch in der Physik

werden Hilfsysteme, wie G in Form des Sonnensystems oder der Galaxis, häufig verwendet

(vgl. [Giulini05] Seite 31, Fußnote 6).

28


Ermittlung der Zeit t (G)

bis zum nächsten

Bilderzeugungsereignis.

Beschleunigung des Beobachters für Zeit t

zur Berechnung des Bilderzeugungsereignisses e

(G)

Kamera(G).

Für alle unabhängig bewegten Objekte

Transformation von e Kamera(G)

in das

aktuelle Objektruhesystem O.

Definition des Ursprungs vom

Kameraruhesystem K bei e Kamera(G)

.

Translation des Objektruhesystem O,

so dass sich O und K zur Zeit 0

im Ursprung treffen.

Berechnung der Lorentz-Transformationen

L und L .

KO

OK

Projektion des Objektes in das Bild

mit dem T-Buffer Algorithmus.

Abbildung 13: Ablaufdiagramm für die relativistische Darstellung in dynamischen

Szenen mit beschleunigtem Beobachter

ben durch:

L KO = L GO · L KG (15)

L OK = L GK · L OG

Im letzten Schritt kann nun der T-Buffer Algorithmus, wie schon in Kapitel

5.1.2 beschrieben, angewendet werden.

29


6 Implementierung auf der Grafikhardware

Aufbauend auf dem Algorithmus zur Darstellung dynamischer Szenen mit einem

beschleunigten Beobachter aus dem vorangegangenen Kapitel, werden in

diesem Kapitel wichtige Details bei der Implementierung des Algorithmus dargelegt.

Hierzu zählt unter anderem eine sinnvolle Verteilung der Berechnungen

auf CPU und Grafikhardware (GPU). Dabei wird insbesondere auf die Implementierung

des T-Buffer Algorithmus auf der Grafikhardware eingegangen. Am

Ende wird eine Architektur vorgestellt, die es erlaubt, sowohl Teile des Algorithmus

mit verschiedenen Shader-Hochsprachen auszuführen, als auch auf der

CPU. Dieser Schritt ist eine wichtige Vorraussetzung, um die in Kapitel 7 aufgeführten

Messungen zu realisieren.

6.1 Die Lorentz-Transformation und Grafikprogrammierung

Die Allgemeine Lorentz-Transformation aus Gl. 1 bildet den zentralen Grundbaustein

der oben vorgestellten relativistischen Visualisierungsalgorithmen. Für

die Implementierung auf der Grafikhardware muss daher die Allgemeine Lorentz-

Transformation mit Hilfe der Grafikhardware umsetzbar sein und von der verwendeten

Grafikschnittstelle (z.B. OpenGL) unterstützt werden.

Die Transformation eines Ereignisses mit der Allgemeine Lorentz-Transformation

entspricht gerade einer Matrizen-Vektor-Multiplikation über 4x4-Matrizen und

vierdimensionale Vektoren. Wie bereits in Kapitel 2.2 erwähnt wurde, werden

genau solche Matrizenoperationen von der Grafikhardware unterstützt. Da diese

Matrizenoperationen auch für das nicht-relativistische Rendering eine zentrale

Rolle spielen, sind diese Operationen besonders effizient auf der Grafikhardware

umgesetzt. Aus diesem Grund ist die Grafikhardware prinzipiell sogar besser

für derartige relativistische Berechnungen geeignet, als die CPU. Dennoch gibt

es Gründe, einige Teile der oben vorgestellten Algorithmen weiterhin auf der

CPU auszuführen, wie im Folgenden dargelegt wird.

6.2 Effiziente Implementierung auf CPU und GPU

Für eine echtzeitfähige Visualisierung der Speziellen Relativitätstheorie ist es

besonders wichtig, dass das in Kapitel 5.2.2 vorgestellte Verfahren effizient implementiert

wird. Hierbei spielt speziell die Aufteilung der verschiedenen Elemente

des Algorithmus auf die CPU und auf die Grafikhardware(GPU) eine

wichtige Rolle. Berechnungen, die auf der Grafikhardware vorgenommen werden,

werden für jeden Vertex (Vertex Shader Programm) oder sogar für jedes

Pixel (Pixel Shader Programm) ausgeführt. Teile des Algorithmus, die über eine

große Zahl von Vertizes konstant bleiben, würden daher ständig neu berechnet.

Hier lohnt sich eine Verlagerung der entsprechenden Rechnungen auf die CPU.

In Abbildung (14) wird eine effiziente Aufteilung der Berechnungen auf CPU

und GPU gezeigt, die auf der Annahme basiert, dass ein einzelnes unabhängig

bewegtes Objekt in der Regel aus einer großen Zahl von Polygonen besteht. In

diesem Fall ist es effizienter, Berechnungen, die für das gesamte Objekt oder

31


Ermittlung der Zeit t (G)

bis zum nächsten

Bilderzeugungsereignis.

Beschleunigung des Beobachters für Zeit t

zur Berechnung des Bilderzeugungsereignisses e

(G)

Kamera(G).

Berechnung auf der CPU

für jeden Frame

Für alle unabhängig bewegten Objekte

Transformation von e Kamera(G)

in das

aktuelle Objektruhesystem O.

Definition des Ursprungs vom

Kameraruhesystem K bei e Kamera(G)

.

Translation des Objektruhesystem O,

so dass sich O und K zur Zeit 0

im Ursprung treffen.

Berechnung der Lorentz-Transformationen

L und L .

KO

OK

Berechnung auf der CPU

für jedes Objekt

Berechnung der Translationsmatrix

auf der CPU

Translation der Vertizes mit der Matrix

auf der GPU

Berechnung auf der CPU

für jedes Objekt

Projektion des Objektes in das Bild

mit dem T-Buffer Algorithmus.

Berechnung auf der GPU

für jeden Vertex

Abbildung 14: Aufteilung der Berechnungen auf CPU und GPU.

sogar für einen ganzen Frame konstant bleiben, auf der CPU zu berechnen. Die

blau dargestellten Bereiche werden daher mit Hilfe der CPU berechnet, während

die grün gezeichneten Bereiche auf der Grafikhardware berechnet werden.

Einen Sonderfall bildet die Translation des Objektruhesystems O. In der Theorie

genügt es, das Koordinatensystem entsprechend zu verschieben. In der Praxis

bedeutet dies jedoch, dass die Position aller im System O definierten Vertizes

neu berechnet werden muss. Daher wird an dieser Stelle zunächst auf der CPU

eine entsprechende Translationsmatrix 7 berechnet, welche später bei den Berechnungen

auf der Grafikhardware genutzt werden kann, um die Vertizes zu

verschieben.

Es ergibt sich daher, dass die Hauptaufgabe der Grafikhardware in der Umsetzung

des T-Buffer Algorithmus besteht. Dies wird in den folgenden Ausführungen

näher erläutert.

6.2.1 Der T-Buffer Algorithmus auf der Grafikhardware

Für die Implementierung des T-Buffer Algorithmus ist der Ablauf aus Kapitel

5.1 entsprechend den vorangegangenen Darstellung in Abbildung (15) genauer

aufgeführt. Diese Schritte lassen sich am besten mit Hilfe von Vertex Shader

7 Eine Translationsmatrix ist eine 4x4-Matrix, die in der Computergrafik genutzt wird um

Vektoren, die in Form sogenannte homogene Koordinaten gegeben sind, zu verschieben.

32


Programmen auf der Grafikhardware realisieren, da sich alle Operationen nur

auf die Vertizes der Objekte beziehen.

Berechnung der Lorentz-Transformationen

L und L .

KO

OK

Projektion des Objektes in das Bild

mit dem T-Buffer Algorithmus.

Berechne für jeden Vertex:

Transformation des Bilderzeugungsereignisses

e in das Objektruhesystem O.

Kamera(K)

Berechnung des Zeitpunktes

des Vertex.

t Aussendung(O)

Erzeugen des Aussendungsereignisses

eAussendung(O)

aus Vertexposition und

Zeitpunkt t .

Aussendung(O)

Transformation des Aussendungsereignisses

e ins Kameraruhesystem K.

Aussendung(O)

3D-Projektion des Ortsvektors aus

e Aussendung(K)

.

Abbildung 15: Der T-Buffer Algorithmus auf der Grafikhardware.

Aus Abbildung (13) geht hervor, dass das Bilderzeugungsereignis e Kamera(K)

gerade im Ursprung des Kameraruhesystem K liegt. Da das Objektruhesystem

O nun derart verschoben wird, dass die Ursprünge von O und K sich zum

Zeitpunkt t K = t O = 0 im Ursprung treffen, liegt das Ereignis e Kamera(K) auch

im Objektruhesystem im Ursprung. Es ist also:

e Kamera(K) = e Kamera(O) (16)

Wegen dieses Zusammenhanges kann der erste Schritt in Abbildung (15) für die

Transformation des Kameraereignis weggelassen werden. Stattdessen wird der

Zusammenhang mit Gl. (9) zusammengefasst, so dass sich der zweite Schritt

33


durch die folgende Gleichung beschreiben lässt:


t Aussendung(S) = − x 2 Vertex(S) + y2 Vertex(S) + z2 Vertex(S)

(17)

Es zeigt sich somit, dass der T-Buffer Algorithmus durch die in Abbildung (15)

grün dargestellten Schritte implementiert werden kann. Diese drei Schritte lassen

sich mit NVIDIA Cg oder der OpenGL Shading Language mit nur zwei

Zeilen Programmtext als Vertex Shader Programm übersichtlich implementieren.

6.3 Austauschbare Implementierung des T-Buffer Algorithmus

Neben der Implementierung als Vertex Shader Programm, lässt sich der T-

Buffer Algorithmus auch mit Hilfe der CPU umsetzten. Um diese verschiedenen

Varianten der Umsetzung vergleichen zu können (siehe auch Kapitel 7),

ist es sinnvoll, beide Varianten in einem Softwaresystem zu implementieren. Im

Gegensatz zu der Verwendung mehrerer Softwaresysteme mit unterschiedlichen

Architekturen, ist bei einem einheitlichen Softwaresystem mit nur einer Architektur

bei Messungen der Leistungsfähigkeit beider Implementierungsvarianten

ausgeschlossen, dass ein Leistungsunterschied durch unterschiedliche Softwarearchitektur

hervorgerufen wird.

Um einen direkten Vergleich der verschiedenen Implementierungsvarianten zu

erhalten, unterstützt die Software zu dieser Arbeit verschiedene Modi für die

Darstellung relativistischer Szenen:

1. Den Nvidia Cg Modus.

In der Software MODE GPU genannt.

2. Den OpenGL Shadding Language Modus.

In der Software MODE GPU(GLSL) genannt.

3. Den CPU Modus.

In der Software MODE CPU genannt.

Die drei Modi setzen den T-Buffer Algorithmus zunächst auf zwei grundlegend

verschiedene Arten um: Die ersten beiden Varianten werden auf der Grafikhardware

realisiert, während die dritte Variante alleine mit der CPU arbeitet

und nur den nicht-relativistischen Anteil auf der Grafikhardware umsetzt. Die

ersten beiden Varianten unterscheiden sich in der verwendeten Schnittstelle zur

Grafikhardwareprogrammierung. Im Falle der OpenGL Shading Language wird

die allgemeinere Schnittstelle von OpenGL verwendet. Im Falle von NVIDIA

Cg wird die für NVIDIA Grafikkarten optimierte Schnittstelle verwendet. Im folgenden

Kapitel werden die Messungen zu den verschiedenen Modi beschrieben

und diskutiert.

34


7 Analyse der Messergebnisse

In den vorangegangenen Kapiteln wurde gezeigt, wie speziell relativistische Szenen

mit unabhängig, gleichförmig bewegten Objekten und einem interaktiven

Beobachter simuliert und visualisiert werden können. Folglich ist bereits eines

der in Kapitel 4.2 genannten Ziele hinreichend in dieser Arbeit beschrieben

worden. Es wird daher in diesem Kapitel zunächst auf das zweite Ziel, dem

experimentellen Nachweis der Leistungsunterschiede zwischen der Implementierung

auf der CPU und der GPU, eingegangen. Am Ende dieses Kapitels

werden, die in dieser Arbeit gewonnenen Erkenntnisse in der Form eines Fazites

zusammengefasst.

Vor der näheren Betrachtung der Messergebnisse, wird zunächst auf die Durchführung

der Messungen eingegangen. Dazu wird als erstes die zur Messung

verwendete Software näher betrachtet. Danach werden die für die Messungen

verwendeten Szenen vorgestellt.

7.1 Das Messverfahren

Ziel der Messungen ist eine Bewertung der Berechnungsgeschwindigkeit der verschiedenen

Implementierungsvarianten. Daher muss die gemessene Größe ein

Maß für die Geschwindigkeit des Systems darstellen. Wie überwiegend in der

Computergrafik üblich, werden für derartige Messungen die Bilder pro Sekunde

(engl.: frames per second (fps)) ermittelt.

Für die Messungen werden zwei verschiedene Softwaresysteme eingesetzt: Zum

einen die nach den vorangegangenen Ausführungen zu dieser Arbeit entwickelte

Software ”

Relativator“ in der Version 1.6 und zum anderen die von Daniel

Weiskopf entwickelte Software ”

Virtual Relativity“.

Die Software ”

Relativator“ bringt ein integriertes Messsystem mit. Die Messungen

können aus diesem Grund bei dieser Software automatisiert durchgeführt

werden. Die ermittelten Messwerte werden von der Software in einer Textdatei

zusammengefasst, die den Zeitpunkt der Messung in Millisekunden und die Bilder

pro Sekunde für diesen Zeitpunkt enthält. Für einen Messwert wird die Zeit

nach der Darstellung des letzten Bildes bis zur Darstellung des nächsten Bildes

gemessen. Für jede der in Kapitel 7.2 aufgeführten Szenen werden drei Messungen

bei einer Auflösung von 1280x1024 für die verschiedenen Implementierungsvarianten

(CPU, NVIDIA Cg, OpenGL Shading Language) durchgeführt,

soweit alle Methoden von der jeweiligen Hardware unterstützt werden.

Abbildung 16: Messung der Bilder pro Sekunde mit ”

Virtual Relativity“.

Mit der Software ”

Virtual Relativity“ können nur statische Szenen gemessen

35


werden. Da in ”

Virtual Relativity“ kein Messsystem integriert ist, wird die unten

rechts angezeigte Zahl der Frames (vgl. Abb. 16) als Grundlage genommen.

Die jeweilige Szene wird für 60 Sekunden visualisiert und die Anzahl der Frames

ermittelt. Aus diesen Werten lässt sich die durchschnittliche Anzahl der

Bilder pro Sekunde errechnen. Da für eine relativistische Darstellung noch keine

Culling Verfahren existieren (vgl. Kapitel 8.3), müssen alle Dreiecke einer

Szene für jedes Bild visualisiert werden. Die Anzahl der Bilder pro Sekunde ist

somit sehr konstant. Daher spiegeln die errechneten durchschnittlichen Werte

die Geschwindigkeit direkt wieder.

7.2 Untersuchte Szenen

Die Messungen werden anhand von drei verschiedenen Demoszenen durchgeführt,

die im Folgenden, auch in Bezug auf besondere relativistische Effekte,

näher beschrieben werden. Zuvor wird jedoch allgemein auf das Modellieren

derartiger Szenen eingegangen. Da der T-Buffer Algorithmus eine approximative

Darstellung erzeugt, müssen bei der Modellierung relativistischer Szenen

einige Besonderheiten beachtet werden.

7.2.1 Modellierung von Szenen zur relativistischen Darstellung

Beim Modellieren dreidimensionaler Szenen wird im nicht-relativistischen Fall

versucht, ein Modell mit möglichst wenigen Dreiecken möglichst gut abzubilden.

Bei einer relativistischen Darstellung kann diese Strategie zu Überraschungen

führen. Wie bereits in Kapitel 5.1 beschrieben, werden nur die Eckpunkte der

Dreiecke relativistisch betrachtet. Alle anderen Punkte sind demnach nur näherungsweise

relativistisch korrekt visualisiert. Dies hat zur Folge, dass große

Flächen mit wenigen Vertizes nicht erkennbar relativistisch dargestellt werden.

In Abbildung (17a) ist eine quadratische Fläche bei 80 Prozent der Lichtgeschwindigkeit

zu sehen. Da die Fläche mit nur vier Vertizes modelliert ist, kann

ein Betrachter nur schwer einen Unterschied zu einer nicht-relativistischen Fläche

feststellen. Erst wenn mehr Vertizes hinzugefügt werden, ist die typische

Krümmung zu erkennen (Abb. 17b).

Besteht ein Objekt aus Teilen mit vielen Details und großen Flächen mit wenigen

Punkten, kann die Darstellung derart verfälscht werden, dass nicht nur ein

falscher Eindruck von der Speziellen Relativitätstheorie entsteht, sondern vollkommen

neue Objekte entstehen. In Abbildung (17c) liegen die Fläche mit einem

detailreichen Gitter und die Fläche mit nur vier Eckpunkten an der gleiche

Position. Anstatt zweier übereinanderliegender Flächen, ist ein anderes Objekt

mit einer glatten Fläche und einer gewölbten darüber Fläche zu sehen.

Um derartige Probleme zu vermeiden, müssen die Flächen der Objekte einer

Szene eine möglichst einheitliche Größe und Form haben. Die Größe der Flächen

(und damit die Anzahl der Vertizes) entscheidet über die Genauigkeit

der Darstellung. Wird ein Objekt vom Beobachter aus kurzer Entfernung betrachtet

oder ist es sehr groß, so müssen beim Modellieren mehr kleine Flächen

eingesetzt werden.

36


a) b) c)

Abbildung 17: Auswirkungen unterschiedlicher Gittergrößen beim relativistischen

Rendering mit dem T-Buffer Algorithmus.

In den folgenden Szenen werden diese Anmerkungen berücksichtigt. Mit Hilfe

verschiedener Programme wird zunächst, mittels verschiedener Polygonreduktionsmethoden,

ein Objekt mit möglichst wenigen Dreiecken erzeugt. Danach

werden die Flächen des Objektes derart unterteilt, dass möglichst einheitlich

große Flächen entstehen.

37


7.2.2 Relativistisches Haus

Abbildung 18: Gesamtansicht des relativistischen Hauses.

Das relativistische Haus ist ein typischer Vertreter einer statischen Szene. Für

diese Szene werden sowohl Messungen mit der Software ”

Relativator“ als auch

mit der Software ”

Virtual Relativity“ durchgeführt. Die Szene besteht aus einem

Haus mit Nebengebäuden (vgl. Abb. 18) und ist mit 262604 Dreiecken die

kleinste Szene.

38


7.2.3 Relativistische Raumschiffe

Abbildung 19: Überblick über eine relativistische Szene mit vielen unabhängigen,

gleichförmig bewegten Raumschiffen.

Die relativistische Raumschiffszene ist eine typische dynamische Szene. Sie besteht

aus einer großen Zahl von Raumschiffen, von denen sich 38 unabhängig zueinander,

gleichförmig bewegen (vgl. Abb. 19). Die Modelle dieser, mit 1748459

Dreiecken komplexesten Szene, stammen von verschiedenen Webseiten (siehe

Kapitel 9) und wurden gemäß Kapitel 7.2.1 an die relativistische Darstellung

angepasst.

Zur Messung wird hier nur die Software ”

Relativator“ verwendet, da ”

Virtual

Relativity“ keine dynamischen Szenen darstellen kann.

39


7.2.4 Relativistische Industriehalle

a) b)

c)

Abbildung 20: Ansichten der relativistischen Industriehalle.

Die Modelle der relativistischen Industriehalle stammen von Szenen zur Projektgruppe


Wege und Bewegungen in virtuellen Produktionsumgebungen“ der

Universität Paderborn (siehe Kapitel 9). Diese Szene besteht zum Großteil aus

fest installierten Maschinen und zwei unabhängig, gleichförmig bewegten Gabelstaplern.

Die Industriehalle ist eine dynamische Szene mit drei unabhängig,

gleichförmig bewegten Objekten. Mit 1563945 Dreiecken liegt diese Szene in

ihrer Komplexität zwischen den vorangegangenen Szenen.

Eine Besonderheit dieser Szene ist die auf dem Gabelstapler dargestellte orange

Lampe (vgl. Abb. 20b und 20c). Sie leuchtet in einem vorgegebenen Rhythmus

regelmäßig im Ruhesystem des Gabelstaplers. Anhand des Leuchtrhythmus

lässt sich insbesondere die Zeitdilatation und der relativistische Doppler-Effekt

illustrieren.

7.3 Ergebnisse

An dieser Stelle wird Schritt für Schritt eine Analyse der Messwerte durchgeführt.

Als Erstes kann mit den Messwerten die begründete Vermutung untermauert

werden, dass die Anzahl der Bilder pro Sekunde unabhängig von

Blickrichtung und Position des Beobachters ist und sich daher ein sinnvoller

Durchschnittswert für die gesamte Szene ergibt. Im Anschluss wird gezeigt, dass

die Messergebnisse im Grunde unabhängig von der gemessenen Szene sind. Es

genügt demnach, für die Analyse eine Szene zu betrachten.

Als Drittes wird ein Vergleich zwischen Grafikkarten der Firma ATI und Grafikkarten

der Firma NVIDIA durchgeführt. Im Folgenden wird nachgewiesen,

dass die Implementierung mit Hilfe von NVIDIA Cg und der OpenGL Shading

40


Language maßgeblich abhängig ist von der Grafikhardware, während die Implementierung

mit CPU-Unterstützung nur noch von der Leistungsfähigkeit der

CPU abhängt.

Beim abschließenden Leistungsvergleich kann anhand der Messwerte gezeigt

werden, dass die Darstellung mit Hilfe der Grafikhardware eine deutlich leistungsfähigere

Lösung darstellt als die Implementierung auf der CPU. Dieser

Eindruck wird durch den Vergleich mit der Software ”

Virtual Relativity“ im

Anschluss noch verstärkt.

7.3.1 Unabhängigkeit der Framerate vom Beobachterstandpunkt

Raumschiffe (NVIDIA Cg)

20

Bilder pro Sekunde (fps)

15

10

5

NVIDIA GeForce3(64MB) auf Pentium4

/ 2GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium4 / 1.8GHz

NVIDIA GeForceFX 5700 (256MB) auf

Pentium4 / 1.8GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium3 / 1GHz

NVIDIA GeForce4 Ti 4200 (64MB) auf

Pentium4 / 2.4GHz

NVIDIA GeForce 6600 GT auf

Pentium4 / 2.8GHz

0

0 20000 40000 60000 80000 100000 120000 140000 160000

Zeit

Abbildung 21: Verlauf der Framerate in der Raumschiffszene bei der relativistischen

Darstellung mit NVIDIA Cg.

Das Diagramm in Abbildung (21) zeigt die Messwerte für die Raumschiffszene

im NVIDIA Cg Modus. Für verschiedene Grafikkarten ist der Verlauf der Anzahl

der Bilder pro Sekunde (fps), der sogenannten Framerate, zum jeweiligen

Simulationszeitpunkt dargestellt. Es ist leicht zu erkennen, dass der Verlauf der

Framerate für fast alle Grafikkarten sehr konstant verläuft. Treten Schwankungen

auf (z.B. bei der Messung mit der NVIDIA 6600 GT), so bewegen sich diese

Schwankungen sehr genau um einen einheitlichen Mittelwert.

Im Gegensatz zu typischen Diagrammen zu Cullingverfahren, bei denen Schwankungen

der Framerate in der Regel mit der Anzahl der sichtbaren Dreiecke

zusammenhängt, lässt sich hier kein direkter Zusammenhang zwischen Schwankungen

in der Framerate und Szene feststellen. Es handelt sich stattdessen

um zufällige Schwankungen, die beispielsweise durch andere, im Hintergrund

laufende Prozesse, verursacht werden können. Betrachtet man den Mittelwert

41


über die gemessene Zeit der Framerate, dann ist dieser Wert unabhängig von

den Schwankungen. In den folgenden Analysen wird daher nur der Mittelwert

betrachtet. 8

8 Für die hier vorgeführte Betrachtung wurde aus Übersichtsgründen ein Diagramm ausgewählt.

Für alle anderen Darstellungsmodi und Szenen ergibt sich aber ebenfalls, dass die

Betrachtung des Mittelwertes der Framerate ausreicht.

42


Leistungsvergleich verschiedener Darstellungsmodi der Raumschiffszene

22

Bilder pro Sekunde (fps)

20

18

16

14

12

10

8

6

4

2

ATI RADEON 9800 Pro (128MB) auf AMD

Athlon 64 3200+ / 2.4GHz

ATI RADEON 9700 Mobility (64MB) auf

Centrino / 1.4GHz

NVIDIA GeForce3(64MB) auf Pentium4 /

2GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium4 / 1.8GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium3 / 1GHz

NVIDIA GeForce4 Ti 4200 (64MB) auf

Pentium4 / 2.4GHz

NVIDIA GeForceFX 5700 (256MB) auf

Pentium4 / 1.8GHz

NVIDIA GeForce 6600 GT auf Pentium4 /

2.8GHz

0

CPU

OpenGL Shading

Language

NVIDIA Cg

Leistungsvergleich verschiedener Darstellungsmodi bei der relativistischen Industriehalle

25

Bilder pro Sekunde (fps)

20

15

10

5

ATI RADEON 9800 Pro(128MB) auf AMD

Athlon 64 3200+/2.4GHz

ATI RADEON 9700 Mobility(64MB) auf

Centrino/1.4GHz

NVIDIA GeForce3(64MB) auf Pentium4 /

2GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium4/1.8GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium3/1GHz

NVIDIA GeForce4 Ti 4200(64MB) auf

Pentium4/2.4GHz

NVIDIA GeForceFX 5700 (256MB) auf

Pentium4/1.8GHz

NVIDIA GeForce 6600 GT auf

Pentium4/2.8GHz

0

CPU

OpenGL Shading

Language

NVIDIA Cg

Leistungsvergleich verschiedener Darstellungsmodi bei dem relativistischen Haus

70

Bilder pro Sekunde (fps)

60

50

40

30

20

10

ATI RADEON 9800 Pro(128MB) auf AMD

Athlon 64 3200+/2.4GHz

ATI RADEON 9700 Mobility(64MB) auf

Centrino/1.4GHz

NVIDIA GeForce3(64MB) auf Pentium4 /

2GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium4/1.8GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium3/1GHz

NVIDIA GeForce4 Ti 4200(64MB) auf

Pentium4/2.4GHz

NVIDIA GeForceFX 5700 (256MB) auf

Pentium4/1.8GHz

NVIDIA GeForce 6600 GT auf

Pentium4/2.8GHz

0

CPU

OpenGL Shading

Language

NVIDIA Cg

Abbildung 22: Mittlere Framerate bei den drei Szenen.

43


7.3.2 Unabhängigkeit der Ergebnisse von den Szenen

In den Diagrammen in Abbildung (22) sind die mittleren Frameraten für die drei

relativistischen Darstellungsmethoden der drei untersuchten Szenen in Form eines

Balkendiagrammes zu sehen. An einigen Stellen im Diagramm scheinen Balken

zu fehlen. In diesen Fällen ist der entsprechende Darstellungsmodus nicht

von der jeweiligen Hardwarekombination unterstützt worden. So wird NVIDIA

Cg nicht von den beiden ATI Grafikkarten unterstützt. Die Grafikkarten NVIDIA

GeForce3 und NVIDIA GeForce Ti 4200 haben die OpenGL Shading Language

nicht unterstützt.

Ein Vergleich der Diagramme unterschiedlicher Szenen zeigt, dass die Verhältnisse

der Balkenhöhen in etwa gleichbleiben. Die qualitative Aussage welche

Hardwarekombination schneller ist, ist damit für alle Szenen gleich.

Prinzipiell lässt sich daraus ableiten, dass die Messungen qualitativ unabhängig

von den Szenen sind. Bei genauer Betrachtung zeigt sich jedoch, dass die Messwerte

für die NVIDIA GeForce 6600 GT auf einem Pentium4 mit 2.4 GHz (im

Folgenden immer als Kombination 1 bezeichnet) und die NVIDIA GeForceFX

5200 auf einem Pentium3 mit 1 GHz (im Folgenden immer als Kombination

2 bezeichnet) in der Szene mit dem ”

relativistischen“ Haus von den übrigen

Verhältnissen abweichen. So übersteigt der Messwert für die Kombination 1

bei der Darstellung mit der OpenGL Shading Language die Framerate für die

Darstellung mit NVIDIA Cg. In den beiden anderen Szenen ist es jedoch umgekehrt.

Diese Abweichung lässt sich allerdings mit der hohen Framerate von 50

bis 60 Bildern pro Sekunde erklären. Für derart hohe Messwerte können leicht

Schwankungen von einigen Frames auftreten, was den Geschwindigkeitsvorteil

von der Variante mit der OpenGL Shading Language in der Szene mit dem Haus

erklären könnte.

Die Besonderheit der Kombination 2 ist im Diagramm zum ”

relativistischen“

Haus bei der Darstellung mit NVIDIA Cg zu sehen. Die gemessenen NVIDIA

GeForceFX 5200 auf einem Pentium3 mit 1 GHz (Kombination 2) ist, im Gegensatz

zu allen anderen Messungen, gleichauf mit einer NVIDIA GeForce Ti

4200. Dieser Effekt lässt sich jedoch einfach durch einen fehlerhaften Messwert

erklären. So trat nur während der Messung mit Kombination 2 und der Szene

mit dem Haus ein ungewöhnliches ”

Ruckeln“ während der Messung auf. Dieses

subjektiv zu sehende ”

Ruckeln“ schlägt sich in den Messwerten in Form von

sehr starken Schwankungen (ca. 100 Bilder pro Sekunde) nieder. Derart starke

Schwankungen lassen keine sinnvolle Analyse mehr zu. Da dieser Effekt auch bei

wiederholten Messungen immer wieder auftrat, handelt es sich hierbei um einen

systematischen Messfehler. Im Rahmen dieser Arbeit konnte der Fehler nicht

genau ermittelt werden, es liegt jedoch die Vermutung vor, dass eine fehlerhafte

Einstellung des Treibers das Problem hervorruft.

Zusammenfassend ergibt sich, dass sich beide Abweichungen erklären lassen,

ohne die Aussage abändern zu müssen. Für die folgenden Analysen genügt daher

die Betrachtung von nur einer der drei Szenen.

44


7.3.3 Vergleich zwischen Grafikkarten von NVIDIA und ATI

Die in dieser Arbeit vorgenommenen Messungen zeigen große Unterschiede zwischen

den Grafikkarten von NVIDIA und ATI. Zwar konnten aufgrund geringer

Verfügbarkeit nur zwei Grafikkarten mit ATI Grafikprozessor getestet werden,

es lassen sich jedoch auch bei dieser nicht repräsentativen Anzahl von getesteten

ATI Grafikkarten erste Vermutungen über die Leistungsfähigkeit anstellen.

Vergleich zwischen ATI und NVIDIA

3

2.5

Bilder pro Sekunde (fps)

2

1.5

1

ATI RADEON 9800 Pro(128MB) auf AMD

Athlon 64 3200+/2.4GHz

ATI RADEON 9700 Mobility(64MB) auf

Centrino/1.4GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium4/1.8GHz

0.5

0

CPU

GLSL

Abbildung 23: Vergleich der mittleren Framerate von NVIDIA und ATI Grafikkarten

bei der Raumschiffszene.

Im Diagramm in Abbildung (23) ist die NVIDIA GeForceFX 5200, die schwächsten

NVIDIA gestützte Grafikkarten, die auch die OpenGL Shading Language unterstützt,

im Vergleich zu den beiden ATI gestützten Systemen aufgeführt. Es

ist deutlich zu erkennen, dass beide ATI Systeme deutlich unter dem Ergebnis

der NVIDIA Grafikkarte liegen.

Bei einem Vergleich des grafikhardwaregestützten, auf der OpenGL Shading

Language basierenden, relativistischen Rendering mit dem CPU basierten Rendering,

zeigt sich bei den ATI gestützten Systemen, dass hier nur geringe Unterschiede

vorliegen.

Die Ergebnisse der getesteten ATI Systeme sind somit nicht zufriedenstellend.

Diese schlechten Werte können verschiedene Ursachen haben:

• Schlechte Hardwareunterstützung der nötigen Funktionen für das relativistischen

Renderings bei ATI Grafikkarten.

• Schlechte Implementierung des Treibers für die OpenGL Shading Language

bei ATI Grafikkarten. Die Folge ist eine schlechte Übersetzung der

45


OpenGL Shading Language Programme in für Grafikkarten verständlichen,

assemblerartigen Code. 9

• Schlechte Abstimmung zwischen System und Grafikkarte.

Welche dieser Ursachen zutreffen, lässt sich im Rahmen dieser Arbeit nicht beantworten.

Für die folgenden Messanalysen werden daher nur NVIDIA gestützte

Systeme betrachtet, bei denen in der Regel deutliche Unterschiede zwischen

Grafikkarten gestütztem relativistischen Rendering und CPU gestütztem relativistischen

Rendering bestehen.

7.3.4 Darstellungsmodi im Zusammenhang mit GPU und CPU

Bilder pro Sekunde (fps) mit NVIDIA Cg bei der Raumschiffszene

3.5

3

1.2

3.2

20.3

Prozessorleistung in GHz

2.5

2

1.5

1

2.1

3.4

3.1

3.0

4.0

6.5

20.2

18.9

0.5

0

NVIDIA GeForce3

NVIDIA GeForceFX 5200

NVIDIA GeForce Ti 4200

NVIDIA GeForceFX 5700

NVIDIA GeForce 6600 GT

schlechter Grafikleistung besser

9 Diese Ursache lässt sich durch direkte Implementierung als assemblerartigen Code prüfen.

46


Bilder pro Sekunde (fps) im CPU-Modus bei der Raumschiffszene

3.5

3

0.43

0.44

0.44

Prozessorleistung in GHz

2.5

2

1.5

1

0.26

0.26

0.25

0.21

0.37

0.25

0.26

0.21

0.5

0

NVIDIA GeForce3

NVIDIA GeForceFX 5200

NVIDIA GeForce Ti 4200

NVIDIA GeForceFX 5700

NVIDIA GeForce 6600 GT

schlechter Grafikleistung besser

Abbildung 24: Abhängigkeit der Framerate von der CPU und der Grafikkarte

in verschiedenen Darstellungsmodi.

Ein wichtiges Argument für die Implementierung auf programmierbarer Grafikhardware

ist neben dem Performancevorteil auch die Unabhängigkeit von der

CPU. Auf diese Weise kann mit Hilfe verhältnismäßig günstiger, aber leistungsstarker

Grafikhardware ein schwacher Prozessor ausgeglichen werden. Dies setzt

natürlich voraus, dass die Geschwindigkeit der entsprechenden Implementierung

für die Grafikhardware hauptsächlich von der verwendeten Grafikkarte abhängt

und nicht von der Prozessorleistung.

Mit Hilfe der ermittelten Messwerte lässt sich zeigen, dass die relativistische

Darstellung mit Hilfe von programmierbarer Grafikhardware maßgeblich abhängig

von der verwendeten Grafikhardware ist, gleichzeitig aber unabhängig von

der verwendeten CPU. Bei der relativistischen Darstellung mit Hilfe der CPU

ist es genau umgekehrt: Hier entscheidet die Leistung des Prozessors hauptsächlich

über die Performance, während die Anzahl der Bilder pro Sekunde

unabhängig von der verwendeten Grafikhardware ist. Dies lässt sich besonders

gut anhand der in Abbildung (24) aufgeführten Blasendiagramme erkennen. Die

Größe der Blasen repräsentiert die jeweils gemessene mittlere Framerate für die

Raumschiffszene. Die Position der Blase stellt die entsprechende Hardwarekombination

dar.

Das erste Diagramm stellt die Grafikhardware gestützte Darstellungsvariante

basierend auf NVIDIA Cg dar. Es ist gut zu erkennen, dass die Blasengröße und

47


damit die Framerate von links nach rechts zunimmt und damit umso höher wird

je besser der Grafikprozessor ist. Eine Veränderung von oben nach unten, und

somit eine Abhängigkeit von der Prozessorleistung, lässt sich hingegen nicht

erkennen.

Das zweite Diagramm zeigt die Darstellung mit Hilfe der CPU. Es ist zu erkennen,

dass die Blasengrösse und die damit verbundene Framrate von unten

nach oben zunimmt, aber keine Zunahme von links nach rechts zu sehen ist.

Hier ist die Framerate also von der Leistung der Grafikhardware unabhängig

und maßgeblich von der Prozessorleistung abhängig.

7.3.5 Leistungsvergleich der verschiedenen relativistischen

Darstellungsimplementierungen

Leistungsvergleich verschiedener Darstellungsmodi der Raumschiffszene auf NVIDIA Grafikkarten

22

20

Bilder pro Sekunde (fps)

18

16

14

12

10

8

6

4

NVIDIA GeForce3(64MB) auf Pentium4 /

2GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium4 / 1.8GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium3 / 1GHz

NVIDIA GeForce4 Ti 4200 (64MB) auf

Pentium4 / 2.4GHz

NVIDIA GeForceFX 5700 (256MB) auf

Pentium4 / 1.8GHz

NVIDIA GeForce 6600 GT auf Pentium4 /

2.8GHz

2

0

CPU

OpenGL Shading

Language

NVIDIA Cg

Abbildung 25: Leistungsvergleich verschiedener Implementierungsvarianten des

relativistischen Renderings auf NVIDIA Grafikkarten.

Ein wichtiges Ziel dieser Arbeit ist die Verbesserung der Performance des relativistischen

Echtzeitrenderings unter Verwendung programmierbarer Grafikhardware.

Um den Performancevorteil bei der Implementierung auf der Grafikhardware

gegenüber der Implementierung auf der CPU zu untersuchen, wird

das Diagramm für die Raumschiffszene aus Abbildung (25) herangezogen. Auf

den ersten Blick ist zu erkennen, dass die beiden grafikhardwareunterstützten

Darstellungsmethoden deutlich schnellere Darstellung ermöglichen. Selbst mit

der schwächsten Grafikkarte (NVIDIA GeForce3) lassen sich bessere Werte erreichen,

als der CPU gestützte Darstellungsmodus mit dem schnellsten Rechner

(Pentium4 2.8 GHz) und der stärksten Grafikkarte (NVIDIA GeForce 6600 GT)

erzielen kann.

48


Ein weiteres Argument für die Verwendung programmierbarer Grafikhardware

ist die mögliche Leistungssteigerung. So zeigt sich zwischen dem schwächsten

Prozessor (Pentium3 1 GHz) und dem stärksten Prozessor (Pentium4 2.8

GHz) bei der Darstellung mit Hilfe der CPU eine nur geringe Leistungssteigerung

von ungefähr 0.23 Bildern pro Sekunde. Unter Berücksichtigung des

Erscheinungsdatums des gemessenen Pentium3-Prozessors von 1999 und des

gemessenen Pentium4-Prozessors von 2002, entspricht dies etwa einer Verdoppelung

der Geschwindigkeit innerhalb von drei Jahren. Betrachtet man hingegen

die schwächste (NVIDIA GeForce3) Grafikkarte, welche im Jahre 2001 auf dem

Markt erschienen ist, und die stärkste (NVIDIA GeForce 6600 GT) Grafikkarte,

die 2003 erschienen ist, bei der relativistischen Darstellung mit NVIDIA Cg, so

verzehnfacht sich die Leistung innerhalb von drei Jahren. 10

Als letztes wichtiges Ergebnis lässt sich erkennen, dass die Implementierung mittels

OpenGL Shading Language in der Regel etwas schwächer abschneidet als

die Implementierung mit NVIDIA Cg. Dies ist indes nicht weiter überraschend,

da hier ausschließlich NVIDIA Grafikkarten betrachten wurden und diese Karten

natürlich auf die herstellereigene Sprache besser optimiert sind als auf die

herstellerunabhängige OpenGL Shading Language.

Insgesamt zeigt das Diagramm eindrucksvoll die Überlegenheit der Implementierung

auf der Grafikhardware gegenüber einer Implementierung der relativistischen

Darstellung auf der CPU.

7.3.6 Vergleich von relativistischem mit nicht-relativstischem Rendering

Bei einem Vergleich von relativistischem und nicht-relativistischem Rendering

zeigt sich, wie im Diagramm in Abbildung (26) zu erkennen ist, dass das relativistische

Rendering nicht so schnell durchgeführt werden kann, wie das nichtrelativistische.

Dies ist jedoch nicht besonders verwunderlich, da für die relativistische

Darstellung eine neue Renderingstufe in die Rendering Pipeline

eingefügt wird.

Bei einer Betrachtung der Messwerte für die relativistischen Darstellung mit

einer NVIDIA GeForce 6600 GT ist zu erkennen, dass dieser Wert nahezu gleich

dem Messwert für die nicht-relativistische Darstellung mit einer NVIDIA Ge-

Force3 Grafikkarte ist. Mit Hilfe besserer Grafikhardware lässt sich der höhere

Rechenaufwand des relativistischen Renderings somit ausgleichen.

7.3.7 Vergleich von ”

Relativator“ und ”

Virtual Relativity“

Im Diagramm in Abbildung (27) ist ein direkter Vergleich mit der Referenzsoftware


Virtual Relativity“ zu sehen. Da ”

Virtual Relativity“ nur statische Szenen

unterstützt, sind diese Messwerte mit Hilfe der Szene mit dem ”

relativistischen“

Haus ermittelt worden. Aus den in Kapitel 7.3.2 angeführten Gründen, ist die

Messung mit der NVIDIA GeForceFX 5200 auf einem Pentium3 mit 1 GHz nicht

in das Diagramm aufgenommen worden.

10 Betrachtet man die Leistungssteigerung unter den Gesichtspunkten des Moore´schen Gesetzes,

dann ist derzeit bei der Grafikhardware ein steilerer Leistungsanstieg als bei den

CPUs zu verzeichnen.

49


Vergleich zwischen nicht-relativistischer Darstellung und relativistischer Darstellung

70

60

Bilder pro Sekunde (fps)

50

40

30

20

NVIDIA GeForce3(64MB) auf Pentium4 /

2GHz

NVIDIA GeForceFX 5200 (128MB) auf

Pentium3/1GHz

NVIDIA GeForce4 Ti 4200(64MB) auf

Pentium4/2.4GHz

NVIDIA GeForce 6600 GT auf

Pentium4/2.8GHz

10

0

Relativistisches Rendering mit NVIDIA

Cg

Nicht-Relativistisches Rendering

Abbildung 26: Nicht-relativistisches und relativistisches Rendering.

Bereits bei grober Betrachtung fällt auf, dass die Frameraten des ”

Relativators“

in der Regel besser sind als die von ”

Virtual Relativity“. Nur im Falle der ATI

RADEON 9800 auf einem AMD Athlon 64 3200+ mit 2.4 GHz erreicht ”

Virtual

Relativity“ etwas bessere Werte.

7.4 Fazit

Mit der in dieser Arbeit entwickelten Software ”

Relativator“ ist es möglich, sich

interaktiv durch eine relativistische Umgebung mit mehreren unabhängigen,

gleichförmig bewegten Objekten zu bewegen. Dabei gelingt es auch bei großen

Szenen, die Echtzeitfähigkeit mit Hilfe der Umsetzung auf programmierbarer

Grafikhardware zu garantieren.

Bei der Verwendung von Grafikkarten mit Grafikchips der Firma ATI zeigen

sich Schwächen bei der Performance. Aus diesem Grund kann die Zielsetzung

für die Entwicklung eines Systemes, welches dynamische Szenen mittels programmierbarer

Grafikhardware relativistisch darstellt, als erreicht bezeichnet

werden. Der Nachweis für einen Performancevorteil einer Implementierung auf

der Grafikhardware gegenüber einer Implementierung auf der CPU kann bei

Grafikkarten mit NVIDIA Grafikchip erbracht werden; bei Grafikkarten mit ATI

Grafikchip kann der Nachweis hingegen nicht erbracht werden. Die starke Leistungssteigerung

im Bereich der Grafikhardware ermöglicht zudem den Ausgleich

der höheren Komplexität des relativistischen Renderings durch neuere Grafikhardware.

Eine relativistische Szene mit zwei Millionen Polygonen lässt sich

auf einer NVIDIA GeForce 6600 GT ebenso mit 20 Bildern pro Sekunde darstellen,

wie eine nicht-relativistische Szene mit zwei Millionen Polygonen auf einer

50


Vergleich zwischen dem Relativator und Virtual Relativity

60

50

Bilder pro Sekunde (fps)

40

30

20

Relativator

VirtualRelativity

10

0

NVIDIA

GeForce3(64MB)

auf Pentium4 /

2GHz

NVIDIA

GeForceFX 5200

(128MB) auf

Pentium4/1.8GHz

NVIDIA

GeForceFX 5700

(256MB) auf

Pentium4/1.8GHz

NVIDIA GeForce4

Ti 4200(64MB)

auf

Pentium4/2.4GHz

NVIDIA GeForce

6600 GT auf

Pentium4/2.8GHz

ATI RADEON

9800 Pro(128MB)

auf AMD Athlon

64 3200+/2.4GHz

Abbildung 27: Leistungsvergleich zwischen dem Relativator (NVIDIA Cg) und

Virtual Relativity“.


NVIDIA GeForce3.

Im Vergleich mit der Software ”

Virtual Relativity“ , bei dessen Entwicklung

noch keine derartig frei programmierbare Grafikhardware zur Verfügung stand,

schneidet das in dieser Arbeit entwickelte System überwiegend positiv ab.

Insgesamt ergibt sich, trotz der beschriebenen Probleme bei ATI basierten Grafikkarten,

dass die gesetzten Ziele erreicht werden konnten. Es zeigt sich daher,

dass aktuelle Grafikhardware sehr gut geeignet ist, um die geometrischen Effekte

der Speziellen Relativitätstheorie zu visualisieren. Für eine maßstabsgetreue

Darstellung von astronomischen Szenen (z.B.: das Sonnensystem) zeigt sich jedoch,

dass der Wertebereich des Z-Buffers von derzeit maximal 32-Bit zu klein

ist. Hier wäre ein grösserer Wertebereich wünschenswert.

Betrachtet man die gegenwärtigen Preise der getesteten Grafikkarten von ca. 50

Euro bis 200 Euro, so ermöglicht die Software ”

Relativator“ jedem PC-Besitzer

- und somit einer großen Masse - einen guten Einblick in die verschiedenen

Effekte der Speziellen Relativitätstheorie.

51


8 Ausblick

Die Visualisierung der Speziellen Relativitätstheorie ist ein sehr umfangreiches

Themengebiet, dass nicht innerhalb einer einzelnen Diplomarbeit abgehandelt

werden kann. Die zu dieser Arbeit entwickelte Software kann daher, außerhalb

des Rahmens dieser Diplomarbeit, noch erweitert werden. Im Folgenden wird

ein Ausblick auf mögliche Erweiterungen gegeben. Dabei wird auf die Probleme

und mögliche Lösungsansätze eingegangen.

8.1 Doppler- und Suchscheinwerfereffekt

Die visuellen Auswirkungen des relativistischen Doppler- und Suchscheinwerfereffektes

sind bereits in Kapitel 3.3.2 beschrieben worden. Für die Darstellung

beider Effekte müssen die Farben jedes Pixels neu bestimmt werden. Im Zusammenhang

mit der Realisierung auf programmierbarer Grafikhardware bietet

sich daher an, diese Effekte mit Hilfe der in Kapitel 2.3 erwähnten Pixel

Shader Programme darzustellen. Prinzipiell lassen sich diese Effekte auf diese

Weise verhältnismäßig einfach in die zu dieser Arbeit entwickelten Software

einarbeiten, da lediglich ein entsprechendes Pixel Shader Programm entwickelt

werden muss; die grundsätzliche Architektur des Programmes kann hingegen

beibehalten werden.

8.2 Beschleunigte Objekte

In dieser Arbeit wurden Verfahrensweisen vorgelegt, um dynamische Szene

relativistisch zu visualisieren. Dabei wurden die dynamischen Szenen jedoch

auf gleichförmige Bewegungen eingeschränkt. Um uneingeschränkte dynamische

Szenen relativistisch darzustellen, müssen auch beschleunigte Objekte visualisiert

werden. In [Sudm04] wird bereits in Kapitel 4.1 auf Ansätze für die Visualisierung

beschleunigter Objekte eingegangen. Diese Ansätze werden in den

folgenden Ausführungen erneut aufgegriffen und speziell im Zusammenhang mit

programmierbarer Grafikhardware betrachtet.

Bei der relativistischen Visualisierung beschleunigter Objekte ist die grundlegende

Problemstellung die gleiche wie bei gleichförmig bewegten Objekten: Für

die Darstellung muss das Aussendungsereignis für den darzustellenden Punkt

im Kameraruhesystem ermittelt werden. Für eine approximative Lösung können

hier also, wie schon beim T-Buffer Algorithmus, nur die Vertizes betrachtet

werden.

In Abbildung 28 ist die Situation für einen beschleunigten Beobachter und dem

Vertex eines beschleunigten Objektes dargestellt. Prinzipiell genügt es hier wieder,

den Schnittpunkt des Lichtkegels ausgehend vom Bilderzeugungsereignis

mit der Weltlinie des Vertex zu ermitteln. Die Weltlinie des Vertex kann, ähnlich

wie die Beobachterweltlinie, mit Hilfe numerischer Methoden approximiert

werden und in ein Hilfssystem G zusammen mit der Weltlinie des Beobachters

53


ct

G

ct

K

Bilderzeugung (e Kamera )

x

K

K (Kamera)

Weltlinie eines Vertex

eines beschleunigten Objektes

Lichtkegel

ct O

Weltlinie des

Beobachters

G (Hilfssystem)

xG

x

O (Objekt)

O

Aussendung des Lichtes

zur Kamera (e )

Aussendung

Abbildung 28: Prinzip zur relativistischen Visualisierung eines beschleunigten

Beobachters mit beschleunigten Objekten.

projiziert werden. Im Gegensatz zur Beobachterweltlinie kann die Weltlinie des

Objektes jedoch schon im Vorfeld berechnet werden. Die Objektweltlinie muss

somit nicht zur Laufzeit berechnet werden.

Im Gegensatz zur Darstellung von statischen Szenen, gibt es bei der Darstellung

beschleunigter Objekte aus der Sicht des Beobachters verschiedene Objektruhesysteme,

da sich die Geschwindigkeit des Objektes ständig ändert. Diese Problematik

kann man mit dem Hilfssystem G etwas vereinfachen. Da G sich nicht

verändert, kann in G zunächst der Schnittpunkt des Lichtkegels mit der jeweiligen

Weltlinie berechnet werden. Zusammen mit dem Schnittpunkt steht dann

auch die Geschwindigkeit zur Zeit der Lichtaussendung fest und damit das Objektruhesystem.

An dieser Stelle kann die Situation wie im statischen Fall mit

dem T-Buffer Algorithmus behandelt werden.

Für die Bestimmung der Schnittstelle ist vor allem wichtig, in welcher Form

die Weltlinie dargestellt wird. Da sich alle Vertizes eines Objektes im Regelfall

gleichermaßen bewegen (Kreisbewegungen bilden hier eine Ausnahme), genügt

die Beschreibung einer Weltlinie pro Objekt. Am besten lässt sich die Objektweltline

in Form sehr vieler Streckenzüge approximativ darstellen. Für die Ermittelung

des Schnittpunktes wird im ersten Schritt die Strecke gesucht, die

vom Lichtkegel geschnitten wird. Danach wird der Schnittpunkt auf der Strecke

berechnet.

Die Schnittpunkte verschiedener Vertizes eines Objektes können sich auf ver-

54


schiedenen Strecken befinden, daher muss die Suche nach der richtigen Strecke

für jeden Vertex einzeln durchgeführt werden. Es ist einsehbar, dass dies insbesondere

bei großen Szenen zu hohem Rechenaufwand führt. Da alle Schritte für

jeden Vertex ausgeführt werden müssen, würde sich eine Verlagerung dieser Berechnungen

auf die Grafikhardware anbieten. Die Streckenzüge könnten hierbei

in Form von Texturen an die Grafikhardware übertragen werden. Ob die oben

vorgestellten Ansätze auf der CPU oder auf der Grafikhardware echtzeitfähig

umsetzbar sind, ist noch offen.

8.3 Relativistisches Culling

Bei sehr großen Szenen wird in der Computergrafik häufig versucht, nicht sichtbare

Teile der Szene erst gar nicht an die Grafikhardware weiterzugeben. Verfahren,

mit denen zwischen unsichtbaren und sichtbaren Teilen einer Szenen unterschieden

werden kann, gehören zur Gruppe der sogenannten Culling-Verfahren.

Es liegt nahe die nicht-relativistischen Culling Verfahren auch für die Visualisierung

großer relativistischer Szenen einzusetzen. Es zeigt sich jedoch, dass

dies aufgrund der verschiedenen relativistischen Effekte nicht direkt möglich ist,

wie die folgenden Beispiele zeigen werden.

Sichtkegel bei

0 % Lichtgeschwindigkeit

Beobachter

Sichtkegel bei

60 % Lichtgeschwindigkeit

Beobachter

Abbildung 29: Probleme beim relativistischen Frustum-Culling.

55


In der Regel blickt ein Beobachter in eine bestimmte Richtung und kann nur

einen bestimmten Bereich der Szene sehen. Dieser Sachverhalt wird beim Frustum-

Culling ausgenutzt. Für diese Art des Cullings wird ein Sichtkegel definiert,

der den Sichtbereich des Beobachters beschreibt. Alle Teile der Szene die nicht

innerhalb des Sichtkegels, dem sogenannten Frustum liegen, werden nicht dargestellt.

Bei einer relativistischen Szene zeigt sich, dass dieser Sichtbereich nicht

mehr fest definiert werden kann, sondern abhängig ist von der Geschwindigkeit

zwischen dargestellten Objekt und Beobachter. Wie in Abbildung (29) gezeigt

wird, ist bei 0 Prozent der Lichtgeschwindigkeit nur ein Raumschiff zu sehen.

Bewegen sich Szene und Beobachter jedoch mit 60 Prozent der Lichtgeschwindigkeit

zueinander, wird, aufgrund des Prinzipes der relativistischen Aberration

des Lichtes, ein größerer Bereich sichtbar und der Beobachter sieht einen Teil

des zweiten Raumschiffes.

a) b)

Abbildung 30: Probleme beim relativistischen Occlusion-Culling.

Ein weiteres Culling Verfahren ist das sogenannte Occlusion-Culling. Bei diesem

Verfahren wird der Tatsache Rechnung getragen, dass Teile der Szene durch andere

Teile verdeckt werden. Im nicht-relativistischen Fall entscheidet dann die

aktuelle Position der Objekte in der Szene, ob diese angezeigt werden müssen

oder nicht. Dagegen muss im relativistischen Fall zudem die Geschwindigkeit

zwischen den Objekten und dem Beobachter betrachtet werden. So ist das zweite

Raumschiff in Abbildung (30a) durch das erste verdeckt. Sind indes nicht beide

Raumschiffe in Ruhe zum Beobachter, sondern bewegt sich das zweite Raumschiff

mit 35 Prozent der Lichtgeschwindigkeit, wird es vollständig sichtbar (vgl.

Abb. 30b).

Aus diesen Beispielen ist bereits ersichtlich, dass für das Culling im relativistischen

Fall Annahmen des nicht-relativistischen Falles nicht immer gelten müssen.

Das nicht-relativistische Culling ist daher ein Sonderfall des relativistischen

Culling, in dem gerade alle Objekte und der Beobachter zueinander ruhen. Umgekehrt

betrachtet ist damit das relativistische Culling eine Verallgemeinerung.

Es lohnt sich daher, dieses Gebiet der relativistischen Culling Algorithmen im

Rahmen der theoretischen Informatik genauer zu untersuchen.

56


9 Modellverzeichnis

Relativistisches Haus:

Das Modell ist aus Videoaufnahmen eines echten Hauses entstanden.

Relativistische Raumschiffe:

Die Modelle stammen von den unten aufgeführten Seiten und wurden enstprechend

Kapitel 7.2.1 angepasst.

http://www.startrekaustralia.com/newindex.htm

http://www.trekmeshes.ch/

http://www.space-graphics.com/asteroid_intro.htm

http://hem.passagen.se/timov/down.htm

Relativistische Industriehalle:

Alle Modelle stammen aus Szenen zur Projektgruppe ”

Wege und Bewegungen

in virtuellen Produktionsumgebungen“ der Universität Paderborn.

http://gauge.upb.de/madh/wubivipu/

10 Verzeichnis verwendeter Programmbibliotheken

In der Software ”

Relativator“ , die mit dieser Arbeit entstanden ist, werden

insbesondere folgende Bibliotheken verwendet:

• The Visualisation Toolkit (VTK)

• CxImage

57


11 Literaturverzeichnis

Literatur

[BorKra05] Borchers, Marc und Kraus, Ute: ”

Fast lichtschnell durch die

Stadt: Visualisierung relativistischer Effekte“. Physik in unserer Zeit. Ausgabe

36(2), Seiten 64-69, (2005).

[Giulini05] Giulini, Domenico: ”

Einsteins Kunstwerk - Die Allgemeine Relativitätstheorie

- aus mittlerer Entfernung betrachtet“. Physik Journal. Ausgabe

4 Nr. 10, Seiten 27-33, (2005).

[Hsiung89] Hsiung, P.-K. und Dunn, R.H.P.: ”

Visualizing relativistic effects

in spacetime“. In Proceedings of Supercomputing ’89 Conference, Seiten 567-

606, (1989).

[Hsiung90] Hsiung, P.-K. und Thibadeau, R.H. und Wu, M.: ”

T-Buffer:

Fast Visualisation of Relativistic Effects in Spacetime“. Computer Graphics

1990. Ausgabe 24(2), Seiten 83-88.

[Møller72] Møller, Christian: ”

The theory of relativity“. Clarendon Press,

Oxford , Second Edition, (1972).

[NVCg04] ”

Cg Toolkit User’s Manual“. NVIDIA Corporation, (2004).

ftp://download.nvidia.com/developer/cg/Cg_1.2.1/Docs/Cg_Toolkit.pdf.

[WeisVis97] Rau, René T. und Ruder, Hanns und Weiskopf, Daniel:

Special Relativity in Virtual Reality“. Mathematical Visualization, Springer,


Seiten 269-279, (1998).

[OGSL04] Rost, R. und Kessenich, J. und Baldwin, D.: ”

The OpenGL

Shading Language“. (2004).

http://www.opengl.org/documentation/oglsl.html.

[Rindler82] Rindler, Wolfgang: ”

Introduction to Special Relativity“. Clarendon

Press, Oxford ,(1982).

[StepKil] Stephenson, G. und Kilmister, C.W.: ”

Special Relativity for

physicists“. Dover Publications, INC., New York.

[Sudm04] Sudmann, Oliver: ”

Algorithmen zur Visualisierung der Relativitätstheorie“.

Studienarbeit, Universität Paderborn, (2004).

[WeisTex99] Weiskopf, Daniel: ”

A texture mapping approach for the visualization

of special relativity“. In IEEE Visualization ’99 Late Breaking Hot

Topics Proceedings, Seiten 41-44, (1999).

[WeisImg00] Weiskopf, Daniel und Kobras, Daniel und Ruder, Hanns:

An Image-Based Approach to Special Relativistic Rendering“. Report Nr.


145, Eberhard-Karls-Universität zu Tübingen, (2000).

59


[WeisVirt00] Weiskopf, Daniel: An Immersive Virtual Environment for


Special Relativity“. WSCG Conference Proceedings, Seiten 337-344, (2000).

[WeisDis] Weiskopf, Daniel: Visualization of Four-Dimensional Spacetimes“.

Doktorarbeit, Eberhard-Karls-Universität zu Tübingen,


(2001).

60


12 Erklärung und Danksagung

12.1 Erklärung

Ich versichere, dass ich diese Arbeit ohne fremde Hilfe und ohne Benutzung

anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in

gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen

hat und dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen,

die wörtlich oder sinngemäß übernommen wurden, sind als solche

gekennzeichnet.

Paderborn, 29. November 2005

Oliver Sudmann

12.2 Danksagung

Für die Übernahme des Zweitgutachtens danke ich Priv.-Doz. Dr. habil. Daniel

Weiskopf.

Dr. Martin Ziegler gilt mein Dank für die Betreuung und seine nützlichen Anmerkungen

und Vorschläge für den schriftlichen und praktischen Teil dieser

Diplomarbeit.

Für die Diskussion über die Spezielle Relativitätstheorie möchte ich mich bei

Priv.-Doz. Dr. Udo Schelb bedanken. Mein Dank gilt außerdem Dipl. Inform.

Frank Götz für die nützlichen Informationen zu programmierbarer Grafikhardware

und verschiedenen Bereichen der Grafikprogrammierung.

Für die technische Unterstützung bei den Messungen bedanke ich mich bei

Dipl.-Inform. Heinz-Georg Wassing. In diesem Zusammenhang danke ich außerdem

Ralf Petring und Manuel Köster, die mir ihre Rechner für die Messungen

zur Verfügung gestellt haben.

In besonderem Maße möchte ich mich bei meiner Mutter bedanken, die mich,

soweit es ihr möglich ist, in meinem Studium unterstützt. Zuletzt möchte ich

mich bei allen Freunden und Bekannten bedanken.

61

Weitere Magazine dieses Users
Ähnliche Magazine