Computational Design · Grasshopper-Plugin-Entwicklung
Eine Definition löst ein Problem einmal. Ein Plugin löst dasselbe Problem beim nächsten Mal wieder, im ganzen Team, ohne dass jemand die Logik kopiert und dabei verändert.
01 · Entscheidung
Nicht jede Aufgabe braucht ein Plugin. Eine Grasshopper-Definition ist schneller gebaut, leichter zu ändern und für viele Projekte die richtige Antwort. Ein Plugin lohnt sich, wenn mindestens einer der folgenden vier Punkte zutrifft, und es lohnt sich sehr, wenn drei davon zutreffen.
Dieselbe Gruppe von vierzig Komponenten taucht in sieben Projekten auf, jedes Mal leicht anders, weil sie jedes Mal von Hand kopiert und angepasst wurde. Sobald das passiert, ist die Logik faktisch siebenmal vorhanden und nirgends gepflegt. Eine kompilierte Komponente ersetzt die vierzig durch eine, und ein Fehler wird an einer Stelle behoben statt an sieben.
Grasshopper wertet einen Graphen aus, und bei Schleifen, großen Datenbäumen und Geometrieprüfungen kostet dieser Weg spürbar Zeit. Was in einer Definition als Kette aus vielen kleinen Schritten läuft, läuft in kompiliertem C# als eine Rechnung. Der Unterschied wird dort entscheidend, wo jemand am Regler zieht und eine Antwort erwartet, statt einen Batch-Lauf zu starten.
Eine Definition ist offen: Wer sie öffnet, liest die Methode. Das ist im eigenen Team ein Vorteil und außerhalb ein Risiko. Wenn eine Definition an einen Zulieferer, einen Partner oder einen Kunden geht, ist eine kompilierte Komponente die Form, in der Sie Funktion weitergeben, ohne das Verfahren mitzuliefern. Die Entscheidung darüber, was offen bleibt und was nicht, treffen Sie und nicht das Dateiformat.
Eine Definition, die per Mail wandert, existiert nach vier Wochen in fünf Ständen. Ein Plugin hat eine Version, eine Installationsroutine und eine feste Stelle in der Komponentenleiste. Alle im Team arbeiten mit demselben Werkzeug, und wer ein Modell öffnet, das jemand anders gebaut hat, findet dieselben Komponenten vor.
Der ehrliche Test: Wenn Sie dieselbe Gruppe zum dritten Mal kopieren, war der richtige Zeitpunkt beim zweiten Mal.
02 · Aufbau
Eine Grasshopper-Komponente sieht aus wie ein Kästchen mit Anschlüssen und ist innen ein kleines Programm mit drei Aufgaben: Eingaben prüfen, rechnen, Ergebnisse und Meldungen zurückgeben. Fahren Sie über einen Bereich der Zeichnung oder wählen Sie ihn mit der Tastatur, um die passende Erklärung hervorzuheben. Alle Erklärungen stehen dauerhaft daneben.
Das Schema ist gezeichnet, nicht abfotografiert. Es zeigt den Aufbau, den wir für eigene Komponenten verwenden, und nicht die Oberfläche einer bestimmten Rhino-Version.
03 · Umfang
Ein Plugin ist nicht die Datei allein. Vier Teile gehören zusammen, weil ohne sie das Werkzeug nach dem Projekt niemandem gehört.
04 · Aufgabenklasse
Eine der Aufgaben, die uns über dieses Thema erreichen, sieht immer ähnlich aus. Ein Betreiber betreibt mehrere Standorte derselben Art, in unserem Fall Trainingsflächen mit Geräten. Jeder Standort hat einen anderen Grundriss: andere Länge, andere Tiefe, andere Stützen, andere Lage der Türen. Die Geräte dagegen sind immer dieselben, und die Regeln, nach denen sie stehen dürfen, auch.
Von Hand entsteht daraus eine Zeichnung pro Standort, jedes Mal von vorn. Der Planer setzt Geräte, misst Abstände nach, prüft, ob ein Weg frei bleibt, zählt am Ende, wie viele Geräte hineingepasst haben, und liefert eine Variante. Wenn der Betreiber eine zweite Anordnung sehen will, beginnt die Arbeit erneut. Die eigentliche Frage des Betreibers, nämlich welche Anordnung die meisten Geräte bei gleicher Wegequalität trägt, wird dabei nie beantwortet, weil man dafür Varianten vergleichen müsste, die niemand gezeichnet hat.
Parametrisch gestellt ist es eine andere Aufgabe. Der Umriss, die Stützen und die Türen sind Eingaben. Die Gerätetypen mit ihren Stellflächen, ihren Bedienradien und ihren Mindestabständen sind eine Liste. Die Regeln sind Bedingungen: Ein Hauptweg muss durchgehend frei bleiben, jeder Punkt der Fläche muss innerhalb einer festgelegten Länge einen Ausgang erreichen, Geräte einer Gruppe stehen zusammen, vor Spiegelflächen bleibt Abstand. Was herauskommt, ist keine Zeichnung, sondern eine Funktion, die aus einem Grundriss Anordnungen erzeugt.
Der Nutzen liegt nicht in der ersten Anordnung, sondern in der zwanzigsten. Wenn das Modell in wenigen Minuten zwanzig zulässige Varianten rechnet und für jede die Kennzahlen ausgibt, die den Betreiber interessieren (Geräteanzahl, Fläche je Gerät, längster Weg zum Ausgang, Anteil der Fläche ohne Nutzung), dann verschiebt sich die Arbeit von der Produktion der Varianten auf ihre Beurteilung. Genau an diesem Punkt lohnt sich ein Plugin statt einer Definition: Die Prüfregeln sind das Firmenwissen des Betreibers, sie gelten an jedem Standort gleich, und sie sollen nicht in fünf verschiedenen Kopien einer Datei leben.
Wir beschreiben hier die Aufgabenklasse und nicht einen einzelnen Auftrag. Wer eine Trainingsfläche plant, ein Lager einrichtet, eine Werkstatt belegt oder eine Verkaufsfläche mit Möbelmodulen bestückt, hat dasselbe Problem in anderer Kleidung: begrenzte Fläche, feste Objekte, harte Wege, weiche Ziele. Der Weg zur Antwort ist derselbe. Der Einstiegspunkt, wenn der Grundriss zunächst nur als Zeichnung oder als Scan vorliegt, ist Floorplan AI: Ohne strukturierte Fläche gibt es nichts zu optimieren.
05 · Vorbereitung
Diese Punkte klären wir vor der ersten Zeile Code, weil jeder davon die Bauweise verändert. Je mehr davon Sie vorab beantworten können, desto kürzer wird die Vorlaufzeit.
06 · Fragen
Wenn dieselbe Logik in mehreren Projekten gebraucht wird, wenn die Auswertung im Graphen zu langsam für interaktive Nutzung ist, wenn das Verfahren das Haus verlässt und nicht offenliegen soll, oder wenn mehrere Personen mit demselben Werkzeug arbeiten sollen. Trifft nichts davon zu, ist eine Definition die schnellere und billigere Antwort, und wir sagen das auch.
Kompilierte Komponenten entstehen in C# gegen das Rhino- und Grasshopper-SDK. Python setzen wir für Vorstufen, Datenaufbereitung und Prüfskripte ein, weil sich damit schneller ausprobieren lässt. Was sich bewährt, wandert danach in eine kompilierte Komponente.
Ja, der Quellcode ist Teil der Übergabe, zusammen mit der Bauanleitung und den Abhängigkeiten. Damit können Sie das Plugin selbst neu bauen und weiterentwickeln. Wie die Rechte im Einzelnen geregelt werden, steht im Vertrag und nicht auf dieser Seite.
Über eine Installationsroutine, die die Dateien an die vorgesehene Stelle legt, oder als Paket in dem Format, das Ihr Team ohnehin für Rhino-Erweiterungen einsetzt. Welcher Weg passt, hängt von Ihrer IT ab und wird vor dem Bau festgelegt, weil es die Struktur des Projekts beeinflusst.
Das hängt vom SDK-Ziel und von den verwendeten Abhängigkeiten ab. Es ist eine Anforderung, die vor dem Bau feststehen muss, denn sie schränkt ein, welche Bibliotheken und welche Oberflächenelemente in Frage kommen. Nachträglich portieren ist deutlich aufwendiger als von Anfang an beide Ziele mitzudenken.
Ein Plugin ist gegen eine bestimmte SDK-Version gebaut. Bei einem größeren Versionssprung von Rhino kann ein Neubau gegen das neue SDK nötig werden. Weil das absehbar ist, gehört es an den Anfang: Wer den Neubau übernimmt und in welchem Rahmen, wird im Projekt geklärt und nicht erst beim nächsten Update.
Prüfregeln lassen sich einbauen, solange sie sich als Geometrie- oder Zahlenbedingung formulieren lassen: Mindestbreiten, Abstände, maximale Weglängen, zulässige Flächenanteile. Nicht sinnvoll ist es, hunderte Regeln fest in Code zu schreiben, weil Regelwerke sich ändern. In dem Fall ist die bessere Bauweise ein Plugin, das eine externe Regelliste liest, gegebenenfalls neben einer durchsuchbaren Wissensbasis über die Originaldokumente.
Ja, das ist ein häufiger zweiter Schritt. Entweder die Definition läuft als Dienst auf einem Server und der Browser fragt sie an, oder die Regel wird für den Browser nachgebaut und läuft vollständig auf dem Gerät des Nutzers. Welche Bauart passt, hängt von der Komplexität der Geometrie und davon ab, wer den Konfigurator bedienen soll.
Zur letzten Frage ausführlicher: Der Gedanke, wie aus einer Definition ein Web-Konfigurator wird, steht im Beitrag Definition als Dienst. Was der Begriff Grasshopper für Termine und Kosten bedeutet, ist unter Was ist Grasshopper 3D eingeordnet.
Nächster Schritt
Schildern Sie kurz, was die Gruppe tut und wie oft sie gebraucht wird. Wir sagen Ihnen, ob daraus eine Komponente werden sollte oder ob eine aufgeräumte Definition in Ihrem Fall reicht.
Arthur C. Clarke
“Jede hinreichend fortgeschrittene Technologie ist von Magie nicht zu unterscheiden.”
COOKIES
Dürfen wir messen, wie diese Seite genutzt wird?
Wir würden Google Analytics einsetzen, um zu verstehen, welche Seiten gelesen werden. Das setzt Cookies und überträgt Daten an Google. Notwendig ist es nicht: die Website funktioniert ohne vollständig.