In deisem Kapitel wird ein grober Überblick über die Struktur und die Komponenten des GL Transmission Formats und der 3D Tiles gegeben. Diese wurden verwendet um umd ie Punktwolken zu speichern.
In deisem Kapitel wird ein grober Überblick über die Struktur und die Komponenten des GL Transmission Formats und der 3D Tiles gegeben. Diese wurden verwendet um um die Punktwolken zu speichern.
3D Tiles und gltf
3D Tiles are an open specification for streaming massive heterogeneous 3D geospatial datasets
...
...
@@ -26,7 +26,7 @@ Das Tileset hat eine baumartige Struktur aus Tiles und deren Metadaten.
Jedes Tile hat hierbei ein 3D Volumen der den geografischen Bereich beschreibt, einen geometrischen Fehler zur Echtwelt.
Außerdem können Kinder und deren Transformationen zu dem Elternteil angegeben werden.
Alle Kinder leigen hierbei in dem Volumen des Elternknotens und können mit verschiedenen Datenstrukturen, wie K-D Bäumen Quadtrees oder ähnlichem die Region genauer spezifizieren (sieh Bild \ref{img:nonunifomQuad}.
Hierbei können die Kinder das Elterntile ersetzen (replace, z.B. genaueres Mesh) oder das bestehende Tile ergänzen (refine, zusätzliche Gebäude oder Details).
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.
...
...
@@ -46,30 +46,45 @@ Tiles können in unterschiedlichen Formaten sein zum Beispiel:
Tileformat für Instancing. Die Geometrie wird als glTF übertragen und zusätzlich eine Liste aus Positionen an denen die Objekte Instanziiert werden sollen.
Kann zum Beispiel für Bäume genutzt werden.
\item[ Point Cloud]
Format um Punktwolken zu übertragen. Das Teileformat enthält einen kleinen Header mit Metadaten und der Anzahl an Punkten.
Außerdem ist enthalten welche und wie die Daten wie Postion und Farbe in vorleigen.
Die eigentlichen Daten werden als Binärdaten übertragen und können so ohne Parsen direkt in den Speicher geladen werden.
Format um Punktwolken zu übertragen. Das Teileformat enthält einen kleinen Header mit allgemeinen Metadaten.
Danach folgt ein JSON String indem Steht welche Daten wie in dem Binärteil vorliegen.
Außerdem ist enthalten welche und wie die Daten wie Postion und Farbe dabei sind.
Die eigentlichen Daten werden als Binärdaten übertragen und können so ohne Parsen direkt in den Speicher und Grafikspeicher geladen werden.
\item[ Composite]
Tileformat zum gleichzeitigen Übertragen mehrerer einzelner Tileformate in einem. Es lässt sich zum Beispiel ein Batched3D Modell für Gebäude mit Instanced3D Modell für Bäume verbinden und als ein Tile überragen.
\end{description}
% GLTF
\section{glTF}
Das GL Transmission Format (glTF \cite{GLTF}) ist ein Format zum effizienten Übertragen von 3D Szenen für Gl Api's wie WebGL, OpenGl ES und OpenGL.
\subsection{glTF}
Das GL Transmission Format (glTF \cite{GLTF}) ist ein Format zum effizienten Übertragen von 3D Szenen für Gl Api's wie WebGL, OpenGl ES und OpenGL udn wird hier nru Kurz erwähnt da es für die Implementierung nicht verwendet wurde.
GlTF dient als effizientes, einheitliches und erweiterbares Format zur Übertragung und Laden von 3D Daten.
Im Vergleich zu aktuellen Standards wie COLADA ist glTF optimiert, schnell übertragen und kann schnell in eine Applikation geladen werden.
In einem JSON formatierten Datei (.gltf) wird eine komplette Szene samt Szenegraf, 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 Bildern die für das einfache und effiziente Übertragen von Geometrie, Texturen oder den nötigen GLSL Shadern genutzt werden
\subsection{Struktur}
Die .gltf Datei bildet den Kern jedes Modells und ist eine JSON formatierte Datei. In Ihr werden alle grundlegenden Informationen wie zum Beispiel die Baumstruktur 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) im Szenengraf, die wiederum Knoten als Kinder haben können. Jeder Knoten kann eine Transformation im lokalen Raum definieren, bestehend aus eine Translation, einer Rotation und eine Skalierung. Jeder Knoten kann eine Mesh und damit die eigentliche Geometrie referenzieren.
Die .gltf Datei ist eine JSON formatiert und bildet den Kern jedes 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 eine Translation, einer Rotation und eine Skalierung.
Jeder Knoten kann eine Mesh und damit die eigentliche Geometrie referenzieren.
Diese Geometrie wird in Buffern als Binärdaten gespeichert. Diese sind entweder als Base64 String direkt im JSON oder als zusätzliche Binärdatei gespeichert.
Auf einen Buffer wird mit einem Asccessor 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.
Jedes Mesh kann auf ein Material referenzieren. Materialien bestehen aus einem Materialparametern, Texturen und einer Techniken.
Techniken bestehen hauptsächlich aus einem GLSL Shader Programm das ebenfalls im glTF mitgeliefert wird.
Außerdem wird spezifiziert wie die VAO und VBO aus dem Mesh bei dem Rendervorgang an den Shader gebunden werden müssen.
Ein weiteres Feature von glTF Datein ist die Möglichkeit Animationen und Skinning Informationen zu übertragen.
@@ -78,4 +93,45 @@ Buffer sind die eigentlichen Daten in einem Binären Block.
Diese können entweder als externe Datei (.bin) oder als BASE64 encodierter 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.
glf right Handed y Axis up in Meters and radians
\ No newline at end of file
%glf right Handed y Axis up in Meters and radians
\section{Umsetzung}
Für das Speichern der Punktwolke wurden keine LOD verfahren angewendet.
In der Praxis hat sich gezeigt das die Wolken klein genug sind, sodass sie als ganzes effizient gerendert werden konnten.
Sollte man größere Punktwolken, z.B. von einem ganzen Raum erstellen könnte das Performancevorteile beim visualisieren bringen.
Das verwendete Tileset ist statisch und sehr einfach gehalten. Es beinhalte ein Tile das auf die Punktwolke referenziert. Es ist nicht transformiert und hat ein statisches Boundigvolume eine 5m große Kugel.
Dei eigentlichen daten werden in einem Point Cloud Tile abgespeichert.
Die Positionsdaten der einzelnen Punkte wird als Array aus float abgespeichert.
Dabei bilden 3 floats immer die x,y,und z Koordinaten eines Punktes.
Zusätzlich speichern wir einen Array an Farbdaten.
Pro Punkt wird jeweils ein Byte pro RGB gespeichert.
Um das Kalibriern zwischen der Echtwelt zu vereinfachen wurde beim aufnehmen ein Vive Tracker in der Welt platziert und als Ursprung verwendet.
Alle Punkte wurden vor dem schreiben der Datei in das Lokale Koordinatensystem des Trackers transformiert und können beim visualisieren erneut an dem Tracker orientiert werden.
