Diese Arbeit behandelt einen Vergleich verschiedener Algorithmen zur Vorhersage der Bewegung einer Person bei der Ausführung einer sportlichen Aktivität. Als Grundlage für die Vorhersage dienen Bildströme, welche mittels zweier Hochgeschwindigkeitskameras aufgezeichnet wurden. Im Laufe der Arbeit werden Vor- und Nachteile der umgesetzten Ansätze theoretisch erläutert und anschliessend an einer Reihe von Messergebnissen nachgewiesen. Für die Messungen wurde eine Anwendung eingesetzt, welche ebenfalls im Rahmen der Arbeit entwickelt wurde. Neben realen Aufnahmen, wurden zusätzlich synthetische Bildfolgen betrachtet, um Erkenntnisse über das Verhalten der betrachteten Algorithmen unter optimalen Bedingungen zu erlangen.

Ziel dieser Arbeit ist es, markerloses Tracking unter dem Ansatz der Analyse durch Synthese zu realisieren und dabei auf den Einsatz merkmalsbasierter Verfahren zu verzichten. Das Bild einer Kamera und ein synthetisches Bild der Szene sollen durch den Einsatz von Stilisierungstechniken so verändert und angeglichen werden, dass zu dem gegebenen Kamerabild aus einer Auswahl von gerenderten Bildern jenes erkannt werden kann, welches die reale Kamerapose am exaktesten wiedergibt. Es werden Kombinationen von Ähnlichkeitsmaßen und Visualisierungen untersucht, um eine bestmögliche Vergleichbarkeit der Bilder zu erreichen, welche die Robustheit gegen Trackingfehler erhöhen soll.

Für die Netzwerkprogrammierung hat sich auf breiter Front das Socket API nach Vorbild der Berkley Sockets durchgesetzt. Die "normalen" Sockets in Form von Stream- oder Datagram-Sockets erleichtern zwar die Programmierarbeit, verschleiern jedoch auch zahlreiche Details der Netzwerkkommunikation vor dem Programmierer. So ist man beispielsweise auf die Nutzung der Protokolle TCP oder UDP eingeschränkt und agiert zwangsläufig bereits auf dem Application-Layer des TCP/IP Referenzmodells. Für den Zugriff auf tiefer gelegene Netzwerkschichten, d.h. für den Zugriff auf die Headerdaten eines Netzwerkpaketes, hält das Socket API die sogenannten RAW Sockets bereit. Mit ihnen ist es möglich, alle IP Pakete inklusive Headerdaten zu lesen oder von Grund auf neu zu generieren. Hiermit ist es nun auch möglich, Protokolle zu verwenden, die dem Anwendungsprogrammierer bislang nicht zugänglich waren (z.B. ICMP oder OSPF) oder sogar eigene IP basierte Protokolle zu entwickeln. RAW Sockets stoßen an ihre Grenzen, wenn es darum geht auf den Data-Link-Layer der Netzwerkkommunikation zuzugreifen. Unter Linux gibt es hierfür einen weiteren Socket-Typ: Den PACKET Socket. Die Studienarbeit möchte einen Einstieg in die Programmierung mit den eher unbekannten RAW und PACKET Sockets schaffen. Dabei werden einige Beispielprogramme vorgestellt und mögliche Anwendungsgebiete aufgezeigt.

Ziel dieser Studienarbeit war es, Erfahrungen in der Grafik- und Spieleprogrammierung zu sammeln. Als Grundidee kam dabei die Erstellung eines 3-dimensionalen Terrains auf. Solche Terrains werden heutzutage nicht nur in der Spielebranche eingesetzt, wo sie in beinahe jedem Genre vertreten sind, sondern auch z.B. in der Geologie zur Erstellung von Simulationen von Plattentektonik. Die simple Erstellung eines 3-dimensionalen Terrains wäre für eine Studienarbeit jedoch zu trivial, daher sollte das Terrain spezielle Anforderungen erfüllen. Zum einen sollte das Terrain dynamisch erzeugt werden, d.h. der Benutzer des Programms hat Einfluss darauf, wie sich das Terrain entwickelt. Dies sollte vorzugsweise spielerisch eingebracht werden. Zum anderen sollte das Terrain zufällig generiert werden. Dies bedeutet, dass keine vormodellierte Landschaft genutzt, sondern jede Erhebung/- Vertiefung des Terrains mittels Zufallsfaktoren erzeugt werden sollte. Zusätzlich sollte das Terrain endlos erzeugt werden. Bei einer Bewegung über das Terrain sollte also niemals ein Ende erreicht werden. Also auch keine Kreistrecke, sondern ein wirklich endloses und stets anders aussehendes Terrain. Desweiteren sollte es dem Benutzer møglich sein, ein Fluggerät über das Terrain zu steuern. Dies gab dann auch die Chance, aus der oben genannten dynamischen Anforderung ein spielerisches Element zu machen, indem der Benutzer das Terrain durch Einsammeln von sogenannten TerraformItems beeinflussen kann. Die Steuerung eines Fluggerätes spielt auch für die geforderte Endlosigkeit des Terrains eine wichtige Rolle, da diese ohne eine Möglichkeit der Fortbewegung gar nicht nachprüfbar wäre. Das Problem mit der Endlosigkeit ist dabei, dass kein System endlosen Speicher zur Verfügung hat um das Terrain komplett zu speichern und dem Benutzer somit die Option zu bieten, die gleiche Strecke zurückzufliegen. Eine Lösung für diese Problematik wäre bei einer Kehrtwende das Terrain auch rückwärts wieder neu zu generieren. Der Einfachheit halber sollte stattdessen ein komplette Kehrtwende einfach nicht zugelassen werden. Eine Kollisionserkennung musste dann natürlich auch implementiert werden. Zum einen weil das Fluggerät ja nicht einfach wie ein Geist durch das Terrain hindurchgleiten sollte, zum anderen muss das Programm ja irgendwie das Einsammeln der oben angesprochenen TerraformItem-Objekte registrieren können. Weitere Objekte wie Bäume oder Felsen sollten das Terrain optisch aufwerten. Zu guter Letzt sollte noch eine simple Benutzeroberfläche erstellt werden, um dem Benutzer diverse Bedienelemente und Rückmeldungen zu bieten. Damit sollte es z.B. auch möglich sein dass Terrain direkt zu verändern.

In der vorliegenden Studienarbeit wird eine OpenGL-Applikation vorgestellt, die Geometrie-Shader in einem Feedback-Loop einsetzt, um auf der GPU Geometrie zu erzeugen. Dargelegt werden die erforderlichen Grundlagen Geometrie-Shader und Transform Feedback betreffend, die Umsetzung der Anwendung und die eingesetzten GLSL-Shader.