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.

{1} Programmierte Grafik. Geschichte und Anwendung

Wenn in diesem Buch von „generativem Design“ gesprochen wird, bedeutet das, dass es ein Programm gibt, das Grafiken aufgrund von zuvor vom Designer programmierten Verhaltensweisen erzeugen kann.
Dies ist ein anderer Zugang zum Design als der gewohnte und deshalb soll in diesem ersten Kapitel geklärt werden, wie sich generatives (oder „programmiertes“) Design erzeugen lässt, welche Anwendungsprogramme und Entwicklungsumgebungen den Zugang dazu beschleunigen können und welches Grundwissen und welche Grundeinstellung dazu benötigt werden.

In Kapitel 1.1 wird erklärt, wie man generatives Design definiert. Was die klassischen Designtools leisten und welche Ansprüche deswegen an die generativen Tools gestellt werden müssen, soll in Kapitel 1.2 erläutert werden. In Kapitel 1.3 wird gezeigt, welche etablierten Technologien verfügbar sind um programmiertes Design zu erzeugen und dass diese vom Benutzer einige Programmiererfahrung fordern. Das ist der Grund, warum in Kapitel 1.4 eine grafische Strategie vorgestellt wird, die sich auch für erklärte Nicht-Programmierer anbieten könnte.

1.1. Über generatives Design

In diesem Kapitel wird “generatives Design” definiert. Dazu werden einige Definitionen aus verwandten Forschungsgebieten herangezogen werden, da es im Designkontext keine eindeutige Definition zu geben scheint.

1.1.1. Arte programmata und OpArt

Eine sehr schöne Entsprechung, die allerdings in einem Kunstkontext steht, ist der, 1962 von Umberto Eco geprägte, Begriff „arte programmata“. Im Vorwort des Kataloges zu einer von Bruno Munari und Giorgio Soavi organisierten Kunstausstellung in Mailand schreibt er:

Da keine gesicherte deutsche Übersetzung dieser Aussage Ecos gefunden werden konnte, muss eine Übersetzung des Autors genügen:

Eco sagt also, dass ein direkter Zusammenhang zwischen den bei der Ausstellung gezeigten Arbeiten und ihrer zugrunde liegenden Struktur, aus den Werken selbst hergestellt werden kann, da ihre Ausführung auf sehr präzisen formalen Vorgaben beruht, welche die Freiheit nicht einschränken, sondern ihr nur richtungsgebend sind. (vgl. Eco 1962, 23). Es gibt also einen thematischen oder szenischen Zusammenhang, der einem komplexen oder mehrteiligen Kunstwerk zugrunde liegt, aufgrund dessen ein Künstler sein Werk schaffen kann.
Zuerst werden Regeln definiert und durch die Einhaltung dieser führt das zu einem programmierten Ergebnis.

Während die „Arte programmata“ nur in Italien ein Bestandteil der Kunstszene zu sein scheint, haben Spielarten der von Eco beschriebenen Strömung (Anmerkung: Eco selbst ist kein Künstler der Arte Programmata, sondern hat nur den Begrff geprägt!) starke Popularität erfahren. Die „Op Art“ (ein 1964 von George Rickey geprägter Begriff) war zwar nie so populär wie die gleichzeitig herrschende Pop Art, schaffte es aber dennoch, 1963 ein wichtiger Bestandteil der Modebranche zu werden.

Ziel von Vertretern dieser Kunstrichtung, unter anderem Josef Albers, Victor Vasarely und M.C. Escher (siehe Abb. 1), war es, die Sinne zu überlisten und Täuschungen zu schaffen.

Es werden also mathematische Verhältnisse gesucht, die gewisse Effekte erzielen und diese dann zu einem Kunstwerk verarbeitet.

1.1.2. Einführung in die programmierte Bildgenerierung

Diese, im vorigen Kapitel angesprochenen mathematischen Verhältnisse können in sogenannte „Algorithmen“ übersetzt werden. Obwohl in der ersten Hälfte des 20. Jahrhunderts eine ganze Reihe von Ansätzen entwickelt wurden, um zu einer genauen Definition des Begriffs „Algorithmus“ zu kommen, gibt es nach wie vor keine allgemein akzeptierte Definition des Begriffes. Unter anderem hat Alan Turing eine formale Maschine zur Berechnung von Algorithmen (die Turing-Maschine) konstruiert, welche die folgende Definition eines Algorithmus ermöglicht:

In Verbindung mit der Church-Turing-These („Jedes intuitiv berechenbare Problem kann durch eine Turingmaschine gelöst werden.“, Church 1932) und der Tatsache, dass sich eine Turingmaschine von einem Computer simulieren lässt, kann ein Programm geschrieben werden, das Algorithmen berechnen kann. Turings Einschränkung, dass diese Berechnungsvorschrift auch zu einem Endergebnis führen muss, ist damit allerdings noch nicht sichergestellt. Der Begriff der Berechenbarkeit ist dadurch definiert, dass ein Problem nur berechenbar ist, wenn es eine Abbruchbedingung für ein gewisses Problem gibt, d. h. wenn eine entsprechend programmierte Turing-Maschine das Problem in endlicher Zeit lösen kann. Sonst würde eine Endlosschleife entstehen, die nie ein Ergebnis zurückliefern würde. Der Positivist Wittgenstein sagte in Bezug auf die menschliche Kreativität etwas ganz ähnliches: “Wenn sich eine Frage überhaupt stellen lässt, so kann sie auch beantwortet werden.” (Wittgenstein 1921).
Legt man diese Aussage auf ein Problem im Kunst- und Designkontext um, bedeutet dies, dass jedes Werk, das sich explizit in ein formales Regelwerk übersetzten lässt, auch als maschinenlesbarer Algorithmus beschrieben werden kann. Für generatives Design im Sinne dieses Werks, scheint demnach die von Peter Weibel gelieferte Definition passend:

Der erste für einen Computer gedachte Algorithmus wurde 1842 von Ada Lovelace, in ihren Notizen zu Charles Babbages Analytical Engine (vgl. Stein 1984), festgehalten. Sie gilt deshalb als die erste Programmiererin. Weil Charles Babbage seine Analytical Engine nicht vollenden konnte, wurden Ada Lovelaces Algorithmen nie darauf implementiert. Als Beispiel für die Illustrierung des Begriffs Algorithmus soll der Euklidische Algorithmus dienen, der bereits um 300 v. Chr. beschrieben wurde und noch immer für die Ermittlung des größten gemeinsamen Teilers zweier natürlicher Zahlen A und B Verwendung findet:

Algorithmen können sehr viele Rechenschritte erfordern um zu einem Ergebnis zu gelangen und oft sind tausende Berechnungsschritte notwendig bevor ein Wert zurückgeliefert wird. Diese Rechnungen stur durchzukalkulieren war früher die Aufgabe von Studenten und Gehilfen, da zur Erfüllung ihrer Aufgabe nur ein minimales Grundverständnis der Mathematik benötigt wird. Die große Herausforderung ist die Konstruktion eines sinnvollen Algorithmus, nicht dessen Berechnung.
Die sich rasant entwickelnde Computertechnologie, angefangen bei mechanischen Rechenmaschinen über Relais und Elektronenröhren bis hin zu Transistoren und deren ständige Verkleinerung, bildete stets die Grundlage für die Berechnung immer ausgefeilterer und komplexerer Algorithmen in immer kürzerer Zeit und mit größerer Präzision. Der Mensch hat so die Abarbeitung von Entscheidungsverfahren in eine Maschine ausgelagert. Für mehr Information zu Algorithmen und deren Berechnung empfiehlt sich die Lektüre von „Einführung in die Automatentheorie, Formale Sprachen und Komplexitätstheorie“ (Hopcroft 2002).

Um nun den Bogen zurück zum ursprünglichen Thema, der Anwendung von Algorithmen in Kunst und Design zu spannen, wird eine wichtige Gemeinsamkeit von Op Art und arte programmata herangezogen: beide stellen Regeln auf, die zu befolgen sind, um ein gewünschtes Resultat zu erzielen. Und beide verwenden mathematische Algorithmen dazu.
Die von den mathematischen Berechnungen gelieferten Ergebnisse wurden von den Künstlern dieser Kunstströmungen meist händisch auf ein Medium (z.B.: Leinwand) übertragen. Für die in diesem Werk verfolgten Zwecke wird jedoch, sowohl für die Berechnung als auch für die Darstellung, ein Computerprogramm verwendet. Es sollen Regelsysteme mit Hilfe von Algorithmen aufgestellt und diese dann in den Computer eingegeben werden. Alles Weitere soll frei von menschlicher Intervention vonstatten gehen und vollautomatisch ablaufen.
Während es Leonardo Da Vinci 1509 noch ziemlich schwer hatte, die festgelegten Proportionen seines „Uomo Vitruviano“ (Abb.2) selbst zu berechnen und einzuhalten, könnte er heute einen Computer so programmieren, dass dieser, ohne Leonardos zutun, sicherstellen würde, dass die zuvor definierten Regeln eingehalten werden. Alles, was außerhalb dieses Regelsystems liegt, könnte er dann noch auf gewohntem (dem händischen) Weg ergänzen.

Genauso wie es der Computer erlauben würde, den, nach Leonardo Da Vincis Vorstellungen, perfekten Menschen automatisch zeichnen zu lassen, kann ein Computerprogramm einem Designer helfen, ein gewünschtes Design zu erzeugen.
Allerdings nur, wenn sich das zu erzielende Resultat so formulieren lässt, dass es der Computer umsetzen kann. Ist dies geschehen, braucht sich der Designer nur noch das für seinen Zweck schönste Design auswählen und dieses dann entweder unverändert übernehmen oder beliebige Änderungen mit anderer Software vornehmen. Jedes einzelne Element oder jede beliebige Gruppe von Elementen kann, bei entsprechender Vorarbeit, direkt als Ebenen in ein Bildbearbeitungsprogramm importiert werden. Hier bieten sich dem Designer wieder alle gewohnten Möglichkeiten des klassischen Designs mit dem Computer, aber er muss nicht mit einem leeren Dokument starten, sondern hat schon passendes Ausgangsmaterial, dem er nur noch den letzten Schliff geben muss. Selbstverständlich hat er auch die Möglichkeit, im Zuge seiner Nachbearbeitung das gesamte Design so zu verändern, dass es mit dem automatisch generierten Ausgangsmaterial kaum noch Ähnlichkeiten aufweist. Jedem ist hierbei selbst überlassen inwieweit, wenn überhaupt, eine weitere Bearbeitung des generierten Materials notwendig ist. Die automatisch erzeugten Design-Rohlinge können auch nur zur Ideenfindung benutzt werden und daraus dann ein endgültiges Design entwickelt werden, das den generierten Vorlagen mehr oder weniger ähnlich sein kann.

1.1.3. Generatives Design im Sinne des beiliegenden Bildbandes

Auf den ersten Blick scheint es sehr viele Beispiele für algorithmische Kunst zu geben, doch keinerlei Entsprechungen im Designkontext.
Bei einer etwas genaueren Betrachtung der Aufgabengebiete und der geschichtlichen Entwicklung von Design lassen sich jedoch einige Parallelen zu generativem Design finden. So war das, einst nur von Druckern und Textsetzern ausgeübte, Design-Handwerk frei von künstlerischen Idealen und verfolgte nur kommerzielle Ziele. Die Arbeit des Textsetzers war den strengen Regeln und Einschränkungen des Bleisatzes unterworfen. Erst das Bauhaus ermöglichte um 1920 die Emanzipation des Designs.
Von der Idee getrieben, die ökonomischen Barrieren zu eliminieren und während der Depression in Deutschland allen ein besseres Leben zu ermöglichen, hinterfragten die Vertreter dieser Strömung (u.a. Walter Gropius und Ludwig Mies van der Rohe) die althergebrachten Konventionen. Die vom Bauhaus eingeführte Verschmelzung von künstlerischen Idealen mit dem sehr mechanisch betriebenen Handwerk führte, auch durch Einflüsse von Kubismus und Konstruktivismus, zu einer neuen Bildsprache, die mehr war als ein bloßes Handwerk, aber trotzdem viel zweckgebundener als die Kunst.
Begriffe wie Ästhetik und die Diskussion um das Verhältnis zwischen Design und Kunst erlangten große Bedeutung. Was vielen Designern auf diesem Weg verloren ging, ist die Fähigkeit den Designprozess zu beschreiben. Ein Handwerker vermag jeden Schritt seiner Arbeit zu erklären, der Designer erlangte jedoch, dank der Kunst, die Freiheit, sein Werk unkommentiert und undokumentiert zu lassen.
Es gibt jedoch Bereiche, in denen ausführliche Erklärungen unerlässlich sind: bei Design Manuals. Diese müssen alle Regeln und Richtlinien enthalten um die korrekte Umsetzung einer Corporate Identity, auch von wenig qualifizierten Mitarbeitern, sicherzustellen.
Und wenn diese Regeln gut durchdacht sind, können sie das Bestehen eines Erscheinungsbildes für Jahrzehnte ermöglichen. Als Beispiel soll das, 1956 von Paul Rand entwickelte, IBM-Erscheinungsbild und das dazugehörige Logo dienen. Durch einen modularen Aufbau, der es ermöglicht das Logo den unterschiedlichsten Situationen anzupassen, wurde ein zeitloses Markenzeichen geschaffen, das nach 50 Jahren immer noch eingesetzt wird (vgl. IBM, 2004) Die Mutationsmöglichkeiten des Logos sind im Design Manual exakt vorgeschrieben, so dass sie auch einem Computerprogramm als Regelwerk eingegeben werden könnten, um jedes angefertigte Schriftstück auf Regelkonformität zu überprüfen oder sogar um automatisch Designstücke herzustellen. Auch wenn sich ein Design Manual wahrscheinlich nie vollständig als ein von einem Computer verarbeitbares Regelwerk umsetzen lassen wird, so sind zumindest Teilaspekte als Algorithmen programmierbar.
Sobald es eine exakte Beschreibung eines Handlungsablaufes gibt, kann es auch ein Computerprogramm geben, das die beschriebene Aufgabe ausführen kann. Dazu muss sich der Designer allerdings Gedanken über die Struktur dieses Handlungsablaufes machen, einen entsprechenden Algorithmus konstruieren und diesen dann in ein ausführbares Programm verwandeln, das dann das gewünschte Ergebnis zurückliefert. Auch hierfür kann Paul Rand als Vorbild betrachtet werden, da auch er während des Designprozesses stets mehr geschrieben als gezeichnet hat (vgl. Hefland 2001,147f): So fertigte er für seine Kunden stets detaillierte Berichte über seinen Arbeitsprozess und dessen Fortschritte an. Seine Fähigkeit Ideen verbal auszudrücken, machen ihn zu einem Musterbeispiel für einen generativ denkenden Designer.Laszlo Moholy-Nagy, ein Pionier der Typografie und Professor am Weimarer Bauhaus schrieb über Rand: “an idealist and a realist using the language of the poet and the businessman. He thinks in terms of need and function. He is able to analyze his problems, but his fantasy is boundless.” (Moholy-Nagy 1933)

Um nun zu einer exakten Definition von generativem Design zu gelangen, werden die Definitionen von „Arte Programmata“ und „Op Art“, unter Zuhilfename des Begriffs „Algorithmus“, verwendet und um einige für den Designkontext wichtige Aspekte erweitert. Was dabei von den kunsttheoretischen Definitionen übernommen wird:

Einschränkungen, die vorgenommen werden:

Die Punkte, die als Einschränkungen angeführt sind, gelten nur in Bezug auf den beiliegenden Bildband und stellen keine allgemein akzeptierten Prinzipien dar. Da nähere Ausführungen zu Thema Farbe, 3D Animation und Programmierung den Rahmen gesprengt hätten und für die Produktion des Bildbandes nicht relevant waren.
Ein wichtiger Punkt in Bezug auf die benötigten formalen Regelwerke ist die Feststellung, dass sich generatives Design auf einer anderen Stufe abspielt, als das Klassische. Der Designer denkt nicht mehr darüber nach, wie er einzelne Objekte manuell positionieren soll, sondern überlegt, welche Befehle und Algorithmen ein Objekt generieren können, das seinen Vorstellungen entspricht.

Es ist daher angebracht von „Meta-Design“ zu sprechen. Auf dieser höheren Ebene sind ganz andere Strategien notwendig um Design zu erzeugen. Der gewohnte Vorgang, eine leere Arbeitsfläche mit den benötigten Objekten (Bilder, Texte, Ornamente, usw.) zu füllen und diese dann so lang zu manipulieren bis ein ansprechendes Ergebnis erreicht ist, ist bei der Programmierung eines generativen Designs so nicht anwendbar, was auch den Vergleich mit nicht-generativem Design verkompliziert.
Der Designer ist demnach gezwungen, seine Vorstellungen in formal eindeutige Beschreibungen zu übersetzen und die Umsetzung des entstandenen Regelwerkes anschließend der Maschine zu überlassen.

Die in dieser Arbeit propagierte Definition des „generativen Designs“ ist stark auf die Form fixiert, was durch die selbstaufgelegte Beschränkung auf Grundformen und den Verzicht auf importierte (d.h. vorgefertigte) Daten zum Ausdruck gebracht wird. Dies soll jede Ablenkung durch nicht-generative Elemente (Bilder als Texturen oder andere importierte Objekte) verhindern. Des Weiteren werden sich die generierten Beispiele auf Graustufen beschränken, da Farbe eine weitere Ablenkung von der Form sein kann.

Unsere Definition lautet demnach:

Diese Definition beachtend, werden nun Methoden analysiert, welche die Erstellung von generativem Design erlauben sowie Werkzeuge gewählt, die die gestellten –und noch zu stellenden– Anforderungen bestmöglich erfüllen.

1.2. Die Ansprüche an generatives Design

John Maeda, einer der Pioniere auf dem Gebiet des generativen Designs, stellt in seinem Buch „Design by Numbers“ die von ihm entwickelte Programmiersprache DBN (Design by Numbers) vor. Diese Sprache erlaubt über einen textbasierten Editor das Zeichnen von Punkten und Linien und stellt zudem einfachste Funktionen bereit, um diese Objekte nach definierten Regeln automatisch zeichnen zu lassen. Anhand dieser Programmiersprache führt Maeda, der die Professur für Media Arts & Sciences am MIT Media Lab innehat, den Leser in die grundlegenden Konzepte von computergeneriertem Design ein.
Dabei sieht Maeda den Computer als Werkzeug um Ideen zu verwirklichen, die mit analogen Werkzeugen wie z.B. einem Pinsel, nicht umsetzbar wären. Im Zuge seiner Ausführungen hebt er ganz klar hervor, dass es für ihn zwei verschiede Arten von digitalen Werkzeugen gibt: Solche, die analoge Methoden nur simulieren und solche, die vollkommen neue Möglichkeiten eröffnen.

Die wahre Herausforderung bei der Benutzung von digitalen Designwerkzeugen ist es also, jene Möglichkeiten des neuen Mediums zu nutzen, die über die Möglichkeiten der analogen Werkzeuge hinausgehen. Da Computer sehr viele Befehle sehr schnell ausführen können schlussfolgert Maeda, dass „computation“ (d.h. Berechnung, Errechnung) die natürlichste Methode ist um Design mit dem Computer zu erzeugen:

Dabei geht er sogar noch weiter indem er schreibt dass die Kombination von traditionellen Kunstformen mit der Computertechnologie keine wahre digitale Kunst sein kann, sondern nur eine digital-verstärkte, aber noch immer analoge Kunst. „True digital art embodies the core characteristics of the digital medium, which cannot be replicated in any other“ (Maeda, 2001, 251) Das Ziel von „Design by Numbers“ ist es, mit Hilfe von DBN ein grundlegendes Verständnis der Formgenerierung mit einer Programmiersprache zu vermitteln. Dabei ist für Maeda der Prozess des Programmierens und die Eleganz des Programmcodes ebenso wichtig, wie das erreichte Ergebnis.
Diesen Ansatz soll auch der in diesem Werk verwendete Begriff “generatives Design” verfolgen. Da sich die Methoden von generativem Design stark von denen des klassischen Designs (welches analoge Techniken nur mit digitalen Werkzeugen simuliert) unterscheiden, wird der Vergleich der zwei Welten auf der Ebene des Funktionsumfanges der verfügbaren Werkzeuge stattfinden.
Welche Möglichkeiten stehen dem Designer jeweils zur Verfügung und auf welche Funktionen muss dieser eventuell verzichten?
Da die Firma Adobe plattformübergreifend eine Rolle als Marktführer (vgl. Cnet, 2005) eingenommen hat, dient deren Software, insbesondere Photoshop CS als pixelbasiertes Bildbearbeitungsprogramm und Adobe Illustrator CS als vektorbasiertes Illustrationsprogramm, als Vergleichsgrundlage. Zur Einführung in Illustrator und Photoshop empfehlen sich die „Photoshop Cs Bible“ (McClelland 2004) und „Classroom in a Book: Adobe Illustrator CS“ (Adobe 2003).

Um die Leistungsfähigkeit von Software für die Erstellung von generativem Design zu messen, soll die Betrachtung der Werkzeuge in 5 Themengebiete gegliedert werden. Dies ermöglicht die Betrachtung von Gemeinsamkeiten und Unterschieden zwischen generativem- und klassischem Design:

Das Wichtigste hier ist, dass das verwendete Tool mehr als nur eine Aufgabe erfüllen muss. Eine Software, die nicht modifizier- und erweiterbar ist und daher nur ein Design (in Variationen) liefert oder nur ganz bestimmte Formen darstellen kann, ist für die in diesem Werk propagierten Zwecke nicht geeignet.

Es gibt viele Beispiele für „Spezialdesigngeneratoren“, wie die „n_Gen Design Machine“, programmiert von Move Design (www.movedesign.com). Diese erlaubt die Eingabe einer Überschrift, Unterüberschrift und von Fließtext und generiert daraus ein Designstück (Flyer, Poster, Webseite oder CD Hülle) nach einem vorgegebenen Design-Template (Abb. 3-6).

Allerdings hat der Benutzer keine anderen Einflussmöglichkeiten, außer sich für eine Stilvorgabe (modern, klassisch, technisch, formalistisch…) zu entscheiden und sich daraus ein mehr oder weniger zufälliges Design nach dem anderen generieren zu lassen bis ein akzeptables Resultat erzielt wird. Aus diesem Grund scheidet dieser und viele ähnliche Template-basierte Ansätze von vornherein aus.
Generatives Design soll aber auch nicht alle Aufgaben des klassischen Designs übernehmen. Vielmehr muss herauskristallisiert werden, in welchen Fällen eine Entscheidung zugunsten generativer Ansätze von Vorteil ist und in welchen Fällen dies eine Verkomplizierung des Designprozesses mit sich bringt.

1.2.1. Unterstützte Ausgabemedien und die erreichte Qualität

Die erste Qualität muss das Ausgabemedium selbst sein. Die Ausgabe auf Papier stellt andere Ansprüche als die Wiedergabe auf einem Bildschirm. Die verwendete Software muss Schnittstellen besitzen um ein im Computer erzeugtes Design in hoher Qualität auf Papier bringen zu können. Für eine Publikation im Web muss ein Standard existieren, der die Darstellung der erzeugten Inhalte, auf so vielen Plattformen wie möglich, garantiert.
Photoshop und Illustrator sind auf den Printbereich spezialisiert und bringen daher alle Voraussetzungen mit um Motive in beliebiger Größe erstellen und bearbeiten zu können. Auch sonst werden die Adobe Produkte allen Anforderungen einer hochqualitativen Ausgabe wie Farbseparierungen, Rasterung, Schnitt- und Passmarken gerecht. Für die Darstellung im Web stehen hier das JPG und GIF Format zur Verfügung, Formate wie SVG und PNG lassen sich exportieren, was eine universelle Darstellbarkeit garantiert.
In diesem Punkt können die generativen Tools grundsätzlich nicht mithalten, da diese ihren Fokus ganz klar auf die Ausgabe über den Bildschirm haben und deshalb nur selten Funktionen für den Export von hochauflösenden Bilddaten besitzen. Auch wenn vektor-basierte Tools wie Macromedia Flash den Export von auflösungsunabhängigen Pfaden, die in beliebiger Größe gedruckt werden können, unterstützen, bieten generativen Tools diese Funktion nicht standardmäßig an. Dies bedeutet, dass für das Finishing von generativen Designs praktisch immer auf ein Bildbearbeitungsprogramm zurückgegriffen werden muss.

1.2.2. Der Funktionsumfang der Werkzeuge

Die zweite Anforderung an ein Designwerkzeug ist, dass es Funktionen zur Verfügung stellt um Objekte zu erstellen, Texte zu platzieren und um Pfade zu zeichnen (z.B. Bezier Funktion). Photoshop und Illustrator bieten eine Fülle an Funktionen, die die Erstellung und Manipulierung von Objekten ermöglichen.
Alle in Kapitel 1.3 vorgestellten generativen Tools erfüllen ebenso die Voraussetzungen, d.h. sie besitzen die oben aufgeführten Funktionen, die je nach Spezialisierung der Software unterschiedlich ausgeprägt sind. So sind die Vektorfunktionen bei SWF und dem SVG Format sehr ausgeprägt, während sich z.B. processing (siehe Kapitel 1.3.3) gut für eine dreidimensionale Objektgenerierung eignet. Vor allem der individuelle Stil des Designers, in Kombination mit dem angepeilten Designziel, ist ein Auswahlkriterium für das Werkzeug.

1.2.3. Die Benutzbarkeit der Werkzeuge

Der dritte und wohl wichtigste Punkt ist die Bestimmbarkeit des gewünschten Ergebnisses und das Maß an Kontrolle die über das Programm ausgeübt werden kann. Der Designer muss im Stande sein, genau zu definieren, wie und wo Elemente zu platzieren sind und wie diese farblich und strukturell beschaffen sein müssen. Ein Programm, das es dem Designer nicht ermöglicht jedes Element seines Designs zu beeinflussen, sei es durch Mängel im Interface oder wegen einer Fixierung auf unveränderbare Templates, ist ungeeignet, da es die Freiheit des Designers einschränken würde.
Grundsätzlich ist das Handling der generativen Tools viel schwieriger zu erlernen als der Umgang mit Photoshop, da die meisten generativen Funktionen Programmiertechniken erfordern. Allerdings bieten die generativen Tools auch Funktionen um den genauen Ablauf eines Programms zu überprüfen (Tracking) und Fehler aufzuspüren (Bugfixing).
Dadurch, dass jede gewünschte Eigenschaft explizit programmiert werden muss, ist der Designer beim generativen Ansatz jederzeit versichert, dass das Programm nur das macht, was auch vorgegeben ist. Dem ist allerdings entgegen zu halten, dass kein Photoshop User so viel über die innere Struktur des Programmes wissen muss um es beherrschen zu können, da es auf vollkommen verschiedenen
Bedienprinzipien beruht.

1.2.4. Nachträgliche Veränderbarkeit eines erstellten Designs

Dieser Punkt prüft, inwieweit es möglich ist gewisse, im Designprozess getroffene Entscheidungen zu revidieren und Objekte nachträglich zu manipulieren.
Die UnDo Funktion ist ein einfacher Mechanismus um Veränderungen rückgängig zu machen. Dabei wird eine Liste erstellt auf der jeder verwendete Befehl notiert wird und bei Bedarf kann der Designer zu einem früheren Stadium seiner Arbeit zurückspringen. Allerdings geht so die ganze Arbeit, die nach dem fehlerhaften Schritt gemacht wurde, verloren.
Gewisse Programme, wie etwa „Maya“ von Alias (vgl. Alias 2005) verfügen über viel ausgeklügeltere Funktionen, mit der jeder Parameter jedes gemachten Arbeitsschrittes jederzeit verändert und sogar gelöscht und verschoben werden kann ohne die später erteilten Befehle zu löschen.
Generatives Design muss im Optimalfall 100% variabel sein so dass jederzeit jedes Element beeinflussbar bleibt. Dies wird gefordert, um leicht Variationen eines Designs erzeugen zu können. Photoshop legt einzelne Ebenen an, die nachträglich manipuliert werden können, genauso wie es Illustrator erlaubt, jeden einzelnen Punkt und jedes Objekt, bzw. Gruppen von Objekten zu manipulieren.
Die generativen Tools gehen hier viel weiter. Sie können beliebige Werte (Farben von Objekten, Transformationen) als Variablen definieren, die jederzeit beeinflusst werden können. So kann z.B. eine einzige Variable die Größe eines Objekts und gleichzeitig die Helligkeitswerte von 5 anderen Objekten kontrollieren. In diesem Punkt sind die generativen Ansätze den klassischen Tools weit überlegen.

1.2.5. Erweiterbarkeit der Werkzeuge

Dieser letzte Punkt beschreibt die Erweiterbarkeit eines Programmes. D.h., die Integration von neuen Funktionen durch den Anwender, um so Ergebnisse erreichen zu können, die dem Programm ursprünglich nicht möglich gewesen wären. Plugins sind eine Möglichkeit um dies zu gewährleisten, aber es gibt auch Open Source Software die mit den dazu nötigen Programmierkenntnissen zu 100% personalisiert werden kann. Dieser Punkt wird immer dann sehr wichtig, wenn bei einem Programm eine dringend benötigte Funktion abgeht.
Während die Adobe Produktpalette eine Erweiterung nur über meist sehr teuere Plugins von Drittherstellern erlaubt, bieten die generativen Ansätze gewöhnlich mehr Möglichkeiten um benötigte Funktionen zu integrieren. Die in Kapitel 1.4 vorgestellten Tools besitzen alle Schnittstellen um über diverse Protokolle (TCP, UDP, NetSend, OSC, MIDI, DMX, RSh, usw.) mit anderen Programmen Daten auszutauschen. So können Bild- oder Audioanalysedaten in einem geeigneten Programm berechnet werden und dann über eine Schnittstelle an ein generatives Tool übermittelt werden, wo diese Daten dann auf Objekte angewendet werden können.
Auch die Integration von Daten aus Online Quellen (RSS Newsfeeds, Wetterdaten und anderen Datenbanken) und direkt an das System angeschlossener Hardware (Sensoren, Interfaces, usw…) ist möglich. Also liegt auch hier der Vorteil beim generativen Ansatz.

1.3. Etablierte Ansätze im generativen Design

Die Frage, die es nun zu klären gilt ist, welche Werkzeuge uns zur Verfügung stehen und wie diese benutzt werden um die im Werkteil gezeigten Objekte generieren zu können. Deshalb sollen in diesem Kapitel einige etablierte Ansätze besprochen werden, die zur Erzeugung von generativem Design Verwendung finden können. Wie schon festgestellt wurde muss nicht gezeigt werden, dass sie die klassischen Designtools vollständig von generativen Tools ersetzt werden müssen. Die einfache Tatsache, dass der generative Ansatz für gewisse Aufgaben effektiver ist, reicht vollkommen aus, um den Einsatz dieser Methoden in vielen Situationen zu rechtfertigen. Zum Beispiel: die im Werkteil gezeigten Grafiken sind, vor allem in diesem Variantenreichtum und in dieser Geschwindigkeit, nicht mit Photoshop, Illustrator und ähnlichen Programmen erzeugbar. Es muss noch vorweggenommen werden, dass der generative Einsatz nicht ohne eine Syntax auskommt, die bestimmt wie das Programm Anweisungen entgegennehmen kann.
Die am weitesten verbreitete Form dieser Syntax ist die textbasierte. Anweisungen werden Zeile um Zeile eingetippt, in ein ausführbares Programm übersetzt und dann ausgeführt.

Das Design wird also erst in jenem Moment erstellt, in dem das Programm aufgerufen wird. Vorher ist das Design zwar schon vorhanden, aber nur implizit, als eine Menge an Regeln, die erst angewendet werden müssen um ein Bild zu erzeugen. Der Umgang mit einer generativen Programmierumgebung erfordert demnach einiges Umdenken. Der Designer produziert sein Werk nicht mehr selbstständig, er schreibt ein kleines Programm, das diese Arbeit für ihn erledigt. In diesem Programm schlummert dann die Funktion, das gewünschte Design (oder beliebige Variationen desselben) zu generieren.
Im Zuge der Recherchen zeigte es sich, dass vor allem 4 Technologien weite Verbreitung finden und diese sollen nun vorgestellt werden und auf ihre Eignung, generatives Design zu erzeugen, geprüft werden.

1.3.1. Flash und Action Script

Macromedia Flash ist eine proprietäre, integrierte Entwicklungsumgebung zur Erzeugung von Animationen in einem auf Vektorgrafiken basierenden Grafik- und Animationsformat (SWF). Die 1992, aus dem Zusammenschluss der Firmen MacroMind und Authorware, hervorgegangene Firma Macromedia kaufte sich 1996 das von FutureWave entwickelte Animationsprogramm FutureSplash-Animator und benannte dieses in „Macromedia Flash 1.0“ um. Dessen Funktionsumfang war allerdings noch stark begrenzt. 1999 stellte die Integration der Programmiersprache ActionScript (vgl. Lott 2003) in Flash Version 4 erste Kontrollstrukturen, wie if-Anweisungen und Schleifen zur Verfügung, mit deren Hilfe die Entwicklung von wesentlich komplexeren Applikationen (Trainingssoftware, Online Spiele und auch schon einfaches generatives Design) ermöglicht wurde.
ActionScript wurde seitdem stets erweitert und an Programmiersprachen wie JavaScript angepasst, was den Umstieg für Entwickler, die mit anderen Programmiersprachen zu tun hatten, wesentlich erleichtert. Im März 2002 erschien die MX-Version mit neuer Zeichnen-API und wesentlich erweiterten ActionScript-Programmierfunktionen, die das Erstellen von dynamischen Formen ermöglichen. Zusätzlich wurde das Objekt- und Ereignismodell erweitert. Mit ActionScript 2.0, das mit Flash MX 2004 im Oktober 2003 eingeführt wurde, schaffte Flash endlich den Sprung zu einer wirklich umfassenden Programmierbarkeit, was es zu einem guten Kandidaten zur Erzeugung generativer Formen macht.

Macromedia beschreibt sein Tool folgendermaßen:

Durch die weite Verbreitung des SWF Plugins, das laut einer von Macromedia in Auftrag gegebenen Studie der NPD Group, auf 97% (vgl. Macromedia 2005b) der Rechner weltweit installiert ist, wird sichergestellt, dass praktisch jeder Internetnutzer die mit Flash erstellten Inhalte betrachten kann.
Die große User Gemeinde (laut Macromedia über eine Million Anwender) ist ein weiterer großer Vorteil von Flash. Die Tatsache, dass sich Flash mit seiner Bedienstrategie sehr an gewohnten Windows-Konventionen orientiert ist mit Sicherheit ein wichtiger Grund für die weite Verbreitung, da gewohnte Strategien zur Benutzung von Designsoftware zum Teil beibehalten werden können.
Dieser Ansatz funktioniert allerdings nur bei der grafischen Erstellung von Formen und Objekten, nicht aber um Anweisungen zu deren Verhalten und Positionierung zu geben. Dafür muss auf Action Script zurückgegriffen werden, was den Designer zwingt, seine Anweisungen textbasiert zu programmieren.

Um ein Beispiel zu geben, wie ein einfaches Action Script Programm aussieht:

Allerdings richtet sich Flash an zwei vollkommen unterschiedliche Zielgruppen gleichzeitig: Designer und Programmierer. Das Programm bietet sogar zwei vollständig angepasste Interface-Konfigurationen an, von denen eine (Designer oder Developer) beim ersten Aufruf des Programmes ausgewählt werden muss. Dies zeigt, dass in Agenturen nach wie vor eine große Distanz zwischen den Rollenmustern von Programmierern (“technisch versiert aber unkreativ”) und Designern (“kreative Köpfe, die von der Technik wenig Ahnung haben”) besteht. Dies kann daran liegen, dass sich die Designer nur schwer mit der textbasierten Programmierung anfreunden können, da diese im absoluten Gegensatz zu deren bildhafter Denkweise steht.

1.3.2. SVG und SMIL

SVG (Scalable Vector Graphics ) ist ein freies Konkurrenzformat zu SWF. Es wird vorwiegend von der Firma Adobe vorangetrieben und ist eine Sprache zur Beschreibung zweidimensionaler Vektorgrafiken in XML. SVG unterstützt mittels SMIL (Synchronized Multimedia Integration Language) auch Animationen. Es wurde im September 2001 zur W3C-Empfehlung (World Wide Web Consortium, www.w3.org) erhoben und wird bereits von einigen Browsern, wie Mozilla Firefox, der von www.mozilla.org/projects/svg heruntergeladen werden kann, nativ unterstützt. Für andere Browser ist dafür ein Plugin notwendig, wie z.B. der SVG Viewer von Adobe. Macromedia gibt auf seiner Seite an, dass das SVG Plugin nur auf 13,5% aller Computer installiert ist, was eine Verbreitung von SVG-Grafiken über das Web (noch) unattraktiv macht.
Alle grafischen Objekte in SVG bauen auf einfachen grafischen Grundelementen auf. Komplexere Objekte sind dabei aus mehreren einfachen Objekten zusammengesetzt, wobei der Pfad das eigentliche Grundelement in SVG ist. Aus ihm können alle anderen Objekte (Kreise, Rechtecke, Polygone etc.) aufgebaut werden. Da das aber teilweise sehr umständlich ist, hat das Team das die Spezifikationen ausarbeitet, diese häufigen Formen mit jeweils eigenen Beschreibungen versehen.

Das W3C beschreibt SVG so:

Wie das obrige Zitat belegt, hat SVG in der aktuellen Spezifikation 1.0 einen großen Nachteil: die Beschränkung auf 2D Grafik. Allerdings ließe sich auch in zwei Dimensionen äußerst komplexes und optisch ansprechendes generatives Design erzeugen. Da SVG jedoch nur eine Beschreibungssprache ist, für die es noch keine, mit Flash und anderen generativen Tools vergleichbare, Entwicklungsumgebung gibt, fällt ein Einstieg in die sehr formelle Welt von SVG nicht leicht. Auch wenn es Vektorgrafik-Programme wie Sodipodi und Inkscape (beide Freeware) gibt, die SVG als ihr natives Datenformat verwenden und mit der Bedienung von Adobe Illustrator vergleichbar sind, fehlt ihnen jede Möglichkeit, komplexere Verhaltensweisen zu programmieren, weswegen diese Tools und damit SVG, für die in diesem Werk verfolgten Ziele ausscheiden.

1.3.3. Java und processing

Java ist eine objektorientierte, plattformunabhängige Programmiersprache, die von Sun Microsystems entwickelt wird. Üblicherweise benötigen Java-Programme zur Ausführung eine spezielle Umgebung (Java Virtual Machine) um lauffähig zu sein (vgl. Gosling 2000). Der Vorteil ist, dass nur diese Umgebung an verschiedene Computer und Betriebssysteme angepasst werden muss. Sobald dies geschehen ist laufen auf der Plattform alle Java-Programme ohne Anpassungsarbeiten.
Die Urversion von Java wurde 1992 im Auftrag von Sun entwickelt. Das ursprüngliche Ziel war nicht lediglich die Entwicklung einer weiteren Programmiersprache, sondern die Entwicklung einer vollständigen Betriebssystemumgebung, inklusive virtueller CPU, für unterschiedlichste Einsatzzwecke. Man entschied sich für den Namen Java nach dem Namen einer starken Kaffee-Sorte, die speziell für Espresso Verwendung findet (Java-Bohne) und von den Entwicklern bevorzugt getrunken wurde.
Processing ist eine Erweiterung von Java mit einer stark vereinfachten und verkürzten Syntax und von den Initiatoren des Projekts (Ben Fry und Casey Reas) als eine Programmierumgebung zum Erlernen der Grundprinzipien des Programmierens im Kontext der elektronischen Künste konzipiert. Processing wird vom MIT Media Lab (in der von John Maeda geleiteten Gruppe Aesthetics and computation) in den USA und am italienischen Institut für interaktives Design IVREA entwickelt.

Es ist ein offenes, sich schnell weiterentwickelndes Projekt, das auf der Projekthomepage (proce55ing.org) so beschrieben wird:

Durch seine Spezialisierung auf den Kunst- und Designkontext und die breite Palette an Erweiterungsmöglichkeiten, die sich durch die zugrunde liegende Java Technologie ergeben, machen Processing zu einem ausgezeichneten Werkzeug um damit generatives Design zu erzeugen. Es existiert eine große Community (04.05.05: 2583 registrierte User), die in diversen Foren (fast 4000 Themen mit insgesamt über 14.000 Postings) sehr guten Support (processing.org/discourse) und Hilfe bei Fragen bietet. Zudem ist es eine kostenlose Technologie, die noch dazu auf jeder Plattform und jedem Betriebssystem mit einer Java Virtual Machine ausgeführt werden kann.
Allerdings kommt der Anwender auch bei diesem Ansatz nicht um das Erlernen einer textbasierten Programmiersprache herum.

1.4. Ein grafischer Ansatz

Dieses Kapitel bespricht die, sich zur Zeit sehr schnell verbreitenden, visuellen Multimedia-Programmiersprachen (von nun an „grafische Programmierumgebungen“ genannt), welche eine gänzlich andere Strategie verfolgen als die 3 besprochenen Ansätze mit ihrer textbasierten Syntax:

Diese, von E. J. Golin in seinem Artikel “The Specification of Visual Language Syntax” gemachte Aussage sagt also, dass eine visuelle Sprache visuelle Informationen manipuliert, eine visuelle Interaktion unterstützt oder programmieren über visuelle Ausdrücke ermöglicht.

B.A. Myers hingegen definiert eine grafische Programmiersprache als ein Programm, das in zwei oder mehr Dimensionen geschrieben wird: “Any system where the user writes a program using two or more dimensions.” (Myers 1990, 97ff). Damit spielt er auf die Positionierung von Funktionsblöcken auf den Arbeitsflächen von visuellen Entwicklungsumgebungen an.
Eine noch präzisere Definition liefern uns M. Burnett, A. Goldberg und T. Lewis in ihrem Buch ”Visual Object-Oriented Programming: Concepts and Environments”:

Eine visuelle Sprache ist ein räumliches Arrangement von beschrifteten grafischen Symbolen, die semantisch interpretiert werden müssen, um innerhalb der Programmierumgebung miteinander kommunizieren zu können. Auf diese 3 Definitionen bezieht sich jede Erwähnung einer “grafischen Programmiersprache” in diesem Werk. Dieser Begriff ist nicht mit integrierten Entwicklungsumgebungen (IDEs) wie Microsoft Visual Studio oder Eclipse (www.eclipse.org) zu verwechseln, die grafische Oberflächen für textbasierte Programmiersprachen sind.
Alle grafischen Programmierumgebungen benutzen so genannte „Knoten“ (engl. „nodes“), um Funktionen der Programmiersprache darzustellen. Diese Funktionsblöcke, die nach Belieben auf einer Arbeitsfläche verteilt werden können, erfüllen die unterschiedlichsten Aufgaben, die, je nach verwendeter Software, unterschiedliche Anwendungsgebiete abdecken. Es gibt Spezialsoftware für Klangerzeugung und Audioanalyse, Prototyping Systeme für die Spieleindustrie, ein Tool, das sich ganz auf die Bildanalyse konzentriert und auch stark visuell orientierte Technologien, die sich für generatives Design eigenen könnten. Eine weitere Gemeinsamkeit dieser grafischen Programmierumgebungen ist, dass alle Knoten nach genau festgelegten Regeln miteinander verbunden werden können, was den Knoten erlaubt, untereinander Daten auszutauschen. Diese Daten können einfache Zahlenwerte, aber auch Media Streams (Audio|Video), 3D Modelle oder Sensordaten sein. Je nach Art des Knotens werden die Daten nach der Ankunft verarbeitet und in irgendeiner Form an einen oder mehrere verbundene Knoten weitergereicht.

Dies sind die beiden Grundeigenschaften von datenflussorientierten Programmierumgebungen: Verhaltensweisen werden programmiert indem Funktionsblöcke auf einer Arbeitsfläche arrangiert und verknüpft werden. Ein sehr grafischer Ansatz, da der Datenfluss zwischen den Funktionsblöcken sehr gut nachvollziehbar ist.
Zur Illustration der erklärten Konzepte sollen folgende zwei Screenshots dienen.
Links puredata|gem (Abb.7), rechts max|MSP (Abb. 8).

Eine genauere Vorstellung der beiden Softwarepakete folgt im Kapitel 1.5.
Grafische Programmierumgebungen stellen, wie die drei zuvor besprochenen Ansätze, nur Werkzeuge dar, um dem Computer, in Grenzen, beizubringen wie er ein gewünschtes Design zu produzieren hat. Die erzeugten Grafiken können den Ergebnissen der anderen besprochenen Technologien zum verwechseln ähnlich sehen. Der unterschiedliche Ansatz macht sich nur auf der Ebene des Schaffenden bemerkbar, nicht aber auf der Ebene des generierten Bildes.
Der frappierend andere Ansatz gegenüber den textbasierten Programmierumgebungen ist der, dass Zusammenhänge zwischen Knoten auf einer visuellen Logik beruhen, die das Gehirn auf einer anderen, viel direkteren Ebene interpretieren kann. Während das Vokabular einer typografischen Programmiersprache ziemlich genau bekannt sein muss, um den Datenfluss im Programm oder auch nur die Verbindungen zwischen zwei Programmfunktionen herauslesen zu können, kann aus der grafischen Verknüpfung zwischen zwei Knoten einer grafischen Programmiersprache sofort gefolgert werden, dass diese Knoten in irgendeinem Verhältnis zueinander stehen. Dieses intuitive Verständnis erleichtert die Kontrolle des Datenflusses auch bei komplexeren Programmen mit vielen Knoten und Verknüpfungen wesentlich. Andrew Bregel, vom MIT Media Lab, schrieb 1996 in einer Abhandlung über eine vom MIT entwickelten grafischen Programmiersprache für Handheld-Computer:

Bei der grafischen Repräsentation kann die lästige Syntax eliminiert, und der Datenfluss im Programm besser visualisiert werden. Metaphern aus dem real-life machen das Programmieren einfacher und ermöglicht den leichten Austausch von Programmen zwischen Programmierern. Ein grafisch visualisiertes Programm lässt sich einfacher begreifen als ein langer Quellcode. Die visuellen Hilfen, wie Linien als Verbindungen zweier Funktionen, sind dabei wohl der größte Vorteil. So lassen sich die von Bregel aufgelisteten Vorteile von grafischen Programmierumgebungen zusammenfassen. Der nächste Absatz listet die von ihm definierten Nachteile auf:

Das „Deutsch Limit“ ist ein von Fred Lakin geprägter Begriff, der das Maximum an Symbolen bezeichnet, das sich in einer grafischen Programmierumgebung überschaubar darstellen lässt. Lakin und Peter Deutsch unterhielten sich über grafische Programmierumgebungen, als Deutsch plötzlich fragte:

Das Problem mit grafischen Programmierumgebungen ist also, dass nicht mehr als 50 primitive visuelle Objekte auf einem Bildschirm Platz finden, was Deutsch zu der Frage veranlasste: „Wie soll man damit ein Betriebssystem programmieren?“ Diesen Vorteil der größeren Informationsdichte von textbasierten gegenüber grafischen Programmierumgebungen führt Bregel als Nachteile an. Ob es eine ähnliche
Beschränkung wie das Deutsch Limit auch für textbasierte Programmierumgebungen gibt, bleibt allerdings offen.

Die meisten grafischen Programmierumgebungen erlauben tatsächlich keine Programmierung über eine textbasierte Syntax, was für viele fortgeschrittene Programmierer eine Einschränkung darstellt. Durch die Fokussierung der Zielgruppe dieses Werkes vor allem auf Nicht-Programmierer, sollten sich daraus aber keine Nachteile ergeben. Dass bei sehr vielen Symbolen ein Programm sehr schnell unübersichtlich werden kann, ist jedoch ein ernstzunehmendes Problem, das sich allerdings durch eine Gruppierung von vielen Knoten und deren Verknüpfungen zu einem einzigen Symbol umgehen lässt.
Dies ist ein wichtiges Feature, das jede ernstzunehmende grafische Programmiersprache besitzen muss. Jede Gruppe von Knoten und deren Verknüpfungen muss auch als Modul verwendet werden können, das als einfacher Knoten mit definierten Ein- und Ausgängen, beliebig oft, in unterschiedlichen Situationen, wiederverwendet werden kann. Dieses Konzept der Module oder „Unterprogramme“ findet sich selbstverständlich auch in modularen, textbasierten Programmiersprachen.
Der grafische Ansatz ist allerdings weit weniger abstrakt.