TECHNISCHE UNIVERSITÄT DRESDEN. Diplomarbeit

TECHNISCHE UNIVERSITÄT DRESDEN FAKULTÄT INFORMATIK INSTITUT FÜR SOFTWARE- UND MULTIMEDIATECHNIK PROFESSUR FÜR COMPUTERGRAPHIK UND VISUALISIERUNG PROF. DR. STEFAN GUMHOLD Diplomarbeit zur Erlangung des akademischen Grades Diplom-Medieninformatiker Speichereffiziente Out-of-Core LoD-Hierarchien zur hochqualitativen und interaktiven Darstellung von punktbasierten Geometrien Stefan Koppitz (Geboren am 02. Oktober 1982 in Radebeul) Betreuer: Dipl.-Medieninf. Sören König Dresden, 25. August 2009

Aufgabenstellung Der Wunsch sehr große Punktwolken zugleich interaktiv und hochqualitativ darzustellen, stößt auf einige Probleme. Sehr große Punktwolken, bestehend aus mehreren Millionen Punkten, können nicht im Hauptspeicher gehalten werden. Zudem sind nicht alle Punkte zu einem Zeitpunkt sichtbar bzw. kleiner als ein Pixel. Ziel ist es nun, nur die sichtbaren bzw. größer gleich ein Pixel großen Punkte darzustellen. Die dafür verwendeten LOD-Hierarchien werden out-of-core z. B. auf der Festplatte gespeichert, und Teile dieser adaptiv zur Renderzeit in den Hauptspeicher geladen. Im Einzelnen sind folgende Punkte zu behandeln: Einführung/Literaturrecherche zu LoD-Hierarchien, Out-of-Core-Ansätzen und Punkwolkenkompression Finden einer geeigneten LoD-Hierarchie und Implementierung dieser Definition eines Algorithmus zur Darstellung von extrem großen Punktwolken Beschreibung der einzelnen Stufen des Algorithmus und Aufzeigen der Schwierigkeiten und zu lösenden Probleme Implementieren des Algorithmus und Integrieren der hochqualitativen Darstellung Definieren von Datenformaten zwischen den einzelnen Stufen, um die Teilmodule leicht austauschbar zu machen Evaluierung der Qualität und Performanz anhand einiger Beispiele

Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die von mir am heutigen Tag dem Prüfungsausschuss der Fakultät Informatik eingereichte Diplomarbeit zum Thema: Speichereffiziente Out-of-Core LoD-Hierarchien zur hochqualitativen und interaktiven Darstellung von punktbasierten Geometrien vollkommen selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Dresden, den 25. August 2009 Stefan Koppitz

Kurzfassung In dieser Diplomarbeit stand eine hochqualitative und zugleich interaktive Darstellung von extrem großen Punktwolken im Mittelpunkt. Hierbei ist von Punktwolken von mehreren Gigabyte Speicherplatz, wie sie z. B. im 3D- Scanning entstehen, die Rede. Zur hochqualitativen Darstellung wurde der in der Belegarbeit entwickelte EWA- Renderer genutzt. Da nicht alle Punkte zur selben Zeit sichtbar sind, wird hier das Konzept der Level-of-Detail- Hierarchien, genauer der blockbasierten Multiresolution-Punkthierarchien, genutzt. Um die Punktwolke nun zu rendern, muss die Hierarchie traversiert werden. Die CPU wird bei der Traversierung der Hierarchie durch die GPU entlastet. Dazu wird die Hierarchie sequentialisiert, in große Blöcke geteilt und an die GPU geschickt. Die GPU übernimmt dann die feingranulare Traversierung und das Culling. Für die aufgebaute Hierarchie wird jedoch zusätzlicher Speicher gebraucht. Die Menge der Punkte und die Hierarchie passen dann weder in den Hauptspeicher noch in den Videospeicher der Grafikkarte. Aufgrund dessen wurden sowohl entsprechende clientseitige als auch serverseitige Out-of-Core-Algorithmen entwickelt und implementiert. Diese arbeiten mit bekannten Seitenersetzungsstrategien und laden benötigte Teile der Hierarchie in den begrenzten Haupt- oder Videospeicher nach. Somit wird eine uneingeschränkte Interaktion mit der hochqualitativ gerenderten Punktwolke für den Benutzer möglich. Abstract This diploma thesis focuses on a high-quality and at the same time interactive representation of extremely large point clouds. Here is the speech of gigabyte sized point clouds, as they emerge in 3d scanning. For the high-quality representation, the EWA renderer developed in the minor thesis is used. Since not all points are visible at the same time, the concept of level-of-detail hierarchies, more exactly the block-based multiresolution point hierarchies, is used. In order to render the point cloud, the hierarchy must be traversed. The CPU is relieved by the GPU during the representation of the hierarchy. Therefor the hierarchy is sequentialized, divided into large blocks, and sent to the GPU. The GPU takes on the fine-granular traverse and culling. However, additional memory is needed for the constructed hierarchy. But the point set and the hierarchy fit neither in the main memory nor into the video memory of the graphics card. Due to this both appropriate client-side and server-side out-of-core algorithms were developed and implemented. These work with well-known page replacement strategies and reload necessary parts of the hierarchy into the limited main or video memory. Thus an unrestricted interaction with the high-quality rendered point cloud becomes possible for the user.

1 Inhaltsverzeichnis Abbildungsverzeichnis 5 Tabellenverzeichnis 7 1 Einleitung 9 1.1 Motivation.......................................... 9 1.2 Rückblick.......................................... 11 1.2.1 LoD-Hierarchien für Punktwolken......................... 11 1.2.2 Out-of-Core-Ansätze................................ 18 1.2.3 Punktbasiertes Rendering.............................. 20 1.3 Überblick.......................................... 21 1.4 Gliederung......................................... 22 2 Level-of-Detail für Punkte 23 2.1 Diskretes Level-of-Detail.................................. 24 2.1.1 Level-of-Detail-Auswahl.............................. 25 2.1.1.1 Distanz.................................. 25 2.1.1.2 Fläche.................................. 25 2.2 Kontinuierliches Level-of-Detail.............................. 26 2.3 Hierarchisches Level-of-Detail............................... 27 2.3.1 Erweiterungen................................... 30 2.3.2 Sichtbarkeit..................................... 32 2.3.2.1 View Frustum Culling.......................... 33 2.3.2.2 Backface Culling............................ 34 2.3.2.3 Occlusion Culling............................ 35 2.3.2.4 Silhouetten-Erhaltung.......................... 36 2.3.3 Level-of-Detail-Auswahl.............................. 36 2.3.3.1 Objektraumfehler............................ 37 2.3.3.2 Bildraumfehler.............................. 39

2 2.3.3.3 Quantität................................. 41 2.3.4 Hierarchien..................................... 42 2.3.4.1 Kovarianz-Analyse........................... 43 2.3.4.2 Vereinfachung.............................. 43 2.3.4.3 Octree.................................. 48 2.3.4.4 kd-baum................................. 49 2.4 Sequentielles Level-of-Detail................................ 51 2.4.1 Sequentialisierung................................. 51 2.4.2 Blockbildung.................................... 55 2.4.3 Level-of-Detail-Auswahl.............................. 56 3 Out-of-Core für Punkte 59 3.1 Problemanalyse....................................... 59 3.2 Lösungsansätze....................................... 60 3.3 Einordnung......................................... 63 3.4 Parallel Disk Model..................................... 63 3.4.1 Parameter...................................... 63 3.4.2 Disk Striping.................................... 64 3.4.3 Load Balancing................................... 64 3.4.4 Komplexität..................................... 64 3.5 STXXL........................................... 65 3.5.1 Architektur..................................... 66 3.5.2 stxxl::vector..................................... 67 3.6 Out-of-Core in der Vorverarbeitung............................ 68 3.7 Out-of-Core zur Laufzeit.................................. 74 4 Kompression 79 4.1 Vektoren........................................... 80 4.2 Farbe............................................ 83 4.2.1 Uniforme Quantisierung.............................. 83 4.2.2 Adaptive Quantisierung.............................. 83 4.2.3 Octree-basierte Quantisierung........................... 84 4.3 Halbwinkel des Normalenkegels.............................. 86 4.4 Position und Radius..................................... 86 4.4.1 Deltakodierung................................... 86

3 4.4.2 Octree-basierte Kompression............................ 87 5 Implementierung 89 5.1 Mammoth.......................................... 89 5.1.1 Architektur..................................... 89 5.1.2 Benutzerschnittstelle................................ 90 5.1.3 Tools und Plug-ins................................. 91 5.1.4 Renderer...................................... 93 5.1.5 Datenstrukturen................................... 94 5.1.5.1 Octree.................................. 94 5.1.5.2 kd-baum................................. 96 5.1.6 Datenformate.................................... 98 5.2 Verarbeitungspipeline.................................... 98 5.2.1 Vorverarbeitung................................... 99 5.2.2 Rendering...................................... 104 5.3 Hardware- und Softwareanforderungen........................... 110 5.4 Probleme.......................................... 111 5.5 Verbesserungen....................................... 111 6 Ergebnisse und Bewertung 113 6.1 Modelle........................................... 113 6.2 Vorverarbeitung....................................... 115 6.2.1 Zeitkosten...................................... 115 6.2.2 Speicherkosten................................... 117 6.3 Rendering.......................................... 119 6.3.1 Zeitkosten...................................... 119 6.3.2 Geometrie-Cache-Manager............................. 120 6.3.3 Visibility Culling.................................. 120 6.3.4 Level-of-Detail-Auswahl.............................. 121 6.4 Bewertung.......................................... 121 7 Zusammenfassung und Ausblick 123 7.1 Zusammenfassung..................................... 123 7.2 Ausblick........................................... 124 Literaturverzeichnis 125

4

5 Abbildungsverzeichnis 1.1 The Digital Michelangelo Project.............................. 10 1.2 QSplat: A Multiresolution Point Rendering System for Large Meshes.......... 13 1.3 Sequential Point Trees................................... 15 1.4 Layered Point Clouds.................................... 16 1.5 Instant Points: Fast Rendering of Unprocessed Point Clouds............... 18 1.6 An Easy Viewer for Out-of-core Visualization of Huge Point-sampled Models...... 20 2.1 Knotenhierarchie...................................... 27 2.2 Front einer Hierarchie.................................... 29 2.3 Trennung von Struktur und Daten............................. 31 2.4 Speichern der Front..................................... 33 2.5 Visibility Culling 1..................................... 35 2.6 Visibility Culling 2..................................... 37 2.7 Orthogonaler Fehler..................................... 38 2.8 Tangentialer Fehler..................................... 39 2.9 Bildraumfehler....................................... 41 2.10 Vereinfachung........................................ 44 2.11 Mean-Operator....................................... 46 2.12 Proxy-Operator....................................... 47 2.13 Octree............................................ 48 2.14 kd-baum.......................................... 50 2.15 Sequentielles LoD...................................... 52 2.16 Schicht- und z-index.................................... 54 2.17 Morton Code........................................ 55 2.18 Blockbildung........................................ 56 2.19 Variierender Abstand und Worst-Case-Szenario für die Merge- und Split-Distanz.... 57 2.20 LoD-Auswahl für SLoD.................................. 58

6 3.1 Speicherhierarchie..................................... 60 3.2 Festplatte.......................................... 61 3.3 STXXL-Architektur..................................... 67 3.4 STXXL-Vektor....................................... 68 3.5 Stream-Processing..................................... 69 3.6 Hierarchie-Erzeugung.................................... 73 3.7 LRU-Cache......................................... 76 4.1 Vektorquantisierung..................................... 82 4.2 Farbquantisierung...................................... 85 4.3 Positionskompression.................................... 87 5.1 MAMMOTH-Architektur.................................. 90 5.2 MAMMOTH-Benutzerschnittstelle............................. 92 5.3 Unterteilungsregeln für den kd-baum........................... 97 5.4 MAMMOTH-Datenformat.................................. 99 5.5 Verarbeitungspipeline: Vorverarbeitung.......................... 100 5.6 Klassendiagramm für die Erzeugung der LoD-Hierarchie................. 101 5.7 Klassendiagramm für die Komprimierung......................... 103 5.8 Verarbeitungspipeline: Rendering............................. 105 5.9 Klassendiagramm für das Rendering............................ 106 5.10 Cache und Geometrie-Cache................................ 108 6.1 Render-Ergebnisse..................................... 114 6.2 Vergleich der Blockgrößen................................. 118 6.3 View Frustum Culling.................................... 120 6.4 Backface Culling...................................... 121 6.5 Level-of-Detail-Auswahl.................................. 122

7 Tabellenverzeichnis 3.1 Komplexitätsschranken................................... 65 6.1 Testmodelle......................................... 115 6.2 Zeitkosten.......................................... 116 6.3 Speicherkosten....................................... 117 6.4 Performanz......................................... 119

8

9 1 Einleitung Im Folgenden soll das Thema des Darstellens von extrem großen Punktwolken motiviert werden. Dazu ist es notwendig einzelne Begriffe näher zu definieren und verwandte Arbeiten auf diesem Gebiet zusammenzufassen. Der Überblick soll einen kleinen Einblick in die Pipeline bzw. den Algorithmus zur Darstellung großer Punktwolken geben. Anschließend soll eine Gliederung auf die nächsten Kapitel vorbereiten. 1.1 Motivation Punktbasierte Geometrien werden aufgrund von 3d-Range- und Laser-Scanner immer populärer. Heutige Scanner erreichen eine Abtastdichte von weniger als 1 mm. Die dabei entstehenden Punktwolken sind extrem groß und detailliert. Um aus diesen großen eingescannten Punktwolken durch Nachbearbeitung ein polygonales Netz zu rekonstruieren, müssen mehrere Monate eingeplant werden. Der Grund liegt in der Form, in der die Daten vorliegen: Speziell durch Long-Range-Scanner in der Außenumgebung aufgenommene Punktwolken sind durch Löcher und unterschiedliche Abtastdichten charakterisiert. Das heißt, auf eine langwierige und zeitaufwändige Rekonstruktion kann nicht verzichtet werden. Jedoch steht die Bedingung, diese großen Punktwolken interaktiv und sofort zu erforschen, in ihnen zu navigieren und mit ihnen zu interagieren. Das betrifft vor allem die Gebiete CAD, Archäologie, Architektur und Computergrafik. Als Beispiel sei hier das Digital-Michelangelo-Projekt [Lev97] genannt. In diesem wurden mehrere Statuen und Büsten des Künstlers Michelangelo per Laser-Scanner eingescannt und gespeichert (s. Abb. 1.1). Dabei entstanden bei einer Abtastdichte von bis zu 0, 125 mm, Datenvolumen von mehreren Terabyte. Michelangelos David mit einer Höhe von 10 Metern, erreichte ein Datenvolumen von 32 Gigabyte. Das zweite und letzte Beispiel betrifft das flugzeuggestützte Laser-Scanning (LiDAR oder ALS) [Bür08], bei dem die Erdoberfläche mit Gebäuden und Vegetation gescannt werden kann. Die Abtastdichte beträgt dabei ein Punkt pro m 2. Eine Abtastung wurde auch über den Campus der Technischen Universität Dresden durchgeführt. Es entstand ein Datenvolumen von ca. 2 Gigabyte. Aufgrund dieser Datenvolumen wurde das Rendersystem Mammoth entwickelt, dass ohne Nachbearbei-

10 1. EINLEITUNG Abbildung 1.1: Das Digital-Michelangelo-Projekt: Die Digitalisierung von Michelangelos David-Statue mit einem 3D-Laser-Scanner dauerte 4 Wochen [Lev97]. tung und minimaler Vorverarbeitung extrem große Punktwolken mit interaktiven Frameraten darstellen kann. Kombiniert mit dem EWA-Rendering entsteht so ein hochqualitatives und interaktives Renderingsystem. Dabei wird die GPU in allen Teilbereichen zur Entlastung der CPU verwendet. Für weitere Information zum EWA-Splatting soll die vorangegangene Belegarbeit [Kop08] genannt werden. Das Rendersystem muss einige wichtige Kriterien befolgen. Diese sollen im folgenden genauer erklärt werden: Speichereffizienz. Effizienz ist die optimale Ausnutzung der zur Verfügung stehenden Ressourcen. Eine erhöhte Effizienz kann zum einen bedeuten, dass mehr Primitive pro Frame angezeigt werden. Oder dass weniger Speicher für gleich bleibende Qualität benötigt wird, was gleichbedeutend mit Speichereffizienz ist. Out-of-Core. Out-of-Core bezieht sich auf die Speicherung der Punktwolke bzw. dessen Hierarchie. Die Speicherung erfolgt namentlich out-of-core, also nicht im Hauptspeicher, sondern im sekundären Speicher wie die Festplatte. Um effizient auf sekundäre Speichermedien zugreifen zu können, müssen entsprechend angepasste Algorithmen entwickelt werden. Der Vorteil ist, dass die Größe der Punktwolke nur noch durch die Festplattenkapazität und nicht mehr durch den virtuellen Speicher des Betriebssystem begrenzt wird.

1.2. RÜCKBLICK 11 Level-of-Detail-Hierarchie. Eine Level-of-Detail-Hierarchie ist eine Multiresolution-Hierarchie. Also eine hierarchische Struktur deren Level unterschiedliche Detailstufen oder Auflösungen der Punktwolke darstellen. Der Detailgrad steigt von der Wurzel zu den Blättern an. Qualität. Eine hochqualitative Darstellung meint hier ein Rendering nach EWA-Splatting. Das heißt, das finale Bild im Framebuffer der Grafikkarte enthält keine Löcher mehr, und die Beleuchtung wird pro Pixel berechnet. Zusätzliche sollen keine Aliasing-Artefakte zu sehen sein. Interaktivität. Neben der Qualität das wichtigste Merkmal des Rendersystems. Es soll mit Hilfe der LoD-Hierarchie und den Out-of-Core-Algorithmen möglich sein, hohe Frameraten zu erreichen, damit der Nutzer reibungsfrei in der Punktwolke navigieren kann. Punktbasierte Geometrien. Es soll angenommen werden, dass die Punktwolke so betrachtet wird, wie sie aus dem Scanner kommt. Das heißt, die Punkte bestehen lediglich aus der Position im R 3 und der diffusen Farbe im RGB-Farbraum. Zur späteren Darstellung der Punktwolke, werden die einzelnen Punkte zu so genannten elliptischen Splats: Punkte mit einer konzentrisch, räumlichen Ausdehnung. Dazu sind die Normale und der dazugehörige Tangentialraum zu berechnen. Die Menge der Splats bedeckt dann die zu approximierende Oberfläche vollständig. 1.2 Rückblick In diesem Abschnitt sollen die verwandten Arbeiten zu diesem Thema vorgestellt werden. Wo beim Out-of-Core-Rendern von polygonalen Netzen schon sehr viele Arbeiten entstanden sind, sind es beim punktbasierten Rendering nur sehr wenige. Der Grund ist natürlich bei der hohen Akzeptanz und Beliebtheit der Polygone als Renderprimitive zu finden. Das PBR wurde erst 1985 durch die Arbeit von [LW85] als echte Alternative bekannt, wobei das Polygon schon viel eher als Primitive entdeckt wurde. Zudem ist die aktuelle Grafikhardware eher auf Polygone optimiert und spezialisiert als auf Punkte. 1.2.1 LoD-Hierarchien für Punktwolken Die meisten PBR-Verfahren nutzen hierarchische Raumunterteilungsstrukturen, um eine Punktwolke in mehreren Auflösungen zu repräsentieren (Multiresolution). Die am meisten verwendeten Strukturen sind Octrees [BWK02, Paj03]. Weitere beliebte LoD-Hierarchien sind die Bounding-Volume-Hierachien [RL00] und kd-bäume. QSplat: A Multiresolution Point Rendering System for Large Meshes: Als erste wegweisende Arbeit für das Rendern von sehr großen Punktwolken ist sicherlich QSplat [RL00] aus dem Jahre 2000 zu nennen.

12 1. EINLEITUNG Es wurde entwickelt, um die extrem großen Punktwolken aus dem Digital-Michelangelo-Projekt direkt und ohne Umwege darzustellen. Dazu wird für das Visibility Culling, die Level-of-Detail-Kontrolle und das Rendering eine Bounding-Sphere-Hierarchie verwendet. Diese Hierarchie besteht aus Knoten mit Splatzentrum und -radius, Normale, Normalenkegel und Farbe. Um die Normalen- und Radienbestimmung einfacher zu gestalten, wird die LoD-Hierarchie aus einem Dreiecksnetz in einem Vorverarbeitungsschritt top-down generiert und auf Festplatte gespeichert. Die Traversierungstiefe beim Rendern der Punktwolke ist dabei abhängig von der projizierten Größe des Splats in den Bildraum (s. Abb. 1.2) und von einer benutzerbestimmten Framerate. Eine Quantisierung der Splatparameter macht das QSplat-Rendersystem speichereffizienter. Dabei werden die Position und der Radius mit 13 Bits, die Normale mit 14 Bits und die Farbe mit 16 Bits quantisiert. Die Knoten der Hierarchie liegen nach der Vorverarbeitung in breadth-first Reihenfolge auf der Festplatte. Das gesamte Modell wird dann per Memory Mapped File in den virtuellen Speicher geladen. Von dort an übernimmt das Betriebssystem das Cachen der Daten. Während des Renderns wird die geladene Hierarchie progressiv verfeinert, bis eine bestimmte Fehlerschranke unterschritten oder die gewünschte Framerate erreicht ist. Ein großer Nachteil beim QSplat-System ist die Abhängigkeit vom virtuell zur Verfügung stehenden Speicher: die LoD-Hierachie wird im Hauptspeicher aufgebaut. Das heißt, es wird ein mit 64 Bits adressierbarer virtueller Speicher benötigt, um extrem große Punktwolken vorzuverarbeiten und darzustellen. Das Ziel dieser Arbeit ist aber das Rendern von großen Punktwolken auf normalen Verbraucher-PCs. Zwar wird durch die Quantisierung der LoD-Hierarchie nur noch 1 10 des Speicherplatzes benötigt. Es kann jedoch trotzdem vorkommen, dass diese nicht in den virtuellen Speicher des Betriebssystems passt, wenn die Punktwolke mehrere Terabytes Speicherplatz benötigt. Der zweite Nachteil von QSplat ist, dass die gesamten Berechnungen von der CPU durchgeführt werden und die GPU ungenutzt bleibt. Da heutige GPUs die Komplexität von modernen CPUs in Hinsicht auf absolute Transistoranzahl übertreffen (Intel Core 2 Extreme QX6700 besteht aus 582 Millionen Transistoren, nvidia 8800 GTX aus 680 Millionen Transistoren) wäre hier eine Verbesserung möglich. Efficient High Quality Rendering of Point Sampled Geometry: Die Hauptkomponenten in [BWK02] sind eine Quantisierung und ein Octree, der einfache Verarbeitung verspricht. Um eine gleichmäßige Abtastung k zu erhalten, wird in der genannten Arbeit ein uniformes Clustering, ausgehend von einem Hüllwürfel der Punktwolke, ausgeführt. Diese äquidistante Abtastung verhindert Quantisierungsartefakte, soll aber in dieser Arbeit keine Rolle spielen, da sie zu zeitaufwändig ist. Das dabei entstandene k x k x k große Voxelgitter wird durch rekursives Zusammenfassen von 8 Voxel zu einem Elternknoten zu einem Octree umgeformt. Verworfene Informationen, die durch die Vergröberungschritte entstehen,

1.2. RÜCKBLICK 13 Abbildung 1.2: Das Modell von Michelangelos St. Matthew gerendert durch QSplat mit verschiedenen Level-of-Details [RL00]: 15 Pixel Bildraumfehler und 130.712 Punkten (oben) und 1 Pixel Bildraumfehler und 14.835.967 Punkten (unten). werden durch einen so genannten Bytecode gespeichert. Die ursprüngliche Punktwolke kann durch Traversierung und Dekodierung des Bytekodes wieder rekonstruiert werden. Das Voxelzentrum bzw. die Splatposition kann dann aus dem Hüllwürfel und dem Voxelabstand bestimmt werden. Oder schon beim Traversieren des Baumes, durch Hinzufügen der entsprechenden Werte beim Absteigen: 1. Stufe +0.5, 2. Stufe +0.25, usw. Schließlich benötigt man nur noch 2, 67 Bits pro Punkt. Die Quantisierung der Normalen basiert auf den Flächennormalen eines regelmäßig unterteilten Oktaeders, eingebettet in der Einheitskugel. Die Normalen werden bei mittlerer Quantisierung mit 18 Bits quantisiert. Eine weitere Speichereffizienz kann durch Vorberechnung der Normalen und Speichern in einer Lookup-Tabelle anstatt in den Splats erreicht werden. Efficient Level-of-Details for Point Based Rendering: Ziel dieser Arbeit [Paj03] war die effiziente Verarbeitung von großen Punktwolken. Es sollte trotz Bildraumfehler und Darstellung eines Bruchteils der Punkte eine extrem hohe visuelle Qualität erreicht werden. Die genutzte adaptive Octree-Hierarchie besteht aus Knoten c mit k Punkten und Repräsentanten. Die Repräsentanten (auch Proxys genannt) setzen

14 1. EINLEITUNG sich aus der mittleren Position, Normale und Farbe zusammen. Zusätzlich wird zu jedem Knoten der Kugelradius und Normalenkegel gespeichert. Insgesamt werden so 46 Bytes pro Punkt benötigt. Der Octree wird rekursiv und top-down durch regelmäßige Unterteilung des Wurzelknotens in 8 Kindknoten erzeugt. Die Octree-Struktur wird getrennt von den Knotendaten gespeichert. Die Struktur passt so immer in den Hauptspeicher und braucht nicht nachgeladen werden. Um weiter Speicher zu sparen, werden wie in [BWK02] die Normalen durch eine Oktaeder-Unterteilung und einer Look-up-Tabelle quantisiert. Um das Rendern so schnell wie möglich zu gestalten, werden nicht sichtbare Teile der Punktwolke durch Backface und Frustum Culling verworfen. Der aktuelle Knoten wird gerendert, wenn dessen projizierte Fläche kleiner als eine Fehlerschranke ε ist. Natürlich ist das einfache, aber flexible Datenformat nicht so speichereffizient wie in [RL00]. Sequential Point Trees: Die sequentielle Punkthierarchie [DVS03] ist eine Datenstruktur für adaptives Darstellen von Punktwolken auf der GPU. Sie basiert auf einer hierarchischen Punktwolke, die sequentiell auf der GPU verarbeitet wird. Dabei ist die CPU frei für andere Aufgaben (s. Abb. 1.3). Das heißt, die GPU kümmert sich um beides: die Darstellung und die LoD-Auswahl. Das Prinzip hinter dem SPT ist die Überführung einer Punktwolken-Hierarchie in eine sequentielle Liste, so dass die zum Rendern benötigten Punkte nah beieinander liegen (Clustering). Die CPU berechnet die Segmentgrenzen und sequentialisiert die Hierarchie. Die GPU verarbeitet die Segmente/Cluster sequentiell, indem sie sichtbare Punkte auswählt und rendert. Die Auswahl der sichtbaren Punkte passiert nicht wie beim rekursiven Traversieren auf eine Tiefensuche. Sondern auf einen Intervall-Test. Da die GPU die Punkte parallel verarbeitet, kann nun auch die Traversierung parallel und damit viel schneller ablaufen. Zwei Hindernisse haben die SPTs dennoch. Erstens ist kein hierarchisches Visibility Culling vor der GPU-Verarbeitung möglich, da keine Hierarchie-Informationen mehr vorhanden sind. Zweitens muss das sequentialisierte Modell in den Videospeicher der Grafikkarte passen. Die Arbeit stellt auch eine neue Fehlermetrik vor: den geometrischen Fehler, der besonders an Silhouetten und Kanten tiefer traversiert und damit sehr gute Ergebnisse beim Rendern erzielt. Layered Point Clouds: Die Layered Point Clouds [GM04] basieren auf einer Hierarchie aus mehreren vorberechneten Punktwolken im Objektraum. Bei der Darstellung werden die Punktwolken durch eine Top-Down-Traversierung von grob nach fein kombiniert, um die Abtastdichte entsprechend der projizierten Größe im Bild lokal anzupassen. In der Traversierung kommt es zu einer progressiven, blockbasierten Verfeinerung. Es werden Backface, View Frustum und zusätzlich Occlusion Culling unterstützt. In der Publikation wird die Annahme gemacht, dass der Abtastabstand zwischen den Punkten ungefähr gleich ist. Um die Hierarchie aufzubauen, wird die gegebene Punktwolke in Punktwolken mit ungefähr gleicher

1.2. RÜCKBLICK 15 Abbildung 1.3: Sequential Point Trees: Kontinuierliche LoDs der Buddha-Statue generiert durch ein Vertex-Shader auf der GPU [DVS03]. Die Balken beschreiben die Menge der Punkte, die gerendert werden (oben) und die mittlere CPU-Last beim Rendern (unten). Größe geclustert. Diese neuen Punktwolken werden anschließend in einem Binärbaum gespeichert. Die entstehende Hierarchie ist sehr speichereffizient, da die Anzahl der Punkte in der Hierarchie gleichgroß wie die in der ursprünglichen Punktwolke ist. Mit einem Absteigen in der Hierarchie wird auch der Abtastabstand immer kleiner. Man erhält also Punktwolken in unterschiedlicher Auflösung. Die Hierarchie wird dann durch eine Akkumulation aller Punktwolken (s. Abb. 1.4) von der Wurzel bis zu einer bestimmten Hierarchieebene, d. h. bis die gewünschte Dichte erreicht wird, gerendert. Die Verfeinerung beim Rendern passiert progressiv und sichtpunktabhängig. Die Hierarchie wird außerdem noch aufgeteilt. Sie besteht aus einem Index-Baum und einem Punktwolken-Repository. Der Index-Baum beinhaltet die zum Rendern benötigten Daten pro Knoten und referenziert jeden Knoten der Hierarchie durch einen 32-Bit-Index. Der 32-Bit-Index adressiert eindeutig eine Punktwolke im Repository. Das Repository ist wiederum von grob nach fein strukturiert. Zusätzlich wird eine Komprimierung der Punktwolken vorgenommen, um Platz- und Transferkosten zu sparen. Es wird außerdem die Grafikkarte genutzt, um die Punktwolken in Vertexbuffer Objects mit einer LRU-Caching-Strategie zu speichern und so den Busverkehr zu reduzieren. Out-of-Core-Datenzugriffe werden durch asynchrone Zugriffe verdeckt. Die Arbeit verwendet ebenfalls Memory Mapped Files, um das Caching dem Betriebssystem zu überlassen. Ein weiteres oft genutztes Feature zum schnellen Rendern von LoD-Hierarchien sind die Prioritätswarteschlangen. In der Arbeit wird eine Warteschlange nach dem Knoten-Index geordnet, sodass relevante Daten zuerst geladen werden. Zwar wird die Vorverarbeitung (Erstellung der Datenstruktur) out-of-core betrieben, jedoch muss zum Rendern die komprimierte Datenstruktur in den Hauptspeicher bzw. Videospeicher passen. Instant Points: Fast Rendering of Unprocessed Point Clouds: In [WS06] werden nur unverarbeitete Punktwolken und deren direkte Visualisierung betrachtet. Dabei bedeutet eine unverarbeitete Punktwolke, dass keine Interpretation der Daten (Normalenschätzen, Nachbarschaftsbeziehungen,...) durchge-

16 1. EINLEITUNG (a) (b) (c) Abbildung 1.4: Layered Point Clouds der David-Statue in verschiedenen Auflösungen [GM04]. Das Original-Modell besteht aus 28 Millionen Punkten. Das Bild demonstriert, wie gröbere Auflösungen durch Cluster mit feiner Auflösung erweitert werden. (a) Level 0, 2 Cluster, 4K Punkte; (b) Level 0 + 1, 6 Cluster, 12K Punkte; (c) 1 Pixel Toleranz, 1.720 Cluster, 3.435K Punkte. führt wird. Es zählen ganz allein die Position und Farbe eines Punktes in der Punktwolke. Es existieren zudem keine Annahmen über die Abtastrate oder Punktnormalen. Der Fokus liegt voll und ganz auf schnelle, interaktive und ohne Vor- und Nachbearbeitung auskommende Visualisierung von Punktwolken. Die Qualität des Renderns soll vernachlässigt werden. Die Out-of-Core-Datenstruktur basiert auf verschachtelten Octrees und Sequential Point Trees (SPT). In der Arbeit wird eine spezielle Art der SPTs vorgeschlagen. Diese so genannten Memory Optimized SPT sind, wie der Name vermuten lässt, speichereffizienter. Dabei wird der Overhead durch die inneren Knoten des SPTs vermieden. Das heißt, die inneren Knoten (Proxy oder Mean genannt) werden durch Repräsentanten aus der Punktwolke, die dem entsprechenden Mean am nächsten sind, ersetzt. Dadurch entstehen keine neuen Daten. Es werden eben nur vorhandene Punktdaten verwendet und gespeichert. Motiviert wird dieser Sachverhalt, durch die Existenz einer Schnittmenge für Eltern- und dessen Kindknoten von mindestens einem Pixel. Schlussendlich entspricht die Anzahl der Knoten in MOSPT gleich der Anzahl der Punkte in der Punktwolke. Für die Erzeugung des MOSPT wird ein Octree mit benutzerdefinierter, maximaler Rekursionstiefe genutzt. Zuerst wird ein Octree mit leeren inneren Knoten generiert. Die Eingabepunkte werden durch eine

1.2. RÜCKBLICK 17 Top-Down-Verteilung auf die leeren inneren Knoten verteilt. In der zweiten Phase findet eine Bottom- Up-Suche von Repräsentanten durch Miteinbeziehen der Farbinformation statt. Dazu werden die Kindknoten eines inneren Knotens gemittelt, wobei ein neuer Repräsentant entsteht. Zuletzt werden die Knoten sortiert und sequentialisiert. Da durch die Sequentialisierung die Hierarchie-Informationen verloren gehen, kann kein hierarchisches View Frustum Culling mehr ausgeführt werden. Die Lösung hier ist eine Kombination von MOSPTs und Octrees zu so genannten verschachtelten Octrees. Der äußerer Octree übernimmt das View Frustum Culling und Out-of-Core-Rendering mit inkrementeller Verfeinerung. Die inneren Octrees sind MOSPTs und für das effiziente Rendering zuständig. Die inneren Octrees können sich dabei im Raum überlappen. Beim Verfeinern eines Levels im äußeren Octree wird ein neues Level von Punkten zur aktuellen Repräsentation hinzugefügt. Ein Knoten des äußeren Octrees beinhaltet danach einen inneren Knoten, welcher wiederum die Punkte der Eingabepunktwolke beinhaltet. Im Gegensatz zu den Layered Pointclouds muss kein gleichmäßiger Abtastabstand vorliegen. Der verschachtelte Octree entsteht durch rekursive Erstellung des äußeren und der inneren Octrees. Die inneren Octrees werden auf Festplatte gespeichert. Der äußerer Octree besteht aus Knoten, die den Dateinamen des assoziierten MOSPT speichern. Beim Rendering wird der komplette äußere Octree in den Hauptspeicher geladen und mit Hilfe einer Prioritätswarteschlange traversiert. Die Warteschlange ist nach Größe der projizierten Hüllquader geordnet. Nachdem die Prioritätswarteschlange traversiert wurde, wird die Renderwarteschlange traversiert, und die enthaltenen Knoten werden gezeichnet. Falls der zu rendernde MOSPT nicht im Videospeicher der Grafikkarte vorhanden ist, findet ein asynchroner Out-of-Core-Aufruf statt, sodass das Rendering nicht unterbrochen wird. Die für die Traversierung wichtige Fehlermetrik ist hier nur noch vom Durchmesser der Punkte abhängig. Das bedeutet, die Punkte werden gezeichnet, wenn die projizierte Punktgröße kleiner gleich ein Pixel ist. Da die Knoten im selben Hierarchie-Level den gleichen Durchmesser haben, ist auch die Merge- und Splitdistanz pro Hierarchie-Level gleich. Das ermöglicht das effiziente Speichern der Parameter pro Hierarchie-Level in einer Look-Up-Tabelle. Als Nachteil dieser Arbeit stellt sich die große Anzahl an MOSPT-Dateien heraus. Das bedeutet vor allem viele Lesezugriffe auf die Festplatte. Zudem kann kein Backface Culling durchgeführt werden, da keine Normalen vorhanden sind. Die Qualität des Renderns stand von vornherein nicht im Mittelpunkt. Das ist der Nutzung der Repräsentanten anstatt der Means zuzuschreiben. So kommt es leicht zu Farbverfälschungen (s. Abb. 1.5).

18 1. EINLEITUNG (a) (b) (c) Abbildung 1.5: Qualitätsvergleich von SPT (a) und MOSPT (b) Rendering [WS06]. Die Farben für den SPT sind durch Mittelung entstanden, die für den MOSPT durch Auswahl einer repräsentativen Farbe der Kindknoten. Das Differenzbild (c) zeigt die Farbunterschiede. 1.2.2 Out-of-Core-Ansätze Für polygonale Netze gibt es eine große Anzahl von Out-of-Core-Algorithmen, die den externen Speicher verwalten [DP02, VM02, Lin03]. Ursprünglich wurden diese für das Terrain-Rendering [Hop98] und für Walkthrough-Systeme entwickelt [CKS02]. Für Punktwolken gibt es nur wenige Publikationen. An Easy Viewer for Out-of-core Visualization of Huge Point-sampled Models: Die Arbeit von [MZ04] hat sich auf die Visualisierung von sehr großen Punktwolken durch Kombination von Out-of-Core-Techniken und blickpunktabhängige LoD-Hierarchie-Kontrolle konzentriert. Hierfür wird eine partitionsbasierte Out-of-Core-Strategie genutzt, die eine ausbalancierte Nutzung von Hauptspeicher und externen Speicher gewährleistet. Das vorgestellte System ist auf handelsüblichen PCs ausführbar. Es gilt jedoch die Annahme, dass dicht und gleichmäßig abgetastete Punktwolken als Eingabe zur Verfügung stehen. Zuallererst muss durch eine Segmentierung, die Punktwolke in kleine Blöcke gleicher Größe zerlegt werden. Dazu wird der Hüllquader der Punktwolke entlang der längsten Achse rekursiv unterteilt, bis sich eine bestimmte Anzahl von Punkten pro Block befindet. Somit kann der nächste Schritt pro Block im Hauptspeicher durchgeführt werden. Dieser nächste Schritt umfasst das hierarchische Clustering und die LoD-Organisation pro Block, um fehlerkontrollierte LoDs zu erstellen. Jedes Cluster wird solange gesplittet, bis nur noch ein Punkt in einem Cluster vorhanden ist. Aus den resultierenden Clustern entsteht ein Binärbaum mit der entsprechenden gefitteten Ebene der Punkte des Clusters als Knoten. Die Fehlerabschätzung setzt sich danach aus dem Abstand der Punkte zur Fitting Plane und aus der Differenz der Normalen der Fitting Plane zu den Normalen der Punkte zusammen. Die Level-of-Details werden pro Binärbaum entsprechend ihrer Fehlerabschätzung organisiert. Dazu

1.2. RÜCKBLICK 19 werden sie in drei Teile partitioniert. Die erste Partition, der oberste Teil der Hierarchie, wird verworfen. Die zweite Partition, der Mittelteil der Hierarchie, wird in den Hauptspeicher geladen. Und die dritte Partition wird auf die Festplatte ausgelagert. Der Mittelteil ist fundamental für eine schnelle Visualisierung. Er erhält die grobe Form des Modells und stellt somit eine vereinfachte Version des Originalmodells dar. Zusätzlich wird er für eine spätere Suche nach Daten als Index genutzt. Für das Rendern wird eine blickpunktabhängige LoD-Auswahl durchgeführt. Dazu definiert man eine foveale Region (s. Abb. 1.6). Diese Region besteht aus einem fovealen Punkt, einer räumlichen Ausdehnung und aus einer Auflösungsfunktion, die für einen weichen Übergang zwischen den LoDs sorgt. Am fovealen Punkt wird die höchste Auflösung erreicht, und zur Peripherie nimmt die Auflösung kontinuierlich ab. Mit Hilfe der fovealen Region werden Knoten aus der dritten Partition genutzt, um Details darzustellen. Um die Auswahl zu beschleunigen verwendet man Lookup- und Index-Tabellen. Da nur eine begrenzte Hauptspeicherkapazität zur Verfügung steht, kommt ein blickpunktabhängiger Paging-Algorithmus zum Einsatz. Dieser basiert auf der Distanz vom Blickpunkt zur Hüllquader der verfügbaren Blöcke und auf einer LRU-Strategie. Der Paging-Algorithmus sorgt für die LoD-Auswahl und selektiert dafür LoDs aus dem Hauptspeicher und externen Speicher. Die Auswahl variiert mit dem Blickpunkt des Betrachters. XSplat: External Memory Multiresolution Point Visualization: In [PSL05] steht die Behandlung von Punktwolken, größer als der vorhandene Haupt- bzw. Grafikkartenspeicher, im Vordergrund. Dazu wird eine blockbasierte, sequentielle Multiresolution-Hierarchie und virtuelles Speicher-Mapping verwendet. Ein dynamisches Mapping in den Grafikkartenspeicher sorgt für einen nahtlosen Übergang zwischen Festplatten-, Haupt- und Grafikkartenspeicher. Damit wird eine hochqualitative und interaktive Darstellung von extrem großen Punktwolken im externen Speicher erreicht. Der Ausgangspunkt ist die Konvertierung einer konventionellen LoD-Hierarchie in eine sequentielle Out-of-Core-LoD-Datenstruktur. Voraussetzung ist nur, dass die Knoten der Ausgangsstruktur aus Radius, Farbe, Position und Normale bestehen. Die LoD-Auswahl ist abhängig von der Fläche der Punkte im Bildraum und der Entfernung zum Augpunkt. Das entspricht dem klassischen Bildraumfehler. Die Sequentialisierung entspricht der in [DVS03] beschriebenen, außer dass durch zusätzliche Indizes die hierarchischen Informationen erhalten bleiben. Eine Behandlung der einzelnen Punkte der Punktwolke würde die CPU und die Verbindung zwischen CPU und GPU überlasten. Durch eine Kachelung werden deswegen mehrere Punkte zu einem Block zusammengefasst. Die LoD-Auswahl und Punktreduktion wird auf Basis der gebildeten Blöcke durchgeführt. Die grobe blockbasierte LoD-Auswahl und das Visibility Culling benötigen wenig Zeit, da weniger Daten zur GPU transferiert werden müssen. Eine blockweise Verarbeitung reduziert außerdem die

20 1. EINLEITUNG (a) (c) (b) (d) Abbildung 1.6: Verschiedene Teile des Yungang-Grotto-Modells visualisert durch das in [MZ04] vorgestellten Verfahren. Das grobe Modell (a) ist eine vereinfachte Version des Originalmodells. Durch Bewegung der fovealen Region entstehen unterschiedliche LoDs in (b), (c) und (d). CPU-Kosten, im Vergleich zur Top-Down-Traversierung einer LoD-Hierarchie auf per-pixel-basis. Eine blockbasierte Verarbeitung erreicht so eine bessere CPU-/GPU-Auslastung: die CPU für grobe Arbeiten, die GPU für feine, diffizile Arbeiten. Es findet zudem keine Behinderung der CPU und keine Überflutung des GPU-Bus mit nicht brauchbaren (weil nicht gerenderten) Punkten statt. Da Blöcke als kleinste Einheit des Speichers betrachtet werden, kommt es zu keiner großen Fragmentierung des Speichers. Alle Vorverarbeitungsschritte und Dateizugriffe werden durch Memory Mapped Files umgesetzt. Zusätzlich kann ein Geometry Cache Manager genutzt werden, der Blöcke im Videospeicher zwischenlagert. 1.2.3 Punktbasiertes Rendering In [Kop08] existiert eine guter Überblick über die Arbeiten, die sich mit punktbasierten Rendering beschäftigen. In den letzten Jahren wurden auch Weiterentwicklungen, der in [Kop08] aufgeführten Arbeiten veröffentlicht. Zum Beispiel wurde die Arbeit in [BHZK05] um bessere Approximation an den EWA-Filter und transparenten Splats [GBP06] erweitert. In [ZP07] wird der erste GPU-beschleunigte

1.3. ÜBERBLICK 21 PBR-Algorithmus vorgestellt, der nur einen einzigen Durchlauf über die Punktwolke benötigt. Der Fokus dieser Arbeit soll jedoch mehr auf das out-of-core Erstellen von Punkthierarchien und das Out-of- Core-Rendering dieser liegen. 1.3 Überblick Bis heute sind im Vergleich zu polygonalen Netzen nur sehr wenige Arbeiten über das Darstellen von extrem großen Punktwolken erschienen. In den letzten Jahren hat sich dieser Trend jedoch gewandelt. Punktwolken haben nämlich den enormen Vorteil, dass sie keine Topologie- und Nachbarschaftsinformationen speichern. Diese Arbeit will die wichtigsten Publikationen über das Out-of-Core-Rendering von Punktwolken zusammenfassen, erweitern und deren Vorteile in ein Rendering-System für große Punktwolken vereinen. Das System durchläuft grob zwei Phasen: In der Vorverarbeitung wird die LoD-Hierarchie aufgebaut, in der zweiten Phase, dem Rendering, wird die Punktwolke mit Hilfe der Hierarchie gerendert. Wird die Hierarchie auf der Festplatte gespeichert, kann die erste Phase übersprungen werden. Das System arbeitet die folgenden Schritte ab, um eine extrem große Punktwolke interaktiv und hochqualitativ darzustellen: In einem Vorverarbeitungsschritt wird eine LoD-Hierarchie out-of-core aufgebaut. Benötigt werden dafür pro Punkt Position, Normale, Tangente, Binormale und Radius. Diese wiederum können z. B. durch ein Streaming-Prozess [Paj05] aus der Punktwolke generiert werden. Die LoD-Hierarchie wird für eine optimale Nutzung der GPU sequentialisiert. Die Sequentialisierung ist nicht levelabhängig sondern schichtabhängig. Das garantiert eine bessere räumliche Kohärenz. Eine Blockbildung über die sequentialisierte Hierarchie führt zu einer Granularisierung und besseren CPU-GPU-Auslastung. Die CPU arbeitet auf Blockbasis, die GPU auf Punkt- bzw. Surfelbasis. Um das Rendering zu beschleunigen, wird ein Geometry Cache Manager eingeführt. Dieser speichert Blöcke im Videospeicher der Grafikkarte, damit die GPU ohne Umwege auf die Daten zugreifen kann. Auf der GPU selbst finden dann auch die LoD-Auswahl und das Visibility Culling statt. Durch die parallele Architektur der GPU können diese Aktionen simultan pro Punkt durchgeführt werden.

22 1. EINLEITUNG 1.4 Gliederung Die vorliegende Arbeit ist wie folgt gegliedert: Kapitel 2 gibt einen Überblick über die existierenden LoD-Verfahren, -Fehlermetriken und -Hierarchien für Punktwolken. Die in der Implementation verwendeten Hierarchien werden genauer erklärt. Kapitel 3 gibt einen Überblick über die vorhandenen Out-of-Core-Verfahren im Allgemeinen und für Punktwolken. Diese können in clientseitige (Hauptspeicher) und serverseitige (Videospeicher) Verfahren gegliedert werden. Kapitel 4 gibt einen Überblick über die Quantisierungs- und Kodierungsverfahren für Punktwolken, um den Speicheraufwand für Punktwolken und die Transferraten zu reduzieren. Kapitel 5 beschreibt die Implementierung der in den o. g. Kapiteln aufgezeigten Pipeline bzw. Algorithmen und der dabei aufgetretenen Probleme. Kapitel 6 zeigt die performanztechnischen und qualitativen Ergebnisse der Implementation, vergleicht und bewertet diese. Kapitel 7 schließlich fasst die gesamte Pipeline und deren Algorithmen zusammen und gibt einen Ausblick auf mögliche Erweiterungen des Themas in der Zukunft.

23 2 Level-of-Detail für Punkte Da in dieser Arbeit das punktbasierte Rendering betrachtet wird, soll auch nur eine spezielle Art des Levels-of-Detail herangezogen werden: die Levels-of-Detail für Punkte. Dabei ist unter einem Punkt folgendes zu verstehen: Definition 2.1 (Punkt) Ein Punkt p ist definiert durch eine Position p = (x, y, z) und optional durch andere Attribute, wie z. B. eine Farbe... c = (r, g, b). Er hat eine Ausbreitung von mindestens einem Pixel auf dem Bildschirm, wenn er von der aktuellen Kameraposition sichtbar ist. Für die spätere hochqualitative Darstellung wird aus einem Punkt ein Surfel. Die Gesamtheit der Surfels bedeckt dann die Objektoberfläche lochfrei. Ein Surfel ist nach [PZBG00] wie folgt definiert: Definition 2.2 (Surfel) Ein Surfel s ist ein 0-dimensionales n-tupel mit Form- und Beleuchtungsattributen, das eine Objektoberfläche lokal approximiert. Ein interaktives Darstellen von 3d-Modellen ist in vielen Bereichen extrem wichtig. Wie z. B. bei Walkthrough-Systemen für Archäologen und Architekten, in der Spieleindustrie und Computergrafik, bis hin zur wissenschaftlichen Visualisierung. Dafür sind jedoch effektive Visualisierungstechniken von Nöten, die die Menge der zu verarbeitenden Punkte reduzieren. Zwei der am meist genutzten Verfahren, die diese Aufgabe erfüllen, sind Level-of-Details (kurz LoD) und das Visibility Culling. Beide werden in diesem Kapitel näher erläutert. Die Levels-of-Detail bieten einen Weg, komplexe Szenen zu verwalten. Mit ihnen ist es möglich, die Rendergeschwindigkeit so zu kontrollieren, dass Interaktivität garantiert ist. Definiert sind Levels-of-Detail als unterschiedliche Detailstufen eines Modells. Das heißt, zum Originalmodell werden zusätzliche Detailstufen abgespeichert. Aus jener Objektbeschreibung lassen sich dann Punktwolken mit variierendem Detail extrahieren. Ein sehr wichtiger Punkt bei der Level-of-Detail-Verwaltung ist die Entscheidung, wann vom aktuellen Level-of-Detail zu einer niedrigeren oder höheren Detailstufe gewechselt wird. Hier sollen die wichtigsten Auswahlmechanismen vorgestellt werden. Das sind zum einen die Fehlermetriken und zum anderen die Sichtbarkeitsberechnungen, auch unter dem Namen Visibility Culling bekannt.

24 2. LEVEL-OF-DETAIL FÜR PUNKTE Wenn möglich, sollte die Auflösung einer Punktwolke soweit reduziert werden, dass der dabei entstehende Fehler tolerierbar ist. Es ist auch intuitiv klar, dass zu kleine Surfels (projizierte Fläche kleiner als ein Pixel) nicht zur besseren Darstellung der Punktwolke beitragen. Heutige Grafikkarten sind geometrielimitiert. Das Ziel ist also die Renderperformanz durch eine Vereinfachung und Eliminierung von Surfels, dessen projizierte Fläche zu klein ist, als das sie ins Gewicht fallen würden, zu erhöhen. Da das Finden der optimalen Vereinfachung der Punktwolke sehr zeitaufwändig ist, werden die Fehlermetriken meist approximiert und die Sichtbarkeitsberechnungen extrem effizient berechnet. Levels-of-Detail werden aber nicht nur zur interaktiven Darstellung von extrem großen Szenen verwendet. Sie ermöglichen zudem eine Konfigurierbarkeit von Qualität und Geschwindigkeit, Antialiasing, Kompression und progressive Datenübertragung. In den letzten Jahren blieb es jedoch nicht bei einem LoD-Verfahren. Es wurden mehrerer Verfahren entwickelt, welche hier Erwähnung finden sollen. Dabei soll das auch in der Implementierung verwendetet hierarchische Level-of-Detail (HLoD) ganz besonders im Fokus stehen. 2.1 Diskretes Level-of-Detail Oft ist es unnötig ein 3d-Objekt mit vielen Punkten darzustellen, wenn dieses nur auf wenige Pixel im Bildraum projiziert wird. Clark [Cla76] erstellt deshalb pro Objekt mehrere Versionen des Objekts in abnehmender Qualität. Die Detailstufe wird dann aufgrund vom Abstand zur Kamera bzw. der Größe im Bildraum ausgewählt. So können entfernte Objekte durch niedrig aufgelöste LoDs dargestellt werden, wobei die Gesamtanzahl der Punkte reduziert und damit die Darstellungsgeschwindigkeit erhöht wird. Die diskreten LoDs müssen durch eine Vorverarbeitung berechnet werden, sind dann aber beim Rendering sofort verfügbar. Die Vorteile des diskreten Level-of-Detail sind also: Einfachheit. Durch die Entkopplung von Vereinfachung und Darstellung ist dieses Verfahren sehr einfach zu implementieren. Unabhängig von der Vereinfachung kann der Darstellungsalgorithmus die benötigte Detailstufe zur Laufzeit auswählen. Optimierbarkeit. Die LoDs können vor der Darstellung in ein optimales Datenformat konvertiert werden, das die Darstellung beschleunigt (z. B. Display Listen, Vertex Arrays und Vertex Buffer Objects). Die Nachteile von diskreten Levels-of-Detail sind dagegen von qualitativer Natur: Popping Artifacts. Abhängig von der Anzahl der Detailstufen und der Schwellwerte für einen Detailstufenwechsel, kann es zu so genannten Popping Artifacts kommen. Das heißt, es kommt zum

2.1. DISKRETES LEVEL-OF-DETAIL 25 sichtbaren Wechsel zwischen zwei Detailstufen. Nicht ganz optimale Lösungen sind das Morphing bzw. Überblenden zweier Stufen. Oder man erzeugt mit mehr Speicheraufwand mehr LoDs. Isotropie. Das Verfahren ist nicht anwendbar für räumlich ausgedehnte Objekte, da sich der Auflösungswechsel auf das gesamtes Objekt auswirkt und somit nicht blickpunktabhängig ist. 2.1.1 Level-of-Detail-Auswahl Da beim diskreten LoD eine globale Vereinfachung stattfindet, sind die Größen Distanz und Fläche für diese Art LoD die beste Wahl. Wurde die Größe berechnet, muss diese bei der Darstellung des Objektes mit einer Toleranz τ verglichen werden. Für das diskrete LoD existieren pro LoD eine solche Toleranz. Beim Zeichnen des Objektes wird einer der Größen berechnet und mit den Toleranzen der statischen LoDs verglichen. Wird die Toleranz überschritten, wird das nächst gröbere LoD genommen und wird sie unterschritten, wird das nächst feinere LoD genommen. 2.1.1.1 Distanz Die Distanz ist eine Auswahlverfahren im Objektraum. Da hohe Detailstufen für entfernte Objekte nicht sichtbar sind, können auch niedrigere Detailstufen ohne große visuelle Veränderungen verwendet werden [LWC + 02]. Bei der LoD-Auswahl wird die Distanz d mit den Toleranzen τ l verglichen. Die Toleranzen τ l mit l = 0,..., L werden separat pro LoD L des Objekts gespeichert. Die Wahl des Endpunktes im Objekt fällt dagegen schwer. Nimmt man einen zufälligen Punkt in der Punktwolke, so kann es bei einer Rotation zu einer Änderung der Distanz kommen. Das äußert sich besonders dann, wenn dies an einer Grenze zwischen zwei Detailstufen stattfindet. Es kommt zu schnellen Wechseln zwischen den LoDs, dem Popping-Effekt. Am besten wählt man daher die Distanz zum Objekt im Objektraum als Abstand zwischen Blickpunkt und Schwerpunkt der Punktwolke. 2.1.1.2 Fläche Bei diesem LoD-Auswahlverfahren wird die projizierte Fläche A des Objektes in den Bildraum herangezogen. Objekte die sich vom Betrachter entfernen, werden kleiner und können so mit weniger Detail dargestellt werden. Es findet wie bei der Distanz ein Vergleich zwischen der Fläche A und den Toleranzen τ l statt. Da die Projektion des Objektes zu rechenaufwändig wäre, wird anstatt des Objektes selbst das Hüllvolumen des Objektes in Form eines Hüllquaders oder einer Hüllkugel projiziert. Mit diesem Auswahlverfahren werden einige Probleme der Distanzauswahl vermieden, da die projizierte Fläche unabhängig von der Bildflächenauflösung, der Objektskalierung oder dem Blickwinkel ist. Zudem be-