STUDIOTOOLS
Learn.Make.Repeat.
Vom parametrischen Zwischenstand zur festen, weiterverwendbaren Geometrie
Die grüne Vorschaugeometrie im Rhino-Viewport ist nur eine Voransicht — solange sie nicht gebacken ist, existiert sie nicht als eigenständiges Rhino-Objekt. Dieser Workflow beschreibt den bewussten Übergang von parametrischer Definition zu fester Geometrie: wann gebacken wird, wie Layer und Benennung vorbereitet werden und wie Definition und Rhino-Datei danach sauber zusammengehalten werden.
Temporäre Vorschaugeometrie und finale, gebackene Geometrie sind zwei unterschiedliche Dinge. Solange eine Definition noch aktiv verändert wird, bleibt die Vorschau der richtige Arbeitsstand — gebacken wird erst, wenn ein Ergebnis tatsächlich als eigenständiges Rhino-Objekt gebraucht wird, etwa für Export, Rendering oder Weitergabe.
Ein Bake überträgt genau das, was die Definition im aktuellen Zustand tatsächlich ausgibt — Fehler in der Definition werden mit übertragen, nicht automatisch korrigiert.
Mehrere Zweige einer Definition können gleichzeitig eine Vorschau zeigen, auch wenn nur einer davon tatsächlich final ist. Vor dem Bake wird deshalb kontrolliert, welcher Zweig tatsächlich die gewünschte, finale Geometrie liefert — nicht zwingend derjenige, der zuletzt bearbeitet wurde.
Was muss vorhanden sein: eindeutig identifizierter, fehlerfreier Ausgabezweig ohne offene Warnmeldungen.
Was wird geprüft: Preview-Geometrie des gewählten Zweigs gegen die erwartete Form.
Fehlererkennung: mehrere aktive Vorschauzweige gleichzeitig, rot markierte Komponenten in der Definition.
Konsequenz bei Nichtbeheben: Es wird der falsche oder ein fehlerhafter Zweig gebacken, was in Rhino oft erst bei der Detailkontrolle auffällt.
Ein durchdachter Zielort in Rhino erspart nachträgliches Aufräumen.
Vor dem Bake werden passende Layer angelegt, auf die die gebackene Geometrie gezielt einsortiert wird — etwa nach Bauteil oder nach erzeugender Komponente benannt. Ohne vorbereitete Layer landet gebackene Geometrie oft unsortiert auf dem aktuell aktiven Layer.
Grasshopper kann beim Bake Namen und Attribute mit übertragen, wenn diese vorher in der Definition entsprechend gesetzt wurden. Eine geplante Benennung macht die gebackenen Objekte später leichter identifizierbar als automatisch vergebene Bezeichnungen.
Nicht die gesamte Definition wird auf einmal gebacken, sondern gezielt die tatsächlich benötigten Ausgabezweige.
Je nach Geometrietyp entstehen beim Bake unterschiedliche Rhino-Objekte. Wiederkehrende Bauteile lassen sich als Block backen, was Dateigröße spart und spätere Aktualisierung an einer zentralen Stelle erlaubt — allerdings mit den bekannten Einschränkungen von Block-Instanzen bei individueller Bearbeitung einzelner Kopien.
Wird derselbe Zweig einer Definition mehrfach gebacken, ohne die vorherige Geometrie zu entfernen, entstehen unbemerkt doppelte Objekte. SelDup findet solche Duplikate nach dem Bake.
Nach dem Bake wird das Ergebnis wie jede andere neu erzeugte Geometrie behandelt — mit derselben Sorgfalt, nicht als bereits geprüft vorausgesetzt.
Reste aus früheren Testläufen, doppelt gebackene Geometrie oder nicht mehr benötigte Konstruktionshilfen werden entfernt. Purge räumt zusätzlich nicht mehr referenzierte Blockdefinitionen und Layer auf.
Was muss vorhanden sein: vollständige, korrekt benannte Geometrie auf den vorgesehenen Layern, keine Duplikate.
Was wird geprüft: Objektzahl gegen die Erwartung aus der Definition, SelDup liefert keine Treffer.
Fehlererkennung: fehlende Bauteile, doppelte Objekte, Geometrie auf falschem Layer.
Konsequenz bei Nichtbeheben: Der Fehler wandert unbemerkt in Export, Rendering oder Fertigung weiter.
Gebackene Geometrie sieht wie jede andere Rhino-Geometrie aus — ihre Herkunft aus einer Definition ist ohne Dokumentation nicht mehr erkennbar.
Ein kurzer Vermerk, aus welcher Definition und welchem Parameterstand eine gebackene Geometrie stammt, erspart spätere Rekonstruktionsarbeit — etwa als Objektname, Layername oder begleitende Notiz.
Datei und Definition werden mit übereinstimmenden Versionsbezeichnungen gesichert. So bleibt nachvollziehbar, welcher Definitionsstand welche gebackene Geometrie erzeugt hat.
Gebackene Geometrie lässt sich in Rhino wie jedes andere Objekt direkt bearbeiten — sie aktualisiert sich dabei aber nicht automatisch, wenn sich die ursprüngliche Definition später ändert. Diese Trennung wird bewusst berücksichtigt, bevor an gebackener Geometrie direkt weitergearbeitet wird.
Ursache: Kein Ziel-Layer vor dem Bake ausgewählt.
Lösung: Gebackene Objekte nachträglich auf den korrekten Layer verschieben, künftig Layer vor dem Bake aktiv setzen.
Ursache: Derselbe Zweig wurde erneut gebacken, ohne die vorherige Geometrie zu entfernen.
Lösung: Mit SelDup Duplikate finden und die überzähligen Objekte entfernen.
Ursache: Gebackene Geometrie ist eine feste Kopie und aktualisiert sich nicht automatisch.
Lösung: Betroffene Geometrie entfernen und aus der aktualisierten Definition erneut backen.
Ursache: Kein Vermerk zur erzeugenden Definition angelegt.
Lösung: Objekt- oder Layernamen nachträglich um einen Hinweis auf die Quelldefinition ergänzen, künftig direkt beim Bake dokumentieren.