twwwr

Simon Kölsch: Hallo Lucas!

Lucas Dohmen: Wir werden heute über den Twwwr sprechen, das ist ein Kunstprojekt, in dem der Simon mitgewirkt hat. Und bevor wir damit anfangen, magst du dich ganz kurz vorstellen und sagen, wer du bist und was du bei INNOQ so machst?

Simon Kölsch: Ja. Hallo, ich bin der Simon, ich arbeite bei INNOQ ganz regulär, wie fast alle anderen Kollegen auch, als Senior Consultant und bin da ganz normal in Projekten tätig. Ganz oft mit einem Infrastruktur- oder Security-Hintergrund.

Lucas Dohmen: Ich hatte eben schon erwähnt, dass es sich ein bisschen um ein Kunstprojekt handelt, was hat denn INNOQ mit Kunst zu tun?

Simon Kölsch: Die Frage ist ja durchaus berechtigt, die kann man stellen. Vielleicht muss man da ein bisschen weiter vorne anfangen. INNOQ gibt es jetzt seit knapp 17 Jahren. Und dementsprechend ist auch das Logo, die Bildsprache und vielleicht auch ein bisschen die optische Aufmachung. Wir haben ja ab und zu mal die Artikel, die wir haben, gesammelt in einem kleinen Buch veröffentlicht, da ist eine Cover-Gestaltung dabei. Und man hat sich überlegt, das mit einer Agentur zusammen nochmal neu zu erarbeiten. Und im Rahmen von dieser Corporate-Identity-Vorbereitung hat man gesagt, es wäre vielleicht interessant, eine Kooperation mit einem Medienkünstler zu suchen, der zumindest in der gleichen Richtung mit der Technologie arbeitet, und das entstandene Material dabei irgendwie zu verwenden. Und dann kann man sich überlegen, wie man so ein Medien-Kunstprojekt fördert, zum einen mit Geld oder indirekt mit Arbeitszeit. Und in dem Fall war das tatsächlich eine Zusammenarbeit, beziehungsweise die Umsetzung eines Kunstprojektes von Matthew Plummer Fernandez, der digitale Kunstwerke eigentlich schafft und dabei habe ich ihn eigentlich in den letzten knapp 3 Monaten unterstützt.

Lucas Dohmen: Also, du warst da technische Unterstützung für den Künstler?

Simon Kölsch: Genau, wir haben einen Teil von diesem Projekt technisch umgesetzt.

Lucas Dohmen: Magst du ein bisschen was zu Matthew erzählen, was der sich überlegt hat und was vielleicht auch der Hintergrund ist von dem Twwwr?

Simon Kölsch: Matthew macht unter anderem, wie bereits gesagt, digitale Kunstwerke, wir werden da am besten seine Homepage verlinken, in den Shownotes, da kann man sich das auch einfach nochmal ein bisschen angucken, das macht dann wesentlich mehr Sinn. Man muss vielleicht zu dem Projekt, das wir jetzt umgesetzt haben, mit dem Namen Twwwr, geschrieben übrigens, wenn man das später in der URL aufrufen möchte, mit 9 ‘W’, sagen: Da gab es mehr oder weniger ein Vorgängerprojekt, in dem Matthew zusammen mit JODI, das ist ein relativ bekanntes Künstlerkollektiv, aus einem Niederländer und jemandem aus Brüssel, glaube ich, die haben schon mal 3D-Modelle im Internet gescraped, also einfach gesammelt, was die Leute so eingescannt haben, also hauptsächlich 3D-Scans, und offen zur Verfügung gestellt haben, die haben das eingesammelt und daraus neue Modelle erzeugt. Das heißt ganz viele verschiedene Objekte zu einem neuen Objekt arrangiert, indem sie die aneinander gesteckt haben. Und bei Twwwr ist die Idee, dass man eine Art endlos wachsenden Pfahl hat und diese 3D-Modelle aus dem Internet dazu verwendet, diesen Turm periodisch über einen langen Zeitraum wachsen zu lassen. Und das in etwa etwas entsteht, das ein bisschen an eine Social-Media-Wall oder Timeline oder ähnliches erinnert. Das ist die eine Komponente dabei. Und die andere Komponente ist die Idee, dass man als Besucher des Kunstwerkes, sei es in einer Ausstellung, über die wir später noch ein paar Worte verlieren können, sei es über die Homepage, ein Teil davon werden kann, indem man mal so ein Gesicht fotografiert und das verfremdet und dieses dann in diesem Tower-ähnlichen Totempfahl auftaucht.

Lucas Dohmen: Genau, das ist ein bisschen schwer sich das vorzustellen, ich würde einfach vorschlagen, dass man sich das an dieser Stelle mal anschaut. Wir haben den Link zu dem Twwwr mit ganz vielen 'W’s in den Shownotes. Du hast ja gesagt, du bist normalerweise ganz normaler Consultant bei INNOQ, hat sich das Projekt jetzt unterschieden von dem, was du sonst machst oder war das quasi normales Projektgeschäft für dich?

Simon Kölsch: Ich würde ja gerne sagen: Das war total abgefahrene Medienkunst, zumindest haben mir das die Kollegen auch lange vorgehalten, tatsächlich war es am Ende wie ein reguläres Projekt, das sind die gleichen Anforderungen, es ist selten, das man wirklich mal etwas hat, das man wirklich angucken kann und was man mal sehen kann irgendwo. Das ist bei der Arbeit ja sonst eher eine Ausnahme, würde ich sagen, und vielleicht war es ein bisschen mehr grüne Wiese, wie man das in Unternehmen oder Konzernen oder ähnliches kennt. Das heißt, hier waren wir in der Technologie relativ frei, wie wir das umsetzen. Wobei man auch da sagen muss: In jedem Projekt gibt es Vorgaben und Matthew hat mit Blender angefangen, diesen Turm zu erzeugen, und damit war ein Stück weit von der Technologie natürlich auch schon gesetzt.

Lucas Dohmen: Genau. Wir werden nachher nochmal ein bisschen mehr auf die Technologie eingehen, aber erstmal zu den Anforderungen, was für Anforderungen waren an dich gestellt für die Umsetzung, was musstest du machen, was war deine Aufgabe?

Simon Kölsch: Zum einen ist das Kunstwerk die eigentliche Homepage, die man besuchen kann, um diesen Twwwr zu sehen und entsprechend hoch- und runter zu scrollen, zum anderen haben wir im ZKM in Karlsruhe eine Ausstellung und da ist dieser Twwwr ein Teil davon.

Lucas Dohmen: Was ist das ZKM?

Simon Kölsch: Das ZKM ist eine Institution in Karlsruhe, die sich unter anderem mit Medienkunst beschäftigt. Da ist eine etwas größere Ausstellung, wir können die ja kurz erwähnen, das ist die Open Codes, die läuft noch bis zum August 2018, in dem man sich mit dem Thema Digitalisierung und Beeinflussung von dem, was man so als Technologie um sich herum wahrnimmt, auf die Gesellschaft beschäftigt. Und da gibt es eine Installation mit, man muss sich das so vorstellen, man hat eine Reihe an Monitoren, 5 an der Zahl, die mit einer recht hohen Auflösung übereinandergestapelt sind. Und da wird das Kunstwerk halt mit ein paar Metern Höhe dargestellt.

Lucas Dohmen: Aber das ist grundsätzlich dieselbe Software, die da zu sehen ist?

Simon Kölsch: Genau und dadurch hat sich das eigentlich ergeben, da wir eh so etwas wie eine Homepage brauchen, dass wir uns hier im Webumfeld bewegen und der Twwwr an sich, vereinfacht ausgedrückt, einfach eine Homepage ist mit entsprechenden Möglichkeiten auf die Webcam zuzugreifen und ein Foto zu machen, um selbst das Gesicht in den Twwwr zu bringen.

Lucas Dohmen: Okay und das heißt, die Leute, die da in der Ausstellung sind, die können da von sich auch live ein Foto hochladen?

Simon Kölsch: Richtig. In der Ausstellung gibt es ein Tablet, das davor entsprechend installiert wurde, da kann man dann selbst das Gesicht fotografieren, das ist allerdings die gleiche Homepage, wie die, die im Internet zu sehen ist, also da ist auch eine Interaktion irgendwo da.

Lucas Dohmen: Okay. Das heißt also, wenn ich zu Hause eins aufnehme, sieht man das auch in der Ausstellung.

Simon Kölsch: Richtig.

Lucas Dohmend: Du hast schon gesagt, dass der Twwwr aus ganz vielen 3D-Modellen besteht. Zum einen halt diese Gesichter, aber zum anderen sind da auch andere 3D-Modelle dabei, wie muss ich mir das vorstellen, wo kommen die her?

Simon Kölsch: Es gibt diese gesammelte Datenbank aus dem Netz mit frei verfügbaren 3D-Scans, ein Großteil davon stammt zum Beispiel von einer Adobe 3D-Scanner-App, die Leute konnten das dann in die Community hochladen und da hat man dann diese Objekte gesammelt und das ist nicht irgendwie auf einen bestimmten Bereich beschränkt. Das heißt, man hat 3D-Modelle von einer Bohrmaschine neben einem Puppenkopf neben jemandem, der sich komplett selbst gescannt hat und einem Buch, einer Ketchup-Flasche, das zieht sich komplett beliebig durch. Die werden von einem Algorithmus, den Matthew geschrieben hat, entsprechend übereinander angeordnet. Und so entsteht dann dieser Turm. Und aus dieser Datenbank von 3D-Modellen wird immer eins ausgewählt und auf das andere draufgestapelt.

Lucas Dohmen: Ist es denn jetzt abwechselnd ein 3D-Modell und ein Gesicht oder wie passiert das?

Simon Kölsch: In festen Zeitintervallen kommen neue Objekte dazu und mit den Gesichtern, das hängt davon ab, wieviele Leute dann eben ihr Gesicht hinzufügen. Das wird nicht nochmal irgendwie dadurch beeinflusst oder ähnliches.

Lucas Dohmen: Da ist ein ganz großes Zufallselement dabei.

Simon Kölsch: Genau. Der Turm selbst ist komplett generativ erzeugt.

Lucas Dohmen: Und du hast gesagt, das funktioniert mit Blender? Wie muss ich mir das vorstellen, sitzt da jetzt der Matthew live an seinem Blender an seinem Rechner und muss da hochladen oder…

Simon Kölsch: Also, am Anfang saß er da live und hat hochgeladen, was da aus Blender herausfällt. Also letztendlich besteht der Turm von den Grundelementen her aus diesen 3D-Modellen, das sind aber exportierte Fotos, das heißt in Blender existiert als 3D-Modell der Turm, es gibt eine Kamera und diese Kamera exportiert da Screenshots heraus aus dieser Szenerie. Und diese Screenshots werden dann entsprechend gespeichert und aneinander gepackt und so entstehen quasi nahtlose Übergänge zwischen den Objekten.

Lucas Dohmen: Aber der Twwwr ist ja theoretisch unendlich hoch, oder?

Simon Kölsch: Der kann unendlich wachsen und man kann auf der Homepage natürlich auch unendlich nach unten scrollen.

Lucas Dohmen: Muss Blender dann diesen gesamten Twwwr im Speicher haben, um das zu machen oder wie funktioniert das?

Simon Kölsch: Tatsächlich hat ja Matthew diese komplette Blender-Automatisierung geschrieben und er hat es relativ einfach gelöst, indem die Kamera in einer festen Position verbleibt in dieser Blender-Szene und einfach dieser Turm immer ein Stück nach unten rutscht. Das heißt, es wird ein neues Segment oben drauf gepackt und das letzte Segment im Twwwr wird gelöscht und dann wird er einfach ein Segment breit nach unten verschoben. Und so ist quasi sichergestellt, dass man nicht irgendwie ein 2GB großes 3D-Modell im Speicher halten muss oder ähnliches, sondern dass man diese Bilder hat, mit denen man arbeiten kann.

Lucas Dohmen: Das heißt den Gesamtturm, den gibt es niemals in Blender zu sehen, sondern das sind nur die exportierten Bilder, quasi Teilausschnitte von diesem riesigen Blendermodell sind?

Simon Kölsch: Genau richtig. Man muss noch sehen, was man da längerfristig natürlich noch baut, sowas kann man natürlich noch erweitern und periodisch Dinge exportieren, aber da der Algorithmus von Matthew für Blender auch geschrieben ist, wie die Bilder ausgewählt werden und so weiter, ist das einfach erstmal festgesetzt und da hat man einfach nicht die Möglichkeit, ein entsprechend großes Modell zu speichern.

Lucas Dohmen: Klar, aber das heißt, ich habe so wie bei Twitter oder so quasi eine Timeline vor mir, also oben erscheinen immer neue Dinge auf meinem Turm, wenn ich ihn anschaue?

Simon Kölsch: Genau.

Lucas Dohmen: Und wie hast du das umgesetzt, also du hast gesagt, das ist eine Webseite, was hast du dafür verwendet, um das zu bauen?

Simon Kölsch: Das ist der Teil, der tatsächlich grüne Wiese war, das heißt, da sind wir relativ frei, was wir da benutzt haben. Ich mache ab und zu mal etwas mit Node.js und habe da gute Erfahrungen mit gemacht und finde, im Gegensatz zu den ganzen Vorurteilen, die es da zu diesem Ökosystem gibt, alles nicht ganz so dramatisch und habe hier eigentlich eine Möglichkeit gesehen, relativ leichtgewichtig mit kleinen Services, die in Node geschrieben und in Docker-Container verpackt sind, das ganz gut umsetzen zu können. Ohne da jetzt groß Architekturdiskussionen aufmachen zu wollen oder so, das geht schon in eine Microservice-Richtung, und habe dann mit Node.js begonnen und damit quasi Blender instrumentalisiert und das hat ganz gut funktioniert.

Lucas Dohmen: Okay und wo läuft dieses ganze System? Läuft das bei uns im Server-Rack?

Simon Kölsch: Genau, da war natürlich sowieso die Frage: Wie bekommt man die Synchronisation mit dem ZKM, mit der Ausstellung, mit Karlsruhe hin und was da noch so alles dranhängt? Wir selbst haben ja keine, oder nur sehr wenig, Infrastruktur, das heißt, wenn wir so Lösungen umsetzen, gerne mit dem, was man so als Cloud bezeichnet, dabei wäre es auch wieder egal gewesen, was man da nimmt, aber wir machen das Rendern und die Anzeige von der Homepage komplett auf AWS-Infrastruktur. Konkret heißt das, da sind zwei Instanzen, die da laufen, ein relativ einfacher Reverse Proxy, der auch den Twwwr enthält, die entsprechenden Daten, die erzeugten Bilder speichern wir auch komplett im S3 storage layer von AWS und zu guter Letzt haben wir noch eine Maschine, die das Rendering übernimmt, die dann ein bisschen größer ist.

Lucas Dohmen: Das heißt, da läuft dann Blender in der AWS-Cloud drin?

Simon Kölsch: Genau. Dadurch, dass Blender gesetzt ist, hat man halt irgendwie das Problem, dass man mit Filemanagement umgehen muss, ich muss irgendwie mein aktuelles 3D-Modell speichern, das heißt, ich kann das ganz schlecht auf mehrere Maschinen verteilen oder ähnliches. Und ich muss eigentlich dafür sorgen, dass ich immer wieder die gleiche Umgebung habe, in der ich dieses Rendern ausführe. Es gibt natürlich irgendwelche Services, die man dafür auch benutzen kann, das haben wir jetzt noch gar nicht erwähnt. Auch hier unterscheidet sich dieses Projekt auch nicht von üblichen Projekten: Der Endtermin war halt gesetzt mit der Ausstellungseröffnung. Und ohne die Anforderungen konkret geklärt zu haben, hatten wir in etwa 3 Monate. Da war klar, wir brauchen eine Lösung, die ein Stück weit pragmatisch ist, die aber auch gut funktioniert. In dem Fall habe ich mich einfach dafür entschieden, Blender in einem Docker-Container zu benutzen, da gibt es natürlich auch entsprechende fertige Images. Und konkret funktioniert das Rendern dann so, dass in dieser Render-Maschine ein Docker-Container gestartet wird, versehen mit einer ganzen Reihe an Parametern, zum Beispiel, wo die 3D-Modelle zu finden sind, ob ein Gesicht im Turm auftauchen soll und so weiter. Und dieser Docker-Container, dieser single shot container, der einmal hochgefahren wird, direkt das Rendern beginnt und nach dem Rendern ein Bildsegment herausschreibt und sich dann wieder beendet, terminiert.

Lucas Dohmen: Das heißt aber, die Steuerung davon, dass da regelmäßig neue, einzelne 3D-Objekte dazukommen, die ist in einem anderen System abgebildet, die ist nicht Teil von dem Python-Skript?

Simon Kölsch: Richtig, genau. Dieses Python-Skript, das Blender steuert, das kann ich einmal aufrufen und habe dann einfach nur den Parameter ‘Pack mir bitte ein neues Segment an meinen bestehenden Turm ran’ oder ‘Mach ein neues Gesicht in die Totems rein’.

Lucas Dohmen: Okay, das heißt, wir haben diesen Blender-Container, der erzeugt Bilder, legt die dann in S3 hinein, wir haben diesen Container, der wie ein Taktgeber ist und neue Bilder da hinein packt, was hast du noch für Services in deiner Architektur?

Simon Kölsch: Wir können ja mal etwas konkreter darauf eingehen. Kern ist der Twwwr-Service, der zum einen diesen Turm generiert, das heißt, wir haben irgendwo bestehend schon unsere Bilder, die wir mit einem Timestamp entsprechend gespeichert haben, wir haben Metadaten, um die in dem Turm wiederfinden zu können und gleichzeitig haben wir eine API, die sowas wie /store hat, in dem ich dann einfach diese Bildsegmente abspeichern kann. Auf der anderen Seite haben wir auf einer anderen Maschine einen kleinen Node-Service, das sind gerade 100 Zeilen Code, der wartet eigentlich nur darauf, dass er irgendwie getriggert wird, indem entsprechend ein neues Bild eingefügt wird, also ein neues Gesicht, das im Twwwr auftauchen soll oder über ein Zeitintervall ein neues Rendering angestoßen werden soll. Die kommunizieren über eine Message Queue, nicht eine Message Queue, sondern tatsächlich eine Redis-Instanz, in Redis können wir ja einfach Datenstrukturen ablegen, zum Beispiel so etwas wie eine Queue, mit der wir dann mit push und pop arbeiten können. Die warten da einfach auf ein key change event, wenn ein neuer Trigger quasi in Redis gespeichert wird, bekommt der Renderer Services das mit, fängt an, zum Beispiel ein zufälliges Segment auszuwählen, baut es, rendert es und geht dann hin und pusht die Bilder zurück an den Twwwr-Service, die dann da gespeichert werden.

Darüber hinaus gibt es noch einen Service, der einfach nur die fotografierten Gesichter annimmt, das sind auch nur ein paar Zeilen Code, die einfach nur ein Bild speichern eigentlich. Das läuft aber auf der Rendering-Maschine, wir haben hier durch die Blender-Files und durch Textur-Files, die wir brauchen, halt die Einschränkung, dass wir mit dem File-System arbeiten müssen. Man würde ja jetzt erwarten, dass wir so einen API endpoint irgendwo vorne haben, und der nimmt halt das Bild entgegen und reicht es dann geschlossen weiter. Hier ist es eben so aufgebaut, dass es einen reverse proxy gibt, das ist einfach ein nginx Container, der da läuft, der nimmt die requests an. Und wenn er ein Bild bekommt, schickt er das direkt an den Bild-Service, der das einfach nur in das Dateisystem speichert und das housekeeping von den Files macht.

Lucas Dohmen: Und die Gesichter, die sind ja jetzt erstmal flache Bilder, wie werden die zu 3D-Modellen, wie muss ich mir das vorstellen?

Simon Kölsch: Genau, das ist der nächste Punkt, an dem man wahrscheinlich auch gerne ein halbes Jahr Projekt machen könnte, wie man da Bilderkennung macht. Wahrscheinlich wird man da zuerst einmal an etwas wie OpenCV denken, da gibt es ja relativ viele Tutorials, die so etwas wie facetracking auf Kamerabilder können und Kollegen haben beim INNOQ-Event auch mal eine bird view-Kamera für den Kicker gebaut und dann einen Ball verfolgt. Das Problem an der Stelle ist, dass ich am Ende einfach nur das erkannte Gesicht brauche. Und je komplizierter so eine build pipeline wird, desto schwieriger wird es, das zu managen und sinnvoll stabil zum Laufen zu bringen im Netz, wo die Leute darauf zugreifen können. In dem Fall haben wir einfach im Frontend jQuery, dafür gibt es ein Plugin, um die Gesichter auf zum Beispiel irgendwelchen Fotos zu markieren, so wie man das von Facebook oder Twitter kennt, da kann man Personen mit verknüpfen. Diese Gesichtserkennung funktioniert eigentlich, um einen Bildausschnitt zu bekommen, relativ gut. Egal, welche Lösung man sich da anguckt, da gibt es immer kleinere Probleme, und damit es richtig gut funktioniert und auf einem Server läuft, also nicht irgendein Skript, was irgendwer mal zum Testen auf Github gepackt hat, sondern zuverlässig als Library, hat sich angeboten, diese jQuery Library zu benutzen, und die schneidet im Client das Gesicht entsprechend aus und schickt dann dieses erkannte Gesicht zum Server.

Lucas Dohmen: Das heißt, wir kriegen ein freigestelltes Gesicht an den Server geschickt, richtig?

Simon Kölsch: Richtig.

Lucas Dohmen: Und dieses freigestellte Gesicht wird dann als Textur verwendet für ein beliebiges 3D-Modell.

Simon Kölsch: Nee, für eine eingeschränkte Auswahl an 3D-Modellen. Matthew hat als Künstler ja eine sehr präzise Vorstellung davon, wie dieser Twwwr optisch aussehen kann neben so Dingen wie den shadern, die benutzt werden und das Licht, das entsprechend den Twwwr ausleuchtet, gehören da natürlich auch die Objekte dazu, auf denen die Textur vom Gesicht landet. Und Matthew hat da eine Liste aus, ich glaube, 10 - 15 Objekten, das sind relativ einfache geometrische Formen, die aber so ein bisschen verzerrt sind. Man muss sich das vorstellen wie so einen Würfel, der dann oben zum Beispiel durch eine Verzerrung abgerundet ist. Auf diese Objekte wird dann das freigestellte Gesicht als Textur platziert und das als Teil im Twwwr gerendert.

Lucas Dohmen: Okay, das heißt, die anderen 3D-Modelle sind sehr, sehr zufällig, aber das ist schon kuriert, was da genau herauskommt.

Simon Kölsch: Genau.

Lucas Dohmen: Auf welche Probleme bist du denn gestoßen, als du das umgesetzt hast? Du hast ja schon über das File-Handling gesprochen, das nicht so einfach war. Gab es noch andere Sachen, die eine Herausforderung waren bei der Umsetzung?

Simon Kölsch: Ja. Wenn man das Projekt das erste Mal hört, denkt man sich: Naja, nach einer Woche hat man da etwas zusammengebastelt, das irgendwie funktioniert. Aber wenn man das ein Stück weiter denkt, kommt man sehr schnell an den ersten Punkt, wo man denkt: Okay, wir haben diesen unendlich großen Twwwr und man möchte bestimmt irgendwelche Teile in diesem Turm wiederfinden, zum Beispiel sein eigenes Gesicht oder ähnliches. Und am Anfang bin ich ganz gut damit ausgekommen, nur etwas wie einen Timestamp als Metainformation zu verwenden, das Problem dabei ist aber, dass uns bei einem Link auf ein gewisses Segment ja nicht ein Ergebnis von einer Datenbank, zum Beispiel ‘Gib mir alle Bilder, ordne die bitte nach dem Timestamp und das bitte absteigend und dann haben wir einfach eine entsprechende Timeline erzeugt’ interessiert, sondern wir brauchen genau ein Element in der Mitte dieses Turms und die fünf Elemente darüber und die fünf Elemente darunter. Und natürlich kann ich halbwegs mit SQL umgehen, aber ich mache das nicht ständig, täglich im Projekt. Und wenn die Queries komplizierter werden, dann sitzt man da schon eine Weile dran. Ich muss sagen, das hat schon irgendwie, zum Glück, mit einer gewissen Unterstützung von einem Kollegen, ganz gut funktioniert.

Lucas Dohmen: Aber das ist auch anders jetzt als beispielsweise bei Twitter, ne, wenn ich bei Twitter sage: Ich möchte in der Timeline einen bestimmten Tweet teilen mit irgendjemandem, dann teile ich immer den einzelnen Tweet, das wäre ja bei euch das einzelne Gesicht, aber das wollt ihr ja nicht, ihr wollte ja eine bestimmte Stelle in diesem endlos scrollenden Turm haben.

Simon Kölsch: Ja. Wenn man sich diese ganzen Timelines und social walls und so weiter anguckt, ich kenne das zumindest nicht, dass man auf eine gewisse Position in dieser Timeline verlinken kann, wenn man das so vergleichen möchte, sondern ich kann immer auf einen spezifischen Tweet linken und sehe dann aber nur diesen Tweet, ich sehe aber nicht den Tweet im Kontext von der kompletten Timeline, wie sie damals zu dem Zeitpunkt ausgesehen hat. Es ist verständlich, dass es auch nicht geht, zumindest ist es ein eher unübliches feature, aber hier in dem Sinne suchen wir ja wirklich eine konkrete Stelle in dieser Timeline wieder. Und so im Nachhinein ist es natürlich offensichtlich und natürlich wie man das löst, aber da kann man schon erstmal ein bisschen am Anfang beim Darübernachdenken darüber stolpern. Das nächste ist dieses endless scrolling. Ich möchte ja einfach auf dieser Homepage scrollen können und lade dann automatisiert die Bilder nach. Wenn ich jetzt an eine gewisse Position springe, dann muss ich plötzlich auch nach oben endlos scrollen und muss ab der Position entsprechendes paging implementieren, damit es die Bilder entsprechend nachlädt. Das sind so Dinge, da sitzt man dann schon ein bisschen länger dran und hat es auch nicht so alles frei Haus fertig als Frontend-Plugin oder ähnliches, da muss man dann ein bisschen was tun, damit das so funktioniert.

Lucas Dohmen: Und in der Ausstellung, der Turm, der scrollt automatisch, ne?

Simon Kölsch: Ja, das ist relativ pragmatisch gelöst, letztendlich ist es ein Browser in einem Kiosk-Modus, der über diese Monitore die Homepage anzeigt, es gibt Parameter, die dafür sorgen, dass das Menü nicht eingeblendet wird und er hat einfach eine feste Zeit, in der er sich neu lädt und das ist einfach mit einem HTTP header, mit einem meta refresh realisiert und da ist eine Zeit von, ich weiß es jetzt gerade gar nicht, 10 Minuten oder so eingestellt und dann kann man quasi den Turm hoch- und runterscrollen und nach 10 Minuten gibt es einen reload auf die komplette Seite.

Lucas Dohmen: Okay, also das heißt, die Leute in der Ausstellung können auch den Turm bewegen?

Simon Kölsch: Richtig. Die Idee dabei ist, dass wir diesen Turm über so ein scroll wheel komplett hoch- und runterscrollen kann und sich die Objekte darin ansehen kann.

Lucas Dohmen: Okay, es ist nicht ein Kunstwerk, das man nur anschaut, sondern man kann damit wirklich auch interagieren. Nicht nur etwas beitragen, sondern man kann sich darauf bewegen.

Simon Kölsch: Genau.

Lucas Dohmen: Okay! Und wie war das mit der Skalierung? Kommen da jetzt superviele Bilder rein, ich meine, das Rendern ist ja doch sehr aufwändig, wie gehst du damit um?

Simon Kölsch: Ja, da haben wir insofern ein bisschen die Problematik, dass das Rendern einfach Zeit braucht. Und da kann man lange auf dem lokalen Laptop bei sich probieren, wie man den möchte, relevant ist ja, was auf dem Server passiert. Das muss man einfach ausprobieren und messen. Und wir haben dann erst mit einer etwas kleineren AWS-Maschine angefangen und haben dann sehr schnell gemerkt: Okay, da muss die CPU halt rechnen und das geht auf den Speicher und sind am Ende bei einer, ich weiß gar nicht, C4-Large-Instanz gelandet, das heißt, wir haben 16 virtuelle CPU-Kerne darin und wir haben knapp 30GB Arbeitsspeicher und der Qualität, in der wir die Bilder da rausrendern, brauchen wir knapp eine Minute für diesen Rendering-Prozess. Man muss dazu sagen, das ist ein bisschen komplizierter, wir haben ja immer ein Segment, das der aktuelle Kopf von diesem Turm ist und diesen Kopf entfernen wir später wieder, weil wir rendern ja ein neues Objekt dazu und es ist nicht so, dass die Objekte immer bündig an der Bildkante aneinanderliegen, sondern die gehen ineinander über. Und deswegen müssen wir zwei Segmente immer generieren, also das neue Segment, das in diesem Twwwr auftaucht und der abschließende Kopf dadrüber, und da brauchen wir knapp eine Minute für und da ist die Maschine auch, also diese 16 Quad CPUs, die sind auf 100 Prozent und der Arbeitsspeicher ist auch relativ am Limit. Jetzt könnte man da noch eine Nummer größer gehen bei AWS, da ist noch ein bisschen Luft, aber das sind halt auch einfach Kosten, die da entstehen und am Ende kann man natürlich sagen: Okay, hätte man GPU-Instanzen benutzen können an der Stelle, aber zumindest das, was ich ausprobiert habe, in Kombination mit den AWS-Maschinen, hätte sich das kostenmäßig nicht rentiert, wir wären nicht so massiv schneller gewesen, weil wir hier halt an der Stelle trotzdem noch die Höhe skalieren können. Und zum anderen haben wir halt bei dem Setup Blender in einem Docker-Container laufen, und ich muss ganz ehrlich sagen, wie man das direkt mit den GPUs verheiratet bekommt, auf der Maschine, die auch nur irgendwie virtuell bei AWS sind, in einer bisschen älteren Version, da weiß ich gar nicht, ob sich das Setup eins zu eins so hätte übertragen lassen.

Lucas Dohmen: Das heißt, wenn jemand ein Gesicht einscannt, muss man ein bisschen warten und irgendwann erscheint das Gesicht? Oder wie muss ich mir das vorstellen?

Simon Kölsch: Genau. Wir haben so in etwa diese ein, zwei Minuten Rendering-Zeit, je nachdem, was da noch auf der Queue liegt, dauert das vielleicht ein bisschen länger, aber der Prozess ist: Man würde sein Gesicht fotografieren und einfach nach zwei Minuten die Seite nochmal neu laden, und dann sollte das eigentlich Teil des Twwwrs an der Stelle sein. Den Prozess könnte man wahrscheinlich nochmal wesentlich hübscher im Großen und Ganzen machen, aber da ist man dann in der Zeit irgendwann halt eingeschränkt, was das angeht.

Lucas Dohmen: Okay. Und wenn ich mir jetzt diesen Turm so vorstelle, wie groß muss ich mir den vorstellen? Kann man das ausdrücken, in Metern oder so?

Simon Kölsch: So ein Bildsegment im Twwwr sind 675 Pixel groß, das ist immer so eine Frage, wie rechnet man denn Pixel in Zentimeter um? Wenn wir jetzt einfach mal mit einer Faustformel sagen: Naja, die 675 Pixel, das entspricht in etwa so 17 Zentimetern, wir haben jetzt seit der Ausstellungseröffnung, das ist jetzt ein Monat, knapp 6.000 Segmente generiert und dann kommen wir irgendwie bei so einem Kilometer Turmhöhe im Moment heraus.

Lucas Dohmen: Einem Kilometer?

Simon Kölsch: Ein Kilometer, eigentlich. Wenn man sagt, ein Segment sind so 17 Zentimeter. Und der wird wahrscheinlich noch ein bisschen wachsen.

Lucas Dohmen: Und wie hoch ist der Bildschirmturm, den man in der Ausstellung sieht?

Simon Kölsch: Das sind 5 sehr große Monitore, die hochkant gedreht sind, man braucht eine Leiter, um die auszurichten und zu kalibrieren, die genaue Höhe in Metern kann ich jetzt nicht sagen, vielleicht 4 Meter in etwa, so um den Dreh.

Lucas Dohmen: Also man sieht schon einen ganz guten Teil von dem Turm, aber man müsste schon sehr lange scrollen, um den ganzen Kilometer…

Simon Kölsch: Der Kilometer passt da nicht so ganz drauf, genau. Das sind knapp 2.7GB an Bildmaterial, die dafür da sind, wobei man dazu sagen muss: Jedes Gesicht, was man selbst nochmal hochgeladen hat, das 3D-Objekt davon wird gespeichert und das kann man dann auch selbst nochmal herunterladen. Also diese 3D-Objekte, auch wenn die nicht sehr groß sind, das ist einfach nur die Gesichtstextur auf das geometrische Objekt gemappt, in ein Zip-File, die sind da auch mit gespeichert…

Lucas Dohmen: Aber ohne die Umgebung?

Simon Kölsch: …aber ohne die Umgebung, ohne den Turm, der da irgendwie drüber und drunter ist, genau.

Lucas Dohmen: Wieviel Code musstest du dafür schreiben, dass das alles funktioniert?

Simon Kölsch: Ich traue es mich ja gar nicht zu sagen, weil da wird ja jeder sagen: Was? So wenig? Das kann man ja an einem Wochenende alles machen! Ich habe vorher nochmal kurz irgendwie mit word count die Zeilen gezählt, ich muss auch ganz ehrlich sagen, der Code ist nicht minified und man kann das wahrscheinlich alles nochmal ein bisschen hübscher machen und so ein paar duplicate Code-Stellen gibt es, aber das ist trotzdem für das Frontend, für das ganze Scrolling, für das face capturing und so weiter sind das knapp 200 Zeilen JavaScript-Code. Und für das Backend, also der Haupt-Kernpunkt von dem Towwwer, das sind knapp 600 Zeilen, der Service, um die Gesichter zu speichern, um das housekeeping zu machen, sind knapp 130 Zeilen und der Service, der sich darum kümmert, Docker-Container mit Blender darin zu starten und die Ergebnisse an den Tower zu schieben, sind nochmal knapp 60 Zeilen. Und dann kommen wir so in Summe bei knapp 800 Zeilen Code für das Backend und 200 für das Frontend heraus.

Lucas Dohmen: Cool! Jetzt würde ich sagen, kommen wir nochmal zum Ende. Wenn ich mir das anschauen will, kann ich einfach zur Webseite gehen, das werden wir verlinken. Was ist, wenn ich mir das mal live anschauen will? Du hast es eben schon kurz erwähnt, das gibt es im ZKM?

Simon Kölsch: Das Kunstwerk ist natürlich im Internet. Da kann man das live ansehen. Zumindest mein Eindruck war auch, dass Matthew das so sieht. Das Kunstwerk ist ein digitales Kunstwerk. Wenn man trotzdem die Kunstinstallation sehen will, dann gibt es da die Möglichkeit, wie am Anfang schon erwähnt, im ZKM einfach in der Open Codes Ausstellung vorbei zu schauen, der Eintritt dort ist auch kostenlos und die geht noch bis zum August 2018.

Lucas Dohmen: Klasse. Dann vielen Dank für das Interview. Und den Hörern bis zum nächsten Mal beim INNOQ-Podcast!

Simon Kölsch: Danke für das Gespräch!

Lucas Dohmen: Tschüss!