@@ -8,9 +8,9 @@ Die Entscheidung fiel auf die Aufnahme und Visualisierung von 3D Punktwolken.
Als Sensor wurde die Kinect ausgewählt. Diese ist günstig, portabel und wird in der Forschung häufig als 3D Sensor eingesetzt.
Die Kinect als Sensor bietet die Möglichkeit, aus einzelnen Aufnahmen, bestehend aus einem Farbbild und einem Tiefenbild, eine Punktwolke aus der Perspektive der Kinect zu errechnen.
Eine Aufnahme (ein Frame) beinhaltet aber nur die Informationen, die aus der Perspektive der Kamera sichtbar sind.
Das beinhaltet zum einen die Flächen der nächsten Oberfläche.% @@@ zum anderen fehlt
Das beinhaltet zum einen die Flächen der nächsten Oberfläche.
Dahinterliegende Geometrie wird verdeckt und ist aus einer Perspektive nicht sichtbar (siehe \ref{img:KinectSides} (a)).
Außerdem sind an Kanten meist nicht genügend Informationen in der Aufnahme enthalten, sodass seitliche Flächen richtig in Punkte konvertiert werden können. %@@@ statt ``sodass'' muss des doch ``damit'' heißen, oder?
Außerdem sind an Kanten meist nicht genügend Informationen in der Aufnahme enthalten, damit seitliche Flächen richtig in Punkte konvertiert werden können.
In vielen Fällen führt das zu falschen und nicht existierenden Flächen der errechneten Punktwolke (siehe \ref{img:KinectSides} (b)).
Diese Informationen aus einer Aufnahme reichen für die Visualisierung in VR für den Experten nicht aus.
Das Objekt sollte von allen Seiten gescannt werden, damit der Experte frei entscheiden kann, von welcher Seite er das Objekt bzw. die Punktwolke betrachtet.
...
...
@@ -48,7 +48,7 @@ Ein bilateraler Filter erzielt den gewünschten Effekt ist aber relativ rechenau
Im Paper \cite{Martin:2014:RTH} wird hierfür ein Filter vorgestellt, der auch in dieser Ausarbeitung verwendet wurde.
Hierbei wird zunächst das Bild mit einem Gauß-Filter geglättet.
Dieser ist nicht kantenerhaltend. Deshalb wird das geglättet Bild anschließend mit dem Original verglichen.
Bei zu starker Abweichung vom Original wird der Wert des Pixels auf das Original zurückgesetzt. %@@@ Wann ist eine Abweichung stark? Und über welches Pixel sprichst du?
Bei zu starker Abweichung vom Original wird der Wert des geglätteten Pixels auf das Original zurückgesetzt.
Nach der Glättung des Tiefenbildes wird dieses in eine Punktwolke umgewandelt.
Hierfür wurde ebenfalls das Microsoft Kinect SDK verwendet, das alle benötigten Methoden bereitstellt.
...
...
@@ -61,7 +61,7 @@ Auch alle Punkte, die zu nah oder zu weit vom Sensor entfernt sind, werden nicht
Je weiter das Objekt entfernt ist, desto ungenauer werden die Aufnahmen.
Im folgenden wurde ein Mindestabstand von 30cm und ein Maximalabstand von 90cm verwendet.
Als letztes werden alle Flächen, deren Oberflächennormale zu weit von dem Kameravektor abweicht (siehe Abb \ref{img:KinectSides} b), %@@@ wie geht der Satz weiter?
Als letztes werden alle Flächen, deren Oberflächennormale zu weit von dem Kameravektor abweicht verworfen(siehe Abb \ref{img:KinectSides} b),
Diese Flächen entstehen durch die Umwandlung des 2D Tiefenbildes in eine 3D Punktwolke.
Die benötigten Informationen fehlen an dieser Stelle und Punkte werden auf die Fläche zwischen Oberflächenobjekt und Hintergrund gesetzt.
Diese Ebene stimmt nicht mit der wirklichen Oberfläche überein. Diese falschen Punkte müssen entfernt werden.
In diesem Kapitel wird ein grober Überblick über die Struktur und die Komponenten des GL-Transmission Formats (glTF) und der 3D Tiles gegeben. Diese wurden verwendet, um die Punktwolken zu speichern.
\section{3D Tiles}
3D Tiles \cite{3DTiles} ist eine neue, offene Spezifikation für das Streamen von massiven, heterogenen, geospatialen 3D Datensätzen. %@@@ statt ``neu'' könntest du schreiben ``aus dem Jahr xyz'' oder ``veröffentlicht inm Jahr xyz''
3D Tiles \cite{3DTiles} ist eine neue, offene Spezifikation für das Streamen von massiven, heterogenen, geospatialen 3D Datensätzen. %@@@ statt ``neu'' könntest du schreiben ``aus dem Jahr xyz'' oder ``veröffentlicht inm Jahr xyz''-> aktulle verison ost o.o, bzw pre 1.0 die sit noch nciht draußen
Die 3D Tiles können genutzt werden, um Gelände, Gebäude, Bäume und Punktwolken zu streamen und bieten Features wie zum Beispiel Level of Detail (LOD).
Für die Arbeit wurde erwartet, das insbesondere LOD notwendig werden könnte.
Es stellte sich allerdings heraus, dass die Datenmengen, die für die Arbeit benötigt wurden, auch ohne LOD bewältigt werden können.
...
...
@@ -20,13 +20,13 @@ Im Vergleich zu aktuellen Standards wie COLADA ist glTF optimiert, schnell über
In einer JSON formatierten Datei (.gltf) wird eine komplette Szene samt Szenengraf, Materialien und deren zugehörigen Shadern, Kamerapositionen, Animationen und Skinning Informationen übertragen.
Dabei kann auf externe Dateien verwiesen werden. Diese sind zum Beispiel Binärdaten oder Bilder, die für das einfache und effiziente Übertragen von Geometrie, Texturen oder den nötigen GLSL Shadern genutzt werden.
Eine .gltf-Datei ist JSON formatiert und bildet den Kern jedes glTF Modells.%@@@ teilweise Wiederholung zu Zeile 20
Eine .gltf-Datei ist JSON formatiert und bildet den Kern jedes glTF Modells.
In ihr werden alle grundlegenden Informationen wie zum Beispiel die Baumstruktur des Szenengrafen und die Materialien gespeichert (siehe Abb. \ref{img:glTFOverview}).
Eine Szene bildet hierbei den Startpunkt für die zu rendernde Geometrie.
Szenen bestehen aus Knoten (Nodes), die beliebig viele Knoten als Kinder haben können.
Jeder Knoten kann eine Transformation im lokalen Raum definieren, bestehend aus einer Translation, einer Rotation und einer Skalierung.
Die Knoten können ein Mesh und damit die eigentliche Geometrie referenzieren.
Diese Geometrie wird in Buffern als Binärdaten gespeichert, welche wiederum entweder als Base64 String direkt im JSON oder als zusätzliche Binärdatei gespeichert wird.
Diese Geometrie wird in Buffern als Binärdaten gespeichert.
Auf einen Buffer wird mit einem Accessor und einer Bufferview zugegriffen. In diesen ist spezifiziert, in welchem Format die Daten vorliegen (z.B. ein Array aus 2D-Vektoren (VEC2) aus UNSIGNED SHORT).
Alle Datenformate entsprechen Formaten, die in OpenGL vorliegen, sodass die Daten ohne Konvertierung in OpenGL Vertex Array Objetkts (VAO), \bzw{} Vertex Buffer Objekts (VBO) umgewandelt werden können.
...
...
@@ -45,7 +45,7 @@ Ein weiteres Feature von glTF Dateien ist die Möglichkeit, Animationen und Skin
\end{figure}
Buffer sind die eigentlichen Daten in einem binären Block.
Diese können entweder als externe Datei (.bin) oder als BASE64 codierter String in der JSON Datei angefügt werden. %@@@ Wiederholung zu Zeile 29 ?
Diese können entweder als externe Datei (.bin) oder als BASE64 codierter String in der JSON Datei angefügt werden.
Die Hauptaufgabe der Buffer ist es, große Mengen an Daten wie die Geometrie effizient zu übertragen.
\subsection{Tileset und Tiles}
...
...
@@ -53,7 +53,7 @@ Als Basis der 3D Tiles wird ein in JSON beschriebenes Tileset verwendet, das auf
Das Tileset hat eine baumartige Struktur aus Tiles und deren Metadaten.
Jedes Tile hat hierbei ein 3D Volumen, das den geografischen Bereich beschreibt, und einen geometrischen Fehler des Tiles zur Echtwelt.
Außerdem können Kinder und deren Transformationen zu dem Elterntile angegeben werden.
Alle Kinder liegen hierbei in dem Volumen des Elternknotens und können mit verschiedenen Datenstrukturen, wie k-d-Bäumen Quadtrees oder ähnlichem die Region genauer spezifizieren (siehe Bild \ref{img:nonunifomQuad}. %@@@ Komma zwischen ``k-d-Bäumen'' und ``Quadtrees'' ?
Alle Kinder liegen hierbei in dem Volumen des Elternknotens und können mit verschiedenen Datenstrukturen, wie k-d-Bäumen, Quadtrees oder ähnlichem die Region genauer spezifizieren (siehe Bild \ref{img:nonunifomQuad}.
Hierbei können die Kinder das Elterntile ersetzen (replace, z.B. ein genaueres Mesh) oder das bestehende Tile ergänzen (refine, zusätzliche Gebäude oder Details).
Die eigentlichen Daten der Tiles sind durch eine URL verlinkt und können dynamisch nachgeladen werden.
