@@ -29,8 +29,8 @@ Das spart Zeit und Rechenleistung und bietet somit eine einfache und schnelle MÃ
\begin{figure}
\subfigure[Aufnahme aus Sicht der Kinect ]{\includegraphics[width=0.49\textwidth]{Bilder/1FrameKamera.png}}
\subfigure[Aufnahme von der Seite]{\includegraphics[width=0.49\textwidth]{Bilder/1FrameSeite.png}}
\caption{Aufnahme der Kinect aus verschiedenen Perspektiven. In Bild (a) ist zu erkennen, wie die Türme den Hintergrund verdecken. In Bild (b) sind falsche Punkte zu sehen, die durch die Rekonstruktion aus einem 2D Bild entstehen. }
\subfigure[Aufnahme von der Seite\label{img:KinectSides-b}]{\includegraphics[width=0.49\textwidth]{Bilder/1FrameSeite.png}}
\caption{Aufnahme der Kinect aus verschiedenen Perspektiven. In Bild (a) ist zu erkennen, wie die Türme den Hintergrund verdecken. In Bild \ref{img:KinectSides-b}sind falsche Punkte zu sehen, die durch die Rekonstruktion aus einem 2D Bild entstehen. }
\label{img:KinectSides}
\end{figure}
...
...
@@ -44,7 +44,7 @@ Zum Aufnehmen einer Punktwolke aus einem Frame wird das Kinect SDK verwendet.
Sowohl das Tiefeinbild auch als auch das Farbbild kann man aus der API erhalten.
Anschließend wird das Tiefenbild geglättet um glattere Oberflächen in der Punktwolke zu erhalten.
Hierfür braucht man einen Filter, der zwar die Flächen glättet, aber gleichzeitig die Objektkanten erhält.
Ein Bilateral Filter erzielt den gewünschten Effekt ist aber relativ rechenaufwändig.
Ein bilateraler Filter erzielt den gewünschten Effekt ist aber relativ rechenaufwändig.
Im Paper \cite{Martin:2014:RTH} wird hierfür ein Filter vorgestellt den 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.
...
...
@@ -71,7 +71,7 @@ Die Normale wird aus dem Tiefenbild geschätzt.
Eine Transformation ist die zwischen dem Koordinatensystem der Kinect und dem des Vive Controllers.
Ist zum Beispiel die Transformation entlang der X Achse der Kinect verschoben, so verstärkt sich der Fehler, wenn man das Objekt von der anderen Seite, also um 180\degree gedreht aufnimmt (siehe Abb, \ref{img:KinecOffset}).
Ist zum Beispiel die Transformation entlang der X-Achse der Kinect verschoben, so verstärkt sich der Fehler, wenn man das Objekt von der anderen Seite, also um 180\degree gedreht aufnimmt (siehe Abb. \ref{img:KinecOffset}).
Der Fehler im lokalen Koordinatensystem wird in das globale transformiert und ist in dem Fall dann in genau entgegengesetzter Richtung.
\begin{figure}
...
...
@@ -106,7 +106,7 @@ Der Fehler im lokalen Koordinatensystem wird in das globale transformiert und is
\end{center}
\end{figure}
In der offiziellen Dokumentation der Kinect ist beschrieben, dass der Ursprung von Punktwolken in dem Tiefensensor liegt (siehe \cite{KinectDoku}).
In der offiziellen Dokumentation der Kinect ist beschrieben, dass der Ursprung von Punktwolken imTiefensensor liegt (siehe \cite{KinectDoku}).
Leider fehlt die exakte Positionsangabe im Gehäuse.
Im Bild \ref{img:KinectOrigin} aus dem chinesischen Microsoft Forum ist eine von Benutzern vermessene schematische Darstellung der Kinect abgebildet.
Der Tiefensensor liegt hinter der kleineren runden Öffnung.
...
...
@@ -130,13 +130,14 @@ Als Hilfe wurde ein 3D gedruckter Zylinder verwendet der in den Ring des Control
\label{img:KinectOrigin}
\end{center}
\end{figure}
\todo{Bezüglich Bild \ref{img:KinectOrigin}: Ich würde mir hier gut überlegen, ob du das Bild abdrucken willst. Ich habe jedenfalls auf die schnelle keine Lizenz gefunden -> ist vermutlich ne Verletzung des Urheberrechts.}
\begin{figure}
\subfigure[Befestigung der Kienct]{\includegraphics[width=0.32\textwidth]{Bilder/KincetHalterung.JPG}}
\subfigure[Kinect mit Controler]{\includegraphics[width=0.32\textwidth]{Bilder/KinecController1.JPG}}
\subfigure[Relative Position in 3D]{\includegraphics[width=0.32\textwidth]{Bilder/KinectToVive.png}}
\subfigure[Befestigung der Kinect\label{img:KinecttoVive-Befestigung}]{\includegraphics[width=0.32\textwidth]{Bilder/KincetHalterung.JPG}}
\subfigure[Kinect mit Controller]{\includegraphics[width=0.32\textwidth]{Bilder/KinecController1.JPG}}
\subfigure[Relative Position in 3D\label{img:KinecttoVive-3D}]{\includegraphics[width=0.32\textwidth]{Bilder/KinectToVive.png}}
\caption{Befestigung des Controllers an der Kinect. Die Mitte des Controllers ist direkt über dem Tiefensensor.
In Bild a) ist die 3D gedruckte Halterung zusehen. Der Controller wird auf den Zylinder gesteckt. In c) ist die Virtuelle Repräsentation. Koordinatenkreuze zeigen den jeweiligen Ursprung des Geräts ([x,y,z] Achse=[rot,grün,blau]}
In Bild \ref{img:KinecttoVive-Befestigung} ist die 3D gedruckte Halterung zu sehen. Der Controller wird auf den Zylinder gesteckt. In \ref{img:KinecttoVive-3D} ist die Virtuelle Repräsentation. Koordinatenkreuze zeigen den jeweiligen Ursprung des Geräts (X-, Y- und Z-Achse in rot, grün und blau)}
\label{img:KinecttoVive}
\end{figure}
...
...
@@ -152,10 +153,10 @@ In Bild a) ist die 3D gedruckte Halterung zusehen. Der Controller wird auf den Z
\section{Ergebnisse}
Mit dem vorgestellten Verfahren lässt sich einfach und schnell eine Punktwolke erstellen.
Die Ungenauigkeiten des Trackings und Fehler in der Kalibrierung führen aber zu sichtbaren Fehlern in der endgültigen Punktwolke. \todo{Bild}
Zwischen 2 Aufnahmen und den daraus resultierenden Punktwolken ist ein Versatz bis zu 2-3 cm sichtbar.
In einer 3D Umgebung insbesondere in VR ist das eine zu große Ungenauigkeit.
Zwischen 2 Aufnahmen und den daraus resultierenden Punktwolken ist ein Versatz bis zu 2--3 cm sichtbar.
In einer 3D-Umgebung, insbesondere in VR, ist das eine zu große Ungenauigkeit.
Durch die Ungenauigkeiten des Trackings verändert sich die Genauigkeit und damit der Versatz der Punktwolken ständig.
Vergleicht man mit einem 2m Zollstock die reale Distanz mit der realtiven Distanz in VR, so erhält man in VR eine Länge von 1,98 bis 2 m
Vergleicht man mit einem 2m Meterstab die reale Distanz mit der realtiven Distanz in VR, so erhält man in VR eine Länge von 1,98 bis 2 m
Die Distanz ist hierbei abhängig von der Orientierung zu den Basisstationen und der aktuellen Kalibrierung des Lighthous Tracking Systems.
Dieses Problem erschwert es, die Kalibrierung zwischen Controller und Kinect zu überprüfen.
In diesem Kapitel wird ein grober Überblick über die Struktur und die Komponenten des GL Transmission Formats und der 3D Tiles gegeben. Diese wurden verwendet, um die Punktwolken zu speichern.
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.
Die 3D Tiles können genutzt werden, um Gelände, Gebäude, Bäume und Punktwolken zu streamen und bieten Features wie Level of Detail (LOD).
LOD war bei der Asuwahl des Datenfomrats ein wichtiger Faktor, da dies bei großen Punktwolken ein signifikanten Perfomancevorteil bringen könnte.
Bei der Implementierung wurden LOD verfahren nicht verwendet, da die Darstellung der gesammten Punktwolke möglich ist.
3D Tiles \cite{3DTiles} ist eine neue, offene Spezifikation für das Streamen von massiven, heterogenen, geospatialen 3D Datensätzen.
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.
Deswegen wurde auf dieses Feature verzichtet.
\subsection{glTF}
\label{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.
Das GL Transmission Format (glTF \cite{GLTF}) ist ein Format zum effizienten Übertragen von 3D Szenen für OpenGL-APIs wie WebGL. OpenGl ES und OpenGL.
glTF dient als effizientes, einheitliches und erweiterbares Format zur Übertragung und Laden von komplexen 3D Daten.
Dieses wird in den 3D Tiels verwendet um komplexe Geometrie wie Gebäude zu übertragen.
In dieser Arbeit kamen aber nur Punktwolken zum Einsatz.
...
...
@@ -19,49 +20,49 @@ 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.
Die .gltf Datei ist JSON formatiert und bildet den Kern jedes glTF Modells.
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.
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 Accessor und einer Bufferview zugegriffen. In diesen ist spezifiziert, in welchem Format die Daten vorliegen (z.B. ein Array aus 2DVektoren (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.
Die Knoten können ein Mesh und damit die eigentliche Geometrie referenzieren.
Diese Geometrie wird in Buffern als Binärdaten gespeichert, welche wiederumentweder als Base64 String direkt im JSON oder als zusätzliche Binärdatei 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.
Jedes Mesh kann auf ein Material referenzieren. Materialien bestehen aus Materialparametern, Texturen und 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.
Techniken bestehen hauptsächlich aus GLSL Shader Programmen, das ebenfalls im glTF mitgeliefert wird.
Außerdem wird spezifiziert, wie die VAO und VBO des Meshes 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.
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.
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}
Als Basis der 3D Tiles wird JSON formatiertes Tileset verwendet, das auf die eigentlichen Daten in Tiles verweist.
Als Basis der 3D Tiles wird ein in JSON beschriebenes Tileset verwendet, das auf die eigentlichen Daten in Tiles verweist.
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 zur Echtwelt.
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}.
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.
\caption{Ein Tile mit 4 Kindern. Die 4 Kinder fügen die Gebäude hinzu und liegen im Volumen des Elterntiles. Als Datenstruktur liegt ein nicht uniformer Quadtree vor.}
\label{img:nonunifomQuad}
\end{center}
\end{figure}
...
...
@@ -73,21 +74,22 @@ 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.
Das kann zum Beispiel für Bäume genutzt werden.
\item[ Point Cloud]
Format um Punktwolken zu übertragen. Das Tileformat enthält einen kleinen Header mit allgemeinen Metadaten.
Danach folgt ein JSON String, in dem steht, welche Daten wie in dem Binärteil vorliegen.
Außerdem ist enthalten, ob Daten wie Postion und Farbe dabei sind und wie diese gespeichert sind.
Die eigentlichen Daten werden als Binärdaten übertragen und können so ohne Parsen direkt in den Speicher und Grafikspeicher geladen werden.
Format, um Punktwolken zu übertragen. Das Tileformat enthält einen kleinen Header mit allgemeinen Metadaten, einer Beschreibung in JSON sowie einen Binärteil.
Der JSON-Teil beschreibt, welche Art von Daten im Binärteil stehen.
Insbesondere wird hier angegeben, ob Positionen und Farben enthalten sind und wie diese kodiert sind.
Die eigentlichen Daten werden als Binärdaten übertragen und können so ohne weitere Verarbeitung direkt in den (Grafik-)Speicher 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.
Tileformat zum gleichzeitigen Übertragen mehrerer einzelner Tileformate in einem.
Es lässt sich zum Beispiel ein Batched3D-Modell für Gebäude mit einem Instanced3D Modell für Bäume verbinden und als ein Tile überragen.
\end{description}
\section{Implementierung der 3D Tiles}
Für das Speichern der Punktwolke wurden keine LOD Verfahren angewendet.
In der Praxis hat sich gezeigt, dass 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.
Für das Speichern der Punktwolke wurde auf die Implementierung eines Level-of-Detail-Verfahrens verzichtet.
In der Praxis hat sich gezeigt, dass die Punktwolken klein genug sind, um sie immer vollständig zu rendern.
Sollte man größere Punktwolken, z.B. von einem ganzen Raum erstellen, könnte LOD Performancevorteile beim Visualisieren bringen.
Das verwendete Tileset ist statisch und sehr einfach gehalten (siehe Anhang \ref{Anhang:Tileset})
Es beinhaltet ein Tile, das auf die Punktwolke referenziert. Es ist nicht transformiert und hat ein statisches Boundigvolume eine 5m große Kugel.
Es beinhaltet ein Tile, das auf die Punktwolke referenziert. Es ist nicht transformiert und hat als Boundigvolume eine statische 5m große Kugel.
Die eigentlichen Daten werden in einem Point Cloud Tile abgespeichert.
Die Positionsdaten der einzelnen Punkte werden als Array aus float abgespeichert.
...
...
@@ -95,8 +97,8 @@ Die eigentlichen Daten werden in einem Point Cloud Tile abgespeichert.
Zusätzlich wird einen Array an Farbdaten gespeichert.
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 (siehe Abbildung \ref{img:trackerAufnahme}).
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.
Um das Kalibriern zwischen der Echtwelt und einer virtuellern Repräsentation zu vereinfachen, wurde beim Aufnehmen ein Vive Tracker in der Welt platziert und als Ursprung verwendet (siehe Abbildung \ref{img:trackerAufnahme}).
Alle Punkte wurden vor dem Schreiben der Datei mit der folgenden Formel in das lokale Koordinatensystem des Trackers transformiert und können beim Visualisieren erneut an dem Tracker orientiert werden.
\caption{Punktwolke mit 1596685 Punkten. Die Textur im Hintergrund ist die zugehörige Positionstextur, Rechts oben ist FPS und die Renderzeit in ms zu sehen }
\caption{Die beiden Duplotürme, die in der Evaluation verwendet wurden. Die Markierung auf dem Tisch hilft bei der exakten Positionierung. }
\end{figure}
...
...
@@ -75,7 +76,7 @@ Im Video Szenario wird der Videostream angeschaltet, sodass dieser als Interakti
Nachdem der lokale Nutzer den gesuchten Stein erkannt hat, liest dieser die Beschriftung vor.
Der Experte bestimmt selbst, wann er zum nächsten Aufgabenteil voranschreitet.
Nachdem er aus dem Vorbereitungsdaten den Stein erkannt hat, drückt er eine Taste (Controller Trigger/ Enter) und bekommt damit Zugriff auf den Laserbeam bzw. den Videostream.
Nachdem er aus dem Vorbereitungsdaten den Stein erkannt hat, drückt er eine Taste (Controller Trigger/ Enter) und bekommt damit Zugriff auf den Laserbeam \bzw{} den Videostream.
Wurde das Label vorgelesen kann er erneut mit der gleichen Taste zur nächsten Aufgabe gelangen.
Bei jedem Tastendruck wird die aktuelle Uhrzeit gespeichert. Damit können die Zeiten errechnet werden können.
...
...
@@ -204,7 +205,7 @@ Diese Info kann der Experte im Video sehen und die Kontrollfrage direkt beantwor
Bei funktionierendem Tracking hat der Beam gute Ergebnisse geliefert.
Einige Teams konnte durch Zeigen und zusätzliches Sagen der Farbe den Stein eindeutig beschreiben.
Damit ist der Beam zumindest ein gute Grundorientierung für den lokalen Nutzer.
Ein großes Problem mit dem tracking waren kleine konstante Verschiebungen in eine globale Richtung (Kalibrierfehler, bzw. Längenuntreue).
Ein großes Problem mit dem tracking waren kleine konstante Verschiebungen in eine globale Richtung (Kalibrierfehler, \bzw{} Längenuntreue).
Bei kleine Verschiebungen wurde dieses als störend empfunden, aber wenn bekannt ist, wie die Verschreibung ist, dann kann diese im Kopf ausgeglichen werden. %@@@ Konnte man das bei den Probanden auch beobachten?
Ein weites Problem, das in den freien Texten genannt wurde, waren zittrige Hände. % @@@ hattest du Parkinsonpatienten ;-)
