Juni 4, 2019

13 – PrĂ€sentation an der Hofer Kulturnacht

Im Rahmen der 13. Hofer Kulturnacht wurde das fertige VR-Projekt zum ersten Mal der Öffentlichkeit vorgefĂŒhrt. Hier hatte das Team letztendlich die Chance, die erarbeiteten Funktionen und Interaktionen mit der eigentlichen Zielgruppe des Projekts auszutesten. Zur PrĂ€sentation des Ergebnisses wurde dem Projekt in der neu erbauten "Klangmanufaktur" das Foyer bereitgestellt, um sich mit VR-Brille, Beamer und mehr aufbauen zu können.

Von Eröffnung bis Schluss der Veranstaltung war das Projekt aufgebaut und vom interessierten Publikum der Kulturnacht gut besucht. Ohne Pause wollten immer neue Zuschauer sich selbst in den virtuellen Orchestersaal begeben. Die Zuschauer selbst waren wie angekĂŒndigt ein bunt gemischtes Publikum, in dem allerlei Altersgruppen vertreten waren. Die Erfahrungen mit VR-Anwendungen waren meist nicht gegeben.

Eine Überraschung fĂŒr das Team war die Offenheit der Probanden, die sich in die VR begeben haben. Jeder, der sich die Brille aufgesetzt hat, hat sich die Funktionen erklĂ€ren lassen und sich mehrere Minuten selbst intensiv mit der VR auseinandergesetzt. Aus Zeit- und PrĂ€sentationsgrĂŒnden wurde wĂ€hrend des Abends auf das VR-Tutorial verzichtet, da das Symotiv Team mit vor Ort war und die Funktionen den Probanden schnell erklĂ€ren konnte. Das Tutorial ist vor allem dann wichtig, wenn man die Anwendung allein benutzen will. So blieb dauerhaft der Orchestersaal auf der großen Leinwand zu sehen, auf die das Bild ĂŒbertragen wurde, das der aktuelle Zuschauer in der VR-Brille live gesehen hat. Dazu waren noch Lautsprecher aufgebaut, die auch den Ton der Kopfhörer gespiegelt haben, sodass das außenstehende Publikum das Bild und der Ton live aus der VR mitbekommt.

Sowohl das Team des Projekts als auch die Hofer Symphoniker waren sehr zufrieden mit dem Abend und der Reaktion des Publikums der Kulturnacht. Es konnten noch einige Anpassungen an das Interaction Design der Anwendung gemacht werden, wie zum Beispiel die Funktion, die das StĂŒck neu starten lĂ€sst. ZusĂ€tzlich dazu wurden die Buttons am Controller angepasst, sodass man das Auswahlwerkzeug nicht aus versehen aktivieren kann, wĂ€hrend man sich teleportieren will und andersherum. Das neue Setup wird bei der nĂ€chsten PrĂ€sentation am 15.06 an der Nacht der Wissenschaften dargestellt.

Mai 27, 2019

12 – Tutorial

Bevor der Nutzer den Konzertsaal betritt, findet er sich in einem Tutorialraum wieder. Hier werden ihm alle Bedienungen und Interaktionen erklĂ€rt, damit er anschließend problemlos in die Orchesterwelt eintauchen kann. Wie bereits beim Interaktionskonzept beschrieben, gilt es den Teleport, das Zeigewerkzeug und das Deaktivieren der Plattformen zu beschreiben. Hierzu besteht der Raum aus 3 Podesten, die jeweils die genannten Aspekte veranschaulichen. Um Sprachbarrieren mit Begriffen wie „Trigger“ oder „Button“ zu umgehen, ist der Controller wĂ€hrend der gesamten Szene beschriftet.

Beim Betreten des Tutorials befindet sich der Nutzer kurz hinter der ersten Plattform. Wenn er nun einen Schritt nach vorne lĂ€uft, betritt er in der virtuellen Welt die erste Plattform und es erscheint eine Informationstafel auf der linken Seite. Sie zeigt einen Text, der kurz die Teleport-Funktion erklĂ€rt. ZusĂ€tzlich ertönt eine Stimme, die ebenfalls den Inhalt der Tafel wiedergibt. Das Voice-Over erspart so dem Nutzer die Texte lesen zu mĂŒssen. Sollten jedoch noch Fragen offen bleiben, kann jeder Zeit auf den Tafeln nachgelesen werden.

Nachdem auf diesem Weg die Teleportation erklÀrt wurde, wird der Nutzer gebeten sich zur nÀchsten Plattform zu begeben. Sobald er diese betritt, taucht die nÀchste Tafel auf und das Voice-Over erklÀrt das Zeigewerkzeug und bittet den Nutzer damit auf die nÀchste Plattform zu deuten. Wie spÀter bei den Instrumentengruppen erscheint die Informationsebene mit einem Icon. Sie bittet den Nutzer die Plattform mit einem Klick zu aktivieren. Damit ertönt die Stimme ein letztes Mal und erklÀrt dem Nutzer, dass er nun die grundlegenden Interaktionen verstanden hat.

Am Ende des Raumes wird ein Wandelement hervorgehoben. Durch den erlernten Mechanismus lĂ€sst es sich mit dem Zeigewerkzeug untersuchen. Es erscheint der Hinweis, dass es sich um den Weg in den Orchesterraum handelt. Auch auf der anderen Seite der Wand findet sich eine Kennzeichnung, um auf dem gleichen Weg zurĂŒck in die Tutorialszene zu gelangen. So können Nutzer sich jederzeit die Bedienungen erneut erklĂ€ren lassen.

 

Mai 20, 2019

11 – UX – und Interaktionskonzept

Der Nutzer findet sich also in einem digitalen, dreidimensionalen Raum wieder. Um die virtuelle Welt ganzheitlich erfahren zu können, spielen Interaktionsmöglichkeiten eine bedeutende Rolle. Sie bewirken eine Verschmelzung zwischen dem Nutzer und seiner Umgebung und ĂŒberwinden die Barrieren, die gewohnte digitale Medien zwangslĂ€ufig mit sich bringen. Es entsteht eine intensivere Erfahrung, die so nur in der virtuellen RealitĂ€t möglich ist. Die Schnittstelle zwischen Nutzer und Medium bildet eine handelsĂŒbliche VR-Brille. In diesem Fall handelt es sich um die HTC VIVE.

Gesucht wird ein Interaktionskonzept, das den Nutzer in die virtuelle Welt integriert, ohne ihn dabei von den grundlegenden Geschehnissen abzulenken. Hierbei spielt die User Experience (kurz UX) eine tragende Rolle. Sie beschriebt die Erfahrung eines Nutzers mit einem Produkt oder einem Service und wird durch sogenannte User Tests erprobt. In unserem Fall wurde schnell klar, dass virtuelle RealitĂ€ten und VR-Brillen noch sehr neue Technologien sind. Die wenigsten Nutzer haben bereits Vorkenntnisse oder sind sogar erfahren im Umgang mit diesem Medium. Sogar die Studenten am Campus, die regelmĂ€ĂŸiger in Kontakt mit virtuellen Anwendungen kommen, zeigten sich schnell verloren oder ĂŒberfordert.

Die Interaktionsmöglichkeiten einer digitalen, virtuellen Welt scheinen vergleichsweise grenzenlos. FĂŒr eine gute User Experience jedoch gilt es den Nutzer nicht unnötig zu belasten und sich lediglich auf die zentralen Aspekte der Szene zu beschrĂ€nken. Schließlich soll das Orchester so natĂŒrlich und einfach wie möglich erlebbar sein. Zu viele verschiedene Interaktionsmöglichkeiten wĂŒrden diese Erfahrung negativ beeintrĂ€chtigen. Es stellt sich also die Frage, welche Interaktionsmöglichkeiten von fundamentaler Bedeutung fĂŒr eine umfangreiche Erfahrung sind und welche man zur leichteren VerstĂ€ndlichkeit weglĂ€sst.

Auch die Hardware, also der Controller der HTC VIVE, limitiert die Anzahl der geeigneten Anwendungen. Er bietet einen sogenannten „Trigger“ (1) fĂŒr den Zeigefinger und ein Touchpad (2) fĂŒr den Daumen, dass ebenfalls als Knopf funktioniert. DarĂŒber hinaus gibt es noch den „Grip Button“ (3), der durch ein Zusammenpressen der Hand aktiviert wird. Letzterer erwies sich bereits in der Vergangenheit als unintuitiv und unzuverlĂ€ssig. Nutzer können die meisten Funktionen von der Computermaus ĂŒbertragen, ein Zugreifen erscheint allerdings noch zu abstrakt. Es besteht die Option einen zweiten Controller oder sogar die Position des Headsets zu verwenden, um weitere Interaktionsmöglichkeiten zu schaffen. Der SchlĂŒssel jedoch liegt in einer leichten VerstĂ€ndlichkeit der Anwendung und folglich nicht in der grĂ¶ĂŸtmöglichen Anzahl an verschiedenen Interaktionen.

Reduziert man die geplante Szene auf das Wesentliche, so handelt es sich um einen Konzertraum mit einem spielenden Orchester. Das Hauptaugenmerk liegt hier auf den Bewegungsdaten der Musiker und den Soundspuren der jeweiligen Instrumentengruppen. Sowohl die Bewegungen als auch der Klang finden im dreidimensionalen Raum statt. Die GerĂ€uschkulisse verĂ€ndert sich abhĂ€ngig von der Position des Nutzers und die Bewegungen der Figuren lassen sich aus unterschiedlichen Perspektiven analysieren. Es muss dem Nutzer also möglich sein sich im Raum zu bewegen. Hier liegt schließlich auch der grĂ¶ĂŸte Vorteil der virtuellen RealitĂ€t. Letztendlich fiel die Entscheidung auf eine Teleportfunktion. Diese wird regelmĂ€ĂŸig von verschiedenen Anwendungen genutzt und ist somit zumindest einigen Nutzern bereits bekannt. Nicht grundlos konnte sich der Teleport bisher behaupten: ein gradliniges Laufen wie es beispielsweise in Computerspielen angewendet wird, fĂŒhrt in den aktuellen Brillen noch schnell zu Übelkeit und einem unangenehmen Flimmereffekt. Der Teleport umgeht dieses Problem, da die Position schlagartig gewechselt wird. Außerdem ermöglicht sich so ein besserer Vergleich der Audiospuren. Der Nutzer kann sich von der linken auf die rechte Seite der BĂŒhne teleportierten und so den unterschiedlichen Klang nachvollziehen. Die Umsetzung unserer Teleportation hĂ€lt sich dabei an den bisherigen Standard und wird mit dem Touchpad aktiviert. Legt der Nutzer seinen Daumen auf das Bedienfeld, erscheint eine Kurve, die zu einem Punkt auf dem Boden fĂŒhrt. Durch ein Klicken und Loslassen des Touchpads teleportiert man sich zu dem markierten Punkt. Der Nutzer kann sich nun im Raum bewegen und die Szene audiovisuell erkunden.

Jedoch ist er bisher lediglich ein Beobachter. Es fehlt noch die Interaktion mit seiner Umgebung.
ZunĂ€chst bedarf es einer weiteren Interaktionsmöglichkeit. Nachdem das Touchpad fĂŒr die Teleportation genutzt wird bleibt der „Trigger“ fĂŒr die Interaktion mit den Musikern. Dieser bietet ebenfalls zwei Interaktionsstufen: Zuerst lĂ€sst er sich anziehen und in dieser Position halten. Durch ein stĂ€rkeres Ziehen wird dann ein Klick ausgelöst. Die erste Stufe aktiviert das sogenannte Zeigewerkzeug, also einen laserartigen Strahl der gradlinig aus dem Controller austritt. Mit ihm kann der Nutzer auf Objekte zeigen. Handelt es sich um ein aktives, auswĂ€hlbares Ziel, wird dieses heller, wenn der Strahl es trifft. Hier sind es die Plattformen der jeweiligen Musiker die reagieren. Trifft der Laser auf eine SchaltflĂ€che, so erscheint ein Icon und die jeweilige Instrumentengruppe ĂŒber den Köpfen der Musiker. Als Auswahl werden die Plattformen genutzt, weil diese statisch sind und in Kombination mit der BĂŒhnenstruktur eine Orientierung im Raum ermöglichen, wĂ€hrend sich die einzelnen Figuren bewegen und gegenseitig verdecken.

Nun kann sich der Nutzer im Raum bewegen und auf eine Informationsstruktur zugreifen, die ihm die Besetzung des Orchesters erklĂ€rt. Zuletzt soll er in der Lage sein, aktiv in das Geschehen einzugreifen, indem er einzelne Instrumentengruppen nach Belieben ein- oder ausschaltet. Er kann also das Klangbild aktiv manipulieren und ein besseres VerstĂ€ndnis fĂŒr das Orchester und seine einzelnen Klanggruppen entwickeln. Um diese Interaktion durchzufĂŒhren, muss der Nutzer den „Trigger“ bis zum Klick durchdrĂŒcken. Eine so deaktivierte Plattform wird dunkel und die Audioquelle stumm geschaltet, bis sie wieder auf dem gleichen Weg aktiviert wird. Der Nutzer kann also theoretisch das ganze Orchester verstummen lassen, indem er alle Plattformen deaktiviert oder sich auf diesem Weg einzelne Instrumentengruppen gesondert anhören. Er ist nun mit wenigen Interaktionsmöglichkeiten in der Lage sich schnell in die Szene einzugewöhnen und trotzdem umfangreiche Auswirkungen auf das Geschehen zu haben.

Zuletzt spielt die Dirigentenplattform erneut eine gesonderte Rolle: Befindet sich der Nutzer auf der Plattform, werden allen Informationen gleichzeitig eingeblendet. Es entsteht ein Überblick ĂŒber das gesamte Orchester. Deaktiviert man jedoch die Plattform des Dirigenten, pausiert das gesamte Orchester und alle Musiker verharren in ihrer Bewegung. So lassen sich von der Übersichtsposition verschiedene Einstellungen im direkten Vergleich erproben.

MĂ€rz 30, 2019

10 – Transfer der Daten auf biomechanisches Modell

Da sich in der Endanwendung ca. 50 Musiker bewegen sollen, wurde nach einem Weg gesucht Rechenleistung einzusparen. Denn 50 Tabellen mit ĂŒber 40.000 Zeilen abzutasten und als Visualisierung auszugeben, kostet enorm Leistung. Dadurch wĂŒrde eine Verzögerung entstehen, welche die Bewegungen und das Audio nicht mehr synchronisiert darstellen wĂŒrden. Alle Musiker mĂŒssten also ein eine gebackene Animation umgewandelt werden, die bereits berechnet und gestaltet ist. FĂŒr die Animation von humanoiden Charakteren gibt es das .bvh Format. Dieses Format wird oft benutzt um Motioncapture Daten auf ein selbstdesigntes Model oder Mesh anzuwenden. Mit Blender gibt es per Python Script eine Möglichkeit die Daten der csv an ein vorgefertigtes Meta-Rig "anzuklemmen". Mit diesem Rig hat man deutlich mehr Gestaltungsspielraum und Mögklichkeiten mit der Bewegung zu arbeiten. Die Daten Hierarchie sieht folgendermaßen aus.

Das Blender Script lÀdt die csv datei ein und geht dabei die Spalten (Gelenke X, Y und Z) und die Zeilen (Frames) durch. Mit der Sortierung in ein Array werden die Werte dann in der bvh-Struktur an der entsprechenden Stelle eingesetzt.

import csv
import os
import bpy

objects = bpy.context.scene.objects

empties = []

for object in objects:
if object.type == 'EMPTY':
empties.append(object)

#Einladen der .csv-Datei

filename = '2_Geige_1_rounded_10.csv' #.CSV file name

fullpath = os.path.join(os.getcwd(), filename)

with open(fullpath, 'r', newline='') as csvfile:
ofile = csv.reader(csvfile, delimiter=',')

print(ofile)

#Hier werden per for-Schleife die einzelnen Koordiaten eingelesen

i = 0

for line in ofile:
frame_num = i
fpts = [float(p) for p in line]
coordinates = [fpts[18:21], fpts[15:18], fpts[12:15],
fpts[3:6], fpts[6:9], fpts[9:12],
fpts[39:42], fpts[36:39], fpts[33:36],
fpts[42:45], fpts[45:48], fpts[48:51],
fpts[24:27], fpts[30:33],fpts[30:33], fpts[30:33],
fpts[30:33], fpts[30:33], fpts[30:33], fpts[0:3]]

#Hier werden die Daten in die .bvh des Metarigs eingebettet

bpy.context.scene.frame_set(frame_num)
for ob, position in zip(empties, coordinates):
ob.location = position
ob.keyframe_insert(data_path="location", index=-1)
print(ob.name)

i += 1

bpy.data.objects['rig'].select = True

target_file = os.path.join(os.getcwd(), 'estimated_animation.bvh')

bpy.ops.export_anim.bvh(filepath=target_file)

 

Da ĂŒber 40.000 Zeilen konvertiert werden, wird das Script in der Shell ausgefĂŒhrt und nicht im Blender Interface. Wie auch im Post mit der Pipelineentwicklung haben wir per Bash Script eine Schleife erstellt die alle CSV Daten nacheinander umwandelt. In der Blender Datei muss allerdings noch voreingestellt werden, wie viele Frames konvertiert werden sollen. Die Einstellung dafĂŒr findet sich unten im Animationsarbeitsbereich. Der Rohbefehl ist dieser hier:

blender --background directory/csv_to_bvh.blend -noaudio -P directory/csv_to_bvh.py

An dieser Stelle vielen dank an Dene, auf dessen Script aufgebaut wurde und uns bei der Anpassung des Scripts geholfen hat.
https://github.com/Dene33

MĂ€rz 15, 2019

09 – RĂ€umlicher Klang im virtuellen Raum

Bei einer Virtualisierung eines Symphonieorchesters muss darauf geachtet werden, dass der Ton, den man in der Anwendung hören kann, auch einem solchen Orchester gemĂ€ĂŸ wird. Daher wurde fĂŒr die finalen Aufnahmen des Projektes ein Experte beauftragt, der das Orchester mit 64 Mikrofonen aufgezeichnet und in langer Post-Production abgemischt hat. Es wurde eng mit diesem Tonkutscher zusammengearbeitet, um die Audiospuren auf die VR-Anwendung zuzuschneiden. So wurde der Ton vorerst in die einzelnen Instrumentengruppen (wie 1. Violine, Bratsche, HolzblĂ€ser etc.) eingeteilt, da diese auch in der VR interaktiv auswĂ€hlbar sein sollen. Zu Anfang des Projekts war im GesprĂ€ch, alle Musiker als einzelne Tonspur auszugeben, es wurde sich allerdings dagegen entschieden, da das fĂŒr die VR-Szene eine große Belastung wĂ€re und fĂŒr den Tonmischer ein noch grĂ¶ĂŸeren Aufwand, jede einzelne Spur perfekt zu bereinigen.

Die Lösung lag hier in Stereo Spektren fĂŒr jede Instrumentengruppe. FĂŒr jede Gruppe wurde eine Stereo Datei angelegt, in der alle einzelnen Instrumente von links nach rechts im Panning-Spektrum verteilt sind. Der Klang hört sich also genau so an, als wĂŒrde man direkt vor dieser Gruppe stehen. FĂŒr die VR-Szene wurden diese Stereo-Sounddateien wieder in zwei Mono-Dateien zerlegt, da nur die zur rĂ€umlichen Soundverrechnung gut benutzt werden können. Das liegt daran, dass eine Stereo Soundquelle im Raum nicht wĂŒsste, in welche Richtung jeweils der linke und der rechte Kanal ausgehen wĂŒrden. Daher wird die Soundverrechnung – wie in echt – nur mit Mono-Sounds gemacht, die so im Raum platziert werden, dass der Stereo-Effekt wieder auftritt, wenn man sich im virtuellen Raum zwischen ihnen befindet. So stehen also immer an den Ă€ußeren Kanten der Gruppenplattformen jeweils die Tonquellen.

ZusÀtzlich zu den Spuren, die den Klang innerhalb der Gruppe darstellen, sind noch zwei weitere Tonspuren von jeder Gruppe erstellt worden, die mit einem starken Raumklang-Effekt versehen worden sind. Sie sind auf den Klang angepasst, den man von dieser Instrumentengruppe hört, wenn man am Platz des Dirigenten steht. Es ergeben sich also 4 Tonspuren pro Instrumentengruppe, zwei trockene (ohne Effekt) und zwei nasse (mit angewandtem Effekt), also zwei Monospuren auf der linken Seite und zwei auf der rechten Seite der Gruppe. Das eigentliche Abmischen im Raum passiert durch den Benutzer der VR-Anwendung, indem er sich im Orchester bewegt. Jede Soundquelle hat 2 Radii: Der erste Radius bestimmt, in welcher Reichweite man die Tonspur bei voller LautstÀrke hört, der zweite bestimmt, wann der Sound gar nicht mehr zu hören ist. Der VR-Benutzer bestimmt also durch seine Distanz zur Soundquelle, wie stark dieser bestimmme Sound zu hören ist.

Um alle Soundquellen im Orchester gut zusammenzumischen, mĂŒssen deshalb LautstĂ€rkelevels zwischen diesen Radii durch Bezierkurven angepasst werden, um einen realistischen Klang zu erzeugen, der sich immer aus den umliegenden Soundquellen zusammenstellt. Hier bekommen die Spuren mit Raumklang eine grundlegend andere Kurve als die trockenen Spuren, da sich die erst in den Klang mischen sollen, wenn man sich weiter von der Soundquelle entfernt. Gleichzeitig verstummt die trockene Spur schon nach einigen Metern, da der Raumklang dann ĂŒbernehmen soll.

Februar 17, 2019

08 – Entwicklung einer Pipeline zur Datenerstellung und Sortierung

Nach den Aufnahmen lagen Videos jedes Takes von den einzelnen Musikergruppen vor. Damit eine saubere Strukturierung der Daten möglich ist, haben wir uns dazu entschieden, die Musiker einzeln zu maskieren und in die Mitte des Bilder zu setzen, damit die 3D Transformation die Kameramatrix und -projektion richtig interpretiert und die Daten auf einen kleinen bestimmten Bereich zentriert werden.

Bild eines einzelnen maskierten Musikers


Diese Prozedur wurde fĂŒr alle Musiker durchgefĂŒhrt, dass am Schluss alle Videos geschnitten auf den aufgenommenen Klang vorlagen. Alle Videos mussten nun von Openpose im Stapel verarbeitet werden, um an die 2D .json Daten zu kommen. Da viel mit Linux gearbeitet wurde, hat hier ein Shell Script die Arbeit erledigt. Die Grundstruktur des Shellscripts wurde auch fĂŒr spĂ€tere Stapelverarbeitungen der Daten genutzt.

# read files in folder
for file in /path/to/directory/*
do
	path=$1
	filename=$(basename -- "$file")
	# strip filetype
	filename="${filename%.*}"
	filename_op="${filename%.*}_op"
	echo "File: $file"
	echo "Path: $path"
  	echo "File name: $filename"

  	# create output path for json & video
  	# echo "Creating output folder at"
  	# echo "$path/$filename"
  	# mkdir "$path/$filename"
		
  	echo "Executing openpose"
	sudo nvidia-docker run -v /path/to/openpose:/data -v /path/to/openpose/models:/openpose/models -it wenwu449/openpose:latest ./build/examples/openpose/openpose.bin --video /data/$filename.mp4 --write_json /data/Motiondata/$filename/ --model_pose COCO --number_people_max 1 --camera_fps 60 --write_video /data/Motionvideo/$filename_op.avi --display 0
	echo "openpose is done"

  	# convert to mp4
  	ffmpeg -i /Motionvideo/$filename_op.avi Isolation/Motionvideo/$filename_op.mp4 -hide_banner

	echo "AVI File converted to MP4"
  	
  	# delete avi
  	rm Isolation/Motionvideo/$filename_op.avi

	echo "AVI File deleted"

  	echo ""
  	echo "~"
  	echo ""
  	echo ""

done

Nachdem alle Videos von Openpose verarbeitet worden sind, wurde der Datensatz von 3D Baseline weiterverarbeitet. Über ein Shellscript wurde hier wieder auf die einzelnen Ordner zugegriffen, um die csv Tabellen fĂŒr die Bewegungsdaten der Musiker zu erstellen. Hier wurden der openpose Befehl, das Konvertieren zu .mp4, sowie das Löschen der .avi-Datei weggelassen und ausgetauscht durch den Befehl fĂŒr 3d-pose-baseline

Alle CSV Tabellen waren nun zur Weiterverarbeitung bereit. Da noch nicht sicher war, wie die Daten eingebettet werden, wurden die Datenmengen der Tabelle reduziert von XX MB auf YY MB. Durch ein Runden auf zwei Nachkommastellen aller Zahlen reduzierte sich die Zeichenmenge so, dass auch die Datenmenge nach unten ging. Über ein Shellscript wurden die Tabellen wieder im Stapel verarbeitet. Mit einem perl regex Befehl wurden die Zahlen in den Tabellen gerundet und gekĂŒrzt.

perl -i -pe 's/[-+]?\d*(?:\.?\d|\d\.)\d*(?:[eE][-+]?\d+)?/sprintf("%.2f",$&)/ge' $file

Es wurde viel Zeit investiert, die Daten immer im Stapel und nicht einzeln zu generieren, da das einfach mehr Zeit in Anspruch genommen hĂ€tte. Die Shell Scripte haben sehr viel Aufwand gespart und waren ein gutes Mittel Überblick zu behalten.

Nach der langen BeschÀftigung mit der Datenarchitektur, war das nÀchste Thema das Audio- und Klangbild im virtuellen Raum.

 

Januar 28, 2019

07 – Finale Aufnahmen mit dem Orchester

Am 21. und 22. Januar fanden die finalen Aufnahmen fĂŒr das Projekt statt. Im Festsaal der Freiheitshalle wurde aufgebaut fĂŒr eine große Aufnahmesession. Im Voraus wurde viel geplant, wie die Sitzordnung sein muss, damit kaum Verdeckungen der Musiker auftreten. Mit so vielen Leuten zusammenzuarbeiten und das zu koordinieren war allerdings nicht sehr einfach. Die folgende Skizze zeigt, wie der Aufbau in etwa geplant war.

Damit die Daten relativ sauber aufgezeichnet werden können, haben wir nach Instrumentengruppen segmentiert. Mit dem Dirigenten und dem Orchester wurde das vorher auch noch einmal besprochen. Die UmstĂ€nde waren fĂŒr alle sehr ungewohnt, da die Musiker nichtmehr auf ihrer BĂŒhne saßen sondern im Zuschauerraum. Auch klanglich war das fĂŒr die Musiker anders, weil sie weiter auseinander und luftiger saßen als auf der BĂŒhne. ZusĂ€tzlich zu den aufgestellten Kameras war ein Tonmeister anwesend, der alle Musiker einzeln mit Mikrofon abgenommen hat.

 

Insgesamt wurden 7 Takes des StĂŒcks „Charivari“ vom Komponisten HK Gruber durchlaufen. Take 6 und 7 wurden auch von 360° Kameras aufgenommen. Nach den 2 Tagen Aufnahmen wurde das ganze Material gesichtet und geordnet. Der nĂ€chste Schritt war, eine Pipeline zu entwickeln mit der diese Menge an Daten sauber weiterverarbeitet werden kann. Die Menge an Daten, die nach den Machine Learning Prozessen entsteht, war ungewiss trotz der anfĂ€nglichen Experimente mit den Frameworks.

November 13, 2018

06 – Gestaltung eines virtuellen Raums fĂŒr das Orchester

Von Anfang an war klar, dass die Musiker und der Klang des Orchesters einen Raum benötigen, in welchem man sich in der VR befindet und dort interagieren kann. Außerdem ist es fĂŒr den Nutzer extrem wichtig einen rĂ€umlichen Bezug zu haben, damit er sich nicht verloren fĂŒhlt. FĂŒr diese Aufgabe wurde erst einmal ein Objekt entwickelt auf dem sich die Musiker befinden und mit dem interagiert wird. Die Anordnung des Orchesters stand zur Diskussion, denn aufgrund der Anordnung wĂ€hrend der Aufnahmen gibt es EinschrĂ€nkung in der Weiterverarbeitung und der Ordnung im Raum. Der Aufbau des Orchesters geht in die Richtung des „deutschen Aufbaus“. Die ersten Violinen sitzen links und die zweiten rechts. Die BlechblĂ€ser, Hörner und Schlagwerk sitzen weiter hinten.

Damit fĂŒr den Nutzer ein Überblick des Orchesters bestehen bleibt, werden die Bereiche stufig nach hinten etwas höher angesetzt. Mit einem kleinen Raft und schrĂ€gen Elementen werden die Kanten mit dem Boden verbunden. Die eckige Gestalt der BĂŒhne greift die Formensprache des Raumes auf - dazu spĂ€ter mehr. Die Musiker nehmen Platz auf den Plattformen. Der Dirigent steht vorne auf der rautenförmigen Erhöhung.

FĂŒr die Umgebungsgestaltung gab es verschiedene wichtige Anhaltspunkte. Der erste war die Reduktion von Details und Realismus, da die Anwendung auf verschiedenen Plattformen anwendbar sein soll. Auch die Farbigkeit und Textur der Umgebung sollte nicht vom eigentlichen Geschehen ablenken. Deshalb war einer der EntwĂŒrfe heller und weißlich, der andere etwas dunkler. Zudem war es ausschlaggebend, den Unterschied bzw. Vor- und Nachteile zwischen einer offenen Gegend und einem geschlossenen Raum herauszuarbeiten. Da gegen den dunklen Entwurf entschieden wurde, werden die Ideen hierfĂŒr nur kurz erlĂ€utert.

Dunkel:

Man befindet sich auf einer großen runden Plattform und ist von einem Lichtschein und einem Low-Poly Terrain umgeben. Die BĂŒhne befindet sich mitten auf der Plattform. Es gibt wenig Ablenkung und man lĂ€sst sich sehr auf das Orchester ein. Allerdings fĂŒhlt man sich sehr verloren, weil die Umgebung unbekannt und sehr leer ist. Die dunkle Farbstimmung wirkte aber auf viele Tester sehr angenehm. Auf diese wurde im realisierten Entwurf hingearbeitet.

 

Heller:

In diesem Konzept wird ein geschlossener, indirekt beleuchteter Raum erstellt, der die Anmutung eines Konzertsaals gibt. Es gibt allerdings keine RĂ€nge oder PlĂ€tze fĂŒr Publikum. Der Raum existiert nur fĂŒr das Orchester und den Nutzer. Er besitzt sehr hohe Decken und weitlĂ€ufig Platz zu den WĂ€nden. Aufgrund der rĂ€umlichen Referenz und der Beleuchtung fĂŒhlt man sich hier deutlich wohler und vielmehr ins Geschehen eingebunden. Die WĂ€nde geben durch die verschobenen Quader eine Struktur, sodass die Wand gar keine materielle Struktur benötigt. Wenn man vom Dirigent in Richtung des Orchesters blickt, bildet der Raum eine Kraftlinie, die auf das Orchester fĂŒhrt. Das Objekt hinter dem Orchester wirft viel indirektes Licht in den Raum und gibt ein Zentrum, vor dem sich das Orchester befindet. Die Formensprache des Raumes ist sehr eckig und verschoben, damit Platz und FlĂ€che fĂŒr das Licht geschaffen wird. Durch das Licht wird die BĂŒhne an sich in den Vordergrund gerĂŒckt. Die folgenden Bilder verdeutlichen das Konzept des Raumes.

Wie Interaktion mit der BĂŒhne, den Musikern und dem Raum stattfindet, wird im Blogpost ĂŒber das UX- und Interaktionskonzept erlĂ€utert.

September 24, 2018

05 – Toolentwicklung zur Visualisierung der Daten

Als der Arbeitsstand weit genug war, um ein fertiges Datenset mit 3D-Koordinationsdaten aufzuzeigen, mussten wir natĂŒrlich ĂŒberprĂŒfen, wie sie qualitativ ausgegeben wurden. HierfĂŒr eigneten sich gut die Creative Coding Frameworks Processing oder p5.js, um einen schnellen Sketch zu entwerfen, der die Daten ausplottet. Daher wurde sich fĂŒr ein Webtool p5 entschieden, da man das einfach online einbetten und mit anderen Mitwirkenden teilen kann.

Hier wurde also die .CSV eingelesen, die aus dem 3D-baseline Tool ausgegeben worden ist. Um die irrelevanten Zahlen herauszufiltern wurde folgendes Array angewandt, dass die Iteratioinsrehenfolge im Code auf die relevanten Zahlenstellen in der .CSV verweist. Hier ist wieder zu beachten, dass eine Stelle fĂŒr 3 Zahlen (x, y, z) steht:

var relevant = [
0, // HĂŒfte Mitte 0
1, // HĂŒfte Links 1
2, // Knie Links 2
3, // Fuß Links 3
/*4,5,*/
6, // HĂŒfte Rechts 4
7, // Knie Rechts 5
8, // Fuß Rechts 6
/*9,10,11,*/
12, // Torso 7
13, // Nacken 8
14, // Hals 9
15, // Kopf 10
/*,16*/
17, // Schulter Rechts 11
18, // Ellbogen Rechts 12
19, // Hand Rechts 13
/*20,21, 22, 23, 24,*/
25, // Schulter Links 14
26, // Ellbogen links 15
27 // Hand Links 16
/*,28*/];

Es ergeben sich also die genannten 17 Stellen, die vom Sketch durch iteriert werden. Die Iteration lĂ€uft in mehreren Schritten ab. ZunĂ€chst wurde festgelegt, dass die Framerate des Sketches 60 Bilder pro Sekunde betrĂ€gt, mit: frameRate(60);. Um dann in jedem Frame des Sketches auch nur einen Frame der CSV auszulesen, wurde eine Variable erstellt, die sich jeden Frame um 1 erhöht und sich automatisch zurĂŒcksetzt, wenn die Frames der CSV Datei zuende gehen. So kann das zum Beispiel aussehen:

var index = 0;
var pose = out[index].split(",");
if (index < out.length-1)
index ++;
else
index = 0;

Mit der Variablen pose wird also ein Array aufgemacht, das durch die split-Funktion und dem index-Input immer die Koordinationsdaten des aktuellen Frames beinhaltet. Das bietet die Basis, um diese Koordinaten dem 3D-Raum zuzuordnen. Ein simples Skelett der 3D-Bewegung ergibt sich nun durch den nĂ€chsten Schritt der Iteration, indem pro Frame alle Joints des Skeletts nacheinander platziert werden. Das wird mit einer for-Schleife gemacht, die das relevant-Array abtastet. Jede Stelle aus dem relevant array muss hier verdreifacht werden, um in dreier schritten von Joint zu Joint zu kommen. SO ist 0*3 = 0, es werden also die Stellen 0, 1, 2 fĂŒr die x, y, z Positionen des ersten Joints angesprochen; 1*3 = 3 entspricht den Stellen 3, 4, 5 und so weiter:

for (j=0; j<relevant.length; j+=1)
{
  var x = parseFloat(pose[relevant[j]*3]);
  var y = parseFloat(pose[relevant[j]*3+1]);
  var z = parseFloat(pose[relevant[j]*3+2]);
  translate(x, y, z);
  sphere(jointsize);
}

So wird eine Kugel an die 3D-Position von jedem Joint gesetzt und es ergibt sich die Grundlage fĂŒr gestalterische Experimente. Eine einfache Variante, um die Gestaltung der CSV-Ergebnisse schnell verstĂ€ndlich zu machen, sind Verbindungslinien, die sich von Joint zu Joint ziehen. So werden aus einzelnen schwebenden Kugeln schnell eine humanoide Form, die man verstehen kann. Dazu muss ein zweites Set x, y, z – Daten erstellt werden, um eine Linie zu zeichnen. Im folgenden Beispiel werden fĂŒr die Joints des linken Beins (Stellen 1, 2, 3 im relevant-Array) eine Linie gezogen, die sie zum Joint verbindet, der im relevant Array eine Stelle zu vor kommt Daher relevant[j - 1]. Der Fuß wird also mit dem Knie, das Knie mit der linken HĂŒfte, und die linke HĂŒfte mit dem Root-Joint der HĂŒfte verbunden:

for (j=0; j<relevant.length; j+=1)
{
  var x = parseFloat(pose[relevant[j]*3]);
  var y = parseFloat(pose[relevant[j]*3+1]);
  var z = parseFloat(pose[relevant[j]*3+2]);

  if (j > 0 && j < 4) {
    var xl = parseFloat(pose[relevant[j - 1] * 3]);
    var yl = parseFloat(pose[relevant[j - 1] * 3 + 1]);
    var zl = parseFloat(pose[relevant[j - 1] * 3 + 2]);

    stroke(strokecolor);
    strokeWeight(strokeweight);
    line(x, y, z, xl, yl, zl);

  }

  sphere(jointsize);

}

Die Positionierung der Joints im Array erlaubt es leider nicht, immer mit j – 1 zu verbinden, daher sind einge if-Abfragen nötig, um die humaniode Figur zu erstellen:

j – 1: if (j > 0 && j < 4 ||
           j > 4 && j < 7 ||
           j > 7 && j < 11 ||
           j > 11 && j < 14 ||
           j > 14 && j < 17)
j - 4: if (j == 4)
j - 7: if (j == 7)
j – 3: if (j == 11)
j – 6: if (j == 14)

DarĂŒber hinaus kann man mit

viele noch viele andere visuelle Varianten erzeugen. Zum Beispiel lassen sich mit beginShape(); und vertex() Polygone erstellen, oder mit Vektoren und dem Lerp-Befehl 3-dimensionale Zwischenschritte zwsichen den Joints generieren.

Das Tool hat dem Projekt als QualitĂ€tsĂŒberprĂŒfung und gestalterisches Concepting Tool geholfen, da diese Struktur, die Daten auszulesen, auch spĂ€ter im Projekt in C# fĂŒr Unity eingearbeitetes werden konnte.

https://www.openprocessing.org/sketch/578388

Es wurde noch eine zweite Version des Webtools erstellt, um einen spĂ€teren Datensatz zu visualisieren, in dem die ĂŒberflĂŒssigen Werte schon rausgelöscht waren. Dazu wurde hier noch der Low-Pass Filter implementiert, der zum smoothen der Daten angewandt wurde.

https://www.openprocessing.org/sketch/685683

September 13, 2018

04 – Rekonstruktion der Openpose Daten in die dritte Dimension

Wenn man an Ganzkörper-Motion-Tracking denkt, denkt man zumeist erst an Systeme aus der Film- oder Videospiel-Produktion, die mit farbigen Referenzpunkten auf dem zu analysierenden Körper oder sogar Ganzkörper-AnzĂŒgen die Bewegungen sehr genau entnehmen. In diesem Forschungsprojekt musste jedoch ein bestimmter Rahmen an Kosten und Aufwand fĂŒr das Orchester eingehalten werden, der es nicht erlaubt hat, derartige Systeme zu benutzen. Daher war es eine umso grĂ¶ĂŸere Herausforderung, eine Àhnliches Tracking nur mit Kameras und Machine-Learning Frameworks zu erreichen. Um die gewonnenen Daten aus der 2D-Pose-Estimation in der gewollten Virtual Reality Umgebung darstellen zu können, musste der Schritt in die dritte Dimension noch getan werden. Da das Ergebnis des Openpose Trackings 2D-Pixeldaten sind, die abhĂ€ngig vom analysierten Video entstehen, musste eine weitere Pose-Estimation Komponente angewandt werden, um auch die 3-dimensionale Position der einzelnen getrackten Gelenkpunkte zu ermitteln.

Hierzu ließen sich im Internet viele kleine Experimente und AnsĂ€tze finden, die allesamt sehr spezifisch in ihrer eigenen Funktion waren:

https://github.com/chanyn/3Dpose_ssl
Hier wird versucht, die menschliche Bewegung volumetrisch anhand des sichtbaren Körpers herauszufinden.

https://github.com/ildoonet/tf-pose-estimation
Dieses Framework spezialisiert sich auf die live-Erfassung von Bewegungen

http://gvv.mpi-inf.mpg.de/projects/VNect/content/VNect_SIGGRAPH2017.pdf
Hier wird eine weitere Option zur Echtzeiterfassung geboten.

3D-pose-baseline, das Framework fĂŒr das wir uns entschieden haben, versucht anhand eines Datensatzes eine rĂ€umlich realistische 3D-Bewegung aus einem Video zu entnehmen, auf Basis des Open-Source Machine Learning Frameworks tensorflow und der Skriptsprache Python. Arash Hosseini, ein Mitarbeiter am Openpose-Projekt hat diese Methodik auf den Datensatz angepasst, der aus einer Video-Analyse von Openpose entsteht. So können wir direkt an unseren bisherigen Datensatz anknĂŒpfen:

https://github.com/ArashHosseini/3d-pose-baseline

Man gibt hier die Ordnerstruktur an, die von Openpose ausgegeben wurde und das Ergebnis ist eine .TXT-Datei, die die Information fĂŒr die gesamte Bewegung enthĂ€lt. Das Ergebnis-Datenformat wurde allerdings auf .CSV umgestellt, der Inhalt bleibt der gleiche (siehe unten).

Um 3d-pose-baseline zu verwenden, muss eine funktionierende Tesorflow Environment eingerichtet werden. WĂ€hrend dem Forschungsprojekt wurde fĂŒr Machine-Learning Ubuntu 18.04 verwendet, fĂŒr das alle folgenden Installationen gedacht sind:

https://docs.anaconda.com/anaconda/install/linux/
https://github.com/markjay4k/Install-Tensorflow-on-Ubuntu-17.10-/blob/master/Tensorflow%20Install%20instructions.ipynb

Sobald die Tensorflow-Environment installiert und initialisiert ist, können die Python-Befehle ausgefĂŒhrt werden, die wie folgend aussehen:

python src/openpose_3dpose_sandbox_out.py --camera_frame --residual --batch_norm --dropout
0.5 --max_norm --evaluateActionWise --use_sh --epochs 200 --load 4874200 --openpose
trackingdata/mid_coco_op/ --people 0 --out test

Dabei sind folgende Komponenten wichtig zu kennen:

src/openpose_3dpose_sandbox_out.py
Beschreibt das Skript, das mit dem Befehl ausgefĂŒhrt wird. Hier muss man den Pfad angeben, wo sich die .py-Datei befindet

--openpose trackingdata/mid_coco_op/
Hier wird der Ordner angegeben, der den Openpose-Datensatz enthÀlt.

--people 0 --out test
Das sind Flags, die zugeschrieben wurden; „people“ beschreibt per ID die Person, von der das Ergebnis erstellt werden soll und das Wort nach „out“ gibt an wie die auszugebene .CSV-Datei heißen wird. Hier ist die verĂ€nderte Datei:

Link mit erneuertem Python Modul folgt.

Die .CSV-Datei die durch diese Rechnungen erstellt wird, bezieht ihre GrĂ¶ĂŸe aus der Anzahl Videoframes, die berechnet wurden. Wenn man die Datei in Excel/Calc öffnet ergibt sich folgende
Datenstruktur: Zeilen in der Tabelle stehen fĂŒr die einzelnen Frames der Bewegung. Spalten bezeichnen die einzelnen Koordinaten, die die Bewegung zusammenstellen in der X-, Y-, und Z-Position. So sind zum Beispiel die Spalten 1, 2, 3 fĂŒr die x, y, z Position des Joints HĂŒfte-Mitte zustĂ€ndig, 4, 5, 6 fĂŒr HĂŒfte-Rechts, 7, 8, 9 fĂŒr Knie-Rechts und so weiter.

Die aus 3d-baseline exportierte .CSV hat immer 96 Spalten, von denen allerdings viele ĂŒberflĂŒssig sind und daher aus dem benutzbaren Datenset herausfallen. Übrig bleiben 51 Spalten, die fĂŒr 17 mal 3 Koordinaten, also 17 Gelenke stehen. Das folgende Array zeigt die Gelenke aus der .CSV, die benutzt werden und lĂ€sst unbenutzte Werte einfach weg:

int[] relevant = {

0, // HĂŒfte Mitte 0
1, // HĂŒfte Links 1
2, // Knie Links 2
3, // Fuß Links 3
/*4,5,*/
6, // HĂŒfte Rechts 4
7, // Knie Rechts 5
8, // Fuß Rechts 6
/*9,10,11,*/
12, // Torso 7
13, // Nacken 8
14, // Hals 9
15, // Kopf 10
/*,16*/
17, // Schulter Rechts 11
18, // Ellbogen Rechts 12
19, // Hand Rechts 13
/*20,21, 22, 23, 24,*/
25, // Schulter Links 14
26, // Ellbogen links 15
27 // Hand Links 16
/*,28*/
};

FĂŒr den spĂ€teren Gebrauch haben wir das Array lĂŒckenlos gelassen, da wir aus den Tabellen die ĂŒberflĂŒssigen Werte streichen und die CSV wirklich nur aus 51 Spalten besteht. Die Gelenke sind folgendermaßen zuzuordnen.