Generative Erzeugung von Design mit vvvv Bitte beachten Sie, dass die HTML Version vor allem dazu dient, die indizierbarkeit des Inhals durch Suchmaschinen zu erleichtern. Eine wesentlich lesbarere Version enthält dieses pdf.
I.) Die WerkdokumentationenIm Zuge des Werkteils wird vor allem auf die Funktionen von vvvv zurückgegriffen, die es erlauben, Metadaten für eine Bilddatenbank zu generieren. Diese sollen dann in XML Daten übersetzt werden, die alle benötigten Informationen für eine Publikation im Web und als druckfertiges pdf enthalten. Der Prozess, der für die Erstellung des Werkteiles eingesetzt wurde, lässt sich in 4 Schritte einteilen:
Auf Methoden zu Erstellung der Grafiken wird in Kapitel 2.3 und 2.4 eingegangen, der Prozess der Erstellung wird in Kapitel 2.6 beschrieben. Diese Werkdokumentation konzentriert sich deshalb auf die automatische Erzeugung eines Bildbandes (Anhang I.I) und einer Online-Bilddatenbank (Anhang I.II) Auf die Animierbarkeit von Patches für Live Projektionen als Visuals geht Anhang I.III genauer ein. Und die Strategien, die zur Entwicklung der Patches eingesetzt wurden, werden in Anhang I.IV beschrieben.
I.I Bildband Workflow Für das Management der Bilddaten und deren Kombination mit Meta-Daten wurde ein vvvv Patch angefertigt der ein XML File (siehe Kapitel 2.5) produziert, das alle gewünschten Informationen enthält. Dieses kann mittels des vvvv Patches (Abb. 26) jederzeit verändert werden, um Bildtexte oder die Reihenfolge der Bilder zu verändern. Des Weiteren können Meta-Daten auch direkt aus bestehenden Datenbanken oder anderen Quellen importiert werden.
Das Layout dabei auf Zweierpotenzen (0, 1, 2², 2², etc) und alle Raster sowie die Objektformen sind quadratisch angelegt. Dies soll die Verbindung mit vvvv widerspiegeln, wo das Quadrat überall zu finden ist, was das vvvv-Logo (graues Quadrat) beweißt.
Als Schrift kam die Cochin zum Einsatz, die auch für den vvvv-Schriftzug Verwendung findet. Dort in fett-kursiv, im Bildband auch im normalen Schnitt. Aus dieser Dokumentstruktur (Abb. 29) kann InDesign ein XML File generieren, das als Vorlage verwendet wird um vvvv so zu programmieren, dass es Bild- und Meta-Daten für InDesign generieren kann. Hier ein Beispiel XML File für ein zweiseitiges Buch: <?xml version=”1.0” encoding=”UTF-8”?> Mit diesem System ist es möglich, eine große Anzahl von Bildern zu verwalten und je nach Bedarf, ein Dokument (z.B. einen Katalog) vollkommen personalisiert zu drucken. So könnte z.B. ein Portfolio für die Bewerbung in einer Grafikagentur, je nach Spezialisierung der Agentur, unterschiedlich zusammengesetzt sein. Und das ohne großen Mehraufwand.
|
* ein Modul zur Umwandlung von 4 Eingangswerten in eine Farbe. |
Diese Module können nun im Kontrollpatch (Abb. 34) die Übersetzung der Faderbox-Werte in passende Werte für die Formgenerierung übernehmen (Abb. 43).
Allerdings wird es sich nie vermeiden lassen, dass für gewisse Umrechnungen kein Modul bereit steht, so dass diese Verbindungen dazuprogrammiert werden müssen, was Abbildung 44 zeigt. Anschließend (Abb. 45) werden die berechneten Werte direkt mit den entsprechenden Pins verbunden, so dass die benannten Eingabefelder Daten an die oberste Instanz (Abb. 35) übergeben können. Durch Kopieren und Verknüpfen mit den so geschaffenen Output-Pins kann nun im obersten Patch (Abb. 46) die Position jedes Faderbox-Reglers und die Veränderung jedes Wertes abgelesen werden.
Nun kann das Projekt getestet werden und meist finden sich noch viele Möglichkeiten, die Kontrolle des Users über den Patch zu optimieren und die Bedienbarkeit zu erleichtern. Dies führt zu den in Abbildung 47 und 48 gezeigten Kontrolloberflächen.
Alle nicht benötigten Knoten und Verknüpfungen lassen sich sperren und|oder verstecken, wodurch größtmögliche Übersichtlichkeit erreicht werden kann.
Der in dieser Dokumentation besprochene Patch ist eine stark vereinfachte Form des bei der Live Performance in der Arena Wien gespielten Patches. Zur Illustration der Vorgehensweise bei der Umwandlung eines statischen Projektes in ein dynamisches, sollte dieses Beispiel jedoch genügen.
Die Abbildungen 49 bis 54 zeigen Bilder dieser Live Visuals, die in Kombination mit den wunderbar passenden Texturen und Strukturen von Tanja Tomic entstanden. Zudem wird der hier vorgestellte Workflow anlässlich eines Vortrags bei der „Schmiede the Conference“ (www.schmiede.ca), einer internationalen Medienkulturkonferenz auf der Pernerinsel in Hallein, vorgestellt werden. Bei der Abschlussveranstaltung „FocusOn“ werden die selben Visuals in einer alten Salzfabrik projiziert.
Bei einem intuitiven Umgang mit vvvv verlässt sich der Designer mehr auf den Zufall und versucht, durch ein intuitives Auswählen und Verknüpfen von Knoten interessante Ergebnisse zu erzielen. Er weiß dabei nicht immer, was er macht und wie genau seine Eingriffe den Datenfluss zwischen den Knoten beeinflussen. Wenn etwas funktioniert, wird es beibehalten und wenn eine Intervention kein erwünschtes Ergebnis bringt, wird diese wieder rückgängig gemacht. Meist entstehen so äußerst organisch anmutende Patches, mit Verknüpfungen in alle Richtungen und keiner erkennbaren Strukturierung.
Der Datenfluss ist bei einem solchen Patch kaum noch nachzuvollziehen, was daher rührt, dass während der Erstellung nicht über eine logische Anordnung nachgedacht wurde, sondern alle Funktionen „gewachsen“ sind. Was gefiel blieb, was nicht gefiel, wurde gelöscht. Es kann auch sein, dass Knoten im Programm verbaut sind, die absolut keinen Sinn ergeben oder keinerlei Einfluss auf den Output vom Patch haben. Auch von einer „Evolution“ kann hier gesprochen werden, die, nach dem heutigen Wissensstand, auch nicht zielgerichtet, aber sehr wohl regulierend ist. Interessant ist hier, dass sich nach eingehender Analyse und Neuanordnung von solchen darwinistischen Patches sehr oft ein strukturierter Datenfluss herauskristallisiert, was auf eine gewisse Selbstorganisation schließen lässt.
Diese Methode bietet sich vor allem für Anfänger an, da nur ein minimales Grundverständnis notwendig ist um einen Einblick in viele Funktionen und vor allem die Logik von vvvv zu erhalten, die dann helfen, die nächsten Schritte zu machen.
Bei der zielgerichteten Methode wird ein Patch absolut logisch aufgebaut. Der Designer hat ein klares Ziel vor Augen und den Weg, den er dazu beschreiten muss. Dies erfordert natürlich mehr Wissen über vvvv als andere Ansätze, doch für Projekte mit genau festgelegtem Ergebnis ist dies der einzig zielführende. Das Projekt wird in logische Blöcke zerlegt und diese dann zu einem Ganzen zusammengefügt.
Dies gewährleistet eine relativ einfache Fehlersuche, da die Funktion von einzelnen Blöcken (auch Subpatches genannt) leicht getestet werden kann und der Datenfluss zwischen den Subpatches gut nachvollziehbar ist. Falls es zu Performanceproblemen kommen sollte, lassen sich hier leicht Möglichkeiten finden um die Leistung des Patches zu optimieren.
Vor allem in Produktionsumgebungen, in denen mehrere Leute an einem Projekt arbeiten, sollte eine solche Methode angewendet, werden um Nachvollziehbarkeit zu gewährleisten.
Bei der gesteuerten Arbeit mit vvvv handelt es sich um eine Kombination der zwei vorangegangenen Methoden. Nicht ganz so chaotisch wie die intuitiv gewachsenen Patches aber auch nicht so streng gegliedert und determiniert wie die konstruierten Patches der zielgerichteten Arbeit.
Der Designer muss dabei nur ein ungefähres Ziel vor Augen haben und eine grobe Vorstellung, wie der Patch aussehen könnte, um vvvv die gewünschten Bilder zu entlocken. Meist kommt dabei nicht ganz das ursprünglich geplante heraus, kann aber trotzdem den gestellten Anforderungen genügen.
Diese 3 Methoden sind allerdings nur als grobe Unterscheidungen zu sehen und es ist jedem selbst überlassen, den passenden Weg zu finden.
(c) by Thomas Hitthaler, ampop.net |
||