Punktbasiertes Rendering mit modernen Grafikkarten

Transkript

1 Punktbasiertes Rendering mit modernen Grafikkarten Diplomarbeit im Fach Informatik vorgelegt von Carsten Dachsbacher geb. am 1. Dezember 1976 in Neuendettelsau angefertigt am Institut für Informatik Lehrstuhl für Informatik 9 (Graphische Datenverarbeitung) Friedrich-Alexander-Universität Erlangen-Nürnberg Betreuer: Dipl. Inf. Christian Vogelgsang Beginn der Arbeit: Abgabe der Arbeit:

2 ii

3 Inhaltsverzeichnis 1 Einleitung Motivation Überblick über die Diplomarbeit Gegenwärtige Situation Bereits bestehende Verfahren Surfels und Surface Splatting Hardware Oriented Point-Based Rendering of Complex Scenes The Randomized Z-Buffer Algorithm QSplat Interactive Sampling and Rendering for Complex and Procedural Geometry Efficient High Quality Rendering of Point Sampled Geometry Verbesserungsmöglichkeiten Architektur moderner Grafikhardware Die OpenGL Grafikpipeline NVidia GeForce 3 und GeForce Eigenschaften Performanz OpenGL Erweiterungen Zweck und Funktionsweise Verwendete OpenGL Extensions NVidia Vertex Programs Ein- und Ausgabedaten, Register Vertex Program Befehlssatz Die OpenGL Schnittstelle Matrix Tracking Theorie des Lichttransports Physikalische Eigenschaften des Lichts Radiometrie Photometrie iii

4 4.1.3 Emission Verhalten von Licht an Oberflächen Die Bidirectional Scattering Surface Reflectance Distribution Function Die Bidirectional Reflectance Distribution Function Speicherung der BRDF in der Computergrafik Vereinfachung für kalibrierte Kamerabilder Generierung und Speicherung der Punktdatensätze Generierung aus Dreiecksnetzen mit unregelmäßiger Abtastung und variabler Punktgröße Vorgehensweise Bewertung Generierung aus Dreiecksnetzen mit regelmäßiger Abtastung und einheitlicher Punktgröße Uniform Clustering Dreiecksbasierende Splatgenerierung Vor- und Nachteile der beiden Verfahren Generierung aus kalibrierten Kamerabildern Daten und Vorgehen Die Radiance Interpolation und deren Vorteile Qualität einzelner Splats Implementationsdetails Datenstrukturen zur Speicherung Quantisierung der Koordinaten Quantisierung der Normalen Speicherung der Koordinaten Implementation der Speicherung der Koordinaten und Attribute Auflösen von Kollisionen bei der Quantisierung Optimiertes Rendering der Punktdatensätze Datenstrukturen und effiziente Ermittlung sichtbarer Flächen Allgemeine Strategie zur Datenaufbereitung Verwendete OpenGL API-Funktionen Octrees und Frustum Culling Backface Culling und Normalencluster Implementationsdetails Beleuchtungsberechnung über Texturen Rendering mit variabler Abtastdichte Anforderungen und Datenaufbereitung Rendering mit OpenGL und Vertex Programs Eine mögliche Level-of-Detail Strategie Rendering mit gleichmäßiger Abtastdichte Anforderungen und Datenaufbereitung iv

5 6.4.2 Optimiertes Rendering mit OpenGL Rendering der Datensätze aus kalibrierten Kamerabildern Datenaufbereitung Vertex Program für blickrichtungsabhängige Färbung Splatting Techniken Runde Punkte Verwendung von Vierecken zur Darstellung elliptischer Splats Approximation elliptischer Splats Qualitativ hochwertiges Splatting Weitere Verbesserungen und Optimierungen Occlusion Culling Push Pull Operationen Early Z Occlusion Culling Texturkompression Analyse der Performanzengpässe Black Box Analyse Schlussfolgerungen Beschreibung der entwickelten Programme Datengenerierung aus Dreiecksnetzen Datengenerierung aus kalibrierten Kamerabildern Darstellungsprogramm Ergebnisse und Vergleich mit anderen Verfahren Die Testdatensätze und Speicherbedarf der Daten Die Renderperformance Berechnung der benötigten Speicherbandbreite Für variable Abtastdichte und Vergleich mit QSplats Für einheitliche Abtastdichte Für die Daten aus kalibrierten Kamerabildern Visueller Eindruck der Darstellungsqualität Zusammenfassung Vorteile und entwickelte Verfahren Weitere Verbesserungsmöglichkeiten Ausblick Literaturverzeichnis 113 v

6 vi

7 Kapitel 1 Einleitung Zu Beginn dieser Arbeit soll der Begriff des punktbasierten Renderings definiert und die Motivation zum Einsatz dieser Technik erläutert werden. Im Anschluss erhält der Leser einen Überblick über diese Arbeit. 1.1 Motivation In der Computergraphik gewinnt, neben der klassischen Geometrierepräsentation durch Volumen oder Flächenbeschreibung beispielsweise durch Splines oder Dreiecksnetzen, die punktbasierte Repräsentation (point sample representation oder point based representation, kurz PBR) mehr und mehr an Bedeutung. Dabei wird eine geometrische Form lediglich durch eine genügend dichte Menge von Abtastpunkten auf ihrer Oberfläche definiert. Das punktbasierte Rendering hat sich als eine leistungsfähige Alternative zum klassischen Dreiecks-Rendering bei der Darstellung großer Mengen von Geometrie etabliert. Für den Einsatz eines punktbasierten Renderingsystems sind vor allem die Speicherung der Daten, die Renderperformance und die Darstellungsqualität von Bedeutung. Die Speicherung der Daten, insbesondere für die Datenübertragung, sollte effizient und Platz sparend sein. Die Daten bestehen aus reiner Geometrieinformation, also den Positionen der Abtastpunkten und eventuell zusätzlichen Attributen, wie z.b. Normalen oder Farbinformation, jedoch gibt es keine Topologie- oder Konnektivitätsinformation, die gespeichert werden müsste. Allerdings umfassen die Punktdatensätze meist eine große Anzahl von Abtastpunkten und es ist nicht ohne weiteres möglich, eine geometrische Koheränz in unstrukturierten Punktwolken auszunutzen. Eine Lösung bietet hier ein hierarchisches Quantisierungsschema, das sowohl eine kompakte Repräsentation der Koordinaten als auch der Attribute erlaubt. Die Renderingperformance ist der wichtigste Aspekt, der zum punktbasiertem Rendering motiviert und hierauf liegt - neben der effizienten Speicherung - auch das Hauptaugenmerk dieser Arbeit. Vor allem beim Rendering von komplexen 3D Modellen mit sehr hohem Detail kann es vorkommen, dass die projizierte Fläche von Dreiecken kleiner als ein Pixel ist. In solchen Fällen ist es effizienter, einzelne Punkte als Renderingprimitiv zu verwenden, da somit weniger Daten benötigt werden und die Grafikpipeline dadurch entlastet wird. Die Einfachheit 1

8 von punktbasiertem Rendering - die hauptsächlich in der nicht benötigten Topologie liegt - ermöglicht schnelle hardwareunterstützte Implementationen. Die verschiedenen punktbasierten Renderingverfahren lassen sich in drei Kategorien einordnen. Darin enthalten ist nicht die Möglichkeit aus den Abtastpunkten wiederum ein Dreiecksnetz zu rekonstruieren und dieses mit klassischen Polygon-Rendering-Algorithmen darzustellen. Detektion der Lücken und Füllen im Screen-Space: Die einzelnen Abtastpunkte werden auf die Betrachterebene projeziert. Die eventuell entstehenden Lücken in den Oberflächen werden identifiziert und durch Interpolation der Nachbarpunkte gefüllt. Punktrendering (Generierung von genügend Abtastpunkten): Es werden adaptiv so viele Abtastpunkte im Object-Space erzeugt, dass, mit einer genügend großen Wahrscheinlichkeit, auf jeden Pixel mindestens ein Abtastpunkt fällt. Splatting: Ein Abtastpunkt wird auf die Betrachterebene projiziert, wobei aber nicht nur ein Pixel gesetzt wird, sondern auch einen Beitrag (z.b. Farbwerte) für die Nachbarpixel berechnet wird, um die Darstellung einer geschlossenen Oberfläche zu gewährleisten. Einfachere Splatting Verfahren beschränken sich darauf, lediglich mehrere Pixel große Quadrate oder Kreise anstatt einzelner Pixel zu zeichnen. Verfahren mit besserer Darstellungsqualität verwenden gefilterte oder elliptische, ausgerichtete Splats und mitteln den Beitrag aller Splats für jeden Pixel. In dieser Arbeit wurden Datenstrukturen und Verfahren zur effizienten Speicherung und zum hochperformantem Rendering von Punktdatensätze entwickelt. Die damit entstandenen Implementationen umfassen Programme zur Generierung der Datensätze aus Dreiecksnetzen und kalibrierten Kamerabildern, wofür ein Verfahren zur blickrichtungsabhängigen Qualitätsbewertung der Abtastpunkte (und somit zur Selektion) und Radianceinterpolation entwickelt wurde. Das Renderingprogramm unterstützt, nach der obigen Klassifizierung, Punktrendering und Splatting Verfahren. Die erreichte Rendergeschwindigkeit wird dabei nur durch die Transformationsleistung der Grafikhardware begrenzt. Für das Rendering werden Level-of-Detail Verfahren für punktbasiertes Rendering vorgestellt beziehungsweise sind implementiert worden. 1.2 Überblick über die Diplomarbeit In dieser Arbeit soll das punktbasierte Rendering (PBR), welches eine leistungsfähige Alternative zum klassischen Dreiecks-Rendering darstellt, betrachtet werden. Ziel dieser Arbeit ist es, zu untersuchen, welche Verfahren und Methoden sich besonders für den Einsatz auf modernen Grafikkarten, speziell der NVidia GeForce 3 und GeForce 4, eignen. Dazu wurden in Kapitel 2 zunächst bereits bestehende Verfahren untersucht und deren Vorgehensweise grundsätzlich erläutert. Die vorgestellten Verfahren, deren Ziele bezüglich des Einsatzzwecks teils unterschiedlich sind, sind Surfels [23], Surface Splatting [40], The Randomized Z-Buffer Algorithm [33], QSplats [26], Interactive Sampling and Rendering for 2

9 Complex and Procedural Geometry [30], Efficient High Quality Rendering of Point Sampled Geometry [2] und Hardware Oriented Point-Based Rendering of Complex Scenes [5]. Weiterhin werden in diesem Kapitel - allgemein gehalten - Verbesserungsmöglichkeiten aufgezeigt. Im nächsten Kapitel werden die Grundzüge der Architektur der NVidia GeForce 3 und GeForce 4 Karten vorgestellt. Diese Grafikkarten wurden als Testumgebung für die, im Zuge dieser Arbeit entwickelten Programme, festgelegt. Ein weiterer Punkt ist die Beschreibung des OpenGL Extension Mechanismus, zur Bereitstellung von erweiterter, noch nicht in den OpenGL Standard übernommener, Funktionalität und davon speziell die NVidia Vertex Programs, die in der - im Zuge dieser Arbeit - entwickelten Implementation mehrmals zum Einsatz kommen. Kapitel 4 beschäftigt sich mit der Theorie des Lichttransports und legt so die Grundlage für ein Verfahren der Datengenerierung im darauf folgenden Kapitel. Die Generierung und die effiziente Speicherung der Datensätze wird in Kapitel 5 beschrieben. Es gibt drei Arten von Datensätzen: Datensätze aus Dreiecksnetzen mit unregelmäßiger Abtastung, aus Dreiecksnetzen mit regelmäßiger Abtastung und aus einer Bildfolge von kalibrierten Kamerabildern. Die Quantisierung und Speicherung der Daten wird im Anschluss daran beschrieben. In Kapitel 6 wird letztendlich der Rendering-Vorgang beschrieben. Dies umfasst zum Einen die Beschreibung der verwendeten OpenGL Befehle und geeigneten Datenstrukturen für die Sichtbarkeitsberechnungen und das Rendering. Zum Anderen den spezifischen Ablauf des optimierten Renderings für die drei Typen von Datensätzen. Weiterhin werden eine Reihe von zusätzlich möglichen, untersuchten Optimierungen und alternativen Ansätzen vorgestellt. Die entwickelte Software und ihre Anwendung wird in Kapitel 7 vorgestellt. Die damit erzielten Ergebnisse und der Vergleich mit anderen Verfahren sind in Kapitel 8 zu finden. Diese umfasst neben der Renderperformanz auch den Speicherverbrauch und eine subjektive Einschätzung über die Darstellungsqualität. Kapitel 9 zieht abschließend Bilanz über die entwickelten Verfahren, zeigt deren Vor- und Nachteile auf und weist auf mögliche Weiterentwicklungen hin. 3

10 4

11 Kapitel 2 Gegenwärtige Situation In diesem Kapitel werden ausgesuchte Arbeiten aus dem Bereich des punktbasierten Renderings vorgestellt. Im Anschluss daran, werden mögliche Verbesserungen und die Ziele dieser Arbeit aufgezeigt. 2.1 Bereits bestehende Verfahren Es gibt eine Reihe von bereits bestehenden Verfahren für punktbasiertes Rendering. Diese verfolgen dabei ganz unterschiedliche Ansätze und Ziele. Teile dieser Arbeiten dienten als Motivation und Ideenlieferant für die in dieser Diplomarbeit entwickelten Verfahren Surfels und Surface Splatting Bei dem Surfels Verfahren von Hanspeter Pfister, Matthias Zwicker, Jeroen van Baar und Markus Gross [23] handelt es sich um einen Splatting Ansatz auf der Basis von sogenannten Surfels: ein Abtastpunkt auf einer Oberfläche mit Attributen, wie z.b. vorgefilterte Texturinformation und Parameter zur lokalen Approximation der Oberfläche. Das Ziel dieses Verfahrens ist eine qualitativ hochwertige Darstellung von komplexen geometrischen Objekten. Die zum Rendering benötigten Daten werden in einem Preprocessing Schritt generiert. Mithilfe von Ray Casting werden drei orthogonale Layered Depth Images (LDI) eines geometrischen Objektes erzeugt. Bei einem LDI werden entlang eines Strahls alle Schnittpunkte mit Oberflächen berechnet und in diesem Fall wird die Position, zusammen mit der Oberflächennormale und mehreren gefilterten Farbwerten aus Texturen, gespeichert. Die drei Layered Depth Images werden zusammengefasst als Layered Depth Cube (LDC) bezeichnet. Mit der (optionalen) so genannten 3-to-1 reduction wird eine Quantisierung der Koordinaten der drei LDIs durchgeführt und Abtastpunkte mit gleichen quantisierten Koordinaten zusammengefasst. Für das Rendering wird eine Octree Datenstruktur erzeugt, die ein hierarchisches Visibility Culling ermöglicht und verschiedene Detailstufen des Datensatzes enthält. Somit können die sichtbaren Teile des geometrischen Objektes und die dort benötigte Abtastdichte bestimmt und gezeichnet werden. 5

12 Abbildung 2.1: Beim Visibility Splatting des Surfels Verfahrens wird eine lückenlose Darstellung im Z-Buffer durch das Zeichnen von Tangent Disks, beziehungsweise einer Parallelogramm Approximation, erreicht (aus [23]). Die nach dem Culling bestimmten Surfels werden mit einem Z-Buffer Algorithmus gezeichnet, wobei durch Unterabtastung Z-Buffer Pixel ungesetzt bleiben können. Um in einem Post-Processing-Schritt die nicht gezeichneten Pixel der Oberfläche im Vordergrund des Bildes rekonstruieren zu können, muss aber dennoch ein Verdeckungstest stattfinden können. Dazu wird das Visibility Splatting eingesetzt, um die Sichtbarkeitsbestimmung von der Rekonstruktion des Bildes zu trennen: Für jeden Z-Buffer Pixel wird, wenn er gesetzt wird, eine Referenz auf den sichtbaren Surfel und der minimale Z-Wert gesetzt. Bei benachbarten Z-Buffer Pixels, die eventuell nicht von einem Abtastpunkt belegt werden, aber trotzdem zu der - vom Betrachter - sichtbaren Oberfläche gehören und somit andere Flächen verdecken, wird der Z-Buffer ebenfalls beschrieben. Dazu werden die Tangent Disks verwendet. Diese sind zur Oberfläche orthogonale Kreisscheiben, die, auf die Betrachterebene projiziert, eine Ellipsenform besitzen. Diese (bzw. eine Parallelogramm Approximation zum schnelleren Rendering) werden um den Surfel herum platziert und in den Z-Buffer gezeichnet (Abbildung 2.1). Dadurch entstehen geschlossene Oberflächen im Z-Buffer, obwohl sie durch Surfels eventuell unterabgetastet sind. Für das Rendering der Surfels wird ein gewähltes Beleuchtungsmodell und Texturemapping angewendet. Im abschließenden Schritt werden die Farbwerte für die Löcher, die im Z-Buffer als solche markiert sind, rekonstruiert. Dazu wird entweder der Push-Pull Algorithmus [8] verwendet oder die Farbwerte werden durch geeignete Filter, wie z.b. Nearest Neighbour oder Gaußfilter bestimmt. Die Implementation dieses Verfahrens verwendet ausschließlich software-basiertes Rendering zusammen mit algorithmischen Optimierungen, wie z.b. Incremental Block Warping [8], wobei das Visibility Splatting aber nicht die Rekonstruktion des Bildes durch die hardwarezugänglich ist [24]. Die Geschwindigkeit dieser Implementation ist etwas langsamer als eine OpenGL-Software-Implementation bei vergleichbarer Darstellungsqualität des Dreiecksnetzes bzw. des daraus generierten Surfel Datensatzes. Weitere Optimierungen sollen auf der Low-Level Ebene, d.h. mittels spezieller Prozessorbefehlssätze, möglich sein. 6

13 Abbildung 2.2: Radialsymmetrische Basisfunktionen beschreiben für jeden Splat einen kontinuierlichen Farbverlauf (aus [40]). Surface Splatting [40], der gleichen Autoren, konzentriert sich auf qualitativ hochwertiges Texturemapping für punktbasiertes Rendering. Als Eingabedaten liegen hier ungleichmäßig verteilte Punktmengen ohne Konnektivität vor. Mit jedem Punkt P k sind eine Normale und radialsymmetrische Basisfunktionen r k mit Koeffizienten w k assoziiert, die einen kontinuierlichen Farbverlauf beschreiben (Abbildung 2.2). Diese Funktionen und deren Koeffizienten werden in einem Vorberechnungsschritt bestimmt. Für einen beliebigen Punkt auf der Oberfläche, gegeben durch lokale Koordinaten u, lässt sich die kontinuierliche Texture Funktion f c (u) als gewichtete Summe angeben: f c (u) = k N w k r k (u u k ) (2.1) Die Basisfunktionen werden entweder so gewählt, dass sie nur lokalen Support bieten oder entsprechend begrenzt. In Surface Splatting [40] wird nun vorgestellt, wie diese Basisfunktionen beim Rendering in den Screen Space transformiert und gefiltert und dort summiert werden (Abbildung 2.3). Sowohl für die Basisfunktionen als auch die Filter werden elliptische Gaußsche Funktionen verwendet, woraus die Screen Space Elliptical Weighted Average (EWA) Funktion hergeleitet wird. Diese beschreibt den obigen Vorgang. Das Rendering, das mit einem modifizierten A-Buffer Algorithmus [3] arbeitet, bestimmt die Screen Space Funktionen jedes Splats und summiert diese auf. Abschließend wird die Beleuchtungsberechnung für alle Pixel des Bildes durchgeführt. In Object Space EWA Surface Splatting [25] beschreiben Liu Ren, Hanspeter Pfister und Matthias Zwicker einen Ansatz, der EWA Surface Splatting mit Unterstützung moderner Grafikhardware durchführen kann. Das Filtering erfolgt dabei nicht wie im letzten Verfahren im Screen Space, sondern im Object Space und kann somit als pre-processing Schritt durchgeführt werden. Das Rendering erfolgt in zwei Durchgängen. Der erste ist das Visibility Splatting bei dem ein Tiefenbild ohne Löcher in den Oberflächen in den Z-Buffer gezeichnet wird. Dazu werden für jeden Surfel genügend große, zur Normale senkrechte, Vierecke gezeichnet. Dieses Tiefenbild wird benötigt, um im zweiten Durchgang die Akkumulation der Farbwerte (ana- 7

14 Abbildung 2.3: Die Rekonstruktion der Oberfläche beim Surface Splatting erfolgt durch Akkumulation der in den Screen Space transformierten Basisfunktionen (aus [40]). log zur Summierung der Screen Space Texture Funktion) zu kontrollieren. Auch hier werden die Surfels mit Vierecken gezeichnet, die entsprechend texturiert sind. Die Implementation dieses Verfahrens nutzt die Fähigkeiten der programmierbaren Vertex und Pixel Shader von moderner Grafikhardware und erreicht bis zu drei Millionen gerenderte Punkte pro Sekunde Hardware Oriented Point-Based Rendering of Complex Scenes Dieses Verfahren von Liviu Coconu und Hans-Christian Hege [5] verfolgt einen Hybrid Ansatz aus punktbasiertem und dreiecksbasiertem Rendering, das hardwarebeschleunigt arbeitet. In einer hierarchischen Octree Datenstruktur werden sowohl das Dreiecksnetz, als auch die Punktdaten in Form von drei orthogonalen Layered Depth Images in verschiedenen Auflösungsstufen gespeichert. Die Punktattribute sind, neben der Koordinate und der Normale, Farbwerte für ambientes und diffuses Licht und Glanzlichtfarbe und -Exponent für das Phong Beleuchtungsmodell. Weiterhin werden für jeden Punkt drei Texturfarbwerte für unterschiedliche Mipmap Stufen gespeichert, die durch EWA (Elliptical Weighted Average) Filter bestimmt wurden. Für das Rendering können die Punkte bzw. Splats opak gezeichnet werden oder fuzzy. Letzteres bezeichnet einen Splat, dessen Transparenz zum Rand hin zunimmt (Abbildung 2.4). Da es hardwarebeschleunigt keine Trennung zwischen Z-Buffer Test und Blending (semitransparenter Darstellung) gibt - zumindest nur mit mindestens zwei Render-Durchgängen - wird das Rendering ohne Z-Buffer Funktionalität durchgeführt. Dazu wird die räumliche Unterteilung der Daten durch die Datenstruktur mit dem McMillan Algorithmus [15] ausgenutzt, um die Splats von hinten nach vorne zu zeichnen. Hierzu werden noch zusätzliche Tabellen benötigt, die verschiedene Sortierungen der Abtastpunkte beinhalten. Die benötigte Abtastdichte wird während dem Rendering bestimmt und der entsprechende Teil aus dem Datensatz verwendet. Sollte die Abtastdichte nicht genügen, so werden die entsprechenden Teile mit klassischem dreiecksbasierten Rendering gezeichnet. Die Schattierung der Splats kann mit einem beliebigen lokalen Beleuchtungsmodell erfolgen, da die benötigten Informationen gespeichert sind. Durch das Zeichnen von hinten nach 8

15 Abbildung 2.4: Fuzzy Splats besitzen eine zum Rand hin zunehmende Transparenz. Durch Zeichnen der Splats von hinten nach vorne können die Farbwerte akkumuliert werden (aus [5]). vorne und die nach außen hin abnehmende Transparenz der Splats, zusammen mit den gefilterten Texturwerten, ergeben sich qualitativ sehr hochwertige Bilder. Die Neigung der Splats, d.h. deren Darstellung in elliptischer Form, wird über die programmierbaren Vertex und Pixel Shader moderner Hardware erreicht: in den Pixel Shadern wird eine Approximation der Transparenzwerte für jeden Pixel eines Splats, abhängig von der Normale eines Splats und dem Winkel zur Betrachterrichtung berechnet. Die benötigten Vorberechnungen werden in einem Vertex Program durchgeführt. Dieses Verfahren liefert durch die Texturfilterung bei der Datengenerierung und beim Rendering qualitativ hochwertige Bilder bei hoher Rendergeschwindigkeit. Allerdings wird die Leistungsfähigkeit der Transformations- und Beleuchtungsberechnung bei moderner Grafikhardware nur zu etwa 30% ausgenutzt The Randomized Z-Buffer Algorithm Beim Randomized Z-Buffer Verfahren [33] von Michael Wand, Matthias Fischer, Ingmar Peter, Friedhelm Meyer auf der Heide und Wolfgang Straßer wird eine dreidimensionale Szene, die durch Dreiecke beschrieben wird, mit einem punktbasierten Renderingverfahren dargestellt. Die Menge der Abtastpunkte wird dynamisch aus zufällig erzeugten Oberflächenpunkten generiert, wodurch auch die Szene selbst eingeschränkt dynamisch veränderbar sein kann. Dazu werden die Dreiecksnetze und geeignete Datenstrukturen zur Beschleunigung der Punktgenerierung vorberechnet und gespeichert. Der Ablauf des Rendering ist wie folgt. Für gegebene Betrachterparameter wird für jede Oberfläche beziehungsweise für jedes Dreieck ein Projektionsfaktor bestimmt. Dieser hängt von der Orientierung der Oberfläche und dem Abstand zum Betrachter ab. Damit wird ein Maß definiert, wie hoch die Abtastdichte dieser Fläche sein muss. Weiterhin wird eine Wahrscheinlichkeitsabschätzung verwendet, mit der die Anzahl der benötigten zufällig verteilten Punkte bestimmt wird, um mit einer bestimmten Wahrscheinlichkeit eine geschlossene Oberfläche darzustellen. Zur schnelleren Berechnung werden hier, die bereits angesprochenen, vorberechneten Datenstrukturen zur Sichtbarkeitsberechnung und räumlichen Unterteilung (Octrees) und zur Gruppierung von Oberflächen mit ähnlichem Projektionsfaktor verwendet. Beim Sampling einer solchen Gruppe wird jeweils der maximale Projektionsfaktor verwendet, 9

16 um eine genügend hohe Abtastdichte auf allen Teilen zu gewährleisten. Nachdem die Samplingdichte für eine Gruppe von Dreiecken bestimmt wurde, werden die Punkte auf der Oberfläche erzeugt. Für die Generierung der Samples einer Gruppe werden Distribution Lists vorberechnet. Diese ermöglichen die zufällige Auswahl eines Dreiecks mit einer Wahrscheinlichkeit, die der Fläche des Dreiecks im Verhältnis zur Fläche aller Dreiecke dieser Gruppe entspricht. Ein Abtastpunkt wird erzeugt, indem ein Dreieck - wie gerade beschrieben - zufällig ausgewählt wird und ein Punkt auf der Dreiecksfläche durch eine zufällige Linearkombination der Eckpunkte erzeugt wird. Durch Caching werden die generierten Abtastpunkte temporär gespeichert, um zeitliche Koheränzen auszunutzten, d.h. bei ähnlichen Betrachterparametern, bei aufeinanderfolgenden Bildern, müssen die Abtastpunkte nicht nochmals generiert werden. Das Caching wird unabhängig für verschiedene Teile der Szene, gebunden an die Octree Struktur, durchgeführt, wobei eine least-recently-used Strategie verwendet wird. Zum eigentlichen Rendering wurde eine OpenGL Ausgabe verwendet. Große Dreiecke, deren Abtastung und punktbasiertes Rendering nicht effizient wäre, werden auch klassisch als solche gezeichnet. Die Abtastpunkte der Oberflächen werden entweder als Pixel oder OpenGL Punkte aus mehreren Pixels gezeichnet. Für qualitativ hochwertigeres Rendering, das allerdings nicht mehr in Echtzeit möglich ist, werden die Farbwerte der Pixel durch eine gewichtete Kombination von benachbarten sichtbaren Punkten berechnet. Die Ergebnisse zeigten, das der Rendering-Aufwand dieses Verfahren logarithmisch, der Speicherbedarf linear mit der Anzahl der Dreiecke wächst. Die Darstellungsqualität der generierten Bilder ist vergleichbar mit polygonbasiertem Rendering und dank der Caching Strategien erreicht dieses Verfahren interaktive Bildraten auch bei großen Dreiecksnetzen und mit niedrigerer Darstellungsqualität auch noch höhere. Ein Nachteil dieses Verfahrens ist allerdings der hohe Speicherbedarf der Datensätze, wie der erste Datensatz in [33] zeigt. Der Speicherbedarf bei Datensätzen mit vielfach replizierten Teilen darf hierbei nicht in Betracht gezogen werden QSplat Das QSplat Verfahren von S. Rusinkiewicz und Mark Levoy [26] ist im Zuge eines 3D Scanning Projektes entstanden. Aufgabe war es, die dabei entstandenen Datensätze, die aus bis zu mehreren Millionen Knoten und Dreiecken bestehen, interaktiv darstellen zu können. Dazu wurde eine einzige, sehr kompakte, Datenstruktur definiert, die sowohl für die Speicherung, als auch für das Rendering und die Sichtbarkeitsberechnung (View Frustum Culling und Backface Culling) verwendet wird. QSplat arbeitet mit einer Bounding Sphere Hierarchie (Abbildung 2.5, wobei jeder Knoten des Baumes einen Kugelmittelpunkt, -radius, eine Normale, die Breite eines Normalenkegels und optional einen Farbwert enthält. Das Rendering erfolgt rekursiv von der Wurzel des Baumes aus. Für jeden Knoten werden drei Fälle unterschieden: Knoten ist nicht sichtbar: dieser Teilast des Baumes muss nicht gezeichnet werden 10

17 Abbildung 2.5: QSplat verwendet eine Bounding Sphere Hierarchie, um die Abtastpunkte und deren Attribute zu speichern (aus [26]). Knoten ist ein Blatt des Baumes: zeichne einen Punkt/Splat Eine weitere Rekursion ist nicht sinnvoll, d.h. durch eine heuristische Entscheidung wurde festgestellt, dass die Bounding Sphere dieses Knotens kleiner als ein Schwellwert ist: zeichne einen Punkt/Splat Die Sichtbarkeit eines Knotens, und damit die des Teilbaumes, wird durch das Backface Culling mittels des Normalenkegels und das View Frustum Culling mit den Bounding Spheres berechnet. Die Größe des jeweils gezeichneten Punktes beziehungsweise Splats wird durch den, auf den Bildschirm projizierten, Radius der Bounding Sphere bestimmt. Die Beleuchtungsberechnung kann mit der gespeicherten Normale und der Farbe durchgeführt werden. Um eine korrekte Darstellung zu erhalten, wird beim Rendering ein Z-Buffer verwendet. Bei der vorliegenden QSplat Implementation ist es außerdem möglich, die Form der Punkte, z.b. rechteckig oder rund, zu wählen. Die beschriebene Datenstruktur wird in einem separatem Programm vorberechnet und als Datei abgelegt. Als Eingabedaten werden nur Dreiecksnetze akzeptiert, um die Berechnung der Normalen und Kugelradien zu vereinfachen. Die Vorgehensweise ist sehr einfach und dadurch sehr schnell. Zunächst werden nur die Knoten des Dreiecksnetzes verwendet. Die Normale eines Knotens lässt sich leicht aus dem Dreiecksnetz und den Normalen der Dreiecke bestimmen. Weiterhin wird die Größe eines Knotens, die später verwendet wird, berechnet. Diese ist das Maximum aller Bounding Sphere Radien der Dreiecke, die den Knoten enthalten. Abschließend wird der Rest der Baumhierarchie aufgebaut. Dabei wird rekursiv jeweils eine Menge von Baumknoten an der längsten Achse ihrer Bounding Box in zwei Teilbäume unterteilt und deren Bounding Sphere berechnet. Wenn die Rekursion einen der Knoten aus den Dreiecksnetzen erreicht, wird eine Bounding Sphere erzeugt, deren Größe der des Knotens (aus der obigen Berechnung) entspricht. QSplat verwendet also die Konnektivität der 11

18 Dreiecksnetze zur schnellen Generierung der Datenstruktur, aber verwirft diese dann, da sie zum Rendering nicht mehr notwendig ist. Die Speicherung des Baumes erfolgt sehr kompakt in einer quantisierten Darstellung. Die Position und der Radius einer Bounding Sphere werden relativ zu ihrem Elternknoten gespeichert. Dabei wird der Radius in Bruchteilen von 1 13 und die Position relativ in Vielfachen von 1 13 des Radius des Elterknotens angegeben. Da nicht alle der so resultierenden 13 4 Möglichkeiten Bounding Spheres ergeben, die in der des Elternknotes enthalten sind, sondern tatsächlich nur 7621 Kombinationen valide sind, wird eine Tabelle und ein 13 Bit Code dafür gespeichert. Die Normale wird auf 14 Bit quantisiert. Die darstellbaren Normalen entsprechen Punkten auf einem Würfel (um den Koordinatenursprung), wobei sich auf jeder Würfelseite Punkte (gitterförmig angeordnet) befinden. Die Farbwerte werden auf 16 Bit quantisiert, wobei jeweils 5 Bit für die rot und blau und 6 Bit für die grün Komponente vorgesehen sind. Die Breite des Normalenkegels wird relativ zum Vorgängerknoten mit nur 2 Bit gespeichert. Zusammen mit weiteren 3 Bits, die für die Handhabung der Baumstruktur notwendig sind, ergeben sich 48 Bit pro Knoten. Die Knoten werden in einer breadth-first Reihenfolge abgespeichert, womit eine progressive Übertragung der Daten möglich ist. Das Rendering der vorliegenden QSplat Implementation erfolgt mit OpenGL, wobei die einzelnen OpenGL Renderstates (z.b. für die Punktgröße: GL POINT SIZE) zur Einsparung von Application Programmers Interface (API) Aufrufen im Programm selbst nochmals gespeichert werden. Das Rendering selbst erfolgt mit den Immediate-Mode Befehlen, wie z.b. glvertex3[d,f,i,s][v]. Damit kann allerdings die Leistungsfähigkeit bezüglich der Rendergeschwindigkeit von moderner 3D Grafikhardware nicht ausgenutzt werden. Das Durchlaufen der Baumstruktur und die dynamische Erzeugung der Punktmenge stellt einen weiteren begrenzenden Faktor dar Interactive Sampling and Rendering for Complex and Procedural Geometry Bei diesem Verfahren von Marc Stamminger und George Drettakis [30] steht nicht das Rendering, sondern das dynamische, hierarchische Sampling der Oberflächen im Vordergrund. Ein Objekt, gegeben durch eine (u, v) Parametrisierung der Oberfläche wird zunächst in Sample Areas unterteilt und dafür je ein initialer Samplepunkt gespeichert, so dass die wichtigen Eigenschaften der Oberfläche erfasst werden. Diese Punkte sind in einem uniformen Gitter mit einem Abstand h angeordnet. Die beiden Vektoren, die das Gitter aufspannen, sind u 0 = (h, 0) T und v 0 = (0, h) T. Während dem Rendering wird die benötigte Abtastdichte der Sample Areas bestimmt. Diese hängt vom Winkel und Abstand zum Betrachter und der Größe der gezeichneten Splats ab. Für die lokale Verfeinerung der Abtastpunkte werden für jeden initialen Punkt mit dem 5 Sampling vier neue Punkte erzeugt, deren relative Position durch ±u 1 und ±v 1 gegeben ist (Abbildung 2.6): u 1 = 2u v 0 5, v 1 = u v 0 5 (2.2) Somit entsteht ein Gitter mit dem Abstand h/ 5 und den aufspannenden Vektoren u 1 12

19 und v 1. Diese sind um einen Winkel von α = arctan(0.5) gedreht. Die erzeugten Punkte können auch wiederum Ausgangspunkt für weitere Verfeinerung sein. Dieses Samplingschema besitzt angenehme Eigenschaften, da es uniform ist und neue Abtastpunkte zwischen bereits bestehenden eingefügt werden. Durch das 5 Sampling können Abtastpunkte effizient generiert werden. Trotzdem wird Caching verwendet, um die häufig benötigten ersten Unterteilungsschritte einzusparen. Abbildung 2.6: Diese Abbildung zeigt das initiale Gitter für die 5 Abtastung (links), das von u 1 und v 1 aufgespannte einmal unterteilte Gitter (Mitte) und ein adaptiv verfeinertes Gitter (rechts) (aus [30]). Weiterhin wird in [30] die Verwendung von Displacement Mapping und prozeduralen Objekten vorgestellt. Ein Schwerpunkt liegt auch auf dem Rendering von Landschaften, die durch eine Ebene mit Erhebungen dargestellt wird. Dadurch kann die benötigte Abtastdichte leicht bestimmt werden und Occlusion-Culling-Verfahren eingesetzt werden. Für komplexe geometrische Objekte werden durch das Abtastschema Punkte mit zufälligen (u, v) T Koordinaten generiert und gespeichert. Beim Rendering wird die benötigte Abtastdichte abgeschätzt und daraus die Anzahl dieser Zufallspunkte bestimmt, die zum Rendering verwendet werden. Das Rendering erfolgt mit OpenGL-Punkten, wobei alle Abtastpunkte in einem sequentiellen Speicherbereich abgelegt werden und dadurch mit wenigen OpenGL Aufrufen gezeichnet werden können Efficient High Quality Rendering of Point Sampled Geometry Bei diesem Verfahren von M. Botsch, A. Wiratanaya und L. Kobbelt [2] wird eine sehr effiziente, kompakte hierarchische Repräsentation für punktbasiertes Rendering von Oberflächen vorgestellt. Diese hierarchische Datenstruktur wird weiterhin verwendet, um 3D Transformationen und Shading schnell durchführen zu können. Zur Generierung der Datensätze wird, wie auch in Kapitel vorgestellt, das Uniform Clustering verwendet. Daraus resultiert eine uniforme, isotrope Abtastung der darzustellenden Oberflächen. Es wird gezeigt, dass zur Speicherung von m Abtastpunkten in der verwendeten hierarchischen Octree Datenstruktur höchstens 1 3m Bytes, unabhängig von der Quantisierungsgenauigkeit, benötigt werden, dieser Wert aber durch redundanzsparende Kodierung weiter reduziert 13

20 werden kann. Weitere Punktattribute, wie z.b. Normalen oder Farben werden quantisiert und in einer Liste gespeichert. Die Quantisierung der Normalen erfolgt mit einem Schema, das auf den Normalen der Seitenflächen eines uniform verfeinerten Oktaeders basiert, wie es auch in dieser Arbeit verwendet wird Das Rendering erfolgt mit einer softwarebasierten Implementation, wobei die Octree Datenstruktur zum einen zur Sichtbarkeitsberechnung und Backface Culling (mithilfe von Normal Cones) verwendet wird, zum anderen wird gezeigt, dass die Transformation der Koordinaten, durch Ausnutzen der hierarchischen Anordnung der Punkte, inkrementell durchgeführt werden kann. Damit reduziert sich der Aufwand auf vier Additionen und anschließend zwei Divisionen für die perspektivische Abbildung. Das softwarebasierte Rendering erlaubt eine intensive Nutzung von Lookup Tabellen für vereinfachte Beleuchtungsberechnungen und Materialeigenschaften. Optional werden zusätzlich zu Punktrendering auch Splatting Techniken eingesetzt. Dazu werden elliptischen Projektionen der (im Object Space) runden Splats vorberechnet und zum Rendering verwendet. Diese Verfahren zeichnet sich vor allem durch seine kompakte Speicherung der Daten aus. Laut [2] werden pro Punkt etwa 1 bis 1.5 Bit benötigt, optional besteht die Möglichkeit einen Korrekturwert zu speichern, um Quantisierungsfehler auszugleichen. Die Normalen, auf 13 Bit quantisiert, benötigen in komprimierter Form jeweils zwischen 5 und 8 Bit, die Farbinformation zwischen 2 und 6 Bit. Die Software Implementation ist sehr effizient und es ist möglich bis zu 14 Millionen Punkte oder 4 Millionen Splats pro Sekunde darzustellen (gemessen auf einem Athlon 1.5GHz Prozessor). Die Datenstrukturen erlauben allerdings keine direkte Umsetzung auf Grafikhardware bzw. es würden beispielsweise die Vorteile der inkrementellen Transformation wegfallen. 2.2 Verbesserungsmöglichkeiten Die in diesem Kapitel beschriebenen Verfahren zeigen sehr unterschiedliche Ansätze und Möglichkeiten auf. Teile davon dienten in dieser Arbeit als Ideenlieferant und Ausgangspunkt. Die neueren der vorgestellten Verfahren sind dabei bereits so entworfen, dass ein Einsatz moderner Grafikhardware, wie z.b. den NVidia GeForce 3 und GeForce 4 Grafikkarten, möglich ist, aber die verwendeten Datenstrukturen erfüllen entweder nicht die Anforderungen, die die aktuelle Hardware stellt oder sind nicht geeignet, um die Transformations- und Rasterisierungsleistung der Grafikhardware auszuschöpfen. Ein Hauptaugenmerk dieser Arbeit ist es, die Abtastpunkte, die aus Dreiecksnetzen oder kalibrierten Kamerabildern generiert werden, Platz sparend in Dateien abzulegen und so im Speicher aufzubereiten, dass die Sichtbarkeitsberechnung, die Beleuchtungsberechnung und das Rendering effizient möglich sind. Weiterhin wird der Einsatz von zusätzlichen Methoden, wie z.b. der Verdeckungsdetektion untersucht. Durch Versuchsreihen wurde überprüft, welche Datenrepräsentation die beste Balance zwischen Datenvolumen und -verarbeitungsgeschwindigkeit bietet. Wie in dieser Arbeit gezeigt wird, erreichen die resultierenden entwickelten Datenstrukturen ein vielfaches der Rendergeschwindigkeit anderer Verfahren. Außerdem werden neue Ansätze präsentiert, die es ermöglicht, die Punktdaten aus 14

21 kalibrierten Kamerabildern zu gewinnen und dabei sowohl die Radiance der einzelnen Punkte blickrichtungsabhängig zu speichern und zum Rendering zu verwenden, als auch ein richtungsabhängiges Qualitäts- bzw. Validitätsmaß anzugeben, mit dem Abtastpunkte selektiv vom Rendering ausgeschlossen werden können. Die entwickelten Datenstrukturen lassen sich dabei mit den meisten der vorgestellten Splatting Techniken kombinieren. 15

22 16

23 Kapitel 3 Architektur moderner Grafikhardware In diesem Kapitel erhält der Leser einen Überblick über den Aufbau der OpenGL Grafikpipeline und die Architektur der GeForce 3 und 4 Grafikkarten. Diese Kenntnisse sind notwendig, um eine effiziente Implementation von punktbasiertem Rendering zu erstellen. Im Anschluss werden die verwendeten OpenGL Erweiterungen, insbesondere die Vertex Programs, beschrieben. 3.1 Die OpenGL Grafikpipeline Abbildung 3.1: Die OpenGL Grafikpipeline (aus [12]). Die Grafikpipeline ist ein Modell für die Aufgaben die beim Rendering anfallen. Die einzelnen Teile können dabei, je nach System, in Software oder Hardware implementiert sein. Abbildung 3.1 zeigt die OpenGL Grafikpipeline, die sich aus drei wesentlichen Abschnitten 17

24 zusammensetzt. Der erste Teil ist das Geometry Processing, das auch als Transform and Lighting bezeichnet wird. Er besteht aus der Transformation der Koordinaten vom Objectbeziehungsweise Worldspace in den Eyespace, der Beleuchtungsberechnung, der Projektionsabbildung und dem Clipping und der Viewport Transformation. Das herkömmliche Geometry Processing in OpenGL wird auch als Fixed-Function Pipeline bezeichnet und kann durch die Vertex Programs, die in diesem Kapitel noch beschrieben werden, ersetzt werden. Beim zweiten Abschnitt handelt es sich um die Rasterisierung, bei der die Renderingprimitive gezeichnet und die Farb- und Alphawerte der gerenderten Fragmente aus der berechneten Beleuchtung und Texturierung zusammengesetzt werden. Auch dieser Teil kann bei neuerer Grafikhardware durch eine konfigurierbaren beziehungsweise programmierbaren Variante, den so genannten Pixel Shadern, ersetzt werden. Den letzten Teil der Grafikpipeline bilden die pro Fragment durchgeführten Operationen. In der aktuellen Grafikhardware, praktisch aller Hersteller von Grafikkarten für den Consumermarkt, sind alle drei Abschnitte der Grafikpipeline in Hardware implementiert. Die drei kritischen Aspekte, die die Leistungsfähigkeit der Hardware bestimmen, sind: Das Geometry Processing, also die Rechenleistung für Transformation, Beleuchtung und Clipping Die Rasterisierungsleistung Die beschränkte Speicherbandbreite für Geometrieübertragung und Rasterisierung In den folgenden Abschnitten werden die - für diese Arbeit wichtigen - Eigenschaften der NVidia GeForce 3 und GeForce 4 Grafikkarten aufgezeigt. Hauptaugenmerk liegt dabei vor allem auf der GeForce 3 Technik, weil diese auch für die Entwicklung der vorliegenden Implementation verwendet wurde und die GeForce 4 Grafikkarten ohnehin keine grundlegend andere Architektur besitzen. Da genaue Spezifikationen über den Aufbau der Architektur und der internen Funktionsweise nicht verfügbar sind, muss sich die Beschreibung auf, vom Hersteller NVidia freigegebene, Dokumente und Berichte über andere Untersuchungen beschränken. 3.2 NVidia GeForce 3 und GeForce 4 In diesem Abschnitt wird die Architektur der NVidia GeForce 3 und GeForce 4 GPUs (Graphic Processing Units) beschrieben. Diese Hardwareplattform wurde als Basis für die, im Zuge dieser Arbeit, entwickelten Implementationen gewählt Eigenschaften Wie bereits erwähnt, beziehen sich die folgenden Angaben hauptsächlich auf die Architektur der GeForce 3 Karten. Als Schnittstelle für die Grafikkarte dient meist der von Intel 1997 eingeführte Accelerated Graphics Port [21], kurz AGP. Die Peripheral Component Interconnect, kurz PCI, Schnittstelle verliert für Grafikhardware zunehmend an Bedeutung. Die AGP Spezifikation beinhaltet bislang drei verschiedene Übertragungsgeschwindigkeiten 18

25 AGP1x, AGP2x und AGP4x mit 266, 533 beziehungsweise 1066 Megabyte pro Sekunde und erlaubt der Grafikhardware auf den Hauptspeicher des Rechners zuzugreifen. Kürzlich wurde die Übertragungsgeschwindigkeit nochmals erhöht und der AGP8x Standard eingeführt. Die Leistungsdaten verschiedener GeForce Graphic Processing Units (GPU) sind in Tabelle 3.1 aufgeführt, wobei auch die interne Speicherbandbreite aufgezeigt wird. GeForce4 GeForce4 GeForce4 GeForce3 GeForce3 Ti4600 Ti4400 Ti4200 Ti500 GPU Taktfrequenz (MHz) Speicher Taktfrequenz (MHz) Speicher Bandbreite (MB/s) Tabelle 3.1: Die Leistungsdaten verschiedener GeForce GPUs. Die Transformations- und Beleuchtungsberechnung, die Entfernung nicht sichtbarer Rückseiten, sowie die Kappung von Primitiven kann durch die Hardware selbst durchgeführt werden. Zusätzlich zu der so genannten Fixed Function Pipeline können die Transformations- und Beleuchtungsberechnungen, wie bereits erwähnt, durch die Vertex Programs ersetzt werden, die mit einer Assemblersprache arbeiten. Da sie in der Implementation zu dieser Arbeit eingesetzt wird, ist ihr ein eigener Abschnitt 3.4 gewidmet. Zur Beschleunigung von klassischem dreiecksbasiertem Rendering stehen zwei Cache Speicher zu Verfügung. Der erste, mit einer Größe von vier Kilobyte (bei einer GeForce 3 GPU), befindet sich in der Grafikpipeline vor der Transformations- und Beleuchtungsberechnung und dient zur Zwischenspeicherung von Vertexdaten, um Speicherzugriffe zu reduzieren. Der zweite Cache Speicher beinhaltet die Informationen pro Vertex für die Rasterisierung und kann die Daten für bis zu 24 Vertices zwischenspeichern. Bei der Rasterisierung der Primitive stehen eine Vielzahl von Texturemapping-Techniken zur Verfügung, wobei sowohl das Texture Fetching, d.h. das Auslesen der Texel, als auch das Blending konfigurierbar sind. Diese Optionen werden als Pixel Shader bezeichnet. Die Texturen können sich dabei, ohne Leistungseinbußen, in komprimierter Form im Speicher befinden. Dazu wird meist das S3-Texture-Compression-Verfahren verwendet. In einem Renderingpass können bis zu vier Texturen gleichzeitig adressiert werden, wobei der Zugriff auf ein oder zwei Texturen einen Taktzyklus, drei oder vier Texturen zwei Taktzyklen während dem Rendering benötigen. Für die Renderingleistung bei moderner Hardware, die hohe Leistungen bei der Geometrietransformation und dem Rasterisieren bereitstellt, ist die Latenzzeit und die Granularität der Speicherzugriffe entscheidend. Bei geometrischen Primitiven von wenigen Pixels und somit vor allem bei punktbasiertem Rendering, werden oft kleine Bereiche unterschiedlicher Speicherstellen gelesen, z.b. jeweils ein Wert aus Z- und Farbpuffer. Die GeForce Grafikhardware besitzt die so genannte Lightspeed Memory Architektur mit einem Crossbar Memory Controller. Dieser teilt die 256 Bit breiten Speicherzugriffe in vier Einheiten mit 64 Bit Granularität auf. Die weiteren Fähigkeiten der Lightspeed Memory Architektur sollen dazu dienen, die benötigte Speicherbandbreite zu reduzieren. Dazu wird ein Verfahren verwendet, das 19

26 eine verlustfreie Kompression der Z-Buffer Daten während dem Rendering vornimmt. Es verarbeitet vermutlich einzelne Pixelblöcke unabhängig voneinander, wie es bei Grafikhardware anderer Hersteller (z.b. ATI) auch der Fall ist und lässt sich eher als hierarchische Repräsentation des Z-Buffers deuten. Durch eine solche hierarchische Darstellung, deshalb die zuletzt genannte Vermutung, ist das Z-Occlusion-Culling möglich. Dabei handelt es sich um einen vorgezogenen Tiefentest zwischen der Vorbereitung und der Durchführung der Rasterisierung. Bei dem Unterschied der GeForce 4 zu den GeForce 3 GPUs handelt es sich in erster Linie um eine Leistungssteigerung bei einer Vielzahl von Aspekten, in erster Linie der Taktfrequenzsteigerung, erhöhte Bandbreite und Füllrate und parallelisierte Ausführung von Vertex Programs. Weitere Techniken, die für das punktbasierte Rendering eingesetzt werden können, wurden dabei nicht eingeführt Performanz Da der Allgemeinheit keinerlei Information über den internen Aufbau der GPUs zugänglich ist, kann die Leistungsfähigkeit der Grafikhardware nur durch Analyse von Testreihen mit unterschiedlichen Grafikdaten und -mengen erfolgen [4]. Daraus sind beispielsweise Rückschlüsse auf die Transformationsleistung und die begrenzenden Faktoren einer konkreten Implementation möglich. Wie in Kapitel 8 gezeigt wird, sind für das punktbasierte Rendering, mit der Technik die im Zuge dieser Arbeit entwickelt wurde, vor allem die Leistung bei der Koordinatentransformation und der Beleuchtungsberechnung, zusammen mit der Speicherbandbreite von Bedeutung. 3.3 OpenGL Erweiterungen Der OpenGL Extension Mechanismus bietet die Möglichkeit, eine bestehende OpenGL Version um bestimmte Funktionalitäten zu erweitern. Diese Möglichkeit wird von den Grafikkartenherstellern eingesetzt, um die speziellen Fähigkeiten ihrer Hardware zugänglich zu machen, ohne oder bevor sie in eine neue OpenGL Spezifikation eingeflossen ist. Die Beschreibungen der Erweiterungen werden in der so genannten OpenGL Extension Registry [10] gesammelt Zweck und Funktionsweise Die Namensgebung der Erweiterung folgt dabei einem vorgegebenen Schema. Die einzelnen Wörter innerhalb des Namens sind nicht durch Leerzeichen, sondern Unterstriche getrennt. Jeder Name beginnt mit einem Prefix, an dem zu erkennen ist, wer die Erweiterung entwickelt hat oder ob es sich beispielsweise um eine Erweiterung handelt auf die sich mehrere Hersteller geeinigt haben. Um Informationen zu erhalten, welche OpenGL Hardware und welche Erweiterungen einer Applikation zur Verfügung stehen, wird der const GLubyte *glgetstring( GLenum name ) Befehl verwendet. Mit ihm können Zeichenketten, deren Inhalt die Hardware, den Hersteller der OpenGL Implementation und die unterstützten Erweiterungen beschreibt, angefor- 20

27 dert werden. Im letzten Fall wird eine Zeichenkette zurückgeliefert, in der die Namen der unterstützten Erweiterungen, durch Leerzeichen getrennt, aufgelistet sind. Somit lässt sich feststellen, ob die gewünschte Funktionalität zur Verfügung steht. Durch die Erweiterungen werden auch neue OpenGL Methoden, Konstanten und Enumerants definiert. Die letzteren sind in einer Header Datei definiert, die jeweils - zentral bei Silicon Graphics - aktualisiert wird und verwendet werden kann. Um die neuen OpenGL Methoden verwenden zu können, müssen die Funktionsprototypen und zugehörige -variablen definiert werden und die Funktionsadressen angefragt werden. Dazu stehen für die Microsoft Windows Plattform der Befehl PROC wglgetprocaddressarb(lpcstr lpszproc) zur Verfügung. Der entsprechende Befehl für X Windows Systeme lautet void (*glxgetprocaddressarb(const GLubyte *))(). Als Parameter wird jeweils der Name der Funktion übergeben, deren Speicheradresse zum Aufruf abgefragt werden soll Verwendete OpenGL Extensions Im Zuge dieser Arbeit wurden eine ganze Reihe von OpenGL Erweiterungen verwendet und auf ihre Tauglichkeit für oder im Zusammenwirken mit effizientem punktbasiertem Rendering untersucht. In diesem Abschnitt befindet sich eine Auflistung und eine kurze Beschreibung des Zwecks der verwendeten Erweiterungen. Die jeweilige Beschreibung der Anwendung ist den späteren Kapiteln, in denen der Renderingvorgang beschrieben wird, vorenthalten. Die ARB multitexture Erweiterung stellt die notwendige Funktionalität zur Verfügung, um in einem Renderpass, d.h. in einem Durchgang beim Rendering, mehr als eine Textur gleichzeitig zu verwenden. Hierzu gehören verschiedene Sätze von Texturkoordinaten und Textur-Einheiten, die separat konfiguriert werden können. Die beiden ARB texture compression und GL EXT texture compression s3tc Erweiterungen bieten die Möglichkeit, Texturen in einer komprimierten Form, aber trotzdem direkt von der Grafikkarte verwendbar, im Speicher abzulegen. Bei der ersten handelt es sich um eine inzwischen vom OpenGL Architecture Review Board akzeptierte Erweiterung. Es wird hierbei aber nicht definiert, mit welchem Verfahren die Texturen komprimiert werden. Auf die zweite haben sich, wie am EXT-Prefix zu erkennen ist, bereits mehrere Hersteller von Grafikkarten geeinigt. Hierbei wird das S3 Texture Compression Verfahren, das in Microsofts DirectX API als DXTC bezeichnet wird, verwendet. Eine weitere Fähigkeit von moderner Grafikhardware ist, mit dreidimensionalen Texturen zu arbeiten. Die dazugehörige OpenGL Erweiterung wurde mit EXT texture3d bezeichnet. Die EXT compiled vertex array Erweiterung definiert ein Interface, das es erlaubt, statische Vertexdaten in Arrays als solche zu kennzeichnen, um Caching Verfahren, Optimierungen durch den Grafikkartentreiber anzuwenden oder die Daten beispielsweise dauerhaft in den Speicher der Grafikkarte abzulegen. Das Rendering der Punktdaten in OpenGL Arrays, kann beispielsweise mit dem gldrawarrays Befehl angestoßen werden. Dabei wird der erste Vertex im Arrays und die Anzahl der darauf folgenden, zu zeichnenden Vertices angegeben. Die EXT multi draw arrays Erweiterung stellt Befehle zur Verfügung denen jeweils eine Liste mit Startindizes und Anzahl der Vertices übergeben wird. Dadurch kann der Overhead der OpenGL Application Pro- 21

28 grammers Interface (API) Aufrufe reduziert werden, wenn viele - nicht zusammenhängende - Fragmente eines Arrays benötigt werden. Wenn die NV point sprite Erweiterung zur Verfügung steht, können die OpenGL Point Renderprimitive mit Texturen versehen werden. Dabei werden automatisch die Texturkoordinaten beim Rendering auf der Punktfläche interpoliert. Außerdem kann eine lineare oder quadratische Funktion angegeben werden, die aus der Entfernung zum Betrachter die Größe des Punktes auf dem Bildschirm bestimmt. Mit der NV occlusion query Extension ist es möglich, festzustellen, ob beziehungsweise wie viele Pixel bei einem Renderingvorgang tatsächlich in den Frame Buffer geschrieben wurden und nicht etwa durch andere Objekte verdeckt sind (festgestellt durch Z-Buffer Tests) oder Alpha oder Stencil Tests nicht bestanden haben. Sie wird dazu verwendet, um das so genannte Occlusion Culling durchzuführen. Dabei wird festgestellt, ob ein zu renderndes Objekt tatsächlich sichtbar oder durch andere verdeckt ist. Im letzteren Fall muss es nicht gezeichnet werden. Typischerweise wird für diesen Test eine vereinfachte geometrische Repräsentation oder ein Begrenzungsvolumen, das das 3D Objekt enthält, verwendet. Die NV vertex array range Erweiterung dient dazu der Grafikhardware direkten Zugriff auf die - für das Rendering benötigten - Daten über Direct Memory Access (DMA) zu gestatten und somit die Verarbeitungsgeschwindigkeit für die Geometrie zu verbessern. Der NV vertex program beziehungsweise NV vertex program1 1 Erweiterung für NVidia Vertex Programs ist ein eigener Abschnitt gewidmet, da sie einer genaueren Beschreibung bedarf. 3.4 NVidia Vertex Programs Die NVidia Vertex Programs sind Programme in einer speziellen Assembler Sprache. Diese können die herkömmliche Fixed-Function Geometrieverarbeitung der Grafikpipeline ersetzten (Abbildung 3.1). Da es sich um eine Ersetzung handelt, sind sie unter Anderem dafür verantwortlich für, aber nicht beschränkt auf, die Transformation der Vertexkoordinaten in den Clip-Space, die Beleuchtungsberechnung und die Generierung von Texturkoordinaten. Die Beschreibung der Vertex Programs in diesem Abschnitt bezieht sich auf die, die ab den NVidia GeForce 3 Grafikkarten unterstützt werden. Neuere Grafikkarten können einen erweiterten Befehlssatz oder Adressraum besitzen. Ein Vertex Program bearbeitet immer nur einen Vertex gleichzeitig. Da es keine Adjazenzinformation kennt, ist es nicht möglich Renderingprimitive wie Dreiecke zu bearbeitet. Außerdem ist es auch nicht in der Lage neue oder zusätzliche Vertices zu erzeugen. Ein Vertex Program wird für jeden benötigten Vertex ausgeführt. Dabei kann auf vier verschiedene Speichertypen zugegriffen werden: die Eingabedaten des untransformierten und nichtbeleuchteten Vertex, temporäre Arbeitsregister, Konstantenspeicher und die Ausgabedaten (Abbildung 3.2). Die Berechnungen erfolgen dabei stateless, d.h. das Resultat des Vertex Programs hängt von den Eingabedaten und dem Konstantenspeicher, den ein Vertex Program nicht beschreiben kann, ab. Deshalb können keine Berechnungsresultate gespeichert werden, die für Berechnungen zu einem späteren Zeitpunkt zur Verfügung stehen. 22

29 Abbildung 3.2: Die Speichertypen und die Anzahl der Register für die Vertex Programs eines GeForce 3 GPU Ein- und Ausgabedaten, Register Bei den vier Speichertypen wird über eine Adresse jeweils auf ein Quadrupel von vier vorzeichenbehafteten IEEE 32 Bit Gleitkommazahlen zugegriffen. Diese Vektoren können unterschiedliche Daten repräsentieren: Positionen (xyzw), Texturkoordinaten (uvwq), Farben (rgba) oder allgemein vier Skalarwerte (abcd). Die Eingabedaten eines Vertex Program sind nur lesbar. Sie beinhalten typischerweise die Model-Space-Vertex-Koordinaten, die Vertex-Farbe und Texturkoordinaten. Es stehen bis zu 16 dieser Eingaberegister, bezeichnet mit v[0] bis v[15], zur Verfügung. Jedes Register beinhaltet einen bis vier Gleitkommawerte. Die Applikation bestimmt, welche Register, mit welchen Daten, dem Vertex Program zur Verfügung stehen. In der Tabelle 3.2 sind die Eingaberegister, inklusive ihrer herkömmlichen semantischen Bedeutung, aufgelistet. Der Konstantenspeicher besteht aus 96 Speicherplätzen, c[0] bis c[95], und ist für die Vertex Programs nur lesbar. Der Inhalt kann nur durch die Applikation beschrieben werden. Deshalb werden dort normalerweise Daten gespeichert, die pro Bild oder pro 3D Objekt veränderlich sind, wie z.b. Transformationmatrizen, Materialeigenschaften oder Beleuchtungsparameter. Auf die 12 Temporärregister, R0 bis R11, kann ein Vertex Program frei zugreifen, also lesen und schreiben. Der Inhalt dieser Register wird jeweils zu Beginn eines Vertex Programs auf einen initialen Wert gesetzt. Eine Ausnahme stellt das Adressregister a0 dar. Es kann nur beschrieben und zur indirekten Adressierung innerhalb des Konstantenspeichers verwendet werden. Dabei ist nur die Verwendung der ersten Komponente des a0 Registers zulässig. Die Resultate der Vertex Programs werden in den Ausgaberegister gespeichert. Diese Register sind nur beschreibbar und ihr Inhalt wird in der Grafikpipeline verwendet. Auch diese Register sind benannt, aber ihre Semantik ist dadurch nicht zwingend vorgegeben, denn spätere Stufen der Grafikpipeline können wiederum frei programmierbar sein. In der Tabelle 3.3 sind die normalen Bedeutungen, die auch in dieser Arbeit so verwendet werden, angegeben. 23

30 Register Mnemonik Name herkömmliche Semantik v[0] v[opos] Vertex Koordinate v[1] v[wght] Vertex Weight (für Blending) v[2] v[nrml] Normale v[3] v[col0] primäre Farbe v[4] v[col1] sekundäre Farbe v[5] v[fogc] Fog Koordinate v[6] v[7] v[8] v[tex0] Textur Koordinate 0 v[9] v[tex1] Textur Koordinate 1 v[10] v[tex2] Textur Koordinate 2 v[11] v[tex3] Textur Koordinate 3 v[12] v[tex4] Textur Koordinate 4 v[13] v[tex5] Textur Koordinate 5 v[14] v[tex6] Textur Koordinate 6 v[15] v[tex7] Textur Koordinate 7 Tabelle 3.2: Die Eingaberegister der Vertex Programs. Eine Ausnahme stellen die so genannten Vertex State Programs dar. Ihr Aufbau und Befehlssatz gleicht dem der herkömmlichen Vertex Programs, aber ihre Aufgabe ist es nicht Vertices zu transformieren. Sie werden explizit von der Applikation ausgeführt und dienen dazu, um beispielsweise Vorberechnungen durchzuführen und in den Konstantenspeicher zu schreiben Vertex Program Befehlssatz Ein Vertex Program besteht aus bis zu 128 Befehlen, die aus einem speziellen Befehlssatz stammen. Die Instruktionen selbst operieren auf der Basis der Gleitkomma-Quadrupel und ermöglichen eine Vielzahl von Berechnungen für die Transformations und Beleuchtungsberechnung und eine Reihe weiterer Aufgaben. Der Befehlssatz umfasst allerdings keine Sprung-, Verzweigungs- oder Schleifenbefehle und auch keine Möglichkeit, ein Vertex Program während der Ausführung vorzeitig zu beenden. Programmkonstrukte mit bedingten Ergebnissen, so genannte IF-THEN-ELSE Konstrukte, sind aber trotzdem möglich. Wie bei anderen SIMD (Single Instruction Multiple Data) Befehlssätzen, stehen Vergleichsoperationen zur Verfügung, deren Ergebnis als 1 oder 0 in Registern gespeichert wird. Durch Multiplikation des Vergleichsergebnis (beziehungsweise seiner Umkehrung) mit den Resultaten der beiden IF Programmäste und anschließender Addition lässt sich ein solches Konstrukt nachbilden. Der Vertex Program Befehlssatz ist, zusammen mit der Bedeutung der Opcodes, in der Tabelle 3.4 aufgelistet und folgt dem Format: Opcode d, [-]s0 [,[-]s1 [,[-]s2]], 24

31 Register Name Semantik Komponenten Interpretation o[hpos] homogene Koordinaten (x,y,z,w) o[col0] primäre Farbe (vorne) (r,g,b,a) o[col1] sekundäre Farbe (vorne) (r,g,b,a) o[bfc0] primäre Farbe (hinten) (r,g,b,a) o[bfc1] sekundäre Farbe (hinten) (r,g,b,a) o[fogc] Fog Koordinaten (x,y,z,w) o[psiz] Point Size (x,y,z,w) o[tex0] Textur Koordinaten Set 0 (u,v,w,q) o[tex1] Textur Koordinaten Set 1 (u,v,w,q) o[tex2] Textur Koordinaten Set 2 (u,v,w,q) o[tex3] Textur Koordinaten Set 3 (u,v,w,q) o[tex4] Textur Koordinaten Set 4 (u,v,w,q) o[tex5] Textur Koordinaten Set 5 (u,v,w,q) o[tex6] Textur Koordinaten Set 6 (u,v,w,q) o[tex7] Textur Koordinaten Set 7 (u,v,w,q) Tabelle 3.3: Die Ausgaberegister der Vertex Programs und ihre Bedeutung. Wobei d das Zielregister und s0, s1 und s2 die Quellregister sind. Unter den Quellregisters darf sich jeweils nur ein Eingaberegister und ein Konstantenregister befinden. Es darf aber dasselbe Register mehrmals verwendet werden. Die Temporärregister unterliegen keinen Beschränkungen. Bei jeder Instruktion ist es möglich, für die Zielregister eine Maske anzugeben, welche Komponenten beschrieben werden: durch einen Punkt vom Registernamen getrennt, werden die Komponentenbezeichner aufgelistet, z.b..yw. Wenn keine Maske explizit angegeben wird, ist das gleichbedeutend mit.xyzw. Jedes Quellregister kann optional, durch voranstellen eines Minuszeichens, negiert werden. Außerdem kann ein Component Swizzle durchgeführt werden, d.h. jede Quadrupelkomponente (x, y, z und w) kann - in dem zur Berechnung verwendeten Quadrupel - an beliebiger Stelle (auch mehrfach vorkommend) stehen. Beispielsweise kann die x-komponente vervierfacht werden mit.xxxx oder die Reihenfolge verdreht werden mit.wzyx. Dabei sind alle 256 möglichen Kombinationen erlaubt. Die Ausführungszeit eines Vertex Programs ist proportional zu der Anzahl der enthaltenen Instruktionen. Wenn zusätzlich zur NV vertex program Erweiterung auch die NV vertex program1 1 zur Verfügung steht, kann auf einen erweiterten Befehlssatz zurückgegriffen werden. Zusätzlich gibt es eine Option, die es ermöglicht mit einem Vertex Program, exakt dieselben homogenen Koordinaten und Window-Space-Koordinaten wie bei der konventionellen OpenGL Transformation zu erhalten. Dies ist ansonsten nicht zwingend der Fall. 25

32 Befehl Beschreibung ABS d, s0 d.c = ( s0.c >= 0 )? s0.c : -s0.c ADD d, s0, s1 d.c = s0.c + s1.c ARL A0.x, s0.c A0.x = s0.c DP3 d, s0, s1 d.x = d.y = d.z = d.w = s0.x s1.x + s0.y s1.y + s0.z s1.z DP4 d, s0, s1 d.x = d.y = d.z = d.w = s0.x s1.x + s0.y s1.y + s0.z s1.z + s0.w s1.w DPH d, s0, s1 d.x = d.y = d.z = d.w = s0.x s1.x + s0.y s1.y + s0.z s1.z + s1.w DST d, s0, s1 d.x = 1 d.y = s0.y s1.y d.z = s0.z d.w = s1.w EXPP d, s0 d.x = 2 s0.w d.y = s0.w - s0.w d.z = 2 s0.w d.w = 1 LIT d, s0 d.x = 1 d.y = (s0.x > 0)? S0.x : 0 d.z = (s0.x > 0 && s0.y > 0)? s0.y s0.w : 0 d.w = 1 LOGP d, s0 d.x = d.y = d.z = d.w = (s0.w!= 0 )? log( s0.w ) log(2) : MAD d, s0, s1 d.c = s0.c s1.c + s2.c MAX d, s0, s1 d.c = ( s0.c >= s1.c )? s0.c : s1.c MIN d, s0, s1 d.c = ( s0.c < s1.c )? s0.c : s1.c MOV d, s0 d.x = s0.x; d.y = s0.y; d.z = s0.z; d.w = s0.w; MUL d, s0, s1 d.c = s0.c s1.c NOP RCC d, s0 d.x = d.y = d.z = d.w = sign( s0.x ) min( , max( , s0.x ) ) RCP d, s0 d.x = d.y = d.z = d.w = 1 (s0.w == 0 )? : s0.w RSQ d, s0 d.x = d.y = d.z = d.w = (s0.w == 0 )? : 1 s0.w SGE d, s0, s1 d.c = ( s0.c >= s1.c )? 1 : 0 SLT d, s0, s1 d.c = ( s0.c < s1.c )? 1 : 0 SUB d, s0, s1 d.c = s0.c - s1.c Tabelle 3.4: Der Befehlssatz der Vertex Programs der Version 1.1. Bei den bedingten Zuweisungen wurde eine C ähnliche Syntax verwendet. Bei komponentenweiser Berechnung wird repräsentativ nur eine Komponente mit.c dargestellt. 26

33 3.4.3 Die OpenGL Schnittstelle Wie bereits erwähnt, können die, von der Grafikhardware und dem -Treiber unterstützten, OpenGL Erweiterungen über den OpenGL Extensionstring abgefragt werden. Für die Vertex Programs wird die NV vertex program Erweiterung benötigt. Die von NVidia bereitgestellten Schnittstellen und Methoden entsprechen weitgehend dem traditionellen OpenGL Schema, bei dem für Objekte so genannte Identifier generiert werden. Mit diesen werden jeweils einzelne Texturen, Vertex Programs oder Display Lists unterschieden. In diesem Abschnitt sollen die wichtigsten Methoden erläutert werden, die auch in der Implementation zu dieser Arbeit Anwendung finden. Zu Beginn werden mit dem void GenProgramsNV(sizei n, uint *ids) Befehl die gewünschte Anzahl n von Identifiers angefordert. Analog zu dem oben genannten Schema wird mit void glbindprogramnv(enum target, uint id) ein Vertex Program mit einer vorher angeforderten Indentifikationszahl selektiert. Der einzige zulässige Parameter für target - bei diesem und den darauf folgenden Funktionsaufrufen - ist dabei GL VERTEX PROGRAM NV. Die Vertex Programs selbst werden als einfache ASCII Zeichenketten gespeichert und dem void LoadProgramNV(enum target, uint id, sizei len, const ubyte *program) Befehl als Parameter übergeben. Um den Konstantenspeicher zu beschreiben werden verschiedene Befehle bereitgestellt, um Gleitkommazahlen in einfacher oder doppelter Genauigkeit und direkt oder über deren Speicheradresse zu übergeben. Zu dieser Klasse von Befehle gehört beispielsweise der Befehl void ProgramParameter4fNV(enum target, uint index, float x, float y, float z, float w) mit dem vier Gleitkommazahlen mit einfacher Genauigkeit in Konstantenspeicher an der Adresse index abgelegt werden. Mit dem glenable beziehungsweise gldisable Befehl kann die Fixed-Function Pipeline durch ein Vertex Program ersetzt werden, indem es aktiviert beziehungsweise deaktiviert wird. Der Name des Parameters für die beiden Befehle ist auch hier wieder als GL VERTEX PROGRAM NV definiert. Wenn die Punktgröße für das Rendering von Punkten in einem Vertex Program berechnet wird, muss die Verwendung des Wertes aus dem Vertex Program explizit erfolgen. Dies geschieht mithilfe von glenable( GL VERTEX PROGRAM POINT SIZE NV ) Matrix Tracking Beim so genannten Matrix Tracking ist es möglich, die jeweils aktuellen OpenGL Matrizen, d.h. die Projektions-, Modelview- und Texturematrizen, also auch eine Konkatenation aus Projektions- und Modelview-Matrix in den Konstantenspeicher abzubilden. Dabei stehen einem Vertex Program in vier aufeinander folgenden Stellen des Konstantenspeichers die Zeilenvektoren einer gewählten Matrix zur Verfügung. Weiterhin kann angegeben werden, dass die gewünschte Matrix beispielsweise invertiert zur Verfügung gestellt werden soll. Das Matrix Tracking wird mit dem void TrackMatrixNV(enum target, uint address, enum matrix, enum transform) Befehl vorgenommen. Mit address wird dabei die erste Speicherstelle im Konstantenspeicher bezeichnet, matrix bestimmt welche Matrix abgebildet werden 27

34 soll und mit transform kann eine optionale Transformation der Matrix, z.b. die Matrixinversion, gewählt werden. Häufig verwendet wird das Matrix Tracking für die Konkatenation aus Projektions- und Modelview-Matrix, um die Transformation der Vertex-Koordinaten in den Clip-Space durchzuführen und die inverse Modelview Matrix für die Beleuchtungsberechnung. 28

35 Kapitel 4 Theorie des Lichttransports In diesem Kapitel wird die Theorie des Lichttransportes und ihre Anwendung in der Computergrafik beschrieben. Das Hauptaugenmerk liegt dabei auf der Bidirectional Reflectance Distribution Function und ihrem - vereinfachtem - Einsatz beim Rendering der Punktdatensätze, die aus Kamerabildern generiert wurden. 4.1 Physikalische Eigenschaften des Lichts Aus physikalischer Sicht handelt es sich bei Licht um eine Form von elektromagnetischer Strahlung. Das menschliche Auge kann davon den Wellenlängenbereich zwischen dem Ultravioletten- und Infrarotenlicht, also von etwa 380nm bis 770nm wahrnehmen. In der Computergrafik wird praktisch ausschließlich das Modell der geometrischen (Strahlen) Optik verwendet mit der Effekte wie Spiegelung, Lichtbrechung und Beschattung beschrieben werden können. Andere Modelle sind beispielsweise die Wellenoptik, mit der Interaktionen zwischen Licht und Objekten deren Größenordnung mit der Wellenlänge vergleichbar ist beschrieben werden oder die Quantenoptik, die sich mit der Wechselwirkung zwischen einzelnen Photonen und Atomen beziehungsweise subatomaren Partikeln beschäftigt Radiometrie Die Radiometrie behandelt die Messung der Strahlungsenergie in SI-Einheiten und damit die Lichtmenge einer bestimmten Wellenlänge. Die Energie e λ, angegeben in Joule [J] eines Photons der Wellenlänge λ, beziehungsweise der Frequenz f ist: e λ = hc λ = hf (4.1) Dabei ist h Js die Planksche Konstante und c die Lichtgeschwindigkeit, die im Vakuum gleich c 0 = m/s ist. Die Energie von n λ Photonen der Wellenlänge λ ist somit Q λ = n λ e λ [J] (4.2) 29

36 Die Energie von einer Sammlung von Photonen unterschiedlicher Wellenlängen (Radiant Energy) erhält man durch Integration: Q = 0 Q λ dλ [J] (4.3) Im Folgenden wird die Frequenz der Photonen nicht mehr explizit angegeben, denn für Strahlenoptik können verschiedenen Frequenzbänder separat betrachtet werden. Dies ist beispielsweise nicht mehr der Fall, wenn Fluoreszenz- und bestimmte Streuungseffekte betrachtet werden. Der Radiant Flux (Strahlungsleistung) Φ, oft auch einfach Flux genannt, ist die Radiant Energy pro Zeit: Φ = dq dt [Js 1 = W ] (4.4) Die Radiance L(x, w ) (Abbildung 4.1) ist die Leistung, die in eine bestimmte Richtung pro projizierter Fläche senkrecht zu dieser Richtung pro Raumwinkel gestrahlt wird. Ihre physikalische Einheit ist [W m 2 sr 1 ]. Es sind verschiedene Ansätze möglich die Radiance zu definieren. Die Radiance kann ausgedrückt werden, als der Radiant Flux pro Raumwinkel und pro projizierter Fläche: L(x, w ) = d 2 Φ cos θdad w = 0 d 4 n λ cos θd w dadtdλ hc dλ (4.5) λ Abbildung 4.1: Die Radiance ist definiert als die Strahlungsleistung pro Raumwinkel und projizierter Fläche. Im Vakuum ist die Radiance entlang ihrer Richtung konstant. Die wahrgenommene Lichtmenge im menschlichen Auge proportional zur Radiance einer betrachteten Oberfläche, deshalb wird die Radiance für die Beleuchtungsberechnungen beim Rendering verwendet. Zu den weiteren wichtigen Größen zählt die Irradiance. Sie beschreibt die insgesamt einfallende Strahlungsleistung pro Fläche. Sie wird durch die Integration der einfallenden Radiance beim Punkt x über der Halbkugel Ω berechnet, wobei n die Oberflächennormale bei x ist: 30

37 E(x) = L i (x, w )( n w )d w [W m 2 ] (4.6) Ω Die korrespondierende Größe der abgestrahlten Leistung ist die Radiant Exitance oder Radiosity B. Sie wird durch wiederum durch das Integral über Ω über der abgestrahlten Radiance beschrieben: B(x) = L(x, w )( n w )d w [W m 2 ] (4.7) Photometrie Ω Im Gegenschatz zur Radiometrie, die sich mit der objektiven Messung der Energie in SI Einheiten beschäftigt, wird bei der Photometrie auch die perzeptive Wahrnehmung des menschlichen Auges berücksichtigt. Das Auge reagiert unterschiedlich empfindlich auf Licht unterschiedlicher Frequenzen. Die radiometrischen Größen werden mit der Luminous Efficiency Function V (λ) des Standard Betrachters in photometrische umgewandelt. Die Einheit von V (λ) ist Lumen pro Watt [lm/w ]. Der Luminous Flux Φ ν entspricht dem Radiant Flux: Φ n u = 780nm 380nm Die Luminance, die Entsprechung zur Radiance, ist definiert als: Φ λ V (λ)dλ [lm] (4.8) L ν (x, d 2 Φ ν w ) = cos θdad (4.9) w Analog zu den obigen Größen sind auch die Illuminance, entsprechend der Irradiance und die Luminous Exitance entsprechend der Radiant Exitance definiert. Ihre Einheiten sind jeweils [lmm 2 ] Emission Die Emission von Licht kann verschiedene physikalische Gründe haben, wie z.b. Hitze oder chemische Reaktionen, und kann direkt durch die emittierte Radiance L e (y, w ) eines Punktes einer Oberfläche beschrieben werden. Im Vakuum, und bei einem freien Pfad von y nach x in Richtung w, kann die emittierte Radiance auch durch die einfallende Irradiance beschrieben werden: L i (x, w) = L e (y, w ) (4.10) 31

38 4.2 Verhalten von Licht an Oberflächen Im Folgenden wird von einer abstrahierten makroskopischen Betrachtung der Licht-Material Wechselwirkung ausgegangen. Das heisst der atomare Aufbau von Materialien wird nicht berücksichtigt. Für die Wahrnehmung durch den Menschen und somit für das Rendering genügt diese Form der Betrachtung. Wenn Licht auf eine Oberfläche eines bestimmten Materials trifft, wird es gestreut, absorbiert oder transmittiert. Die Möglichkeiten dies zu beschreiben werden im Folgenden aufgezeigt Die Bidirectional Scattering Surface Reflectance Distribution Function Wenn Licht von einem Material gestreut wird, dringt es normalerweise erst in das Material ein, wird dort gestreut und verlässt es an anderer Stelle wieder (Abbildung 4.2). Die Bidirectional Scattering Surface Reflectance Distribution Function [11], kurz BSSRDF, ist die allgemeinste Beschreibung des Lichttransports und diese Lichtstreunung kann damit beschrieben werden. Die BSSRDF S setzt die differentielle reflektierte Radiance dl r an einem Punkt x der Oberfläche in Richtung w mit dem differentiellen einfallendem Flux dφ i an x in Richtung w in Beziehung: S(x, w, x, w ) = dl r(x, w ) dφ i (x, w ) (4.11) Abbildung 4.2: Das Prinzip der BSSRDF: Oft wird ein auftreffender Lichtstrahl im Material selbst gestreut, bevor er es an anderer Stelle wieder verlässt. 32

39 4.2.2 Die Bidirectional Reflectance Distribution Function Mit der Bidirectional Reflectance Distribution Function BRDF (Abbildung 4.3) kann die Reflektion von Licht an einer Oberfläche beschrieben werden. Die BRDF ist nur ein Spezialfall der BSSRDF, da vereinfachend angenommen wird, dass das auf eine Stelle der Oberfläche einfallende Licht auch dort reflektiert wird. Die BRDF ist definiert, als das Verhältnis zwischen reflektierter Radiance und Irradiance, wobei n die Normale der Oberfläche an der Stelle x ist: f r (x, w, w ) = dl r(x, w ) de i (x, w ) = dl r (x, w ) L i (x, w )( w n )d w (4.12) Abbildung 4.3: Bei der BRDF wird davon ausgegangen, dass Licht an der Stelle an der es auftrifft reflektiert wird. Mit der BRDF kann ein lokales Reflexionsmodell beschrieben werden. Wenn die einfallende Radiance an einem Ort einer Oberfläche bekannt ist, kann die Radiance für alle Richtungen berechnet werden. Dies geschieht durch die Integration der einfallenden Radiance L i über der Halbkugel der einfallenden Richtungen Ω bei x: L r (x, w ) = Ω f r (x, w, w )de(x, w ) = Ω f r (x, w, w )L i (x, w )( w n )d w (4.13) Dabei ist ( w n ) = cos θ. Eine wichtige Eigenschaft der BRDF ist das Helmholtz sche Gesetz der Reziprozität. Dieses sagt aus, dass die BRDF unabhängig von der Lichtrichtung ist: f r (x, w, w ) = f r (x, w, w ) (4.14) Eine weitere Eigenschaft lässt sich aus dem Energieerhaltungssatz ableiten: Es kann nicht mehr Licht reflektiert werden, als einfällt. Deshalb muss die BRDF die folgende Bedingung erfüllen: 33

40 Ω f r (x, w, w )( w n )d w < 1, w (4.15) Das Verhältnis von einfallendem zu reflektiertem Licht (Flux) einer Fläche wird als Reflectance bezeichnet. Bei realen Oberflächen ist ihr Wert zwischen Null und Eins. Der nicht reflektierte Teil des Lichtes wird von der Oberfläche entweder absorbiert oder transmittiert. Die Reflectance ist wie folgt definiert: ρ(x) = dφ r(x) dφ i (x) = Ω Ω f r(x, w, w )L i (x, w )d w d w Ω L i(x, w )d w (4.16) Speicherung der BRDF in der Computergrafik Lässt man zunächst die räumliche Veränderlichkeit und die Unterscheidung verschiedener Frequenzbänder der BRDF außer Acht, so bleibt eine vierdimensionale Funktion, mit je zwei Winkel für Einfalls- und Ausfallsrichtung, übrig. Es gibt Spezialfälle für die die Speicherung der BRDF sehr einfach ist. Zum Beispiel ist sie für perfekte diffuse (lambertsche) Reflektoren konstant: f r,l ( w, w ) = f r,0 π (4.17) Kompliziertere BRDFs weisen natürlich eine Winkelabhängigkeit auf. Sie können entweder aus theoretischen Modellen über die Reflexion an Oberflächen [9][36] oder durch direkte Messung mit geeigneten Apparaten [34][14] gewonnen werden. In beiden Fällen bleibt auf jeden Fall das Problem der Speicherung dieser Funktion. Die einfachste Möglichkeit ist sicherlich, die BRDF an einer großen Anzahl von Stellen abzutasten beziehungsweise zu berechnen und die Werte zu speichern. Fehlende Werte könnten dann durch Interpolation berechnet werden. Allerdings ist der Speicheraufwand dieser Methode auch entsprechend hoch, da für ein qualitativ hochwertiges Rendering entsprechend viele Abtastwerte zur Verfügung stehen müssten. Deshalb wurde versucht, für die BRDFs einfachere analytische Modelle zu finden, d.h. Modelle mit wenigen Parametern, die die BRDF gut approximieren. Ein bekanntes analytisches Modell ist die Minnaert BRDF [16], die die Reflectance des Mondes repräsentieren soll. Die Schwierigkeit liegt jedoch darin, ein solches Modell aufzustellen und, wenn dies gelingt, ist es doch nur für eine bestimmte Klasse von Oberflächen geeignet. Deshalb wurden für die Speicherung einer BRDF weitere Verfahren untersucht. Eine Möglichkeit die BRDF an fehlenden Stellen zu interpolieren ist, Spline Patches zu verwenden. Gleichzeitig reduziert sich damit der Speicheraufwand, da weniger Stützpunkte benötigt werden. Es ist sinnvoll die Splines mit einem analytischen Modell zu kombinieren, wenn die Symmetrie der BRDFs ausgenutzt werden soll. Eine weitere Möglichkeit ist die Projektion der BRDF auf so genannte Spherical Harmonics. Dabei handelt es sich um eine orthonormale Basis über einer Kugel [36][13][28]. Diese Methode ist, trotz des noch relativ großen Speicherbedarfs, auch geeignet, um interaktives BRDF Rendering auf moderner Grafikhardware durchzuführen. 34

41 Die Spherical Wavelets verwenden andere orthonormale Basen, um die BRDF zu speichern. In [27] wird eine Klasse von Wavelet Basen beschrieben, die für sphärische Funktionen angewendet werden kann Vereinfachung für kalibrierte Kamerabilder Bei der Generierung von Punktdatensätzen aus den Kamerabildern stehen als Daten zweidimensionale Farb- und Tiefeninformation zur Verfügung. Weiterhin sind die Kameraparameter, d.h. die Position, Blickrichtung und Projektionsabbildung gegeben. Daraus lässt sich für jeden Bildpunkt der Farbinformation, die Position des aufgenommenen Punktes im Raum berechnen. Ein Punkt eines Objektes, das sich auf den Kamerabildern befindet, kann aus verschiedenen Kamerapositionen und Blickrichtungen erfasst werden. Dann stehen mehrere Farbinformationen beziehungsweise Radiance Werte, zur Verfügung. Bei der Generierung werden rekonstruierte Punkte als derselbe Punkt einer Oberfläche betrachtet, die einen geeignet kleinen Abstand voneinander besitzen. Da über die Beleuchtungssituation der erfassten Szene nichts bekannt ist, kann so also nur die Radiance eines Punktes x erfasst werden. Für einen Punkt ist die Radiance eine zweidimensionale Funktion L( w ), wobei die Richtung w im Folgenden in Polar Koordinaten (θ, φ) (ohne Längenkomponente) dargestellt wird. Die Radiance ist für diskrete Oberflächenpunkte für einen oder mehrere diskrete Richtungen durch die Kamerabilder definiert und muss aber für das Rendering für alle Richtungen zur Verfügung stehen. Aufgrund der Tatsache, dass die Radiance pro Punkt eine zweidimensionale Funktion ist, bietet sich ein texturbasierter Ansatz für das Rendering an. Die Textur soll eine Tabelle darstellen, die für verschiedene Richtungen die Radiance speichert. Dabei sollen die Endpunkte der (normalisierten) Richtungensvektoren homogen auf einer Kugeloberfläche verteilt sein. Es ist dann möglich, bei geeignet angelegten Daten, mit der Grafikhardware linear zwischen den dort abgelegten Radiancewerten zu interpolieren. Zur zweidimensionalen Repräsentation der Richtungen werden, wie bereits erwähnt, Polar Koordinaten verwendet. Die Radiance Tabelle jedes Splats umfasst 2 n 2 n Einträge. Die Polar Koordinaten und der Richtungsvektor eines Eintrags der Zeile b und Spalte a sind: θ = a/(2 n 1) 2π φ = b/(2 n 1) π cos θ sin φ w = sin θ sin φ cos φ (4.18) Durch diese Definition ist die erste und letzte Spalte beziehungsweise Zeile der Tabelle identisch, was für die lineare Interpolation mit der Grafikhardware benötigt wird, wenn mehrere dieser Tabellen zu einer Textur zusammengefasst werden. Diese Umsetzungsdetails werden im entsprechenden Kapitel beschrieben. 35

42 Für jeden Eintrag der Tabelle muss ein Radiance Wert aus den Samples berechnet werden. Wenn nur ein Sample zur Verfügung steht, wird die Radiance für alle Richtungen gleich der des Samples angenommen. Bei mehreren Samples wird für jede Richtung in der Tabelle eine Gewichtung der Samples und daraus die resultierende Radiance berechnet. Die Versuche im Zuge dieser Arbeit haben ergeben, dass die im Folgenden vorgestellte heuristische Lösung zur Berechnung der Radiance gute Resultate liefert. Für die folgenden Rechnungen werden die Richtungen in kartesischen Koordinaten dargestellt und es wird dabei von normalisierten Vektoren ausgegangen. Diese Annahmen sind für die Verwendung des Skalarproduktes notwendig. Für jede Richtung eines Tabelleneintrages t wird die Gewichtung a i der m Radiance Werte L r,i ( w i ) aus den dazugehörigen Referenz- Richtungen w i, mit 0 i < m berechnet: ( ) (t wi + 1) k a i = (4.19) 2 Das grundlegende Gewichtungskriterium ist also der Kosinus des Winkels zwischen t und den Referenzvektoren. Mit der Konstante k lässt sich die Gewichtung und somit die Interpolation beeinflussen. Für genügend große k (im Vergleich zur Auflösung der Tabelle) erhält man eine Radiancetabelle, die den Wert des jeweils nächsten Referenzvektors enthält. Der Wertebereich der a i ist somit [0; 1]. Die Bereichsverschiebung vor der Potenzierung ist notwendig, damit die berechneten Radiance Werte, bei mehreren Samples von denjenigen abhängen, deren Referenzvektor in eine möglichst ähnliche Richtung weist und nicht von denen, deren Kosinus des Zwischenwinkels betragsmäßig groß ist. Der Radiance Wert L r (t) setzt sich wie folgt zusammen: a = m 1 i=0 a i L r (t) = 1 m 1 (a i L r,i ( w i )) a i=0 (4.20) Auf diese Weise werden die Radiance Werte jedes Splats für eine Menge von diskreten Richtungen erzeugt und für das spätere Rendering gespeichert. Das folgende sehr einfache Beispiel soll nochmals die Notwendigkeit der Bereichsverschiebung deutlich machen. Bild 4.4 zeigt zwei Referenzvektoren ω 1 = ( 1, 0) T und ω 2 = (0, 1) T, deren dazugehörige Radiance Werte mit L r,1 und L r,2 bezeichnet werden. Es soll nun der Radiance-Wert für die Blickrichtung t = (1, 0) T bestimmt werden. 36

43 Abbildung 4.4: Ein einfaches, konstruiertes Beispiel für die Radianceberechnung. Findet keine Bereichsverschiebung bei den Koeffizienten a i statt, so ergäbe sich: und somit: a 1 = 1 a 2 = 0 a = 1 (4.21) L r (t) = 1 1 ( 1)L r,1 = L r,1 (4.22) Es ist ersichtlich, dass dieses Ergebnis nicht wünschenswert ist, da ω 1 = ( 1, 0) T die entgegengesetzte Richtung von t besitzt und deshalb eher die Lösung mit der Bereichsverschiebung bevorzugt wird. Dabei ist: und a 1 = 0 a 2 = 1 a = 1 (4.23) L r (t) = 1 1 (1)L r,2 (4.24) Das bedeutet, es wird auch tatsächlich der Radiance-Wert gewählt, dessen Referenz- Richtung eher der von t entspricht. In Fällen in denen keine zueinander orthogonalen Referenz- Richtungen auftreten, wird natürlich, durch die oben beschriebene Methode, jeweils eine Gewichtung der Radiance-Werte berechnet. 37

44 38

45 Kapitel 5 Generierung und Speicherung der Punktdatensätze In diesem Kapitel werden die entwickelten und implementierten Verfahren zur Generierung der Punktdatensätze beschrieben. Diese umfassen zum einen die Generierung aus Dreiecksnetzen oder einer Folge von kalibrierten Kamerabildern, zum anderen die dabei auftretenden Probleme und deren Lösung. Im Anschluss wird eine Methode zur kompakten Speicherung aller erzeugten Daten vorgestellt. 5.1 Generierung aus Dreiecksnetzen mit unregelmäßiger Abtastung und variabler Punktgröße In diesem Abschnitt wird beschrieben, wie die Daten für unregelmäßig abgetastete Dreiecksnetze generiert werden. Unregelmäßig bedeutet in diesem Zusammenhang, dass der Abstand der einzelnen generierten Splats (auf der Oberfläche des Objektes) variieren kann. Es wird dabei nicht versucht, die Abstände homogen zu gestalten, oder durch weitere Splats auszugleichen. Deshalb ist es notwendig, die Größe der Fläche, die ein Splat abdecken muss, festzustellen. Im Wesentlichen folgt diese Beschreibung der des QSplat Verfahrens. Allerdings wird auf die Bounding-Sphere Hierarchie verzichtet, da diese nicht für effizientes Rendering mit moderner Grafikhardware geeignet ist. Die Variante der Datengenerierung wurde implementiert, um einen Vergleich zur QSplat Implementation zu besitzen und das Rendering mit variabler Splatgröße wird auch für die Daten aus kalibrierten Kamerabildern benötigt. Renderingverfahren mit dieser Art von Daten sind dem Splatting zuzuordnen Vorgehensweise Als Eingabedaten dient ein Dreiecksnetz, in der Shared-Vertex Datenstruktur, d.h. bestehend aus einer Liste aller Knoten und einer Liste, in der für jedes Dreieck die Indizes der drei Knoten gespeichert sind. Durch die gegebene Topologie lassen sich die Normalen der Dreiecke und somit die Normalen pro Knoten berechnen. Als Splats werden direkt die Knoten des Dreiecksnetzes, zu- 39

46 sammen mit den berechneten Normalen, übernommen. Es bleibt also nur noch die Bestimmung der Splatgröße. Diese wird in einem Vorberechnungsschritt durchgeführt. Zunächst wird die Bounding Sphere jedes Dreiecks, d.h. die kleinste Kugel, in der alle drei Eckpunkte liegen, berechnet. Als Maß für die Größe eines Splats (bzw. Knotens) wird das Maximum aller Bounding-Sphere-Radien von den Dreiecken verwendet, die den betrachteten Knoten enthalten (Abbildung 5.1). Während des Renderings wird dieser Wert, zusammen mit den Betrachterparametern, wie z.b. Abstand und Projektionsabbildung, herangezogen, um die Größe des Splats auf dem Bildschirm zu berechnen, damit eine geschlossene Oberfläche dargestellt wird. Dabei ist diese Abschätzung der Größe konservativ, d.h. sie wird eher etwas zu groß gewählt, aber niemals zu klein. Es könnten auch noch weitere Attribute pro Splat, wie z.b. Farbe oder Texturinformation hinzugenommen werden. Abbildung 5.1: Ein kleines Dreiecksnetz. Links die Bounding Spheres (als Kreise dargestellt) der Dreiecke, rechts die daraus resultierenden Splatgrößen Bewertung Dadurch, dass die Knoten des Dreiecksnetzes als Splats verwendet werden, können die benötigten Daten sehr schnell generiert und große Dreiecksnetze schnell und dann als Punktdatensatz effizient dargestellt werden. Allerdings ist dieser Ansatz nicht gut geeignet, um grobe Dreiecksnetze darzustellen - was eigentlich auch nicht der Einsatzzweck für punktbasiertes Rendering ist. Dabei ist der Abstand zwischen den Abtastpunkten zu groß und die Qualität der Darstellung folglich zu schlecht. 40

47 5.2 Generierung aus Dreiecksnetzen mit regelmäßiger Abtastung und einheitlicher Punktgröße Damit geschlossene Oberflächen durch Punkte gleicher Größe, ohne Fehler dargestellt werden können, ist eine Abtastung mit möglichst konstanter Abtastdichte notwendig. Im Zuge dieser Arbeit wurden zwei ganz unterschiedliche Ansätze untersucht. Der Erste ist das so genannte Uniform Clustering, wie es auch in [2] vorgeschlagen wurde, der auf räumlicher Unterteilung der Bounding Box des Dreiecksnetzes basiert. Der zweite Ansatz verfolgt einen ganz anderen Weg und erzeugt Abtastpunkte, indem er sie in einer bestimmten Dichte auf die Dreiecksflächen projiziert. Durch die anschließende Quantisierung der Koordinaten liefern beide Verfahren, die in diesem Abschnitt vorgestellt werden, vergleichbare Ergebnisse, eignen sich aber für verschiedene Dreiecksnetze und Quantisierungsgenauigkeiten unterschiedlich gut. Als Eingabedaten dienen wiederum Dreiecksnetze in der Shared-Vertex Datenstruktur, womit die Topologie und die Koordinaten und Normalen der Knoten bekannt sind Uniform Clustering Beim Uniform Clustering wird zuerst die Bounding Box, bzw. um eine isotropische uniforme Abtastung zu erhalten, der Bounding Cube berechnet. Dieser wird in m m m, mit m = 2 n, Sub-Würfel (Voxels) unterteilt. Schneidet ein Voxel ein Dreieck, so wird ein Abtastpunkt mit der Koordinate des Voxelmittelpunktes gespeichert. In der Praxis hat sich gezeigt, dass es sinnvoll ist - sowohl vom Aspekt des Speicherbedarfs, als auch von der Rechenzeit - ein rekursives Vorzugehen zu wählen. Dabei werden die Abtastpunkte für jedes Dreieck nacheinander generiert. Ein Würfel, ausgehend vom Bounding Cube, wird rekursiv in acht Sub-Würfel unterteilt und es wird überprüft, welche davon das Dreieck schneiden. Wenn der Überschneidungstest für einen Sub-Würfel positiv ist, wird wiederum mit diesem rekursiv verfahren bis die gewünschte Unterteilung erreicht ist. Durch die Wahl von m, ist die maximale Rekursionstiefe n + 1, da mit der Bounding Box selbst begonnen wird. Der Überschneidungstest wird in der vorliegenden Implementation wie in [1] beschrieben durchgeführt. Für die Abtastpunkte werden außer der Koordinate, für die der Mittelpunkt des Voxels verwendet wird, weitere Attribute, wie z.b. eine Normale benötigt. Die Normale eines Punktes auf einem Dreieck lässt sich durch die barizentrischen Koordinaten und den Normalen der Eckpunkte berechnen. Wenn ein Abtastpunkt bestimmt wurde, liegt dieser aber nicht zwingend auf der Ebene, die durch das Dreieck bestimmt wird. Deshalb wird als Referenzpunkt die senkrechte Projektion der Voxelmittelpunktes auf die Ebene verwendet, und die Normale für diesen Punkt bestimmt und gespeichert. Ist die Oberflächennormale n des Dreiecks, gegeben durch die Eckpunkte v i, i {1, 2, 3} bekannt, so berechnet sich der projizierte Punkt p zum Voxelmittelpunkt m mit (Abbildung 5.2): p = m + n [ (v i m) n ], i {1, 2, 3} (5.1) Die Anzahl der Unterteilungen n sollte so gewählt werden, dass sie gleich der Anzahl der Quantisierungsbits pro Koordinatenkomponente ist. Feinere Unterteilungen sind nutzlos, da 41

48 Abbildung 5.2: Der Mittelpunkt m der Voxelzelle wird senkrecht auf die Ebene des Dreiecks auf den Punkt p projiziert. jeweils zwischen einem und acht Abtastwerte zusammenfallen. Auf gröbere Unterteilungen sollte verzichtet werden, bzw. die Quantisierung in diesem Fall angepasst werden. Aus diesen Gründen sind die Unterteilungen und Quantisierungen beim Uniform Clustering in der Implementation immer gleich. Die daraus resultierende Abtastdichte wird deshalb zusammen mit der Quantisierung in Abschnitt beschrieben Dreiecksbasierende Splatgenerierung Bei dieser Art der Datengenerierung werden die Abtastpunkte so erzeugt, dass für jedes Dreieck direkt Punkte auf der Dreiecksfläche generiert werden. Notwendig dabei ist, die Splats möglichst gleichmäßig verteilt zu erzeugen. Verschiedene Ansätze im Verlauf dieser Arbeit wurden untersucht, wobei das Ziel war, zufällige Punkte, mit möglichst gleichmäßigen Abstand voneinander, auf einer Dreiecksfläche zu platzieren. Die einfachste Möglichkeit, zufällige Punkte auf einem Dreieck, gegeben durch die drei nicht kolinearen Eckpunkte A, B und C, zu generieren ist mittels barizentrischer Koordinaten. Die barizentrischen Koordinaten eines Punktes P bzgl. der drei Eckpunkte sind (u, v, w) T, so dass gilt: Wenn der Punkt P innerhalb der Dreiecks liegt, gilt: P = u A + v B + w C (5.2) 0 u, v, w 1 (5.3) Ein Zufallspunkt auf dem Dreieck ließe sich also durch zwei Zufallswerte im Intervall [0; 1], deren Summe kleiner als eins ist, und der davon abhängigen dritten Komponente bestimmen. 42

49 Der Nachteil der Generierung mit zufälligen Barizentrischen Koordinaten liegt darin, dass die Form des Dreiecks die Lage und somit den Abstand der Abtastpunkte beeinflusst. Dadurch ist keine gleichmäßige Verteilung der Punkte für beliebige Dreiecke möglich (Abbildung 5.3). Dieses Problem wird durch das im Folgenden vorgestellte Verfahren gelöst. Abbildung 5.3: Dieselben zufällig erzeugten Barizentrischen Koordinaten und die daraus resultierenden Punkte auf zwei Dreiecken. Beispielsweise bei flachen Dreiecken (unten) ist die Verteilung der Punkte nicht wünschenswert. Außer den Eingabedaten wird während der Initialisierungsphase zusätzlich eine Liste von k zweidimensionalen Zufallskoordinaten im Intervall [0; 1] [0; 1] benötigt. Dabei ist k ein Maß für die initiale Abtastdichte auf der Oberfläche des Dreiecksnetzes, wie im Folgenden ersichtlich wird. Die Liste wird - ausgehend von einem Startpunkt - sukzessive um einen Punkt vergrößert, indem jeweils i Kandidatenpunkte mit einem Zufallszahlengenerator erzeugt werden. Für jeden dieser Punkte wird der minimalste Abstand zu den bereits in der Liste enthaltenen Punkten berechnet. Der Kandidat mit dem größten Abstand wird zur Liste hinzugenommen. Dadurch wird eine bessere Verteilung der Zufallspunkte erreicht, wie Abbildung 5.4 zeigt. Anschließend können die Abtastpunkte für jedes Dreieck generiert werden. Dazu wird ein orthonormales Koordinatensystem aufgestellt, in das das Dreieck abgebildet wird. Die X- Achse dieses Koordinatensystems wird gleich der Hypotenuse gewählt, die Z-Achse gleich der Normale des Dreiecks. Die Y-Achse wird dann so gewählt, dass die Spitze des Dreiecks einen positiven Y-Wert besitzt. Der Ursprung dieses Koordinatensystems wird auf einen Endpunkt der Hypotenuse gelegt, so dass der andere Endpunkt einen positiven X-Wert besitzt. Anschließend werden die Koordinaten der Eckpunkte des Dreiecks in dieses Koordinatensystem transformiert, dabei sind die Z-Komponenten gleich Null (Abbildung 5.5). Es wird im Folgenden dabei vorausgesetzt, dass kein Dreieck größere zweidimensionale Koordinaten als 1 besitzt, was sich durch eine geeignete Skalierung sicherstellen lässt. Der Skalierungfaktor muss aber für alle Dreiecke gleich sein, um jeweils dieselbe Abtastdichte zu 43

50 Abbildung 5.4: Verschiedene zufällige Punktverteilungen: links durch einen Zufallszahlenpaar pro Punkt, rechts durch die im Text beschriebene Methode. Abbildung 5.5: Ein Dreieck mit seiner achsenparallelen Bounding Box und den projizierten Zufallspunkten. 44

51 erzielen. Dann wird für jeden der k Zufallspunkte aus dem [0; 1] [0; 1] Intervall überprüft, ob dieser auf dem Dreieck liegt. Wenn das der Fall ist, wird der Punkt zurück transformiert und seine dreidimensionalen Koordinaten mit der dazugehörigen, berechneten Normale gespeichert. Der Test, ob sich ein Punkt auf einem Dreieck befindet, wird durch zwei Dinge beschleunigt: Zum einen kommen zweidimensionale Bounding Boxes zum Einsatz, die für jedes Dreieck aufgestellt werden, zum anderen lässt sich ausnutzen, dass die Hypotenuse entlang der X-Achse verläuft (Abbildung 5.5). Die Eckpunkte des Dreiecks werden im Folgenden mit x 0 = (0, 0) T, x 1, der zweite Punkt der Hypotenuse, und x 2, die Spitze des Dreiecks, bezeichnet. Befindet sich ein Punkt p innerhalb der Bounding Box, so kann leicht festgestellt werden, ob er sich auf der Dreiecksfläche befindet. Nun wird der Fall betrachtet, dass die X-Koordinate von p kleiner als die von x 2 ist. Das Vorgehen im anderen Fall lässt sich analog dazu konstruieren. Mithilfe der Steigung s der Dreiecksseite, berechnet als Quotient der Y- und der X-Koordinate von x 2, befindet sich p auf dem linken Teil der Dreiecksfläche, wenn gilt: die Y-Koordinate von p ist kleiner oder gleich dem Produkt aus s und der X-Koordinate von p Vor- und Nachteile der beiden Verfahren Die vorgestellten Verfahren wurden beide implementiert und die Resultate verglichen. Durch das Uniform Clustering ist eine gleichmäßige Abtastung ohne Lücken garantiert. Die benötigte Rechenzeit (pro Dreieck) ist bei geringer Quantisierungstiefe (und damit gekoppelter Abtastdichte) gering, nimmt aber mit höheren Tiefen mit O(n), bzw. O(log 2 m) deutlich zu. Beim zweiten Verfahren soll die zufällige Platzierung der Abtastpunkte einen gleichmäßigen Abstand gewährleisten. Durch eine zu geringe Abtastdichte, also eine zu geringe Anzahl der Zufallspunkte k, können aber Lücken auftreten. Bei Abtastdichten, die gute Resultate ergeben, ist vor allem bei höheren Quantisierungen eine geringere Rechenzeit als bei Uniform Clustering zu erwarten. Zusammenfassend ließ sich feststellen, dass beide Möglichkeiten sowohl visuell, als auch von der Anzahl der generierten Abtastpuntke, etwa gleiche Resultate ergeben, wobei das Uniform Clustering aufgrund der garantierten Abtastdichte zu bevorzugen ist. Die Stärken der zweiten Möglichkeit liegen eindeutig bei hohen Quantisierungen, von 12 oder mehr Bit pro Koordinatenkomponente oder wenn auf die Quantisierung gänzlich verzichtet werden soll. Deshalb kann dies in der vorliegenden Implementation vom Benutzer gewählt werden. Weitere Attribute der Abtastpunkte, wie z.b. Farbwerte durch Texturen lassen sich bei beiden Verfahren bestimmen. Verschiebungen von Oberflächenteilen, so genanntes Displacement Mapping, ist mit der dreiecksbasierenden Methode einfacher zu erreichen. Beim Uniform Clustering müssten die Verschiebungen, die meist durch eine Art Textur gegeben sind, bereits bei den Überschneidungstests berücksichtigt werden, was nicht ohne beträchtlichen Zusatzaufwand möglich ist. 45

52 5.3 Generierung aus kalibrierten Kamerabildern In diesem Abschnitt wird ein Verfahren vorgestellt, das es ermöglicht, aus einer Folge von kalibrierten Kamerabildern Punktdatensätze zu erstellen. Damit ist es möglich, bestehende bildbasierte Renderingverfahren durch punktbasierte zu ersetzen, bzw. zu ergänzen Daten und Vorgehen Als Eingabedaten liegen eine Reihe von Kamerabildern vor. Jedes Bild besitzt eine bestimmte Auflösung und für jeden Pixel liegt sowohl eine Farbinformation als auch eine Tiefeninformation vor. Weiterhin existiert die Information über die Kamera, d.h. die Projektionsabbildung, ihre Orientierung in Matrixdarstellung und ihr Ort, gegeben durch einen Translationsvektor. Damit lässt sich für jeden Pixel eines Bildes der Ort im Raum bestimmen, der durch die Kamera aufgenommen wurde. Der erste Schritt bei der Generierung der Daten ist also die Koordinaten der gewünschten oder aller Pixel der zur Verfügung stehenden Kamerabilder zu berechnen, und zunächst in einer Liste zu speichern, um anschließend die Quantisierung, wie in beschrieben, durchzuführen. Für jeden Splat wird zusätzlich zur Koordinate die Farbinformation und die Richtung von der berechneten Koordinate zur Kameraposition des jeweiligen Bildes gespeichert. Als Nächstes muss die Größe der Splats bestimmt werden. Dabei liegen keine Informationen über die Zusammengehörigkeit der Splats zu Oberflächen oder andere Kriterien vor. Deshalb wurde in dieser Arbeit eine nächste Nachbar Suche für diesen Zweck eingesetzt. Für jeden Splat werden die n (frei wählbar) nächsten Nachbarn aus allen erzeugten Splats, bestimmt und das Maximum der Abstände zu diesen berechnet. Dieser Wert wird als Maß für die benötigte Größe eines Splats herangezogen. Allerdings wird die Größe auf einen maximalen Wert begrenzt, da ansonsten Bereiche, in denen sich nur wenige Splats befinden, z.b. an der Grenze zu Bereichen, die von den Kamerabildern nicht erfasst werden, sehr große Splats aufweisen. Als einfache Heuristik für die getesteten Datensätze hat es sich bewährt, als Obergrenze ein Vielfaches des kleinsten Wertes zu verwenden Die Radiance Interpolation und deren Vorteile Wie in beschrieben, werden Splats, die in einer bestimmten Umgebung liegen, zusammengefasst. In Versuchen, im Zuge dieser Arbeit, hat sich gezeigt, dass es sinnvoll ist, in diesem Kontext, diese Umgebung so zu definieren, dass Splats, deren quantisierte Koordinaten gleich sind, zusammengefasst werden. Das bedeutet, durch die Quantisierung können Splats entstehen, für die nicht nur eine Farbinformation, sondern mehrere Farb- und dazugehörige Richtungsinformation vorliegen. Diese Information wird nicht verworfen oder gemittelt. Stattdessen wird die Radiance, also die Farbinformation, wie bereits vorgeführt, richtungsabhängig in Texturen gespeichert. Dadurch lassen sich, vorausgesetzt, die Kamerabilder sind geeignet und die Auflösung genügend hoch, wichtige Eigenschaften der Oberflächen beim Rendering reproduzieren, die ohne die Radiance Interpolation zu Darstellungsartefakten oder -fehlern führen würden. Eine korrekte Darstellung, ohne Interpolation der Radiance, wird beispiels- 46

53 weise nur bei perfekten diffusen (lambertschen) Reflektoren erhalten. Andere Beleuchtungsmodelle und reale Oberflächen enthalten eine Richtungskomponente zum Betrachter. Ein weiterer Vorteil liegt bei der Darstellung von Oberflächen, die von beiden Seiten unterschiedlich beleuchtet sind oder unterschiedliche Materialeigenschaften besitzen. Ein Testdatensatz hat gezeigt, dass die richtungsabhängige Radiance hierfür wichtig ist, da ansonsten deutlich sichtbare Rendering-Fehler erkennbar sind. Bei einer genügend hohen Abtastdichte, d.h. entsprechend vielen Kamerabildern, lassen sich auch spiegelnde Oberflächen mit punktbasiertem Rendering darstellen Qualität einzelner Splats Außer den Farbwerten können in Texturen so genannte Alpha-Werte gespeichert werden. Diese werden normalerweise dazu verwendet, die Transparenz bzw. Opaziät einer Oberfläche anzugeben. Für das Rendering eines Fragmentes (also ein Teil eines Punktes, einer Linie oder eines Dreiecks beim Rendering) lässt sich aber auch ein Alpha-Test konfigurieren. Mit diesem Test kann festgelegt werden, dass nur Fragmente gerendered werden sollen, deren Alpha-Wert kleiner, kleinergleich, gleich, größer oder größergleich als ein festgelegter Referenzwert ist. Damit lässt sich der Alpha Test zweckentfremden. Genauso wie die Farbinformation lässt sich auch die Güte eines Splats, abhängig von der Richtung, angeben. Mit Güte ist dabei gemeint, das es Abtastpunkte geben kann, deren Darstellung nur aus bestimmten Blickrichtungen erfolgen soll. Die Güte kann im Alpha-Kanal der Texturen gespeichert und wie die Radiance-Werte interpoliert werden. Durch den Alpha Test kann dann die Sichtbarkeit jedes einzelnen Abtastpunktes von der Blickrichtung abhängen Implementationsdetails Wie bereits erwähnt stehen für jedes Kamerabild eine Rotationsmatrix, ein Translationsvektor und Information über die Projektionsabbildung zur Verfügung, um die dreidimensionalen Koordinaten der Oberflächenpunkte zu berechnen. Abbildung 5.6: Der sichtbare Raum bei einer Projektionsabbildung wird durch die sechs Clipplanes begrenzt. 47

54 Die Projektionsabbildung ist durch die Seitenflächen, die Clipplanes, des Viewing Frustum (Abbildung 5.6) analog zu OpenGL definiert. Die Koordinaten der linken und rechten vertikalen Clipplanes werden mit l und r bezeichnet, die der oberen und unteren horizontalen mit t bzw. b. Die Entfernung der Z-Near-Clipplane von der Kamera (deren Position bei der Projektion als (0, 0, 0) T angenommen wird) wird mit z near bezeichnet. In OpenGL wird die Abbildung in Form einer 4 4 Matrix angegeben, in diesem Fall genügt eine 3 3 Matrix, da keine homogenen Koordinaten verwendet werden: Dabei ist A 0 C 0 B D 0 0 E (5.4) A = 2z near r l B = 2z near t b C = r + l r l D = t + b r b E = f + n f n (5.5) Aus diesen Parametern lassen sich die benötigten Werte, nämlich r, l, t und b berechnen, um die Position eines Pixels eines Eingabebildes bei bekannten zweidimensionalen Koordinaten und Tiefeninformation im Raum zu berechnen: l = C A = r + l r l = r + l r l 2z near t = D B = t + b t b = t + b t b 2z near r = l + A 1 = r + l + r l = l 2z near 2z near b = t B 1 = t + b 2z near t b 2z near = 2z near 2z near z near b z near (5.6) Der Wert von z near muss nicht explizit bekannt sein, um die Projektion umzukehren, da er sich jeweils im Nenner der vier Parameter befindet. Die Orientierung der Kamera ist wiederum in einer 3 3 Matrix gegeben. Die Spaltenvektoren dieser Matrix bilden ein orthonormales Koordinatensystem und werden im typischen Jargon mit v right (rechts), v up (oben) und v dir (Richtung) bezeichnet. Der gegebene Translationsvektor p gibt die Position der Kamera im Raum an. Damit läßt sich die dreidimensionale 48

55 Position eines von der Kamera erfassten Punktes berechnen. Dabei ist (u, v) T die zweidimensionale Koordinaten des Pixels. Ihr Wertebereich ist [ 1; 1] und kann durch Verschiebung und Skalierung auf die Größe der Bild- bzw. Tiefeninformation gebracht werden. Für die Berechnung der Richtung, werden folgende Vektoren verwendet: v bl = v dir + l v right + b v up v r = (r l ) v right v u = (t b ) v up (5.7) Die Richtung zu (u, v) T wie folgt berechnet und anschließend normalisiert: d uv = v bl + u v r + v v u (5.8) Zusammen mit dem Tiefenwert z zu einem Pixel berechnet sich die Position mit: p 3d = p + zd uv v dir d uv (5.9) Die Projektion von d uv auf v dir ist notwendig, wenn die Tiefeninformation orthogonal, also entlang der Blickrichtung v dir angegeben ist. Für die Nächste Nachbar Suche wurde die ANN-Approximate Nearest Neighbour Searching Bibliothek der University of Maryland verwendet. Sie verwendet Standard- und Prioritätssuche in KD-Trees und Balanced Box-Decomposition Trees. Die Beschreibung dieser Bibliothek befindet sich in [19]. Nachdem die Koordinaten der Abtastpuntke inklusive ihrer Attribute und Radiance Information, wie oben beschrieben, erstellt und die Größe der Splats bestimmt wurden, werden die Radiance Texturen erstellt. Dabei wird unterschieden, ob für einen Abtastpunkt eine oder mehrere Farbinformationen vorliegen. Zunächst wird die Textur für den ersten Fall angelegt. Angesichts der Tatsache, dass eine Textur auf einer GeForce 3 Grafikkarte bis zu Texel groß sein kann, genügt eine Textur für Datensätze in praxisrelevantem Umfang. Die Liste der Abtastpunkte wird - entsprechend der Reihenfolge, wie sie später dem Darstellungsprogramm vorliegt - durchlaufen und jedem Abtastpunkt, der genau eine Farbinformation besitzt, entspricht dabei genau ein Texel. Die Textur wird zeilenweise von links nach rechts und von oben nach unten gefüllt. Damit wird sichergestellt, dass keine Texturkoordinaten gespeichert werden müssen, sondern nur ein Bit, welches angibt, ob zu einem Abtastpunkt eine oder mehrere Farbinformationen vorliegen. Für Splats mit mehreren Radiance Werten werden separat Texturen angelegt. Jedem Splat entspricht ein 2 m 2 m großer Texelblock innerhalb einer Textur, dessen Farbwerte, wie in beschrieben, berechnet werden. Analog zur obigen Anordnung der Texel wird hier mit den Texelblöcken verfahren. Somit genügt auch hier das Bitflag. In der vorliegenden Implementation kann die Breite der Texelblöcke (2 m ) und der dazugehörigen Texturen (2 n ) frei gewählt werden, solange es sich um eine Zweierpotenz handelt und 2 n > 2 m ist. Dann wird die Anzahl der benötigten Texelblöcke k, also die Anzahl der Abtastpunkte, für die mehrere 49

56 Radiance Werte vorliegen, bestimmt und eine Textur für die Texelblöcke mit der Breite 2 n und Höhe 2 n 2 m n k 2 angelegt. Diese wird für das spätere Rendering mit OpenGL n m in 2 n 2 n große Texturen zerlegt, da quadratische Texturen bevorzugt werden. Wenn die Breite der Texturen sehr groß gewählt wird, wird eventuell bei nicht ganz gefüllten Texturen Speicherplatz (des Grafikspeichers beim Rendering) verschwendet. Bei zu klein gewählter Größe entstehen wiederum viele Texturen und das Wechseln der Textur beim Rendering kann bei zu großer Anzahl negative Auswirkungen auf die Geschwindigkeit haben. Es ist als eine Balance gefragt, wobei dieser Aspekt nicht sehr kritisch ist, da die modernen Grafikkarten zum einen sehr viel Speicher besitzen, zum anderen bei akzeptabler Texturgröße keine hohe Anzahl von Texturen erreicht wird. Die Speicherung der Radiance-Werte in Texelblöcken hat außer der guten Verwendbarkeit für das Rendering noch einen weiteren Vorteil. Die Texturen können mit gängigen Bildkomprimierungsverfahren gespeichert werden. Auch der Einsatz von verlustbehafteten Verfahren ist durchaus möglich. Das JPEG-Verfahren tastet einen 8 8 Pixel Block in Zig-Zag Form ab, und führt eine Frequenzanalyse durch. Die Koeffizienten werden quantisiert und somit verlustbehaftet gespeichert. Dabei können Kompressionsartefakte auftreten, die an den Rändern zwischen zwei dieser Blöcke sichtbar sind. Bei der Wahl von Texel Blockgrößen, die ein vielfaches von acht sind, können diese Texturen sehr effizient komprimiert werden. Zum einen treten keine sichtbaren (und somit bei der Interpolation störenden) Artefakte auf. Zum anderen ist die Farbinformation innerhalb eines Texelblockes meist im unteren Frequenzbereich, da es sich um eine Interpolation mehrerer Farbwerte, also vorwiegend weiche Farbübergange handelt. Nur scharfe Kanten entsprechen hohen Frequenzen. Durch diese beiden Eigenschaften eignet sich das JPEG Verfahren sehr gut für diesen Zweck. Abbildung 5.7 zeigt zur Verdeutlichung als Beispiel die Texelblöcke zweier Abtastpunkte, mit je Farbwerten. 5.4 Datenstrukturen zur Speicherung Für eine effiziente Speicherung sind spezielle Datenstrukturen notwendig. Eine Speicherung der Rohdaten bedeutet einen hohen Bedarf an Speicherplatz und resultiert somit auch in längeren Übertragungs- bzw. Ladezeiten. Die Rekonstruktion der Daten muss aber schnell durchführbar sein, da sonst wiederum der benötigte Zeitbedarf bis zum Beginn der Darstellung zunimmt Quantisierung der Koordinaten Die Quantisierung der Koordinaten kann jeweils nur erfolgen, wenn deren Wertebereich bekannt ist. Bei der Generierung der Daten aus Dreiecksnetzen ist dies dadurch gewährleistet, dass die ursprünglichen Vertices der Dreiecksnetze bereits während der Initialisierung auf entsprechende Koordinatenintervalle abgebildet werden. Bei der Generierung aus den kalibrierten Kamerabildern erfolgt dieser Schritt erst nach dem die Koordinaten der Punkte bekannt sind. Die Koordinaten werden jeweils in einen Begrenzungswürfel bzw. Bounding Cube eingebettet, um eine isotropische uniforme Quantisierung durchzuführen. 50

57 Abbildung 5.7: Für die Radiance Texturen eignet sich eine Speicherung mit verlustbehafteten Bildkompressionsverfahren auf der Basis von Frequenzzerlegungen, wie beispielsweise das JPEG Verfahren. Die Quantisierung erfolgt uniform, unabhängig für jede der drei Komponenten. Der Anzahl der Bits pro Komponente n ist prinzipiell frei wählbar. Bei den vorliegenden Datensätzen haben sich Werte zwischen 8 und 13 Bit bewährt. Niedrigere Quantisierungen stellten sich als zu grob heraus. Höhere hingegen brachten keinen weiteren (subjektiv) feststellbaren Unterschied in der Qualität der Darstellung. Wenn eine sehr akkurate Rekonstruktion der ursprünglichen Koordinaten erfolgen soll, besteht die Möglichkeit einen Korrekturwert als zusätzliches Abtastpunktattribut zu speichern. In [2] wird vorgeschlagen, einen quantisierten Wert mit 2 oder 3 Bit Genauigkeit zu speichern, der eine Translation der Abtastpunktposition entlang seiner Normale bestimmt Quantisierung der Normalen Für die Darstellung von schattierten Bildern, d.h. für die Beleuchtungsberechnung beim Rendering, ist es notwendig, Punktattribute zu speichern. Dazu zählen die Normalenvektoren jedes Punktes, die auch in quantisierter Form gespeichert werden. Das in dieser Arbeit verwendete Quantisierungsschema [6][31] basiert auf den Flächennormalen eines regelmäßig unterteilten Oktaeders, der in der Einheitskugel eingebettet ist (Abbildung 5.8). Ausgehend von den acht Dreiecksflächen, werden diese rekursiv in jeweils 4 Teildreiecke unterteilt. Die Unterteilung findet statt, indem jede Kante eines Dreiecks in der Mitte geteilt wird. Die dadurch entstandenen neuen Knoten werden auf die Einheitskugel zurückprojiziert. Aufgrund der Symmetrie hat das neue mittlere Dreieck nach einer Unterteilung dieselbe Normale wie das Ausgangsdreieck. Dadurch erhält man uniform auf der Kugel 51

58 Abbildung 5.8: Das Quantisierungsschema für Normalen basiert auf der regelmäßigen Unterteilung eines Oktaeders (aus [2]). verteilte Normalen. Dieses Prinzip lässt sich sehr einfach mithilfe von barizentrischen Koordinaten und ohne die explizite Betrachtung des Oktaeders anwenden. Im Folgenden wird die Quantisierung und deren Umkehrung beschrieben. Das Resultat der Quantisierung ist ein Bitcode mit einer Länge von 3 + 2n Bits. Die ersten 3 Bits enthalten die Information, in welchen Oktanten des Koordinatensystems die Normale zeigt. Für jeden Unterteilungsschritt auf einer Oktaederseite kommen jeweils 2 Bit an Information hinzu. Die ersten 3 Bits ergeben sich durch die Vorzeichen der Normalenkomponenten. Außerdem werden in diesem Berechnungsschritt die Eckpunkte der entsprechenden Oktaederseite bestimmt und der Schnittpunkt der Normale mit dieser Fläche berechnet. Der folgende Pseudocode fasst die beschriebenen Schritte zusammen: Eingabe: n Normale, n =1 int code = ( (n.x > 0)? 0 : 1 ) ( (n.y > 0)? 0 : 2 ) ( (n.z > 0)? 0 : 4 ); vektor pn; pn.x = signum( n.x ); pn.y = signum( n.y ); pn.z = signum( n.z ); Eckpunkte der Oktaederfläche: t 0,x =( pn.x, 0, 0 ) T t 0,y =( 0, pn.y, 0 ) T t 0,z =( 0, 0, pn.z ) T Schnittpunkt Normale/Fläche: vektor p; p = n / ( n pn ); 52

59 In jedem Unterteilungsschritt werden zunächst die barizentrischen Koordinaten des Schnittpunktes der Normale und der Oktaederfläche bezüglich deren Eckpunkte t 0,x, t 0,y und t 0,z berechnet. Seien b 1, b 2 und b 3 diese barizentrischen Koordinaten, dann lässt sich ein Unterteilungsschritt durch die folgende Fallunterscheidung darstellen. Es wird jeweils auch die Berechnung der neuen Oktaederteilfläche angegeben: Eingabe: t i,x, t i,y, t i,z, und b i,1, b i,2, b i,3 Ausgabe: 2 Bit Code, in welchem Teildreieck der Punkt liegt Teildreieck für den nächsten Unterteilungsschritt if ( b i,1 > 0.5 ) code = 0; t i+1,x =t i,x t i+1,y =(t i,x + t i,y )/2 t i+1,z =(t i,x + t i,z )/2 else if ( b i,2 > 0.5 ) code = 1; t i+1,x =(t i,x + t i,y )/2 t i+1,y =t i,y t i+1,z =(t i,y + t i,z )/2 else if ( b i,3 > 0.5 ) code = 2; t i+1,x =(t i,x + t i,z )/2 t i+1,y =(t i,y + t i,z )/2 t i+1,z =t i,z else code = 3; t i+1,y =(t i,x + t i,y )/2 t i+1,y =(t i,y + t i,z )/2 t i+1,z =(t i,z + t i,x )/2 Bei den in dieser Arbeit verwendeten Testdatensätzen hat sich gezeigt, dass eine Quantisierung der Normale auf 13 Bits, d.h. 5 Unterteilungsschritte, für eine gute Qualität beim Rendering genügt. Die Quantisierung kann aber, wie oben beschrieben, beliebig genau durchgeführt werden. Die Umkehrung der Quantisierung erfolgt, indem zuerst die Eckpunkte der Oktaederseite aus den ersten 3 Bit der quantisierten Normale bestimmt werden. Anhand der jeweils nachfolgenden 2 Bit Codes wird die Unterteilung der Dreiecksfläche und somit die Berechnung 53

60 neuer Eckpunkte, analog zum Quantisierungsvorgang durchgeführt. Am Ende der Verfeinerung wird die Normale durch die Vektorsumme der drei letzten Eckpunkte und anschließender Normalisierung berechnet. Beide oben beschriebenen Vorgänge lassen sich iterativ und ohne komplexe Rechenoperationen durchführen. Deshalb eignet sich diese Methode zur schnellen Speicherung bzw. Rekonstruktion der Normalen Speicherung der Koordinaten Bei einer Quantisierung von n Bit pro Koordinatenkomponente ergeben sich 2 n 2 n 2 n = 2 3n mögliche Koordinatentripel. Anschaulich bedeutet dies, das der Bounding Cube in 2 3n Sub- Cubes (Voxels) unterteilt wird. Die quantisierten Koordinaten liegen jeweils im Mittelpunkt eines Voxels. Wenn der Würfel die Kantenlänge 1 besitzt, und somit die Kantenlänge eines Voxels d = 1/2 n ist, liegt die Samplingdichte zwischen d und 3d (dem maximalen Abstand zweier Voxel-Mittelpunkte). Der Quantisierungsfehler hat 3/4d als obere Grenze. Dieser Wert entspricht dem Abstand des Voxel-Mittelpunkts zu einem seiner Eckpunkte. Sowohl die Samplingdichte, als auch der Quantisierungsfehler sind also von der Ordnung O(d). Diesen Abschätzungen liegt natürlich zugrunde, dass in jedem Sub-Cube, der die Oberfläche schneidet, auch mindestens einen Abtastpunkt enthält. Das ist, wie die Abschnitte über die Generierung der Punktdatensätze gezeigt haben, nicht zwingend der Fall. Bei den Datensätzen, die durch Uniform Clusterung entstanden sind, ist diese Annahme aber gesichert und auch bei der anderen Methode zur regelmäßigen Abtastung von Dreiecksnetzen kann dies angenommen werden. Sollten zwei oder mehrere Punkte dieselbe quantisierte Repräsentation teilen, d.h. im selben Voxel liegen (kollidieren), so können alle bis auf einen verworfen werden oder eine Spezialbehandlung, wie z.b. im Fall der Daten aus kalibrierten Kamerabildern, wird notwendig. Eine Kollisionsbehandlung für die Generierung der Punktdaten aus Dreiecksnetzen wird in Abschnitt beschrieben. Die Speicherung der Koordinaten nach der Quantisierung kann, sofern keine weiteren Attribute verwendet werden, in einem Binary Voxel Grid stattfinden. Dabei werden nicht die Positionen der Voxels selbst abgespeichert, sondern für jeden Voxel ein Bit, das angibt, ob ein oder mehrere Punkte in diesem Voxel liegen. Deshalb spricht man von einer vollen oder leeren Voxel-Zelle. Aufgrund des hohen Speicherbedarfes bei hohen Quantisierungen ist es nicht sinnvoll, einen Speicherbereich für 2 3n Punkte zu verwenden. Der Speicherbedarf dieses naiven Ansatzes bei einer Quantisierung von 13 Bit pro Koordinatenkomponente wäre bereits Bits oder 64 Gigabyte. Bei einer einfachen Liste der Daten ist es nicht effizient möglich, Kollisionen festzustellen. Deshalb wird eine hierarchische Octree-Datenstruktur, wie in [2] angedeutet, verwendet. Grundsätzlich befinden sich dabei die k k k, mit k = 2 n, ursprünglichen Voxels auf der niedrigste Ebene H 0 der Voxel-Hierarchie. Durch Zusammenfassen von jeweils Voxels erhält man eine gröbere Darstellung H 1 des Voxel-Gitters. Wenn mindestes eine der H 0 Voxels einer H 1 Zelle voll ist, wird das Bit der H 1 Zelle gesetzt, sonst nicht. Diese 54

61 Vergröberung wird n-mal durchgeführt und endet damit in einer einzigen Voxel-Zelle H n, die immer voll ist. Die verworfene Information bei einem Vergröberungsschritt kann durch einen Bytecode gespeichert werden, wobei die 8 Bits jeweils den Status eines Oktanten angeben. Für leere Zellen und darauf folgende Unterteilungen ist der Bytecode natürlich redundant, da er immer gleich Null ist. Daraus folgt, das aus H i+1 und den Bytecodes, für nicht leere Zellen, H i rekonstruiert werden kann. Abbildung 5.9 zeigt eine hierarchische Kodierung eines zweidimensionalen Felder, analog zu der oben beschriebenen Methode. Die zur Rekonstruktion benötigten 4 Bit Codes sind in Abbildung 5.10 für die Kodierung dargestellt. Abbildung 5.9: Ein zweidimensionales Beispiel zur hierarchischen Kodierung der Voxel Repräsentation (aus [2]). Die mit * gekennzeichneten Null-Codes müssen nicht explizit gespeichert werden. Abbildung 5.10: Die 4 Bit Codes für die Rekonstruktion der Voxel Repräsentation (aus [2]). In [2] wird gezeigt, dass der benötigte Speicherbedarf für eine Voxel-Repräsentation mit m gefüllten Voxel-Zellen, unabhängig von der Anzahl der Hierarchieebenen, höchstens 1 3 m Bytecodes bzw Bits pro Voxel-Zelle benötigt. Es gilt aber zu berücksichtigen, dass mit einer genaueren Quantisierung und somit einer höheren Anzahl von Hierarchieebenen die Anzahl der gefüllten Voxel-Zellen zunimmt und somit der Gesamtspeicherbedarf eines Datensatzes steigt. Die obengenannte Abschätzung ergibt sich daraus, dass die Anzahl der m gefüllten Voxel-Zellen in der H 0 Ebene auf der jeweils nächst höheren Hierarchieebene auf ein Viertel reduziert ist und nur gefüllte Voxel-Zellen gespeichert werden müssen. Das bedeutet, H 0 55

62 kann durch H 1 und 1 4m Bytecodes rekonstruiert werden. Daraus ergibt sich die Gesamtzahl der Bytecodes, die ungleich Null sind, für n Hierarchieebenen: n i=1 4 i m 1 m. (5.10) 3 Die Abschätzung ist natürlich nur haltbar, wenn die Voxel-Zellen eine diskretisierte Repräsentation der Oberfläche darstellen, also keine unregelmäßige Abtastung vorliegt. Für die quantisierten Normalen wäre analog eine Dimensionserhöhung, wie von der Quadtree auf die Octree Struktur, denkbar, um den quantisierten Wert als vierte Vektorkomponente einer Punktkoordinate zu verwenden. Eine Testimplementation hat gezeigt, das der daraus resultierende vierdimensionale Voxel-Raum sehr dünn besetzt ist und eine hierarchische Speicherung wie oben beschrieben nicht kompakt erfolgen kann. Deshalb wurden die Normalen und andere Punktattribute in einer Liste gespeichert, wobei die Anordnung der Listenelemente lokale Gegebenheiten für eine effiziente Speicherung ausnutzt, wie im folgenden Abschnitt beschrieben wird Implementation der Speicherung der Koordinaten und Attribute Die für eine effiziente Implementation der im vorigen Abschnitt beschriebenen Verfahren verwendeten Datenstrukturen und die Vorgehensweise sollen hier vorgestellt werden. Aufgrund des hohen Speicherbedarfes und der Nachteile der naiven Ansätze ist für die hierarchische Octree Speicherung nur ein Ansatz sinnvoll, der zunächst mit einem leeren Baum und nicht auf der niedrigsten Hierarchieebene beginnt. Für den Aufbau des Octrees im Speicher bzw. den Octreeknoten wurde folgende Datenstruktur gewählt: typedef struct { unsigned char code; union { void *ptr[ 8 ]; unsigned int normal[ 8 ]; }; unsigned int branchnormal; }OCTREENODE; Darin ist code der Bytecode, dessen Bits die Belegung der Zellenoktanten angeben. In der Union Struktur können entweder Zeiger auf die Nachfolgeknoten, also die Zellenoktanten gespeichert sein, oder, wenn sich der Knoten auf der zweituntersten Hierarchieebene H 1 befindet, sind dort entweder Zeiger auf Punktattribute gespeichert oder nur die Normale, wenn keine weiteren Attribute vorhanden sind. Weitere Punktattribute sind beispielsweise die Punktgröße, in quantisierter oder nicht quantisierter Form oder die Radiancewerte für eine oder mehrere Richtungen. Der Vorteil der Union Struktur liegt in einer großen Speichereinsparung, da die unterste Ebene des Octrees nicht explizit (in Form von 56

63 OCTREENODEs) gespeichert wird. Der branchnormal Parameter ist optional, und kann, wie später vorgestellt, zu einer alternativen Speicherung der Normalen verwendet werden. Das Hinzufügen eines Punktes zu dieser Datenstruktur erfolgt iterativ. Der Punkt wird durch seine quantisierten Koordinaten x, y und z und seine Attribute, wie z.b. Normalen angegeben. Weiterhin wird eine Funktion benötigt, um neue, leere OCTREENODE Strukturen anzufordern. Bei den Koordinaten bezeichnet z.b. x i das i-te Bit (vom untersten aus) der Ganzzahldarstellung der x Koordinate. Für eine Quantisierung auf n Bit zeigt der folgende Pseudocode das Hinzufügen eines Punktes zur Octree Struktur. Begonnen wird dabei von der Wurzel aus, die bei der Initialisierung aus einer leeren OCTREENODE Struktur besteht: OCTREENODE *node = root; for ( l = 0; l < n; l ++ ) { int code = x n l 1 2y n l 1 4z n l 1 ; // nächste Ebene ist H 0? if ( l == n 1 ) { } // H 0 Voxel bereits belegt? if ( node->code & ( 1 << code )!= 0 ) return; // belegt // Speichern der Attribute node->normal[ code ] = normal; return; // Speicherung der H l Voxel-Information: node->code = 1 << code; } // nächste Ebene if ( node->ptr[ code ] == NULL ) node = node->ptr[ code ] = newoctreenode(); else node = (OCTREENODE*)node->ptr[ code ]; Nachdem alle Punkte in der hierarchischen Struktur enthalten sind, kann diese für den späteren Gebrauch gespeichert werden. Für die spätere Rekonstruktion der Koordinaten sind nur noch die code Teile der OCTREENODE Struktur notwendig. Die Normalen bzw. anderen Attribute werden im Speicher aber mit in der Struktur abgelegt, um eine eindeutige Zuordnung der Attribute zu den Punkten, bzw. Koordinaten zu gewährleisten. Die Speicherung der Bytecodes erfolgt rekursiv von der Wurzel ausgehend. Die Attribute eines Punktes werden 57

64 jeweils bei erreichen eines H 0 Voxels einer entsprechenden Liste hinzugefügt. Die Reihenfolge der Attribute in dieser Liste ist diesselbe, die bei der Rekonstruktion der Koordinaten aus den Bytecodes wieder entsteht. Daraus entstehen noch weitere Vorteile für eine kompakte Speicherung der Attribute, auf die später noch eingegangen wird. Auch die Zeiger in der Datenstruktur werden nur für den Aufbau des Baumes im Speicher benötigt. Wie bereits erwähnt, erfolgt die Speicherung rekursiv von der Wurzel aus. Für jeden H i Knoten, mit i > 1, wird der Bytecode gespeichert, und es werden nur Zweige des Octrees weiter verfolgt, deren Bytecode ungleich Null ist. Wird ein H 1 Knoten erreicht, so wird der zugehörige Bytecode und die Attribute der (bis zu acht) darin befindlichen H 0 Knoten, bzw. Punkten gespeichert. Die Rekonstruktion erfolgt analog dazu rekursiv. Bei der Speicherung der Daten und damit der Attributlisten ist - durch die Depth-First Rekursion - die Anordnung so, dass die Attribute benachbarter Punkte, bzw. allgemein näher beieinanderliegender Punkte, hintereinander erfolgt. Bei realen Datensätzen ist anzunehmen, dass sich die Attribute, z.b. die Farbe oder die Normale einer Oberfläche in einer lokalen Umgebung nur leicht oder gar nicht verändern. Am Beispiel der quantisierten Normale bedeutet dies, dass mit großer Wahrscheinlichkeit die obersten Bits, d.h. anschaulich ausgedrückt, die ungefähre Richtung, der Normalen einer Umgebung gleich sind. Diese Tatsache kann man sich für eine kompakte Speicherung der Attribute mithilfe von Datenkompressionsverfahren zu nutze machen. Die vorliegende Implementation teilt die Bits der gespeicherten Normalen auf. Die oberen, z.b. 5 Bits, weisen in der Attributliste nur seltene Veränderungen auf, sind also redundanter, die Entropie der unteren, z.b. 8 Bit, ist deutlich höher. Somit wird nicht nur eine sehr kompakte Darstellung der Punktkoordinaten, sondern auch der Oberflächenattribute erreicht, wie Kapitel 8 zeigt. Eine andere Variante zur Speicherung der Normalen wurde zu Testzwecken implementiert. Dabei wurden in jedem Knoten des Octrees in der branchnormal Variable die obersten Bits und deren Anzahl abgelegt, die in allen darauf folgenden Knoten bzw. Blättern gleich sind. Dadurch wurde versucht die Tatsache der leichten Änderungen in lokalen Bereichen auf der Oberfläche weiter auszunutzen. Es hat sich aber gezeigt, dass der naive Weg, also eine Liste zu verwenden, zusammen mit dem Trick die Bitdarstellung der quantisierten Normalen aufzuteilen, einfacher und besser arbeitet Auflösen von Kollisionen bei der Quantisierung Bei der Quantisierung der Daten können mehrere unterschiedliche Abtastpunkte dieselben quantisierten Koordinaten besitzen, was im Folgenden mit Kollision bezeichnet wird. Anschaulich bedeutet dies, dass zwei oder mehr Abtastpunkte sich in einer Voxel-Zelle der niedrigsten Hierarchieebene (nach der oben beschriebenen Repräsentation) befinden. Natürlich können Informationen verworfen werden, und nur die Attribute eines dieser Abtastpunkte für die spätere Darstellung gespeichert werden. Dieses Vorgehen kann aber zu Darstellungsfehlern führen - vor allem bei Datensätzen mit unregelmäßiger Abtastung, bei denen die Abtastpunkte unterschiedliche Größenwerte besitzen. Aus diesem Grund besitzt die Implementation der hierarchischen Octree-Repräsentation die Möglichkeit, solche Kollisionen, mithilfe, vom Programmierer implementierten und übergebenen, Methoden aufzulösen. Diese Verfahrensweise 58

65 wird bei der Generierung der Daten mit Radiance Interpolation für die Speicherung der Farbwerte verwendet. Im Folgenden werden die untersuchten Möglichkeiten für die Abtastung von Dreiecksnetzen vorgestellt. Bei einer regelmäßigen Abtastung besitzen die Punkte lediglich eine Oberflächennormale. Bei Kollisionen können diese gemittelt werden. Allerdings wird zur Speichereinsparung die quantisierte Repräsentation der Normale verwendet. Das bedeutet, es liegt nur eine Richtungsaber keine Längeninformation vor. Nun bieten sich zwei Möglichkeiten an: Zum einen kann die Quantisierung zweier Normalen (bei einer Kollision zweier Abtastpunkte) rückgängig gemacht werden, die Vektorsumme berechnet und das Resultat wiederum quantisiert werden. Hierbei geht die Längeninformation verloren, was zu nicht korrekten Ergebnissen führt, wenn mehrere Kollisionen auftreten. Dieses Problem kann behoben werden, indem zusätzlich eine (quantisierte) Längeninformation gespeichert wird. Da die Speicherung der quantisierten Normalen intern als 32 Bit Ganzzahl erfolgt, aber die Darstellung selbst meist weniger als 16 Bit benötigt, kann die Längeninformation ebenfalls in dieser Variable kodiert werden. Damit lässt sich eine Vektorsumme aller Normalen berechnen, woraus ein gemittelter Normalenvektor resultiert. Bei einer unregelmäßigen Abtastung von Dreiecksnetzen gilt es zusätzlich den Größenwert der Abtastpunkte bei Kollisionen anzupassen. Eine Möglichkeit ist, im Anschluss an die Quantisierung der Koordinaten die Größenwerte zu bestimmen. Dies bedeutet allerdings einen zusätzlichen Berechnungsaufwand, der sich - wie Versuchsreihen gezeigt haben - mit einer erstaunlich einfachen Heuristik vermeiden lässt. Wenn eine Kollision zweier Abtastpunkte mit den Größenwerten g 1 und g 2 auftritt, so wird als Größe für den weiter bestehenden Abtastpunkt der Wert g neu = max(g 1, g 2 )+0.07 min(g 1, g 2 ) verwendet. Die durch die Quantisierung entstehenden Verschiebungen sind im Vergleich zu den Größenwerten der Abtastpunkte vernachlässigbar klein, und müssen nicht berücksichtigt werden. 59

66 60

67 Kapitel 6 Optimiertes Rendering der Punktdatensätze In diesem Kapitel werden die, für das Rendering entwickelten, Datenstrukturen vorgestellt und der Ablauf des Renderings für die unterschiedlichen Punktdatensätze erläutert. Im Anschluss wird auf verbesserte Splatting Techniken und Optimierungen eingegangen. Schließlich werden Möglichkeiten zur Leistungsanalyse des Renderings aufgezeigt. 6.1 Datenstrukturen und effiziente Ermittlung sichtbarer Flächen Die entwickelten Datenstrukturen bilden die Grundlage für eine sinnvolle und gleichzeitig effiziente Ermittlung der sichtbaren Flächen eines Datensatzes. Der vorgestellte Ansatz erlaubt es, beide Aufgaben gleichermaßen zu lösen Allgemeine Strategie zur Datenaufbereitung Die hohe Leistungsfähigkeit moderner Grafikkarten bei der Transformations- und Beleuchtungsberechnung und dem Rasterisieren erfordert auch eine darauf abgestimmte Art der Datenaufbereitung und -strukturen. Es ist nicht möglich, die Grafikhardware auszulasten, wenn die CPU des Rechners die Daten vor jedem zu renderten Bild modifizieren muss oder die zu zeichnenden Punkte einzeln ermittelt werden müssen und daraus eine Liste erstellt werden muss. Der begrenzende Faktor bei solchen Verfahren ist vor allem der Speicherdurchsatz zwischen CPU und Arbeitsspeicher. Je nach Art und Weise der Implementation kann auch der Overhead der API-Aufrufe, wie beispielsweise die OpenGL Immediate-Mode-Befehle, die Geschwindigkeit negativ beeinflussen. Es ist also notwendig, die Daten so abzulegen, dass das Programm eine einfache Selektion, der benötigten Daten vornehmen kann, die Daten sich aber größtenteils unverändert in, über DMA zugänglichen, AGP Speicher oder im Speicher der Grafikhardware selbst befinden. Es ist wichtig die Menge der pro Bild variablen Daten gering zu halten. Das beinhaltet auch, dass die Vertexliste, die die Koordinaten der Punkte 61

68 enthält, und die Attributlisten nicht geändert werden dürfen. Vielmehr sollten Lookup Tabellen, z.b. für die Beleuchtungsberechung, Farbgebung usw. verwendet werden. Diese können dann durch Texturkoordinaten adressiert werden. Somit sind die Attributlisten statisch und der Speicher, der für jedes Bild zu übertragenden Daten, wird klein gehalten. Die Art und Weise, wie die Daten pro Punkt organisiert werden, wird jeweils in den entsprechenden Abschnitten über Rendering mit variabler und einheitlicher Punktgröße und der Datensätze aus kalibrierten Kamerabildern beschrieben. Im Anschluss an die verwendeten OpenGL API Funktionen, die zum Rendering eingesetzt werden, befindet sich die Beschreibung, wie die Datenlisten aufgeteilt werden, um die verschiedenen Sichtbarkeitsberechnungen durchführen zu können Verwendete OpenGL API-Funktionen Nach der Rekonstruktion der gespeicherten Daten liegt ein Liste von Koordinaten und optional Listen mit Texturkoordinaten, Farbwerten und Normalen vor. Im Zuge dieser Arbeit wurden zahlreiche unterschiedliche Varianten getestet, diese Daten in einer Art und Weise abzulegen, die möglichst schnell von der Grafikhardware verarbeitet werden kann. Eine Aufstellung der bevorzugten Datenformate für NVidia GeForce GPUs befindet sich in [29]. OpenGL kann verschiedene Darstellungen für die Daten, beispielsweise Koordinaten, verarbeiten. Es hat sich aber in allen Fällen erwiesen, dass die Darstellung der Komponenten in 32 Bit Gleitkommazahlen am günstigsten ist, obwohl andere Datentypen, z.b. 16 Bit Ganzzahlen für die Texturkoordinaten, weniger Speicher benötigen und somit geringeren Speichertransfer verursachen würden. Deshalb wurde für jede der oben genannten Listen die jeweiligen Komponenten linear in einem Speicherbereich als 32 Bit Gleitkommazahl abgelegt. Im OpenGL Jargon wird dabei von Vertex Arrays, bzw. Color, Normal oder Texture Coordinate Arrays gesprochen. Die Adressen dieser Arrays und deren enthaltene Datentypen werden an OpenGL, z.b. mit dem glvertexpointer Befehl übergeben. Diese Speicherbereiche werden anschließend, mit den entsprechenden OpenGL Funktionen der Compiled Vertex Arrays als locked, d.h. nicht modifizierbar durch die CPU, deklariert. Dadurch können die Daten, je nach OpenGL Implementation, unverändert belassen, optimiert oder in einen besser geeigneten Speicherbereich übertragen werden. Im Fall der NVidia GeForce 3/4 Grafikkarte, können die Daten (vom Grafikkartentreiber) in den AGP Speicher transferiert werden. Die Liste der Punkte inklusive ihrer Attribute kann ganz oder teilweise mit dem gldrawarrays OpenGL Befehl gezeichnet werden. Wenn mehrere nicht zusammenhängende Fragmente benötigt werden, sollte der glmultidrawarrays Befehl verwendet werden. Mithilfe der Vertex Array Range Erweiterung wird eine Funktion zur Speicherallokation eingeführt, die es - auch wieder abhängig von der OpenGL Implementation - erlauben soll, den am besten geeigneten Speichertyp für ein Array zu allokieren. Bestgeeignet bezieht dabei darauf, einen Speichertyp zu allokieren, dessen Eigenschaften der Häufigkeit, wie oft die Applikation diesen Speicher beschreiben oder lesen wird, und der Priorität des Speicherbereichs, entspricht. Durch bestimmte Wertekonstellationen lässt sich so ein Speicherbereich für AGP/DMA Zugriffe oder direkt im Speicher der Grafikkarte allokieren. Die Unterschiede 62

69 zwischen den Speichertypen liegen in der zur Verfügung stehenden Bandbreite und haben wesentlichen Einfluss auf die Geschwindigkeit des Renderings. Eine Analyse der möglichen Leistungsengpässe befindet sich in Abschnitt 6.8 und Kapitel 8 zeigt anhand von Beispieldatensätzen die Relevanz in der Praxis Octrees und Frustum Culling Die Ermittlung sichtbarer Flächen lässt sich aufteilen in das Entfernen von Flächen, die sich nicht im sichtbaren Bereich des Betrachters befinden und in das Entfernen der Rückseiten. Der erste Teil, ist das so genannte Frustum Culling, dessen Durchführung in der entwickelten Implementation in diesem Abschnitt vorgestellt werden soll. Der Bildraum einer perspektivischen Abbildung besitzt die Form eines Pyramidenstumpfes (siehe auch Abbildung 5.6), ist also durch sechs Ebenen begrenzt. Die Ebenengleichungen lassen sich aus der Abbildungstransformation, d.h. dem Produkt aus Modelview- und Projektionsmatrix, berechnen [17]. In der vorliegenden Implementation wird eine hierarchische Octree Struktur verwendet, die ein schnelles Frustum Culling ermöglicht. Dazu wird ein achsenparalleles Begrenzungsvolumen in Form eines Würfels (Axis Aligned Bounding Cube) des Punktdatensatzes berechnet. Eine Octreedarstellung erhält man durch sukzessives Unterteilen des Würfels, in drei Dimensionen, also in Oktanten. Die Unterteilung erfolgt mit einer vorher festgelegten Tiefe, so dass die unterste Hierarchieebene des Octrees aus 2 3n Sub-Würfeln besteht. Teile des Punktdatensatzes innerhalb eines solchen Sub-Würfels werden im Folgenden als Octree Cluster bezeichnet. Die aufeinander folgenden Unterteilungen werden durch einen Baum dargestellt, dessen Wurzel das ursprüngliche Begrenzungsvolumen ist. Beim Frustum Culling gilt es nun festzustellen, welche der Octree Cluster sich im Bildraum befinden. Dazu wird von der Wurzel ausgehend rekursiv überprüft, ob ein Begrenzungsvolumen den Pyramidenstumpf schneidet. Ist das der Fall, so wird mit den jeweiligen Sub-Würfeln genauso verfahren. Schneidet das Begrenzungsvolumen eines Sub-Würfels der untersten Ebene den Pyramidenstumpf, so wird dieser Octree Cluster für das Rendering benötigt. Sind die sechs Ebenen, die den Pyramidenstumpf begrenzen in Hessesche Normalform gegeben, so lässt sich der Überschneidungstest für einen Begrenzungswürfel mit 6 8 = 48 Skalarprodukten und Additionen und acht binären Und-Verknüpfungen effizient durchführen. Wie bereits erwähnt werden die Daten pro Punkt in Listen gespeichert, in denen die Koordinaten, Normalen oder weiteren Attribute sequentiell gespeichert. Um eine Selektion der zu zeichnenden Punkte vornehmen zu können, erfolgt eine Anordnung, dass Punkte eines Octree Clusters hintereinander in der Liste gespeichert sind. Dabei werden zwei Tabellen, mit jeweils 2 3n Einträgen erstellt, die den Index des ersten Punktes und deren Anzahl eines Octree Clusters in der Liste enthalten. Das Resultat des Frustum Culling ist eine Liste von Octree Clusters die sich ganz oder teilweise im Bildraum befinden. Daraus lässt sich mithilfe der oben beschriebenen Tabellen eine Liste mit Startindizes und eine Liste mit der Punktanzahl pro Octree Cluster zusammenstellen. Diese beiden Listen können der OpenGL Funktion gldrawarrays zum Rendering übergeben werden. 63

70 Diese Vorgehensweise, d.h. eine grobe Ermittlung der sichtbaren Flächen, eignet sich sehr gut für heutige 3D Hardware. Die Punktdaten selbst sind statisch, und müssen also nicht modifiziert werden Backface Culling und Normalencluster Zur Ermittlung der sichtbaren Flächen gehört auch die Entfernung der nicht sichtbaren Rückseiten. Dieser Vorgang wird auch Backface Culling genannt. Auch andere Verfahren zum punktbasierten Rendering entfernen grob die Rückseiten des Oberflächen, um unnötige Arbeit einzusparen. Dazu werden meist Normalen ähnlicher Richtung zusammengefasst und für diese Gruppen bestimmt, ob die Flächenpartien vom Betrachter weg oder zum Betrachter hin zeigen. Oft werden Normal Cones verwendet, wie z.b. in [2], wobei für einen Octree Cluster ein Kegel bestimmt wird, indem alle dort vorkommenden Normalen enthalten sind. Eine andere Möglichkeit zum Clustering von Normalen wird in [38] beschrieben. In diesem Abschnitt wird eine andere Form beschrieben, die auf der, bereits vorgestellten, Quantisierung der Normalen basiert, sich effizient mit der Octree Datenstruktur vereinbaren lässt und zudem eine feinere Ermittlung der sichtbaren Flächen ermöglicht. Eine Gruppe von Normalen ähnlicher Richtung wird im Folgenden als Normal Cluster bezeichnet. Bei der Quantisierung der Normalen, wird ein Ganzzahlwert berechnet, bei dem für jeden Unterteilungsschritt bei der Quantisierung, siehe Kapitel 5.4.2, zwei Bits Information hinzukommen. Daraus ergibt sich aber auch, dass Normalen eine ähnliche Richtung aufweisen, wenn deren obersten m Bits, der quantisierten Darstellung, gleich sind. Daraus resultiert eine mögliche Unterteilung des Datensatzes in 2 m Normal Cluster, in denen sich jeweils Normalen befinden, deren oberste m Bit, mit m < k, gleich sind. Um die beiden Unterteilungen der Punkt- und Attributlisten nach Octree bzw. Normal Cluster zu kombinieren, sind zwei Möglichkeiten denkbar. Bei der ersten Variante wären die Punkte zuerst nach den Normal Clusters sortiert. Innerhalb dieser Normal Cluster könnten die Punkte nach dem Octree Kriterium angeordnet werden. Für das Rendering an sich wäre diese Aufteilung durchaus denkbar, aber es gibt einen Nachteil. Verschiedene Abschätzungen der Darstellungsparameter, wie z.b. die Anzahl der benötigten Abtastpunkte bzw. Splats und deren Größe, hängen vom Abstand zwischen Betrachter und Punkt ab. Diese Berechnungen können, um den Aufwand klein zu halten, auf der Basis von Octree Clusters erfolgen. Deshalb fällt die Entscheidung auf eine andere Variante. Hierbei werden die Punkte, wie im vorherigen Abschnitt beschrieben, zuerst nach den Octree Clusters sortiert. Innerhalb dieser Octree Cluster werden sie nach den Normal Clusters angeordnet. Analog zu den Tabellen für die Octree Unterteilung werden solche für die Normalen Unterteilung für jeden Octree Cluster erstellt. Die Unterteilung nach den Normal Clusters wird aus zwei Gründen vorgenommen: dem Backface Culling und der Abschätzung der benötigten Sampling Dichte der Fläche. Da das Clustering der Normalen aus einer rekursiven Unterteilung von (dreieckigen) Oktaederflächen entstanden ist, lässt sich ein Normal Cluster durch drei Normalen begrenzen. Wenn alle drei begrenzenden Normalen eines Normal Clusters vom Betrachter wegzeigen, ist sichergestellt, dass dies auch bei allen Punkten einer Oberflache der Fall ist, deren Normale zu diesem Normal 64

71 Cluster gehört. Bei Generierung der Daten aus Dreiecksnetzen, die geschlossene Oberflächen darstellen, können solche Abtastpunkte vom Rendering ausgeschlossen werden. Der zweite Grund ist, dass bei Datensätzen, bei denen eine regelmäßige Abtastung eines Dreiecksnetzes vorliegt, die Anzahl der benötigten Punkte, um eine geschlossene Oberfläche zu rendern, abhängig vom Winkel zwischen Betrachterblickrichtung und Oberflächennormale ist. Eine Begründung dieser Aussage befindet sich in Abschnitt 6.4 und [33]. In diesem Fall werden die Punkte zusätzlich zur Unterteilung nach Octree und anschließender Unterteilung nach Normal Clusters, innerhalb der letzteren zufällig angeordnet. In der Praxis hat sich bei vielen Datensätzen eine Unterteilung des Datensatzes beispielsweise in = 512 Octree Cluster und ebenso viele Normal Clusters als gut geeignet erwiesen. Dabei entsteht eine Fragmentierung des Datensatzes in bis zu = Teile. Durchgeführte Testreihen haben gezeigt, dass es keinerlei Einbußen bei der Rendergeschwindigkeit gibt, wenn die Anzahl der Fragmente beim Rendering unter etwa bleibt. In den realen Datensätzen befindet sich die benötigte Anzahl jedoch im Bereich von nur wenigen Tausend. Diese geringe Anzahl kommt zustande, weil bereits durch das Backface Culling nahezu die Hälfte der Fragmente ausgeschlossen werden und jeder Octree Cluster meist nur Abtastpunkte aus einigen wenigen Normal Clusters enthält. Bei Datensätzen ohne Normaleninformation kann natürlich kein Backface Culling durchgeführt werden. Dabei ist die Anzahl der Cluster aber noch geringer, denn sie entspricht lediglich der Anzahl der Octree Cluster. Die in diesem Abschnitt vorgestellte Fragmentierung der Daten, die in Abbildung 6.1 schematisch dargestellt wird, hat sich als sehr praktikabel erwiesen. Sie ermöglicht eine genügend genaue Aufteilung des Datensatzes zur Selektion beim Rendering und erreicht trotzdem die Leistungsgrenzen der getesteten Hardware. Abbildung 6.1: Die Fragmentierung eines Punktdatensatzes erfolgt zunächst nach den Octree Clusters, anschließend nach den Normal Clusters. Letztere kann für das Rendering mit Daten aus kalibrierten Kamerabildern durch eine Unterteilung nach Texturreferenzen ersetzt werden Implementationsdetails Wie bereits erwähnt, wird ein Normal Cluster durch drei Normalen begrenzt. Während der Initialisierungsphase, des für diese Arbeit entwickelten Programms, wird eine Tabelle mit 65

72 diesen Begrenzungsnormalen und eine Tabelle, die für jeden Normal Cluster die Indizes der drei begrenzenden Normalen speichert, erstellt. Vor dem eigentlichen Rendering eines Bildes werden anhand der Betrachterparameter für die Begrenzungsnormalen bestimmt, ob sie zum Betrachter hin oder von ihm weg zeigen. Für die Darstellung der Oberflächen sind die Normal Cluster notwendig, bei denen eine oder mehr Begrenzungsnormalen zum Betrachter hin zeigt. Diese Information wird in einer Tabelle gespeichert. Werden Datensätze mit einer regelmäßigen Abtastung der Oberfläche verwendet, so werden weiterhin für jeden Normal Cluster der Kosinus des mittleren Winkels α zwischen den darin enthaltenen Normalen und dem Vektor zum Betrachter berechnet. Dieser Wert entspricht dem Verhältnis einer Fläche A, die auf die Betrachterebene projiziert wird und dort den Flächeninhalt A besitzt: cos(α) = A A (6.1) Bei punktbasiertem Rendering mit regelmäßig abgetasteten Oberflächen wird abgeschätzt, wie hoch die Abtastdichte sein muss, um eine geschlossene Oberfläche darzustellen. Angenommen, es existieren keine verdeckten Flächen, so lässt sich dieses Problem mit einem Urnen- Kugel-Modell beschreiben [18]. Jedem der ν Pixel des Bildes entspricht eine Urne. Die erwartete Anzahl von zufällig, unabhängig, mit gleicher Wahrscheinlichkeit auf diese Urnen verteilten Kugeln ist ν H ν, wobei gilt H ν = ln(ν)±1. Aufgrund des asymptotischen Verhaltens lässt sich vereinfacht die Zahl der benötigten Kugeln mit O(ν) angeben. Um verdeckte Flächen, deren Größe in Pixels gemessen mit h bezeichnet wird, in diese Betrachtung mit einzubeziehen, sei die gesamte projizierte Fläche a := ν + h. In [32] wird gezeigt, dass a ln ν + O(a) Abtastpunkte genügen, um damit auf jeden Pixel, mit einer genügend hohen Wahrscheinlichkeit, ein Abtastpunkt der sichtbaren Oberfläche fällt. Für praxisrelevante Auflösungen ergeben sich hiermit etwa 11 bis 14 benötigte Abtastpunkte pro Pixel. Mit dem oben berechneten Faktor lässt sich für die Flächen jedes Normal Clusters somit die benötigte Abtastdichte, relativ zu der während der Datengenerierung gespeicherten, berechnen. Durch die zufällige Anordnung der Punkte innerhalb der Normal Cluster kann eine andere Abtastdichte simuliert werden, indem nur ein Teil der Punkte für das Rendering verwendet wird. Bei allen Datensätzen erfolgt im Rendering-Vorgang nach diesen Vorberechnungen die Ermittlung der im Bildraum befindlichen Flächen durch die Octree Datenstruktur. Für jeden sichtbaren Octree Cluster werden die Oberflächenteile bestimmt, die dem Betrachter zugewandt sind. Dabei handelt es sich um Fragmente in der Liste des gesamtem Datensatzes (siehe auch Abbildung 6.1). Zusammenhängende Fragmente werden dabei identifiziert und zusammengefasst. Das Resultat dieser Operationen ist letztendlich eine Liste von Indizes der ersten Punkte der Fragmente und der Fragmentlängen. Mit diesen Listen kann der sichtbare Teil des Datensatzes gezeichnet werden. Sind Abschätzungen notwendig, die innerhalb der Applikation pro Octree Cluster durchgeführt werden, so werden jeweils die Fragmente der Octree Cluster gezeichnet und nicht die des vollständigen Datensatzes. 66

73 6.2 Beleuchtungsberechnung über Texturen Die zur Speicherung quantisierten Normalen dienen, nach der Rekonstruktion, zur Beleuchtungsberechnung während des Renderings. Dies kann entweder mit der Fixed-Function Grafikpipeline von OpenGL oder innerhalb eines Vertex Programs erfolgen. Es ist aber möglich, wenn der Anwendungszweck dies zulässt, eine vereinfachte Beleuchtungsberechnung einzusetzen. Es bietet sich an, sogenannte Directional Lights, d.h. unendlich weit entfernte Lichtquellen zu verwenden. Daraus resultiert eine konstante Lichteinfallsrichtung und somit eine Beleuchtungsberechnung, die nicht mehr vom Ort eines Oberflächenpunktes abhängig ist. Da durch die Quantisierung nur eine begrenzte Anzahl verschiedener Normalen existiert, ist es nicht notwendig die Berechnung für jeden Punkt, sondern nur für jede Normale durchzuführen. Die Beleuchtungsberechnung kann durch die Applikation durchgeführt werden und kann somit parallel zu der Grafikhardware arbeiten. Um diese Form der Beleuchtungsberechnung so zu gestalten, dass ein schnelles Rendering möglich ist, wird die Beleuchtung in einer Textur gespeichert, die als Look Up Tabelle dient. Jeder Texel entspricht der Beleuchtung einer quantisierten Normale. Die Textur wird jeweils nach einer Änderung der Betrachterparameter aktualisiert. Im Allgemeinen werden Texturen mit einer quadratischen Größe bevorzugt. Bei einer Quantisierung der Normalen auf beispielsweise 13 Bit wird deshalb eine 2 7 mal 2 7 Texel große Texture verwendet, da = 2 7. Beim Rendering kann auf die Beleuchtungsinformation dann durch einfaches Texture Mapping zugegriffen werden. Dazu wird jedem Abtastpunkt statt der rekonstruierten Normale ein Texturkoordinaten-Paar (u, v) zugewiesen, das den zur jeweiligen Normale gehörenden Texel adressiert. Die Texturkoordinaten in Gleitkommaformat, d.h. mit einem Wertebereich [0;1], können direkt aus dem Bitcode c der Quantisierung (auf n Bit) bestimmt werden: u = c mod 2 n/2 v c = 2 n/2 mod 2 n/2 (6.2) ( u (u, v) T = 2 n/2, v ) T 2 n/2 Diese Methode kann in dieser Form natürlich nur auf eine vereinfachte Beleuchtungsberechnung angewendet werden. Sie hat dafür aber mehrere Vorteile. Abgesehen von der möglichen Parallelisierung und Verteilung der Arbeit auf die CPU und die GPU, wird die Grafikpipeline, die einen begrenzenden Faktor darstellen kann, entlastet. Weiterhin wird der zu transferierende Speicher bei einer genügend großen Zahl von Punkten, reduziert, da statt einer Normale bestehend aus drei Komponenten, nur noch zwei Komponenten für ein Texturkoordinaten-Paar notwendig sind. Es ist auch eine Verwendung von eindimensionalen Texturen möglich. Allerdings erlaubt dies keine sehr genauen Normalenquantisierungen, da die maximale Anzahl von Texels von 1D-Texturen beschränkt ist. Bei einer GeForce 3 Grafikkarte liegt die maximale Größe einer 1D Textur bei 4096 Texels, womit eine maximale Quantisierung der Normale auf 12 Bit möglich ist. 67

74 6.3 Rendering mit variabler Abtastdichte Bei dieser Renderingmethode wird die benötigte Größe der einzelnen Splats, um beim Rendering eine geschlossene Oberfläche darzustellen, durch die Vorberechnung, wie in Kapitel 5.1 beschrieben, bestimmt. In diesem Abschnitt wird die Organisation der Daten im Speicher und das Rendering vorgestellt Anforderungen und Datenaufbereitung Die notwendigen Daten für diese Art des Renderings umfassen primär die folgenden drei Aspekte die Koordinate, die Größe und die Normale eines Splats. Die tatsächliche Größe eines Splats beim Rendering hängt vom oben genannten Größenwert und der Entfernung zum Betrachter ab. Außerdem ist es in OpenGL nur möglich, die Punktgröße für das Rendering über den Immediate-Mode-Befehl void glpointsize( GLfloat size ) anzugeben. Es ist nicht möglich, diese, wie die anderen Daten, in Arrays zu übergeben. Aus diesen beiden Gründen, werden Vertex Programs eingesetzt. Diesen können verschiedene Datenstreams übergeben werden, deren Semantik nicht definiert ist, d.h. die darin enthalteten Daten kann das Vertex Program für beliebige Zwecke verwenden. Einer der Ausgabeparameter der Vertex Programs, deren Semantik natürlich festgelegt ist, ist die Punktgröße. Es hat sich in Versuchen gezeigt, dass es sinnvoll ist, keinen separaten Datenstream für die Punktgröße zu verwenden. Stattdessen werden keine dreidimensionalen Koordinaten, sondern homogene Koordinaten verwendet. Bei der Initialisierung der Daten, werden diese vorbereitet. Dabei wird die vierte Komponente gleich der Punktgröße g gesetzt, die ersten drei werden mit ihr multipliziert: p = (x, y, z) T p h = (gx, gy, gz, g) T (6.3) Da die Transformationsberechnung ohnehin mit homogenen Koordinaten durchgeführt wird, entsteht dadurch kein Nachteil, aber die Information steht dem Vertex Program zur Verfügung. Die Normalen werden entweder als Vektoren in einem Array von Normalen oder wie in Abschnitt 6.2 beschrieben, als Texturkoordinatenpaar in entsprechenden Arrays übergeben Rendering mit OpenGL und Vertex Programs Für das Rendering gilt es nun festzustellen, welche Teile des Datensatzes für die Darstellung benötigt werden. Hierzu ist die oben beschriebene Fragmentierung der Daten ausgelegt. 68

75 Durch die Ermittlung der sichtbaren Oberflächenteile werden die benötigten Fragmente des Datensatzes bestimmt. Um beim Rendering die Darstellung einer geschlossenen Oberfläche zu erhalten, müssen die einzelnen Splats groß genug dargestellt werden. Dazu wird ein Skalierungsfaktor benötigt, der zusammen mit der während der Datengenerierung bestimmten Größenmaßzahl eines Splats, die OpenGL Punktgröße ergibt. Die Abschätzung dieses Faktors kann entweder für alle Splats eines Octree Clusters gemeinsam oder für jeden Splat separat durchgeführt werden. Im letzteren Fall werden einige wenige Befehle mehr im Vertex Program benötigt. Im Folgenden wird die erste Variante vorgeführt, für die Berechnung pro Splat wird anschließend das entsprechende Vertex Program angegeben. Zur Berechnung werden, für beide Varianten, die OpenGL Projektions- und Modelview- Matrix herangezogen. Zunächst wird die Auflösung des OpenGL Fensters mit x w y w Pixel zum Öffnungswinkel der virtuellen Kamera in Verhältnis gesetzt. Dabei wird eine Projektionsabbildung vorausgesetzt, wie Sie beispielsweise durch den OpenGL Befehl glfrustum erzeugt wird und in Abschnitt beschrieben wurde. Das obige Verhältnis, bezeichnet mit p, wird wie folgt berechnet: p = x w 2 2z near r l = x w r l z near (6.4) Wie bereits erwähnt erfolgt die Abschätzung für jeden Octree Cluster. Als Referenzpunkt wird der dem Betrachter am nächsten gelegene Eckpunkt der Octree Cluster Bounding Box verwendet, der mit b bezeichnet wird. Für die Abbildung eines Punktes aus dem Model-Space (in dem alle Koordinaten der Objekte definiert sind) in das Koordinatensystem der Kamera wird in OpenGL die Modelview Matrix verwendet. Interessant ist in diesem Zusammenhang nur die Z-Komponente der transformierten Koordinate. Ihre Berechnung erfolgt durch das Skalarprodukt des zweiten Spaltenvektors der Modelview Matrix vdir und b : z = vdir b (6.5) Für die Abschätzung des Skalierungsfaktors wird noch eine Konstante c benötigt, die einmalig für die Größenmaße aus der Datengenerierung bestimmt werden muss. Damit lautet der Skalierungsfaktor s: s = c p z (6.6) Der Skalierungsfaktor wird anschließend in den Konstantenspeicher des Vertex Programs geschrieben. Das benötigte Vertex Program inklusive Kommentaren ist im Folgenden aufgelistet, wobei beide Möglichkeiten für die Beleuchtung, also die Berechnung anhand der Normalen und die Verwendung der Textur-Methode, angegeben sind. Außerdem wurden die Befehle der Koordinatentransformation explizit angegeben und nicht die Option der Koordinatentransformation der Vertex Programs 1.1 gewählt. Die Belegung des Konstantenspeichers ist in Tabelle 6.1 aufgelistet. 69

76 !!VP1.1 # Transformation der homogenen Koordinaten DP4 o[hpos].x,v[opos],c[0]; DP4 o[hpos].y,v[opos],c[1]; DP4 o[hpos].z,v[opos],c[2]; DP4 o[hpos].w,v[opos],c[3]; # Beleuchtung 1: Texturkoordinaten und Farbe durchreichen MOV o[tex0], v[tex0]; MOV o[col0], c[36]; # Beleuchtung 2: Eine punktförmige Lichtquelle DP3 R0.x, c[4], v[nrml]; DP3 R0.y, c[5], v[nrml]; DP3 R0.z, c[6], v[nrml]; DP3 R1.x, c[32], R0; DP3 R1.y, c[33], R0; MOV R1.w, c[34].x; LIT R2, R1; MAD R3, c[35].x, R2.y, c[35].y; MAD o[col0].xyz, c[31], R2.z, R3; # Berechnung der Splatgröße (v[opos].w: Größenmaß des Splats): MUL o[psiz], v[opos].w, c[38].x; Konstantenspeicher c[0] bis c[3] c[4] bis c[7] c[32] c[33] c[34].x c[35].x c[35].y c[36] c[38].x c[39] Inhalt Matrix Tracking: Produkt aus Modelview- und Projektionsmatrix Matrix Tracking: Inverse Modelview Matrix Lichtrichtung im Eye Space Eye Space Half Angle Vektor Exponent für das Phong Beleuchtungsmodell Faktor für diffuse Beleuchtung (monochromatisch) Faktor für ambiente Beleuchtung (monochromatisch) Farbe des Phong Glanzlichtes Skalierungsfaktor Verhältnis Auflösung zu Öffnungswinkel Tabelle 6.1: Die Belegung des Vertex Program Konstantenspeichers für das Rendering mit variabler Splatgröße. 70

77 Wenn die Berechnung des Skalierungsfaktors für jeden Splat durchgeführt werden soll, ist im Vertex Program das oben berechnete Verhältnis zwischen Auflösung und Öffnungswinkel der Kamera notwendig. Es muss dabei darauf geachtet werden, dass es sich bei den Vertices um homogene Koordinaten handelt, deren vierte Komponente die Splatgröße enthält. Die Rückführung auf kartesische Koordinaten muss im Vertex Program explizit durchgeführt werden. Der folgende Teil ersetzt die Berechnung der Punktgröße pro Octree Cluster: # Berechnung des z-wertes MOV R2, v[opos]; DP4 R0.w, R2, -c[10]; # zweimaliges Multiplizieren des Reziproken mit der Größe RCP R1, R0.w; # 1. für homogene kartesische Koordinaten MUL R1, R1, R2.w; # 2. für Größenskalierung MUL R1, R1, R2.w; # und mit Verhältnis multiplizieren MUL o[psiz], c[39].x, R1; Angesichts der Tatsache, dass die Ausführungszeit eines Vertex Programs proportional zur Anzahl seiner Instruktionen ist, ist es datensatzabhängig, ob die Transformationspipeline der Grafikkarte der begrenzende Faktor ist. Bei Datensätzen mit vielen großen Splats kann die Rasterisierungsstufe einen Engpass darstellen. Durchgeführte Experimente haben aber gezeigt, dass beide Varianten des Vertex Programs bei den meisten Datensätzen etwa gleiche Geschwindigkeit erreichen. Stärker ins Gewicht, als die Berechnung der Splatgröße, fällt dabei die Beleuchtungsberechnung Eine mögliche Level-of-Detail Strategie Für das Rendering von niedrigeren Detailstufen eines Datensatzes verwendet das QSplat- Verfahren [26] eine hierarchische Bounding-Sphere-Repräsentation der Abtastpunkte auf der Oberfläche. Diese wird, ausgehend von der Wurzel, durchlaufen bis die Größe einer Bounding- Sphere einen, von den Betrachterparametern abhängigen, Schwellwert unterschreitet. An dieser Stelle wird die Traversion des Baumes abgebrochen und ein Punkt mit einer zur Bounding- Sphere-Radius proportionalen Größe gezeichnet. Diese Form der Datenbestimmung ermöglicht keine optimale Auslastung der Grafikhardware, da sehr viel Rechenzeit für die Bearbeitung der Datenstrukturen und Generierung der Splat-Daten verwendet wird. In diesem Abschnitt wird ein Level-of-Detail Verfahren vorgestellt, das ganz im Sinne der bisherigen Datenfragmentierung und -selektion arbeitet und eine nahezu vergleichbare Qualität bei niedrigeren Detailstufen erzeugt. Dabei wird davon ausgegangen, dass die Daten, wie in den letzten Abschnitten verwendet, erzeugt wurden. Die Fragmentierung des Datensatzes erfolgt zuerst nach den Octree Clusters und anschließend nach den Normal Clusters. 71

78 Neu hinzu kommt, dass die Abtastpunkte innerhalb eines Normal Clusters nach ihrer Größe absteigend sortiert werden. Es wird angenommen, dass Abtastpunkte mit kleinerer Größe Bereiche mit mehr Detail repräsentieren und diese, bei weniger gewünschtem Detail früher entbehrt werden können. Natürlich ist es nicht möglich, bei dieser Art des punktbasierten Renderings, einfach Abtastpunkte wegzulassen, da ansonsten Lücken in der Oberflächendarstellung entstehen. Stattdessen werden, wie im Folgenden beschrieben, eine festgelegte Anzahl von Detailstufen erzeugt, bei denen jeweils eine zunehmende Anzahl von (kleinen) Abtastpunkten weggelassen wird. Für die jeweils verbleibenden Abtastpunkte kann mit der nächsten Nachbar Suche, beispielsweise mit der bereits eingesetzten ANN Bibliothek, die neue benötigte Größe bestimmt werden, um mit der reduzierten Abtastpunktanzahl wieder eine geschlossene Oberfläche darzustellen. Somit resultieren für die Abtastpunkte jedes Normal Clusters für k Detailstufen eine Tabelle mit k Einträgen, in der festgehalten wird, wie viele Abtastpunkte für die jeweilige Stufe verwendet werden. Und die Abtastpunkte selbst besitzen zwischen einem und k Größenwerte, je nachdem in wie vielen Detailstufen sie verwendet werden (Abbildung 6.2). Detailstufen, zu denen ein Abtastpunkt nicht gehört, wird die Größe Null zugewiesen. Abbildung 6.2: Ein Normal Cluster mit 16 Abtastpunkten unterteilt für vier Level-of-Detail (LOD) Stufen und exemplarischen Größenwerten. Somit kann eine einfache Level-of-Detail Darstellung erreicht werden. Es ist aber nicht nur eine sprunghafte Änderung der Detailstufe möglich. Die Übergänge können auch stufenlos erfolgen, indem mittels eines Vertex Programs zwischen den Größenwerten zweier Detailstufen interpoliert wird und erst nach Erreichen des Größenwertes der nächsten Detailstufe werden die nicht mehr benötigten Abtastpunkte auch nicht mehr dargestellt. Damit wird eine so genannte Continuous-Level-of-Detail Darstellung des Punktdatensatzes erreicht, die mit der Strategie der Datenaufbereitung konform geht und eine Ausnutzung der Grafikhardware ermöglicht. 6.4 Rendering mit gleichmäßiger Abtastdichte In diesem Abschnitt wird das Rendering mit gleichmäßiger Abtastdichte vorgestellt. Diese Methode ist dem Point Rendering sehr nahe, kann aber aufgrund der fixen Abtastdichte der Oberflächen und der variablen Punktgröße bzw. -form beim Rendering auch den einfachen Splatting Verfahren zugeordnet werden. 72

79 6.4.1 Anforderungen und Datenaufbereitung Bei dieser Renderingmethode wird von einer gleichmäßigen Verteilung von Abtastpunkten auf der darzustellenden Oberfläche ausgegangen. Für die Abtastpunkte liegt deshalb keine Größeninformation vor, sondern lediglich die Daten, die für die Beleuchtungsberechnung benötigt werden - also die Oberflächennormale. Solche Datensätze werden wie in Kapitel 5.2 beschrieben erzeugt. Für jeden Abtastpunkt ist gespeichert: die kartesische Koordinate und die Normale. Im Allgemeinen bestehen diese Datensätze aus deutlich mehr Abtastpunkten, als die mit unregelmäßiger Abtastung. Da während dem Rendering keine Größenberechnungen für Splats vorgenommen werden müssen, ist hier kein Einsatz von Vertex Programs notwendig. Vielmehr ist hier die Fragmentierung der Punktdaten und die Abschätzung und Selektion der benötigten Abtastpunkte wichtig. Sie sind, wie in Abschnitt und beschrieben, fragmentiert. Dadurch sind jeweils alle Abtastpunkte eines Normal Clusters jedes Octree Clusters zusammengruppiert. Innerhalb dieser Gruppierung sind die Abtastpunkte in einer zufälligen Reihenfolge angeordnet. Dadurch ist es möglich, eine niedrigere Abtastdichte zu simulieren, indem nur ein Teil der Punkte für das Rendering verwendet wird. Abbildung 6.3 verdeutlich, warum unterschiedliche Abtastdichten benötigt werden: Bei konstanter Abtastdichte im Object Space resultiert, bedingt durch die Orientierung und Krümmung der Oberflächen, eine dichtere Punktmenge an den Objektsilhouetten. Genauso resultiert eine projektive Abbildung in kleineren Punktabständen, wenn die Entfernung zum Betrachter zunimmt. Abbildung 6.3: Dieses einfache Beispiel zweier, im Object Space, regelmäßig abgetasteter Oberflächen, verdeutlicht daraus resultierende unterschiedliche Punktdichte beim Rendering. 73

80 6.4.2 Optimiertes Rendering mit OpenGL Vor allem zwei verschiedene Varianten bieten sich für das punktbasierte Rendering dieser Art an: vom Abstand zum Betrachter abhängige Punktgröße konstante Punktgröße beim Rendering und variable Abtastdichte Für die erste Möglichkeit bietet sich die OpenGL Erweiterung EXT POINT PARAMETERS an. Damit kann die Größe der Punkte abhängig von der Entfernung zum Betrachter automatisch bestimmt werden, indem die Koeffizienten einer linearen oder quadratischen Abstandsfunktion angegeben werden. Obwohl diese Variante prinzipiell einsetzbar wäre, offenbaren sich Nachteile. Bei vielen Datensätzen würden beim Rendering nur wenige verschiedene Punktgrößen berechnet. Die Punktgröße ändert sich dabei an einem bestimmten Abstand zum Betrachter. Daraus resultieren zwei Nachteile: Zum Einen ist diese Grenze meistens vom Betrachter (negativ) zu erkennen und zum Anderen erschwert dieser Ansatz die Implementation einer Level-of-Detail Strategie. Deshalb wurde die zweite Variante verwendet. Dabei wird vor dem Rendering eines Bildes die Punktgröße festgelegt. Es gibt natürlich eine Untergrenze: Wenn die Abtastdichte im Datensatz zu gering oder die Auflösung des zu rendernden Bildes zu hoch ist, kann nur mit einer genügend großen Punktgröße eine geschlossene Fläche dargestellt werden. Anhand der festgelegten Punktgröße, den Betrachterparametern und der bekannten Abtastdichte kann bestimmt werden, welcher Prozentsatz der Abtastpunkte eines Oberflächenteils benötigt wird. Weiterhin kann noch der Winkel zwischen der Oberfläche und Blickrichtung herangezogen werden. Flächen, die senkrecht zum Betrachter stehen, benötigen eine höhere Abtastdichte, als flach betrachtete. Somit kann die Zahl der, für das Rendering, benötigten Abtastpunkte weiter reduziert werden. Die im Folgenden vorgestellte Berechnung basiert auf Überlegungen, die sich leicht empirisch nachvollziehen ließen und in der vorliegenden Implementation eingesetzt werden. Wiederum ist die Auflösung des OpenGL Fensters x w y w und die Pixels per Radian p (oder Angular Pixel Density) in Pixel pro Winkel, wichtig. Diese Größe hängt vom Öffnungswinkel der virtuellen Kamera bzw. der projektiven Abbildung ab: p = x w 2 2z near r l = x w r l z near (6.7) Die benötigte Abtastdichte S muss natürlich proportional zu der Auflösung des Bildes zunehmen: S p (6.8) Beim Rendering besitzt ein Punkt der Punktgröße g (g ist beim Rendering mit OpenGL wählbar) unabhängig von der Entfernung zum Betrachter genau g 2 Pixel bzw. bei rund dargestellten Punkten einen Durchmesser von g Pixel auf dem Bildschirm. Die Länge einer Linie, 74

81 bei einer perspektivischen Projektion des Raumes auf die Betrachterebene, ist indirekt proportional zum Abstand d zum Betrachter. Deshalb lässt sich auf feststellen, dass gelten muss: S 1 zg. (6.9) Die Quantisierung der Koordinaten erfolgt, wie bereits erwähnt, auf 2 n Stufen. Daraus ergibt sich eine Samplingdichte, die - bei einer Quantisierungsintervalllänge von eins - gleich 2 n ist. Der maximale Quantisierungsfehler lässt sich mit 3/42 n angeben. Der Quantisierungsfehler ist dabei ein Maß für den Abstand der Punkte auf der Oberfläche, deren Zwischenraum beim Rendering ausgefüllt werden muss. Deshalb ist S auch proportional zu 2 n : S 2 n p zg. (6.10) Wie bereits erwähnt, ist auch die Orientierung der Oberflächen ausschlaggebend für die benötigte Abtastdichte. Eine orientierungs- und betrachterabhängige Abschätzung kann durch die Fragmentierung des Datensatzes für einzelne Oberflächenteile durchgeführt werden. Hierzu wird das Skalarprodukt aus der Blickrichtung v und der gemittelten Normale eines Normalenclusters n berechnet und die obige Abschätzung erweitert. Zusammengefasst ergibt sich mit einer geeigneten Konstante C: S = C2 n p ( zg max 0, v n v n ). (6.11) Durch die Maximumbildung und das Vorzeichen des Skalarproduktes resultiert für rückseitige Flächen die Abtastdichte 0. Diese Abschätzung für S ließ sich in der Praxis gut verwenden und die Konstante konnte leicht durch kurze Versuchsreihen bestimmt werden. Sie ermöglicht durch die wählbare Punktgröße eine interaktive Wahl zwischen Rendergeschwindigkeit und Darstellungsqualität. Allerdings gilt es eine Sache zu berücksichtigen: bei der Abschätzung erhält man ein Maß für die benötigte Abtastdichte. Der Datensatz selbst enthält aber nur eine bestimmte Abtastdichte, deshalb wird die Abschätzung dazu verwendet, um festzustellen, wieviele der vorhandenen Abtastpunkte für das Rendering verwendet werden. Durch die zufällige Anordnung der Abtastpunkte im Datensatz innerhalb der Normal Clusters, lässt sich damit eine andere Abtastdichte simulieren, aber nicht wirklich erreichen. Deshalb kann es bei diesem Verfahren zu seltenen, kleinen Lücken in dargestellten Oberflächen kommen. Auch andere Verfahren leiden darunter, wie z.b. [30]. Durch eine geeignete Abschätzung, wie oben beschrieben und im Folgenden noch verbessert, lassen sich diese Fehler aber weiter reduzieren. Weiterhin wird in Abschnitt eine bildbasierte Methode vorgestellt, um diese Fehler im Post Processing zu reduzieren. Da, wie oben beschrieben, nur eine niedrigere Abtastdichte simuliert werden kann, empfiehlt es sich, die Abschätzung großzügig vorzunehmen. Das bedeutet, eher etwas mehr Punkte für das Rendering zu verwenden, als durch die Abschätzung berechnet. Vor allem bei kleineren Prozentsätzen sollte dies getan werden. Als erstes erfolgt eine Modifikation der Abschätzung für die Orientierung der Oberflächen. Anstatt des Skalarproduktes selbst, wird der folgende Ausdruck verwendet, wobei C 1 und C 2 zwei Konstanten sind, deren Werte in der Praxis beispielsweise 0.2 und 0.8 sind: 75

82 v n C 1 + C 2 v n. (6.12) Weiterhin wird die folgende einfache Funktion verwendet, um kleine Schätzwerte S stärker, größere schwächer anzuheben: S (S) = S + C 3 C 4 + S (6.13) Für C 3 und C 4 haben sich in der Praxis die Werte 0.1 und 2.0 als geeignet erwiesen. Durch die Abschätzungen, die auch abhängig von der OpenGL Punktgröße sind, lassen sich Bilder unterschiedlicher Qualität darstellen. Es kann also gewählt werden, welche Menge des Datensatzes (als Folge der gewählten Punktgröße) zum Rendering verwendet wird und es lässt sich somit die Menge des Details festlegen. Die Datensätze für dieses Verfahren sind, wie im letzten Kapitel vorgestellt, entweder durch Uniform Clustering oder ein selbst entwickeltes Verfahren entstanden. Das Uniform Clustering bringt den Vorteil einer gesicherten Abtastdichte und einer oberen Grenze der Quantisierungsfehler mit sich. Allerdings wird dieser Vorteil durch die Abschätzung und der nur teilweisen Verwendung der Punkte beim Rendering abgeschwächt. Es hat sich gezeigt, dass die andere Methode zur Datengenerierung oft vergleichbare visuelle Resultate - bei einer geringeren Anzahl von benötigten Splats für das Rendering - hervorbringt bringt und somit durchaus eine Existenzberechtigung besitzt. Der Ablauf des Renderings erfolgt so, dass mit dem Backface Culling und der Berechnung der Faktoren für die verschiedenen Normal Clusters begonnen wird. Diese wird anschließend benötigt, wenn durch das Frustum Culling mit der Octree Datenstruktur, die sichtbaren Octree Cluster bestimmt wurden. Dann wird die Abschätzung der Abtastdichte durchgeführt und die Information für die sichtbaren Oberflächenteile, bzw. die entsprechenden Fragmente des Datensatzes, für das anschließende Rendering gespeichert. 6.5 Rendering der Datensätze aus kalibrierten Kamerabildern Das Rendering der Datensätze aus kalibrierten Kamerabildern basiert auf dem in Abschnitt 6.3 vorgestellten Verfahren zum Rendering mit variabler Punktgröße Datenaufbereitung Der wesentliche Unterschied zu der Verfahrensweise in Abschnitt 6.3 liegt darin, dass die Abtastpunkte in diesem Fall keine Normalen besitzen (obwohl diese aus Punktwolken natürlich geschätzt werden könnten) und somit kein Backface Culling durchgeführt werden kann. Andererseits liegen aber Farbinformationen vor. Diese sind dabei wie in Kapitel 5.3 beschrieben in Form von Texturen gespeichert. 76

83 Die pro Splat für das Rendering vorliegenden Daten umfassen: die homogene Koordinate inklusive Größe, eine Referenz auf die benötigte Textur mit der Farbinformation und die Texturkoordinaten, die auf den Texel bzw. Texelblock zeigen. Anhand der Texturreferenz kann festgestellt werden, ob ein Abtastpunkt einen oder mehrere Farbwerte besitzt. Die Liste der Punkte wird wie in Abschnitt beschrieben, nach der Zugehörigkeit zu den Octree Clusters fragmentiert. Innerhalb dieser Octree Cluster werden die Splats nach der Texturreferenz angeordnet statt, wie bisher, nach Normal Clusters Vertex Program für blickrichtungsabhängige Färbung Da der Ablauf des Renderings analog zu dem in Abschnitt 6.3 beschriebenen abläuft, wird hier nur noch auf die Radiance Interpolation eingegangen. Die Farbinformation ist in den Texturen in Texelblöcken einer bestimmten Größe enthalten. Die Texturen, die die Farbinformation für Splats mit nur einem Farbwert enthalten, werden im Folgenden wie Texturen mit 1 1 Texel großen Blöcken behandelt. Innerhalb eines Texelblockes ist die Farbinformation für jede Richtung, gegeben durch eine zweidimensionale Parametrisierung (Polarkoordinaten ohne Längeninformation), gespeichert. Die Genauigkeit hängt natürlich von der Größe der Blocks ab, die im Folgenden mit m m, mit m = 2 n bezeichnet wird. Die Texturkoordinaten der Splats zeigen auf den Mittelpunkt des Texels im linken oberen Eck eines Blocks. Die unterschiedlichen Blickrichtungen sollen eine Verschiebung der Texturkoordinaten innerhalb dieses Blockes verursachen, damit der zur Richtung gehörige Farbwert ausgelesen wird. Die Verschiebung wird vor dem Rendering berechnet und im Konstantenspeicher der Vertex Programs abgelegt. Ihre Bestimmung kann für den ganzen Datensatz, pro Octree Cluster oder pro Splat erfolgen, je nach gewünschter Präzision. Dazu wird zunächst die Blickrichtung benötigt. Im ersten Fall entspricht diese dem zweiten Spaltenvektor der OpenGL Modelview Matrix, in den anderen beiden Fällen muss diese durch Subtraktion zweier Ortsvektoren, der Splatposition bzw. dem Octree Cluster Mittelpunkt und der Betrachterposition, bestimmt werden. Der Richtungsvektor wird mit w bezeichnet und normalisiert vorausgesetzt. Daraus können die Polarkoordinaten berechnet werden (die Längenkomponente r ist für den späteren Zweck uninteressant, siehe auch Abbildung 6.4): w = (x, y, z) T r = x 2 + y 2 + z 2 ( = 1 θ = tan 1 z ) x ( ) x φ = sin z 2 ( = cos 1 y ) r r (6.14) mit θ [0, 2π) und φ [0, π]. 77

84 Abbildung 6.4: Die Darstellung eines Vektors in sphärischen bzw. Polar Koordinaten (aus [35]). Bei einer Blockgröße von 2 n 2 n Texels werden die durch θ und φ verursachten Verschiebungen, bezeichnet mit u und v, wie folgt berechnet (die obigen Wertebereiche vorrausgesetzt): ( ) θ u = 2π (2n 1) ( ) (6.15) φ v = π (2n 1) Die Abbildung der Verschiebungen erfolgt also von [0, 2π) auf [0; 2 n 1] bzw. von [0, π] auf [0; 2 n 1]. Wie bereits in Kapitel beschrieben ist die erste und letzte Texelspalte bzw. -zeile eines Blocks identisch. Der Grund dafür ist, dass die Grafikhardware verwendet werden soll, um die Farbwerte auszulesen und zwischen ihnen linear zu interpolieren. Wenn allerdings u bzw. v einen Wert größer als 2 n 1, also z.b. 2 n 0.5 annehmen, findet eine bilineare Interpolation zwischen den Texel zweier unterschiedlicher Texelblöcke statt. Das Beispiel in Abbildung 6.5 zeigt auf der linken Seite einen 8 8 Texel großen Radiance Block, dessen umgebende Texel zur Verdeutlichung grün dargestellt werden. Auf der rechten Seite ist eine vergrößerte Darstellung des Ausschnitts durch bilineare Interpolation dargestellt. Für eine fehlerfreie Verwendung der Texel kann nur der Bereich des Blockes eingesetzt werden, auf den Texel von Nachbarblöcken keinen Einfluss haben (in diesem Beispiel also keinen Einfluss der grünen Farbe unterliegen). Dazu muss in OpenGL nach dem Anlegen der Texturen der Filter für Texturstreckung und -stauchung auf bilineare Interpolation eingestellt werden. Dieser Aufwand ließe sich natürlich einsparen, wenn für jeden Splat eine eigene Textur angelegt werden würde. Allerdings ist dabei die Geschwindigkeitseinbuße enorm hoch - das Wechseln der Texturen gilt es bei hardwarebeschleunigter Grafik immer zu vermeiden. Die Verschiebungen stehen, pro Datensatz oder pro Octree Cluster berechnet, wie bereits erwähnt, dem Vertex Program im Konstantenspeicher zur Verfügung. Prinzipiell könnten die Verschiebungen auch für jeden Splat individuell im Vertex Program selbst berechnet 78

85 Abbildung 6.5: Durch die bilineare Interpolation sind nicht alle Texel des 8 8 Blockes (links, umgeben von anderen Texels, grün dargestellt) verwendbar. werden, allerdings umfasst deren Befehlssatz keine Arcustangens oder Arcuskosinus Funktion. Fehlende Funktionen könnten wie in [37] beschrieben etwa durch Taylor Reihen oder Look Up Tabellen und linearer Interpolation approximiert werden, jedoch ist der Rechenaufwand pro Splat zu groß für komplexere Datensätze und es ist keine merkliche Verbesserung bei der Darstellungsqualität zu erwarten. Deshalb kommen in dieser Arbeit nur die ersten beiden Ansätze zum Einsatz. Somit reduziert sich das benötigte Vertex Program auf wenige Befehle und ist dadurch sehr effizient. Die Belegung der Register und Speicherplätze ist in Tabelle 6.2 aufgelistet, das Vertex Program lautet wie folgt (es wurde die Option NV position invariant zur Fixed-Function Pipeline identischen Transformation gewählt):!!vp1.1 # Transformation der homogenen Koordinaten OPTION NV position invariant; # Farbwert durchreichen MOV o[col0], c[36]; # Verschiebung der Texturkoordinaten ADD o[tex0], v[tex0], c[ 40 ]; # Berechnung der Splatgröße: MUL o[psiz], v[opos].w, c[38].x; 79

86 Konstantenspeicher Inhalt o[opos] Homogene Koordinaten eines Splats v[tex0] Texturkoordinate des Texelblockes (pro Splat definiert) c[36] Konstanter Farbwert: Weiss (1, 1, 1, 1) c[38].x Skalierungsfaktor für Splatgröse pro Octree Cluster c[40].x Verschiebungswert u c[40].y Verschiebungswert v Tabelle 6.2: Die Belegung des Vertex Program Konstantenspeichers für das Rendering mit variabler Splatgröße und Farbinterpolation. Für jeden sichtbaren Octree Cluster, bestimmt durch das Frustum Culling, werden zuerst alle Splats der ersten Blocktextur, dann der zweiten usw. gezeichnet. Während der Initialisierung wird sichergestellt, dass die Splats entsprechend der Zugehörigkeit zu den Texturen angeordnet sind, damit jede Textur nur maximal einmal pro Octree Cluster selektiert werden muss. Die in diesem Abschnitt vorgestellte Variante ist äußert hardwarefreundlich. Sie benötigt nicht sehr viel Grafikkartenspeicher, da die Hardware Texturkompression eingesetzt werden kann und sie arbeitet sehr performant, da nicht mehr Vertex Program Befehle benötigt werden, als ohne die Farbinterpolation. Außerdem wird nur eine Texturierungs Einheit der Grafikkarte verwendet, d.h. es können weitere Rendering Optionen eingesetzt werden. 6.6 Splatting Techniken Aufgrund einer beschränkten Abtastdichte, bzw. einer sehr hohen Auflösung des Bildes kann es notwendig sein, dass beim Rendering Punkte größer als ein Pixel benötigt werden. Mit zunehmender Größe leidet allerdings auch die Darstellungsqualität. Vor allem an den Rändern und Kanten der Objekte treten dabei Artefakte auf Runde Punkte Es gibt verschiedene Ansätze, um diesem Problem entgegenzuwirken. Der einfachste Ansatz, mit dem bereits eine merkliche Verbesserung erzielt werden kann, ist statt quadratischen Punkten der Größe n, also mit n 2 Pixels, runde Punkte mit einem Durchmesser von n Pixel zu zeichnen. Diese Variante kann mit sehr geringem Aufwand angewendet werden. Die Grafikhardware bietet die Möglichkeit, Punkte mit Antialiasing zu zeichnen. Dabei wird für jeden Pixel eines Punktes ein Alpha-Wert (Opazitätswert) berechnet. Dieser Alpha-Wert nimmt von der Mitte zum Rand radialsymmetrisch ab. Weiterhin besteht die Möglichkeit einen so genannten Alpha-Test während dem Rendering durchzuführen. Dieser kann so konfiguriert werden, dass nur Pixel mit einem Alpha-Wert gesetzt werden, der größer als ein festgelegter 80

87 Referenzwert ist. Somit lassen sich mit diesem Trick runde Punkte darstellen. Es ist auch keine andere Abschätzung für die Punktdichte oder -größe beim Rendering notwendig. Daher kann diese einfache Möglichkeit problemlos eingesetzt werden, wie es beispielsweise auch bei QSplats [26] geschieht Verwendung von Vierecken zur Darstellung elliptischer Splats Eine weitere sehr flexiblere Möglichkeit wäre, die Ausrichtung der, im Object Space runden, Splats - gegeben durch deren Normale - und dem Winkel zum Betrachter zu berücksichtigen. Somit ergeben sich elliptische Splats, die gezeichnet werden müssen. Solche elliptischen Splats sind am einfachsten mit texturierten Vierecken zu zeichnen. Diese Variante kommt in [25] zum Einsatz. Dabei wird die Ausrichtung der Vierecke in Vertex Shadern (das Direct3D Pendant der OpenGL Vertex Programs) während der Vertextransformation berechnet und die Alphawerte, z.b. für einen Alphatest oder Blending Operationen, während dem Rendering aus einer Textur ausgelesen. In den Texturen sind die benötigten Farb- und Alphawerte und somit die Formen der Splats für alle möglichen Blickwinkel gespeichert. Dieses Verfahren hat allerdings einen Nachteil: ein Vertex Shader bzw. ein Vertex Programm kann nur Berechnungen für bestehende Vertices durchführen, aber keine neuen erzeugen. Deshalb müssen viermal so viele Vertices wie Splats redundant gespeichert und transformiert bzw. vorbereitet werden und belasten somit die Grafikpipeline Approximation elliptischer Splats Mit dem Einsatz der OpenGL Erweiterung NV point sprite ist es möglich, einen quadratischen OpenGL Punkt, gegeben durch seine Position und Größe, zu texturieren. Dabei werden die beiden ersten Texturkoordinaten s und t für jeden Pixel generiert, so dass beide von 0 bis 1 laufen. Durch eine Textur mit radialsymmetrisch abfallenden Alphawerten lässt sich der Effekt wie in Abschnitt erzielen. Abbildung 6.6: Durch Rotation und Skalierung der Texturkoordinaten könnten elliptische Splats mithilfe von Point Sprites dargestellt werden (aus [5]). 81

88 Für die folgenden Berechnungen wird für den Wertebereich von s und t [ 1; 1] statt [0; 1] verwendet. Solche Operationen (und die Umkehrung) kann die Grafikhardware in den so genannten Pixel Shader bzw. Register Combiner ausführen. Diese Funktionalität stellt eine konfigurierbare Rasterisierungsstufe in der OpenGL Grafikpipeline dar. Mithilfe eines Vertex Programs kann für jeden Punkt der Arcuskosinus des Winkels β zwischen der Punktnormale und der Blickrichtung berechnet werden. Weiterhin kann die planare Projektion der Normale auf die Betrachterebene berechnet werden, deren beide Komponenten mit n x und n y bezeichnet werden. Durch die beiden Komponenten ist außerdem eine Rotationsmatrix R definiert. Wenn die ursprünglichen Texturkoordinaten s und t wie folgt transformiert werden, und der Alpha Test verwendet wird, resultieren daraus elliptische Punkte (Abbildung 6.6): (s, t ) T = cos(β)r(s, t) T (6.16) Allerdings ist es bei der heutigen Grafikhardware nicht möglich, die Texturkoordinaten für einzelne Pixel auf diese Art zu modifizieren. Deshalb wird in [5] eine Approximation eingeführt. Diese verwendet zum Einen eine Textur mit einem Gaußschen Verlauf der Alpha Werte, die mit folgender Funktion beschrieben werden kann: α gauss (s, t) = e a s 2 +t 2 (6.17) In einem Vertex Program wird außer der projizierten Normale, also n x und n y, noch der folgende winkelabhängige Faktor berechnet: b(β) = (1 1e ) ( 2 cos(β) 1 ) 2ln2 (6.18) cos(β) In einem Pixel Shader, bzw. mit den NVidia Register Combiners, kann für jeden Pixel mittels Skalarproduktes der gewichtete Abstand zur Gerade, deren Richtung durch (n y, n x ) gegeben ist, berechnet, mit b skaliert und von eins abgezogen werden: α linear (s, t) = 1 b(s, t) T (n x, n y ) (6.19) Der Faktor b verursacht dabei einen schnelleren Abfall der α linear Werte bei größeren Winkeln. Weiterhin kann mit den Register Combiners das Produkt von α gauss und α linear berechnet werden. Durch den Alpha Test werden nur Pixel gezeichnet, deren Alpha Wert eine festgelegte Referenzschwelle übertrifft. Die so erhaltenen Punktformen sind ellipsenartig und für eine Darstellung ausreichend gut approximiert. Abbildung 6.7 zeigt das ellipsenartige Ergebnis, erstellt mithilfe einer Testimplementation. Diese Methode kann auch nachträglich in ein bestehendes System eingebunden werden und läuft vollständig hardwarebeschleunigt. Der Vorteil gegenüber dem Verfahren aus Abschnitt ist, dass keine redundanten Vertexdaten notwendig sind. 82

89 Abbildung 6.7: Die beschriebene Approximation elliptischer Splats mit den Möglichkeiten der aktuellen Grafikhardware Qualitativ hochwertiges Splatting Ein in letzter Zeit mehrfach behandelter Aspekt bei punktbasiertem Rendering ist der Einsatz erweiterter Splatting Techniken. Es ist anzunehmen, dass für heutige Grafikhardware ein Ansatz mit zwei Renderpasses, wie beispielsweise in [25], am sinnvollsten ist, der in diesem Abschnitt erläutert wird. Solche Verfahren können von den, in diesem Kapitel vorgestellten, Datenstrukturen und Verfahren profitieren, da diese ein hochperformantes Rendering und eine Ausnutzung der Renderingleistung der Grafikhardware gewährleisten. Andere Verfahren, die z.b. eine Sortierung der Abtastpunkte voraussetzen, sind für Hybridansätze und reale Anwendungen weniger flexibel und geeignet. Die Verwendung eines A-Buffers ermöglicht zwar qualitativ hochwertiges, aber nicht sehr schnelles Rendering. Abbildung 6.8: Im ersten Renderdurchgang wird eine lückenfreie Darstellung im Z-Buffer erzeugt (aus [25]). Die für das Splatting beim Rendering mit zwei Passes zusätzlich benötigten Daten können analog zu den bisher verwendeten Attributen der Abtastpunkte gespeichert werden. Der Ab- 83

90 lauf des Renderings würde, wie bereits erwähnt, in zwei Schritten stattfinden. Im ersten Renderingdurchgang erfolgt das Visibility Splatting, wobei - nur für die Tiefeninformation des Bildes - eine geschlossene Darstellung der Oberflächen erzeugt wird. Diese Darstellung kann mit den oben genannten Möglichkeiten, z.b. mit opaken Vierecken, erfolgen. Im zweiten Schritt werden die Farbwerte der Splats akkumuliert. Da bereits eine Verdeckungs- bzw. Sichtbarkeitsdetektion durch das Z-Buffer Rendering im ersten Schritt durchgeführt wurde, kann die Akkumulation der Farbwerte mithilfe von Z-Buffer Tests und Blending Operationen der Grafikhardware fehlerfrei erfolgen. Abbildung 6.8 und 6.8 zeigen die beiden Renderpasses bei dem Object space EWA surface splatting Verfahren [25]. Abbildung 6.9: Durch Z-Buffer Tests und Blending Operationen werden im zweiten Renderdurchgang die Farbwerte der Splats akkumuliert (aus [25]). Es bleibt abzuwarten, ob die nächsten Generationen der Grafikhardware verbesserte Unterstützung für Splatting Techniken bieten. Ein erster wichtiger Schritt wäre ein sogenannter ɛ-z-buffer Test, bei dem ein Schwellwert angegeben werden kann, um Blending Operationen auf etwa gleichweit (im Sinne eines festgelegten Intervalls) vom Betrachter entfernte Oberflächen zu ermöglichen. 6.7 Weitere Verbesserungen und Optimierungen In diesem Abschnitt werden mögliche Erweiterungen beschrieben, die implementiert wurden, um zu überprüfen, inwieweit verschiedene Fähigkeiten moderner Grafikkarten für das punktbasierte Rendering und dabei auftretende Probleme sinnvoll einsetzbar sind. 84

91 6.7.1 Occlusion Culling Das Occlusion Culling soll dazu dienen, verdeckte und dadurch nicht sichtbare Teile eines Objektes oder einer Szene zu identifizieren, damit sie vom Rendering ausgeschlossen werden können. Dazu gibt es zwei OpenGL Erweiterungen, die HP occlusion test und die NV occlusion query Erweiterung. Letztere bietet die Möglichkeit, die Anzahl der Pixel eines gezeichneten Primitivs, d.h. Dreieck, Linie oder Punkt, die die Z-Buffer und Stencil Buffer Tests bestehen, von der Grafikkarte feststellen zu lassen. Die ältere HP occlusion test Erweiterung kann nur Auskunft geben, ob es solche Pixel gibt oder nicht. Das prinzipielle Vorgehen beim Einsatz der NV occlusion query Erweiterung ist wie folgt: Während der Initialisierung werden Identifier angefordert, um verschiedene unabhängige Verdeckungstests durchführen zu können. Im ersten Schritt des Verdeckungstests, innerhalb der glbeginocclusionquerynv und glendocclusionquerynv Befehle, werden die Oberflächen, oder eine vereinfachte Repräsentation davon, deren Sichtbarkeit es festzustellen gilt, gezeichnet. Dabei kann die Modifikation der Farb- bzw. Z-Buffer Werte deaktiviert werden, um das dargestellte Bild nicht zu beeinflussen oder um Bandbreite einzusparen. In einem zweiten Schritt kann die Anzahl der sichtbaren Bildpunkte jeder getesteten Oberfläche anhand der Identifier abgefragt werden. Da zwischen dem eigentlichen Verdeckungstest und dem Bereitstehen der Ergebnisse, laut der Spezifikation der Erweiterung, eine verhältnismäßig lange Zeitspanne liegt, wurde in der entwickelten Implementation eine Occlusion Culling Funktionalität eingebaut, die zeitliche Koheränzen ausnutzen soll. Dabei wird für jeden Octree Cluster ein Occlusion Culling Identifier angefordert und die minimale achsenparallele Bounding Box der Abtastpunkte des Octree Clusters berechnet. Nachdem der Punktdatensatz gezeichnet wurde, wird der erste Schritt des Occlusion Culling Tests für die Bounding Boxes - mit denselben Kameraparametern - durchgeführt. Dies ist ein konservativer Test (wegen Verwendung von Bounding Boxes), d.h. die Anzahl der sichtbaren Pixel der Bounding Box ist mindestens so groß wie Anzahl der durch Punkte dargestellten. Das Auslesen der Resultate, also der zweite Schritt, erfolgt erst unmittelbar vor dem Rendering des nächsten Bildes. Dabei werden dann nur Octree Cluster gezeichnet, deren Bounding Box im letzten Bild sichtbar war. Mit dieser Ausnutzung der zeitlichen Koheränz entstehen bei entsprechend geringer Betrachterparameteränderung nur Darstellungsfehler durch weggelassene Teile des Datensatzes, die sich im Bereich von wenigen Bildpunkten bewegen. Da aber der erste Teil konservativ durchgeführt wird, treten diese kaum sichtbar auf. Der Leistungszuwachs durch das Occlusion Culling ist allerdings nicht so groß wie erwartet. Die Gründe dafür sind zum einen bei den Datensätzen zu suchen. Vor allem sehr komplexe Datensätze mit konkaven Oberflächenteilen sind für solche Verfahren predestiniert. Ein weiterer Grund ist, dass das Occlusion Culling auf der Basis der Octree Cluster durchgeführt wird. Genaueres Occlusion Culling kann daher nur durch kleine und somit viele Octree Cluster erreicht werden. Dadurch entsteht aber wiederum Zusatzaufwand beim Frustum Culling und eine stärkere Fragmentierung des Datensatzes. Die Unterstützung der Verdeckungstests durch die Grafikhardware selbst ist erst ab den GeForce 4 Grafikkarten performant gegeben. Die durchgeführten Versuche haben gezeigt, dass trotz Ausnutzung der Koheränz und der 85

92 damit automatisch entstehenden Wartezeit auf die Ergebnisse, die Aktivierung der Occlusion Culling Abfrage bei GeForce 3 Grafikkarten die meiste Zeit benötigt. Eine weitere Möglichkeit ist deshalb, vorberechnete Verdeckungsinformation zu speichern. Das bedeutet, durch einen Vorberechnungsschritt können die sichtbaren Teile eines Objektes, abhängig von der Betrachtungsrichtung identifiziert und diese Information gespeichert werden Push Pull Operationen Die Push Pull Operation ist ein Verfahren zur Bildrekonstruktion bei unvollständiger Information, z.b. fehlende Pixel. Es wurde in [7] vorgestellt und für punktbasiertes Rendering in [8] verwendet. Bei der Push Pull Variante aus [8] wird jedem Pixel ein Gewicht aus [0; 1] zugewiesen, das ein Maß für die Verlässlichkeit der Farbinformation des Pixels angibt. Im Folgenden sind nur Werte von eins, also dass der Farbwert des Pixels sicher korrekt ist, und Werte ungleich eins von Bedeutung. In der Pull Phase werden sukzessive Approximationen des Bildes mit niedrigerer Auflösung berechnet. Dies geschieht, indem jeweils ein Block von 2 2 Pixels zu einem Pixel zusammengefasst werden. Das Gewicht des resultierenden Pixels ist die Summe der Gewichte des 2 2 Blocks, aber maximal eins. Abbildung 6.10: Der benötigte Farbwert (rot) wird aus der gewichteten Summe der nähesten Nachbarwerte aus der niedrigeren Auflösung berechnet (aus [8], modifiziert). In der Push Phase werden die Bilder mit niedrigeren Auflösungen verwendet, um Lücken, d.h. Pixel mit einem Gewicht kleiner eins, im Bild der jeweils nächst höheren Auflösungsstufe zu füllen: Der Farbwert eines Pixels mit der Farbe c und dem Gewicht w < 1 wird rekonstruiert, indem zunächst eine Interpolation der drei nähesten Farbwerte im Bild der niedrigen Auflösung, mit der Gewichtung 0.25, 0.5 und 0.25 erfolgt (Abbildung 6.10). Daraus ergibt sich der Farbwert c i. Durch lineare Interpolation zwischen c und c i wird der endgültige Wert erhalten: wc (1 w)c i. Diese Operationen lassen sich nicht durch die Grafikhardware durchführen und müssten nach dem Rendering mit einer Softwareimplementation durchgeführt werden. Die Zeiteinbußen durch den Transfer der Bilddaten von der Grafikkarte in den Hauptspeicher und der Push Pull Operation lassen hochperformantes Rendering allerdings nicht mehr zu. 86

93 In der vorliegenden Implementation wurde deshalb eine weitere Variation, die zumindest einen Push Pull Schritt in Hardware zulässt, versuchsweise integriert. Dabei wird zunächst ein erzeugtes Bild, das noch Lücken aufweisen kann, in eine Textur kopiert. Die Auflösung der Textur ist prinzipiell frei wählbar, aber im Folgenden wird davon ausgegangen, dass ihre Auflösung und die des endgültigen Bildes identisch sind. Eine Art Gewichtswert, wie oben beschrieben, ist dadurch gegeben, dass Pixel, die einen Farbwert besitzen, auch einen von Null verschiedenen Alphawert besitzen, der beim Rendering der Punkte erzeugt wird. Zur Rekonstruktion der fehlenden Farbwerte gilt es zunächst die Lücken in der Oberflächendarstellung zu identifizieren. Dazu wird die Textur, die das Bild enthält, mehrmals, in diesem Beispiel fünf mal, in der Größe des sichtbaren Bereichs auf diesen gezeichnet, ohne die Farbwerte der Pixel zu verändern - lediglich die Sichtbarkeitsinformation ist von Interesse. Bei jedem Mal, wird die Textur um einen Pixel verschoben. In der Implementation wurden Verschiebungen um (0, 0) T, (1, 0) T, (0, 1) T, ( 1, 0) T und (0, 1) T Pixel gewählt. OpenGL wird dabei so konfiguriert, dass nur Texel mit einem Alphawert ungleich Null dargestellt werden. Mithilfe des Stencil Buffers wird gezählt, wie oft ein Pixel beschrieben wird. Bei einer genügend großen Anzahl von z.b. drei von fünf Mal wird davon ausgegangen, dass es sich bei diesem Pixel um eine Lücke in der Oberflächendarstellung handelt. Somit können bereits eine Reihe von Fehlerkonstellationen identifiziert werden. Allerdings kann es auch vorkommen, dass Pixel fälschlicherweise als Lücke interpretiert werden, was vor allem an den Silhouetten von Objekten auftritt. Mit dieser Information, gespeichert im Stencil Buffer, können Farbwerte für die fehlenden Pixel rekonstruiert werden. Hierzu wird zunächst die Textur wieder fünf-mal gezeichnet. Beim Zeichnen ohne Verschiebung wird nur der Alpha Test verwendet. Bei den darauf folgenden Durchgängen werden nur Pixel überschrieben, deren Stencil Wert, also die oben bestimmte Anzahl der Überschreibungen, größer gleich drei ist. Diese Variante kann vollständig in Hardware durchgeführt werden und löst das Problem von nicht gesetzten Pixel, kann allerdings keine korrekte Verdeckungsberechnung durchführen. Dazu ist die Trennung von Sichtbarkeits- und Farbbestimmung notwendig, wie sie z.b. in [40] oder [25] durch mehrfaches Rendering des Punktdatensatzes oder durch Verwendung des A- Buffers [3], vorgeführt wird. Für Datensätze mit überwiegend konvexen Oberflächen würde sich aber auch die hier vorgestellte Methode eignen. Obwohl damit nur ein deutlich geringerer Teil der Abtastpunkte benötigt wird, ist es, durch die hohe Leistung moderner Grafikkarten bei geometrischen Berechnungen und beim Rendering in den meisten Fällen, sinnvoller die Abtastdichte des Datensatzes und die Anzahl der verwendeten Abtastpunkte beim Rendering genügend hoch zu wählen, so dass eine geschlossene Oberfläche dargestellt wird Early Z Occlusion Culling In Kapitel 3 wurde bereits das Early Z Occlusion Culling erwähnt. Damit soll die Tiefenkomplexität beim Rendering reduziert werden. Laut [4] soll durch ein grobes Sortieren der Oberflächen und Zeichnen von vorne nach hinten beim Rendering verdeckte Flächen bzw. Fragmente vor dem Rasterisieren identifiziert und davon ausgeschlossen werden. Somit kann die Bandbreite für Z- und Frame-Buffer und gegebenenfalls Texturzugriffe reduziert werden. 87

94 Eine grobe Sortierung der Oberflächen beim punktbasiertem Rendering, mit der in dieser Arbeit vorgestellten Datenstruktur, kann realisiert werden, indem der Octree so durchlaufen wird, dass näher am Betrachter liegende Octree Cluster zuerst gezeichnet würden. Diese Option wurde in der Implementation integriert, aber es konnte keine Änderung der Renderleistung festgestellt werden. Es ist daraus zu schließen, dass das Early Z Occlusion Culling bei der getesteten Hardware dem dreiecksbasiertem Rendering vorbehalten ist, bzw. keine Auswirkungen auf Punktprimitive hat Texturkompression Der Speicherbedarf von Texturen ist für das Rendering von Datensätzen aus kalibrierten Kamerabildern von Interesse. Ohne Geschwindigkeitseinbußen lässt sich eine Komprimierung der Texturen im Speicher einsetzen. Dabei kommt meist die S3 Texturkompression zum Einsatz. Hierbei werden die Farbwerte eines 4 4 Texelblockes in 64 Bit verlustbehaftet komprimiert. Die Alphainformation, soweit vorhanden, bedarf weiterer 64 Bit. Der Qualitätsunterschied ist dabei im Allgemeinen kaum wahrnehmbar. 6.8 Analyse der Performanzengpässe In diesem Abschnitt befindet sich die Beschreibung, wie eine Analyse der Leistungsengpässe beim Rendering mit einer bestimmten Implementation durchgeführt wird. Zu diesem Zweck besteht leider nicht die Möglichkeit, die benötigte Rechenzeit innerhalb des Grafikkarten Treibers zu bestimmen, noch existiert eine Beschreibung der internen Operationen und deren Zeitbedarf des Grafikprozessors. Deshalb fand eine sogenannte Black-Box Analyse nach den Anregungen aus [4] statt Black Box Analyse Es gibt eine Vielzahl von Aspekten, die es zu berücksichtigen gilt, um die Leistung der Grafikhardware möglichst vollständig auszunutzen. Deshalb gilt es, jeden dieser Punkte zu analysieren und gegebenenfalls zu optimieren. Ein oft genannter Aspekt, der immer im Zusammenhang mit Grafikhardware und Grafik APIs genannt wird, ist die Anzahl der so genannten State Changes zu reduzieren. Dazu gehört beispielsweise das Auswählen einer Textur oder die Änderung von Renderparametern für die Beleuchtungsberechnung oder das Blending. Dieser Aspekt lässt sich genauso wie die Reduzierung der API Aufrufe insgesamt durch eine geeignete Datenorganisation, wie sie bereits in diesem Kapitel vorgestellt wurde, lösen. Einen weiteren möglichen Engpass stellt die Speicherbandbreite dar. Zuerst ist die begrenzte Bandbreite des AGP Busses zu nennen. Diese beträgt bei AGP4x beispielsweise 1066 Megabyte pro Sekunde, wobei dieser Wert in der Praxis niedriger liegen kann, denn er wird außerdem noch durch die Bandbreite des Systemspeichers begrenzt. Wenn pro Splat beispielsweise Daten bestehend aus einer Koordinate und einer Normale, also Byte = 24 Byte Daten, übertragen werden müssen, liegt die maximale Anzahl von Splats pro Sekunde 88

95 bei ( )/ und kann je nach Grafikhardware bereits einen begrenzenden Faktor darstellen. Für eine vorliegende Implementation kann überprüft werden, ob eine Begrenzung durch diese Speicherbandbreite zwischen Hauptspeicher und Grafikhardware vorliegt, indem zusätzliche, nicht für das Rendering verwendete, Attribute für Splats mit übertragen werden. Solche Attribute können z.b. nicht verwendete Texturkoordinaten sein. Sinkt die Anzahl der dargestellten Splats pro Sekunde, so kann davon ausgegangen werden, dass die Bandbreite ein begrenzender Faktor ist. Umgekehrt lässt sich die Menge der Attribute reduzieren und eine steigende Anzahl von Splats pro Sekunde lässt denselben Schluss zu. Beim Rendering mit Dreiecksnetzen kann die Bandbreite durch eine geeignete Umordnung des Netzes, so dass die Caches der Grafikhardware ausgenutzt werden, besser genutzt werden. Bei punktbasiertem Rendering besteht diese Option natürlich nicht. Der nächste Abschnitt in der Grafikpipeline den es zu untersuchen gilt, ist die Transformations- und Beleuchtungsberechnung. Der Zeitbedarf pro Vertex hängt dabei direkt von der Anzahl der Lichtquellen, dem Beleuchtungsmodell und weiterer Zusatzfunktionen, wie z.b. die automatische Generierung von Texturkoordinaten ab. Bei der Verwendung von Vertex Programs sinkt die Verarbeitungsgeschwindigkeit mit zunehmender Länge der Programme. Die Verarbeitungsgeschwindigkeit beider Möglichkeiten, der Fixed-Function Pipeline und der Vertex Programs, hängt von der Taktfrequenz des Grafikprozessors ab. Ob bei dieser Stufe der Grafikpipeline ein Engpass vorliegt, kann überprüft werden indem - bei Verwendung der Fixed-Function Pipeline - verschiedene Beleuchtungsmodelle verwendet werden, oder die Anzahl der Lichtquellen verändert wird. Wenn Vertex Programs eingesetzt werden, kann deren Länge, und somit deren Ausführungszeit, verändert werden. Dabei ist zu beachten, dass offensichtlich unnötige Instruktionen innerhalb eines Vertex Programs automatisch eliminiert werden. Auch in diesem Schritt lässt sich der Cache der Grafikhardware nur für dreiecksbasiertes Rendering einsetzen. Der letzte zu analysierende Aspekt ist die Rasterisierung. Oft wird von der so genannten Fill-Rate gesprochen. Dabei handelt es sich um die Speicherbandbreite die beim Rasterisieren für Zugriffe auf Texturen, den Frame-, Z- und Stencil Puffer, zur Verfügung steht. Diese Speicherzugriffe erfolgen, vorausgesetzt die verwendeten Texturen sind dort gespeichert, lediglich auf dem Grafikkarten internen Speicher, der eine Bandbreite von mehreren Gigabyte pro Sekunde zur Verfügung stellt. Da bei dem punktbasierten Rendering der vorliegenden Implementation keine komplexen Texturzugriffe oder Blending Operationen eingesetzt werden, kann die benötigte Bandbreite leicht abgeschätzt werden, ohne dass weitere Faktoren, wie z.b. Textur Filterung und voneinander abhängige Texturzugriffe, berücksichtigt werden müssen. Die benötigte Bandbreite zum Rendering eines Splats kann als Produkt aus der Anzahl der Pixels, der ausgelesenen Texels und den gelesenen bzw. geschriebenen Frame und Z-Buffer Werten (bzw. deren Speicherbedarf) dargestellt werden. Analog zu den obigen Analysen lässt sich feststellen, ob ein Engpass beim Rasterisieren vorliegt, indem die Splats - bei sonst gleichem Rendering - einfach größer oder kleiner dargestellt werden oder die Auflösung des Bildes verändert wird. 89

96 6.8.2 Schlussfolgerungen Die Analyse der Ergebnisse in Kapitel 8, anhand der obengenannten Verfahrensweise, lässt den Schluß zu, dass der Hauptprozessor des Rechners nicht den Flaschenhals beim Rendering darstellt, was durch die in dieser Arbeit vorgestellten Datenstrukturen und -organisation verhindert wird. Damit zeigt sich, das die Geschwindigkeit des Renderings durch die Leistung der Grafikhardware selbst begrenzt wird. Diese Datenstrukturen ließen sich auch mit anderen Splatting Algorithmen, wie z.b. [25], kombinieren und können somit um qualitätssteigernde Verfahren, z.b. zum Rendering mit Textur Filterung, ausgebaut werden. 90

97 Kapitel 7 Beschreibung der entwickelten Programme In diesem Kapitel werden die - im Zuge dieser Arbeit - entstandenen Anwendungen beschrieben. Diese sind zum Einen die Programme zur Generierung der Punktdatensätze aus Dreiecksnetzen bzw. kalibrierten Kamerabildern und das Betrachterprogramm. Die Punktdatensätze werden jeweils in einer Reihe von Dateien mit der Endung CDS abgelegt. Tabelle 7.1 zeigt die immer vorhandenen bzw. optionalen Dateien und deren Inhalt. Datei header.cds normal1.cds normal2.cds octree.cds attribute.cds color*.cds Beschreibung Information über den Datensatz, z.b. Quantisierung, Abtastpunkte usw. Speicherung der oberen Bits der quantisierten Normalen pro Punkt Speicherung der unteren Bits der quantisierten Normalen pro Punkt Hierarchische Quantisierung des Voxelgrids, d.h. die Lage der Abtastpunkte Weitere Attribute, wie z.b. Punktgröße oder Texturflag (optional) Texturen für die Radiance Interpolation (optional) Tabelle 7.1: Die Dateien eines Punktdatensatzes, der mit den entwickelten Programmen erstellt wurde. 7.1 Datengenerierung aus Dreiecksnetzen Das erste Anwendungsprogramm dient zur Erstellung von Punktdatensätzen aus Dreiecksnetzen. In diesem Programm sind die in Kapitel 5 beschriebenen Verfahren sowohl zur regelmäßigen, als auch zur unregelmäßigen Abtastung implementiert. Das Programm wurde in die lgf3 Bibliothek integriert und verwendet die dadurch zur Verfügung stehenden Importmodule zum Lesen von OFF-Dateien. Dieses ASCII Dateiformat beschreibt Dreiecksnetze in der Shared Vertex Struktur und dient als Eingabeformat. Der Aufruf des hier beschriebenen Programms pbr-genreg erfolgt mit dem Namen einer OFF-Datei als Parameter. Nachdem die Daten des Dreiecksnetzes geladen wurden, erscheint der in Abbildung 7.1 gezeigte Konfi- 91

98 gurationsdialog, der verschiedene Optionen bei der Generierung des Datensatzes bietet. Die Bedeutung der einzelnen Parameter wird im Folgenden beschrieben. Abbildung 7.1: Der Konfigurationsdialog für das Programm zur Generierung von Punktdatensätzen aus Dreiecksnetzen. Als erstes wird die Art der Datengenerierung festgelegt. Zur Auswahl stehen: Regelmäßige Abtastung durch Uniform Clustering oder Regelmäßige Abtastung durch die in Abschnitt vorgestellte Methode oder Unregelmäßige Abtastung durch Verwendung der Knoten des Dreiecksnetzes als Abtastpunkte, analog zum QSplat Verfahren. Weiterhin kann die Quantisierungsgenauigkeit für die Speicherung der Koordinaten gewählt werden. Sie wird in Bits pro Komponente angegeben. Auch die Quantisierung der Abtastpunktnormalen kann festgelegt werden. Der eingestellte Wert bestimmt die Anzahl der Unterteilungsschritte der Oktaederquantisierung aus Abschnitt Die Anzahl der Bits pro Normale setzt sich aus 3 (für den Oktanten) plus 2 mal der Anzahl der Unterteilungsschritte zusammen. Der letzte Parameter bezieht sich lediglich auf die regelmäßige Abtastung durch die Projektion von Abtastpunkten auf die Dreiecksflächen, also die zweite der oben genannten drei Optionen. Hier wird die Anzahl der Zufallspunkte in dem [0; 1] [0; 1] Intervall und somit die resultierende Abtastdichte festgelegt. Die erstellten CDS Dateien werden nach dem Schließen des Dialogs erstellt und im aktuellen Verzeichnis angelegt. 7.2 Datengenerierung aus kalibrierten Kamerabildern Diese Form der Datengenerierung wird, wie in Abschnitt 5.3 beschrieben, durchgeführt. Die Folge der kalibrierten Kamerabilder, also der Farb- und Tiefenbilder, ist in den CCI Dateien definiert. Der Dateiname der entsprechenden CCI Datei wird dem gen-ibr Programm als 92

99 Parameter übergeben. Zum Lesen aller Eingabedaten dient wiederum die Funktionalität der lgf3 Bibliothek. Mithilfe des Konfigurationsdialogs aus Abbildung 7.2 können Parameter für die Generierung der Daten eingestellt werden. Abbildung 7.2: Der Konfigurationsdialog für das Programm zur Generierung von Punktdatensätzen aus kalibrierten Kamerabildern. Die ersten beiden Parameter bestimmen, wieviele Bildpunkte der Kamerabilder als Abtastpunkte verwendet werden, indem die Schrittweite durch das Bild spalten- und zeilenweise angegeben wird. Die Anzahl der Kamerabilder kann ebenfalls angegeben werden. Es kann das Start- und das Endbild (First View/Last View) und die Schrittweite durch diese (Teil-)Folge festgelegt werden. Wenn die Eingabedaten so genannte Confidence Maps besitzen, d.h. Informationen über die Validität einzelner Bildpunkte, so kann diese verwendet oder ignoriert werden. Für die Quantisierung der Koordinaten kann, wie beim ersten Programm, die Anzahl der Bits pro Komponente gewählt werden. Weiterhin wird festgelegt, ob ein Abtastpunkt nur einen Farbwert besitzen kann, oder ob die Radiance Interpolation eingesetzt wird. Im letzteren Fall kann für diese Technik die Größe der Texelblöcke und die der Radiance Texturen festgelegt werden. Nach Verlassen des Dialogs beginnt die Generierung der Abtastpunkte und die Daten werden im CDS Dateiformat abgelegt. 7.3 Darstellungsprogramm Das Darstellungsprogramm (Abbildung 7.4) wurde ebenfalls in die lgf3 Bibliothek integriert. Ein CDS Datensatz wird dem pbr-viewer Programm als Parameter übergeben. Anschließend wird dieser geladen und es erscheint der Konfigurationsdialog, wie in Abbildung 7.3. Dieser ist 93

100 notwendig, um bestimmte Initialisierungsparameter für die Betrachtung des Punktdatensatzes festzulegen. Abbildung 7.3: Der Konfigurationsdialog für das Betrachterprogramm. Der erste Parameter bestimmt, in welchem Speicherbereich bzw. in welcher -form die Geometriedaten abgelegt werden sollen. Dabei stehen folgende Möglichkeiten zur Auswahl: Vertex Arrays Compiled Vertex Arrays AGP Speicher Video Speicher Eine Untersuchung der Render-Geschwindigkeit, abhängig von diesem Parameter, befindet sich im folgenden Kapitel. Sollte die Allokierung des gewählten Speichertyps fehlschlagen, so wird jeweils der nächst langsamere Speichertyp verwendet. Der zweite Parameter bestimmt, wie fein die Unterteilung der gesamten Menge von quantisierten Normalen (sofern diese im Datensatz vorhanden sind) in Normal Clusters erfolgen soll. Analog zum Generierungsprogramm setzt sich die Anzahl der obersten Bits, die bei Normalen eines Clusters gleich sind, aus 3 plus 2 mal den gewählten Wert zusammen. Weiterhin kann die Anzahl der räumlichen Unterteilungen des Bounding Cubes des Datensatzes für die Octree Repräsentation festgelegt werden. Die noch folgenden Parameter bestimmen, ob die Beleuchtungsberechnung über Texturen oder pro Abtastpunkt erfolgen soll, ob Occlusion Culling verwendet werden soll, bzw. ob für die Radiance Texturen die S3 Textur Kompression verwendet werden soll. Sollte eine benötigte OpenGL Erweiterung, wie z.b. das Occlusion Culling, nicht unterstützt werden, so wird dies automatisch erkannt und die Darstellung erfolgt ohne diese Option. Somit ist gewährleistet, dass das Betrachterprogramm auch auf älterer Grafikhardware lauffähig ist. 94

101 Abbildung 7.4: Das Betrachterprogramm, integriert in die lgf3 Bibliothek. Während dem Betrachten des Datensatzes können mithilfe der Mouse die Betrachterparameter geändert werden. Weiterhin existieren eine Reihe von Optionen (rechts in Abbildung 7.4): Splat Shape: Es kann zwischen rechteckiger und runder Punktform gewählt werden. Show Octree: Legt fest, ob die Bounding Boxes der Octree Cluster dargestellt werden. Angle Dependant Bias und Angle Dependant Cos Scale 1 : Anhand des Winkels zwischen Blickrichtung und der gemittelten Normale eines Normal Clusters erfolgt eine Abschätzung, wieviele Abtastpunkte benötigt werden. Diese kann modifiziert werden, indem er mit dem Scale Wert multipliziert und der Bias Wert aufaddiert wird. Correction Factor Scale 1 : Der nach Abschnitt 6.4 berechnete Korrekturfaktor fließt mit der angegebenen Gewichtung in die Abtastdichte ein. Distance Dependant Scale 1 : Ein Gewichtungsfaktor für die Schätzung der Abtastdichte abhängig von der Entfernung zum Betrachter. Point Size 1 : Hiermit kann die Punktgröße und somit die Menge der verwendeten Abtastpunkte und die Darstellungsqualität gewählt werden. Point Size Scale 2 : Mit diesem Wert wird die pro Splat berechnete Größe multipliziert. 1 für regelmäßig, 2 für unregelmäßig abgetastete Oberflächen 95

102 96

103 Kapitel 8 Ergebnisse und Vergleich mit anderen Verfahren In diesem Kapitel werden die Ergebnisse der, in dieser Arbeit entwickelten, Verfahren und Implementationen vorgestellt und mit denen anderer Verfahren verglichen. Die Leistungsfähigkeit des Verfahrens zur kompakten Speicherung der Punktdatensätze wird anhand von einigen Beispielen deutlich. 8.1 Die Testdatensätze und Speicherbedarf der Daten In diesem Abschnitt wird zunächst der Speicherbedarf zur Übertragung bzw. Archivierung ausgewählter Punktdatensätze dargestellt. Für die Datensätze, die aus Dreiecksnetzen generiert wurden, zeigt Tabelle 8.1 die Anzahl der Knoten v und Dreiecke t sowie den Speicherbedarf, wenn diese in binärer Form in Shared Vertex Darstellung gespeichert werden. Dieser Speicherverbrauch in Bits errechnet sich wie folgt, wenn die Koordinaten pro Knoten durch drei IEEE 32 Bit Gleichkommawerte repräsentiert werden: 3 t log 2 v v (8.1) Datensatz Knoten Dreiecke Speicherbedarf Shared Vertex Binärdaten in Byte Bunny Horse (Happy) Buddha Dragon Blade Tabelle 8.1: Die Dreiecksnetze aus denen die Punktdatensätze generiert wurden. Die Angaben bzgl. des Speicherbedarfes der Punktdatensätze beziehen sich jeweils auf die binäre Repräsentation der Daten, wie sie von der entwickelten Software erstellt wird und 97

104 einer anschließenden Kompression mit einer redundanzsparenden Kodierung. Für diese Zwecke wurde der Associative Coder of Buyanovsky gewählt, der eine sehr gute, natürlich verlustfreie, Kompression erzielt. Damit lassen sich die Ergebnisse für die Speicherung der Koordinaten aus [2] unterbieten und es wird eine sehr gute Kompression der quantisierten Normalen erreicht. Die Ergebnisse für Datensätze mit regelmäßiger Abtastung von Dreiecksnetzen zeigt Tabelle 8.2. Die Datensätze mit einer Normalenquantisierung von 11 Bit sind nur der Vollständigkeit halber aufgeführt. Praxisrelevanz besitzen nur Datensätze mit 13 Bit Quantisierung. Wie zu sehen ist, kann der Speicherbedarf pro Koordinatentripel auf unter 1 Bit, der Speicher für eine Normale auf etwa 2.5 Bit reduziert werden. Mit einer noch feineren Abtastung, die allerdings feiner als zu einer Darstellung auf dem Bildschirm benötigt wäre, ließen sich noch kleinere Werte erreichen. Es ist weiterhin die Abschätzung des Speicherbedarfes, die in Abschnitt vorgestellt wurde nachzuvollziehen. Datensatz Quantisierung Abtastpunkte Größe Bits pro Bits pro Octree/Normale in Byte Koordinate Normale Bunny 6/13 Bit Bunny 7/13 Bit Bunny 8/11 Bit Bunny 8/13 Bit Bunny 9/11 Bit Bunny 9/13 Bit Bunny 10/13 Bit Horse 8/13 Bit Horse 9/13 Bit Horse 10/13 Bit Buddha 8/13 Bit Buddha 9/13 Bit Buddha 10/13 Bit Buddha 11/13 Bit Dragon 8/13 Bit Dragon 9/13 Bit Dragon 10/13 Bit Dragon 11/13 Bit Blade 8/13 Bit Blade 9/13 Bit Blade 10/13 Bit Blade 11/13 Bit Tabelle 8.2: Der Speicherbedarf für unterschiedliche Quantisierungen nach uniformen Clustering. 98

105 Tabelle 8.3 zeigt den Speicherbedarf für die Datensätze, die vergleichbar mit dem QSplat Verfahren, durch unregelmäßige Abtastung der Dreiecksnetze entstanden sind. Auffällig ist der deutlich höhere Speicherbedarf pro Koordinate bzw. Normale, als bei regelmäßig abgetasteten Dreiecksnetzen. Dieser resultiert daraus, dass die gerade erwähnte Abschätzung nur gilt, wenn eine geschlossene Fläche durch das Voxel-Gitter repräsentiert wird. Dies ist bei dieser Art der Datengenerierung nicht der Fall und daraus resultiert ein dünner besetztes Voxel-Gitter mit erhöhtem Speicherbedarf pro Abtastpunkt. Wichtig zu erwähnen ist bei diesen Daten, dass durch die Quantisierung der Koordinaten einzelne Splats zusammenfallen, bzw. deren Lage verändert werden kann. Diese zwei Faktoren können verursachen, dass die Abschätzung der Splatgröße, wie in Kapitel 5.1, nicht direkt übernommen werden kann. Dieses Problem wird durch eine Kollisionsbehandlung beim Quantisieren, wie in Abschnitt 5.4.5, gelöst. Datensatz Quantisierung Abtast- Größe Bits pro Bits pro Bits pro Octree/Nrml punkte in Byte Koordinate Normale Splatgröße Bunny 8/13 Bit Bunny 9/13 Bit Bunny 10/13 Bit Buddha 9/13 Bit Buddha 10/13 Bit Buddha 11/13 Bit Buddha 12/13 Bit Buddha 13/13 Bit Dragon 9/13 Bit Dragon 10/13 Bit Dragon 11/13 Bit Dragon 12/13 Bit Dragon 13/13 Bit Blade 13/13 Bit Tabelle 8.3: Der Speicherbedarf für unterschiedliche Datensätze und Quantisierungen bei unregelmäßiger Abtastung und Quantisierung der Splatgröße auf 8 Bit. Der Speicherbedarf für die Punktdatensätze, die aus kalibrierten Kamerabildern erzeugt wurden, zeigen Tabelle 8.4 und 8.5. Die darin aufgeführten Datensätze umfassen synthetische Datensätze, die mithilfe eines modifizierten Raytracing Programmes oder aus einer Folge von synthetischen Kamerabildern generiert wurden. Diese Datensätze zeigen, dass die - im Zuge dieser Arbeit - implementierte Radiance Interpolation sowohl sehr gute Ergebnisse bei der Darstellung von Beleuchtungseffekten, wie beispielsweise durch das Phong Beleuchtungsmodell, liefert und sich auch für die Darstellung von Spiegelungen eignet (Abbildung 8.1). Reale Datensätze lagen meist nur mit qualitativ schlechter Tiefeninformation vor. Deshalb ist in der Tabelle nur der Magen Datensatz aufgeführt. Ein weiteres Beispiel unterstreicht die Wichtigkeit der Radiance Interpolation: bei Flächen, deren Materialeigenschaften auf beiden 99

106 Seiten unterschiedlich sind (Abbildung 8.2). Tabelle 8.4 zeigt dabei den Speicherbedarf für die Koordinaten und Splatgrößen, Tabelle 8.5 zeigt den benötigten Texturspeicher in folgenden Repräsentationen: unkomprimiert mit je 8 Bit für die Rot-, Grün- und Blau-Komponente (optional 8 Bit für den Alpha Wert), in der komprimierten S3 Texture Compression Form und als JPEG Datei. Abbildung 8.1: Die Radiance Interpolation erlaubt eine korrekte Darstellung beliebiger Beleuchtungsmodelle und sogar Spiegelungen. Abbildung 8.2: Die Radiance Interpolation wird für die Darstellung von Oberflächen mit unterschiedlichen Materialeigenschaften oder Beleuchtungssituationen beider Seiten benötigt. Die Darstellung als JPEG Datei eignet sich zur Übertragung und Speicherung der Radiance Information. Aufgrund der bereits in Kapitel erwähnten Darstellung der Radiance 100

107 Information und der Speicherung der JPEG Daten kann eine hohe Kompression erreicht werden, ohne dass Kompressionsartefakte beim Rendering zu erkennen sind. Somit wird eine sehr kompakte Darstellung der Daten erreicht. Datensatz Quantisierung/ Bits pro Bits pro Splatgröße Anzahl Splats Koordinate und Texturflag R. Softshadow 8 Bit/ R. Reflection 8 Bit/ Petruschka 9 Bit/ Magen 9 Bit/ Avatar 1 9 Bit/ Tabelle 8.4: Der Speicherbedarf der Abtastpunktkoordinaten für verschiedene Datensätze mit Radiance Interpolation. Datensatz Abtast- Radiance Textur Größe/ S3 Texture JPEG Punkte Information unkomprimiert Compression R. Softshadow Texel , 53614kb 8192kb 1396kb R. Softshadow Texel , kb 26624kb 3547kb R. Reflection Texel , kb 34816kb 8424kb Avatar Texel , 1242kb 512kb 115kb Petruschka Texel , 3443kb 512kb 336kb Magen Texel , 610kb 128kb 70kb Tabelle 8.5: Der Speicherbedarf für verschiedene Datensätze mit Radiance Interpolation. Die JPEG Kompression ist verlustbehaftet, wobei darauf geachtet wurde, dass beim Rendering keine Kompressionsartefakte zu erkennen sind. 8.2 Die Renderperformance In diesem Abschnitt soll die Geschwindigkeit des Renderings mit den, in dieser Arbeit, entwickelten Datenstrukturen und Implementationen vorgestellt werden. Die Resultate wurden größtenteils mit einer Athlon XP CPU mit 1466Mhz und einer GeForce 3 Grafikkarte mit einer GPU Taktfrequenz von 200 MHz und 64 Megabyte Speicher mit einer Speichertaktfrequenz von 460MHz gemessen. Die Grafikkarte wurde an der AGP4x Schnittstelle betrieben. Für eine Testreihe wurde alternativ eine GeForce 4 Ti4200 Grafikkarte verwendet. Zur Bestimmung der Ergebnisse wurde jeweils die Windows Version der entwickelten Implementation verwendet, die sich aber sowohl vom Programmkern selbst, als auch von der Geschwindigkeit nicht von der Linux Portierung unterscheidet. Wie im Folgenden, mithilfe der Berechnung der benötigten Bandbreite gezeigt, ist nicht die Implementation oder die verwendeten Algo- 101

108 rithmen der begrenzende Faktor, sondern die Transformationsleistung oder die Fillrate der Grafikhardware Berechnung der benötigten Speicherbandbreite Bei der Analyse der Leistungsengpässe kann zum Einen, wie in Kapitel 6.8 verfahren werden. Zusätzlich kann die benötigte Speicherbandbreite für den AGP Bus und für den Grafikkarten eigenen Speicher berechnet werden. Wenn die Geometriedaten sich nicht im Speicher der Grafikkarte befinden, müssen sie vollständig, für jedes dargestellte Bild über den AGP Bus transferiert werden. Der Speicherbedarf pro Splat setzt sich aus folgenden Teilen zusammen: Koordinate: drei 32 Bit Gleichkommazahlen Splatgröße (optional): eine 32 Bit Gleichkommazahl Normale (optional): entweder zwei oder drei 32 Bit Gleichkommazahlen, für die Beleuchtungsberechnung über Texturen oder eine Beleuchtungsberechnung pro Punkt Texturkoordinaten (optional): zwei 32 Bit Gleichkommazahlen pro Koordinatenpaar Daraus läßt sich bereits eine Obergrenze der dargestellten Splats pro Zeit berechnen, indem das Minimum aus AGP Bandbreite und Systemspeicherbandbreite durch den benötigten Speicher pro Abtastpunkt geteilt wird. Die Betrachtung von Grafikkarten, die nicht am AGP Bus betrieben werden, ist für die heutige Praxis nicht relevant. Wenn die Geometriedaten im Speicher der Grafikkarte abgelegt sind, belasten sie den AGP Bus nicht mehr, belasten aber die interne Bandbreite der Grafikkarte. Aufgrund einer Inkonsistenz der Grafikkartentreiber kann es notwendig sein, die Punkte in diesem Fall nicht mit gldrawarrays sondern gldrawelements zu zeichnen. Dann wird pro OpenGL Punkt ein 4 Byte Index benötigt, der über den AGP Bus übertragen werden muss, aber sicher keinen begrenzenden Faktor darstellt. Die interne Speicherbandbreite der Grafikkarte setzt sich hauptsächlich, wie bereits erwähnt, aus dem Speicher der Geometrieinformation und den Speicherzugriffen auf Texturen, die sich im Allgemeinen im Speicher der Grafikkarte befinden, sowie Frame, Stencil und Z Buffer Operationen zusammen. Diese sind z.b. beim Rendering eines texturierten, ein Pixel großen Fragmentes mit Z-Buffering und 32 Bit Farbtiefe: ein 32 Bit Lesezugriff auf die Textur ein 32 Bit Lesezugriff auf den Z-Buffer ein 32 Bit Schreibzugriff auf den Z-Buffer ein 32 Bit Schreibzugriff auf den Frame Buffer 102

109 Die AGP Speicherbandbreite hat sich in den Testreihen, die durchgeführt wurden, als begrenzender Faktor gezeigt, wenn die Geometriedaten nicht im Speicher der Grafikkarte abgelegt wurden. Der AGP4x Bus genügt noch für die Übertragung von Punkten mit Koordinaten und Texturkoordinaten um die Transformationsleistung einer GeForce 3 Karte auszuschöpfen, bei mehr Daten pro Abtastpunkt ist er schon der begrenzende Faktor. Die interne Speicherbandbreite bzw. Fillrate war vor allem beim Rendering mit Splats variabler Größe der begrenzende Faktor. Auch bei beabsichtigt zu groß gezeichneten Punkten wird schnell die Bandbreite der GeForce 3 Karte ausgelastet, da viele Pixel des Bildes mehrfach gezeichnet wurden Für variable Abtastdichte und Vergleich mit QSplats In diesem Abschnitt wird die Geschwindigkeit bei der Darstellung mit variabler Punktgröße aufgezeigt. Als Testdatensätze dienten die in Tabelle 8.3 aufgeführten. Tabelle 8.6 zeigt die erreichten Bilder pro Sekunde für verschiedene Datensätze mit variabler Punktgröße. Zum Vergleich zeigt Tabelle 8.7 die QSplat Datensätze, die aus denselben Dreiecksnetzen generiert wurden und mit der original QSplat-Implementation dargestellt wurden. Es wurden jeweils die Anzahl der auf dem Bildschirm dargestellten Punkte angegeben. Es wird deutlich, dass das QSplat Verfahren auf der getesteten Hardwarekonfiguration deutlich langsamer ist. Die verschiedenen Quantisierungen und die daraus unterschiedliche Anzahl von Abtastpunkten in Tabelle 8.6 zeigt den zu erwartenden Geschwindigkeitszuwachs, wenn das Level-of-Detail Verfahren aus Abschnitt implementiert werden würde. Datensatz Quantisierung Anzahl Splats Bilder pro Sekunde Bunny 8 Bit Hz Bunny 9 Bit Hz Buddha 8 Bit Hz Buddha 9 Bit Hz Buddha 10 Bit Hz Buddha 11 Bit Hz Buddha 12 Bit Hz Buddha 13 Bit Hz Dragon 8 Bit Hz Dragon 9 Bit Hz Dragon 10 Bit Hz Dragon 11 Bit Hz Dragon 12 Bit Hz Dragon 13 Bit Hz Tabelle 8.6: Die Rendergeschwindigkeit verschiedener Datensätze mit variabler Punktgröße bei Pixel Auflösung. 103

110 Datensatz Anzahl Splats Bilder pro Sekunde Bunny Buddha Dragon Tabelle 8.7: Die Rendergeschwindigkeit der QSplat Implementation. Vor allem bei einer größeren Anzahl Splats sinkt die Anzahl der Bilder pro Sekunde rapide Für einheitliche Abtastdichte Tabelle 8.8 zeigt die Anzahl der Punkte, die pro Sekunde dargestellt werden können. Die Ergebnisse wurden jeweils mit unterschiedlichen Speicherorten der Geometriedaten und Beleuchtung über Texturen oder OpenGL Beleuchtungsberechnung mit einer Lichtquelle ermittelt. Es ist zu erkennen, dass bei den ersten beiden Speicherorten die Übertragung der Geometriedaten der begrenzende Faktor ist. Für die GeForce 3 Grafikkarte genügt die Übertragungsgeschwindigkeit des AGP Busses, um die Transformationsleistung der GPU auszunutzen. Bei der GeForce 4 GPU ist ein deutlicher Sprung zwischen den unteren beiden Zeilen der Tabelle zu erkennen. Weiterhin wird deutlich, dass die Beleuchtungsberechnung über Texturen bei GeForce 3 eine höhere Geschwindigkeitssteigerung mit sich bringt als bei der GeForce 4. Es muss auch erwähnt werden, dass diese Resultate nicht verbindlich für jegliche Hardwarekonfiguration und Treiberkonstellation ist. Eine Testkonfiguration erreichte bei allen vier Speicherorten die maximale GeForce 3 Leistung, was auf den verwendeten Speichertyp und eine bestimmte Treiberversion zurückzuführen ist. Mit den in Kapitel 6.8 vorgestellten Methoden ergab sich, dass mit den Datenstrukturen der vorliegenden Implementation die Leistung der Transformations- und Beleuchtungsberechnung der GeForce 3 und 4 Grafikkarten ausgenutzt werden kann und gleichzeitig eine intelligente Selektion der benötigten Daten vorgenommen wird. OpenGL Datenformat Speicherort GeForce 3 GeForce 4 Ti4200 Textur/Normale Textur/Normale OpenGL Arrays System 20.6 / / 14.4 Compiled Vertex Arrays System/AGP / / 15.3 AllocateMemoryNV/AGP AGP 38.4 / / 36.8 AllocateMemoryNV/Video Grafikkarte 38.4 / / je nach verwendetem Treiber Tabelle 8.8: Die Rendergeschwindigkeiten in Millionen Punkte pro Sekunde, wenn die Geometriedaten in unterschiedlichen Speicherbereichen liegen und die Beleuchtungsberechnung über Texturen bzw. Normalen erfolgt. Tabelle 8.9 zeigt die erreichten Bilder pro Sekunde verschiedener Datensätze, bei einer fehlerfreien Darstellung mit unterschiedlicher Punktgröße und Bildauflösung. Dazu wurden die Datensätze aus Tabelle 8.2 verwendet. An den Werten läßt sich ablesen, dass die Darstellung 104

111 von unterschiedlicher Detailmenge, abhängig von Auflösung des Bildes und vom Benutzer gewählter Qualität (durch die Punktgröße), sehr gut funktioniert. Für Punktgröße 1 bei einer Quantisierung von weniger als 10 Bit pro Komponente kann allerdings für die Auflösung von Pixels keine lückenfreie Darstellung mehr erreicht werden, da die Abtastdichte zu gering ist. Bei gleicher Abtastdichte verschiedener Datensätze besteht ein direkter Zusammenhang zwischen Größe der Oberfläche und Anzahl der Abtastpunkte und somit auch der Rendergeschwindigkeit. Punktgröße: Bunny, 9 Bit, Hz, 18.3% 562 Hz, 5.5% 612 Hz, 2.6% 670 Hz, 1.2% Bunny, 9 Bit, Hz, 37.8% 217 Hz, 19.3% 276 Hz, 11.1% 427 Hz, 6.3% Bunny, 9 Bit, Hz, 37.5% 116 Hz, 26.4% 152 Hz, 19.5% Buddha, 9 Bit, Hz, 14.9% 653 Hz, 3.4% 705 Hz, 1.5% 770 Hz, 0.8% Buddha, 9 Bit, Hz, 35.5% 395 Hz, 17.5% 440 Hz, 12.0% 640 Hz, 3.5% Buddha, 9 Bit, Hz, 46.8% 158 Hz, 32.5% 267 Hz, 16.3% Blade, 8 Bit, Hz, 40.9% 485 Hz, 23.2% 670 Hz, 16.9% Blade, 9 Bit, Hz, 37.8% 227 Hz, 16.4% 313 Hz, 9.0% 541 Hz, 9.3% Blade, 10 Bit, Hz, 14.1% 180 Hz, 3.9% 256 Hz, 2.3% 370 Hz, 1.0% Tabelle 8.9: Die erreichten Bilder pro Sekunde mit verschiedenen Datensätzen, die mit Uniform Clustering erzeugt wurden. Die Ergebnisse wurden mithilfe einer GeForce 3 Karte bestimmt, die Beleuchtungsberechnung erfolgte über Texturen Für die Daten aus kalibrierten Kamerabildern Das Rendering der Datensätze aus kalibrierten Kamerabildern entspricht, vom Ablauf und den verwendeten OpenGL Funktionalitäten, dem Rendering mit variabler Punktgröße. Auch die Radiance Interpolation benötigt letztendlich nur wenig zusätzlichen Rechenaufwand im Betrachterprogramm und keine zusätzlichen Vertex Program Instruktionen. Der Unterschied liegt lediglich nur bei den verwendeten Radiance Texturen. Bei allen erstellten Datensätzen war der Speicherbedarf der Texturen so gering, dass sie - zumindest mit der Textur Kompression - im Speicher der Grafikkarte selbst abgelegt werden konnten. Deshalb wird eine sehr hohe Darstellungsgeschwindigkeit erreicht, wie Tabelle 8.10 zeigt. 8.3 Visueller Eindruck der Darstellungsqualität In diesem Abschnitt soll auf die Qualität der Darstellung eingegangen werden. Dabei muss darauf hingewiesen werden, das jede der Renderingoptionen auf eine maximale Auslastung der Hardware und geschwindigkeitsoptimiertes Rendering abzielt. Die Datensätze, die aus Dreiecksnetzen generiert wurden, erreichen dabei durchweg eine hohe Darstellungsqualität. Vor allem das schnelle Rendering der Datensätze, die durch regelmäßige Abtastung entstan- 105

112 Datensatz Anzahl Splats Anz. der Kamerabilder Bilder pro Sekunde Avatar Hz Avatar Hz Avatar Hz Petruschka Hz Petruschka Hz Magen Hz Raytrace Softshadow Hz Raytrace Reflection Hz Raytrace Refraction Hz Tabelle 8.10: Die erreichten Bilder pro Sekunde beim Rendering einiger Datensätze, die aus kalibrierten Kamerabildern erzeugt wurden, bei einer Auflösung von Pixel. den sind, ermöglicht die dafür benötigte, hohe Abtastdichte. Die Darstellungsqualität beim Rendering mit variabler Punktgröße ist vergleichbar mit der des QSplat Verfahrens. Das Rendering der Datensätze mit Farbinformation, und Gleiches gilt für andere texturierte Flächen, offenbart allerdings die Notwendigkeit verbesserter Splatting Techniken. Lediglich mit sehr hoher Abtastdichte werden qualitativ ansprechende Darstellungen erreicht. Die Erweiterung der Implementation um solche Techniken wurde in Abschnitt 6.6 erläutert. Die Ergebnisse der Radiance Interpolation zeigten, dass diese Technik für das Rendering von Beleuchtungs- und Spiegelungseffekten realer Oberflächen einsetzbar ist, sofern die Quelldaten, also die kalibrierten Kamerabilder, eine genügend hohe Auflösung und Tiefeninformation über die Oberflächen bieten. Nachgewiesen wurde diese Tatsache durch eine Reihe von synthetischen Datensätzen. Eine verbesserte Ausnutzung des Texturspeichers, beispielsweise durch Identifikation von Oberflächenpunkten mit ähnlicher Beleuchtungssituation im Pre-Processing, würde dieses Verfahren für einen praktischen Einsatz weiter empfehlen. Die Abbildungen 8.3, 8.4, 8.5 zeigen zwei Dreiecksnetze, die als Quelldaten dienten und die Ergebnisse mit punktbasiertem Rendering mit variabler und konstanter Abtastdichte. Visuelle Unterschiede sind bei den drei unterschiedlichen Bildpaaren kaum wahrzunehmen. Eine genauere Betrachtung offenbart, dass die Renderingergebnisse der Datensätze mit konstanter Abtastdichte nahezu identisch zum Dreiecksrendering sind. Deshalb sind diese sowohl von der Rendergeschwindigkeit, als auch von der Qualität den Datensätzen mit variabler Abtastdichte vorzuziehen. Abbildung 8.7 demonstriert die Level-of-Detail Darstellung, durch die Abschätzung der benötigten Abtastdichte (siehe Abschnitt 6.4) in Abhängigkeit von der Punktgröße, also der interaktiv gewählten Darstellungsqualität. Abbildung 8.6 zeigt einen Punktdatensatz, der aus eine Folge von synthetischen Kamerabildern erzeugt wurde. 106

113 Abbildung 8.3: Zwei Dreiecksnetze, die als Quelldaten für Punktdatensätze dienten. Optimiertes, dreiecksbasiertes Rendering erfolgt mit 10.1 bzw Hz bei Pixel Auflösung auf einer GeForce 3 Karte. Abbildung 8.4: Zwei Datensätze, generiert aus den Datensätzen aus Abbildung 8.3, mit variabler Abtastdichte. Die erreichten Bilder pro Sekunde sind 86 Hz bzw. 114 Hz. 107

114 Abbildung 8.5: Zwei Datensätze, generiert aus den Datensätzen aus Abbildung 8.3, mit konstanter Abtastdichte. Die erreichten Bilder pro Sekunde sind 146 Hz bzw. 120 Hz. Abbildung 8.6: Diese Abbildung zeigt den Petruschka Datensatz, generiert aus einer Folge von synthetischen Kamerabildern. 108

115 Abbildung 8.7: Ein regelmäßig abgetastetes Dreiecksnetz und die Level-of-Detail Darstellung durch punktbasiertes Rendering, jeweils mit Punktgröße 1 (91 Hz), 2 (132 Hz), 4 (204 Hz) und 16 (227 Hz). 109