OpenSCAD-Modelle mit verständlichen Parametern versehen
09.10.2026
Ein brauchbarer Modellgenerator macht nicht jede interne Variable sichtbar. Entscheidend sind verständliche Bezeichnungen, passende Standardwerte und eine übersichtliche Gruppierung. Dieser Leitfaden zeigt, wie Sie OpenSCAD-Parameter für den Customizer vorbereiten, typische Grenzen beachten und wiederverwendbare Varianten exportieren.
Ein Parameter ist eine Entscheidung, keine interne Variable
Ein anpassbares Modell wird verständlicher, wenn seine Oberfläche die Entscheidungen der späteren Nutzerinnen und Nutzer abbildet: etwa Breite, Wandstärke oder Zahl der Befestigungslöcher. Technische Hilfswerte und Zwischenrechnungen sollten nicht automatisch als Eingaben erscheinen. OpenSCADs Customizer ist für Variablen im Hauptskript gedacht und zeigt nur einfache Literale als Ausgangswerte; berechnete Ausdrücke sind dafür nicht geeignet ([Customizer-Handbuch](https://files.openscad.org/documentation/manual/Customizer.html)). Beginnen Sie daher mit einer kleinen öffentlichen Schnittstelle. Verwenden Sie sprechende, konsistente Namen wie `wandstaerke` oder `lochabstand`, und halten Sie Einheiten im Namen oder in der Beschreibung sichtbar. Das ist eine Gestaltungsregel, keine OpenSCAD-Syntaxvorgabe. Für Funktions- und Modulparameter sind sinnvolle Namen ebenfalls hilfreich; Standardwerte können Aufrufe vereinfachen, wenn ein Wert oft gleich bleibt ([Funktionen und Module](https://files.openscad.org/documentation/manual/User-Defined_Functions_and_Modules.html)).
Beschriftungen und Wertebereiche konkret machen
Direkt über der Variablen kann ein Kommentar als Hinweis für die Customizer-Oberfläche stehen. Schreiben Sie nicht bloß „Größe“, sondern zum Beispiel „Außenbreite in mm“. Ein guter Hinweis beantwortet, was gemessen wird und in welcher Einheit. Wo eine Auswahl begrenzt sein muss, kann eine Liste zulässiger Werte als Dropdown dienen; numerische Wertebereiche lassen sich mit einem Slider-Kommentar ausdrücken ([Customizer-Handbuch](https://files.openscad.org/documentation/manual/Customizer.html)). Beispiel: ```scad // Außenbreite in mm breite = 60; // [40:5:100] // Anzahl der Rastnasen rastnasen = 4; // [2, 4, 6, 8] ``` Im ersten Fall bezeichnet der Bereich 40 bis 100 mm mit Fünferschritten den Slider. Im zweiten Fall bildet die Werteliste eine diskrete Auswahl. Wählen Sie Grenzen nicht willkürlich: Sie sollten den sinnvollen Konstruktionsbereich widerspiegeln. Wenn bestimmte Kombinationen geometrisch unplausibel sind, muss der Modellcode sie zusätzlich behandeln; die Eingabeform allein beweist nicht, dass jede Kombination ein druckbares Teil ergibt.
Gruppieren, was gemeinsam verändert wird
Bei mehreren Eingaben helfen Tabs dabei, Geometrie, Befestigung und Darstellung auseinanderzuhalten. Ein Kommentarblock wie `/* [Geometrie] */` leitet eine Gruppe ein. Platzieren Sie zusammengehörige Entscheidungen nebeneinander und halten Sie die wichtigsten Einstellmöglichkeiten oben. Ein eigener Bereich für seltene oder interne Werte verhindert, dass eine lange Liste den eigentlichen Modellgenerator unübersichtlich macht. Die dokumentierte Customizer-Syntax kennt außerdem spezielle Gruppen wie `[Global]` und `[Hidden]`; prüfen Sie im Handbuch, ob diese Sichtbarkeitsregeln zu Ihrem Skript passen ([Customizer-Handbuch](https://files.openscad.org/documentation/manual/Customizer.html)).
Eine robuste Mini-Struktur
Die folgende Skizze trennt direkte Nutzerangaben von abgeleiteten Größen. `innenbreite` ist bewusst eine Berechnung und steht deshalb erst nach einem Block-Ende, der die sichtbaren Parameter abschließt: ```scad /* [Geometrie] */ // Außenbreite in mm breite = 60; // [40:5:100] // Wandstärke in mm wand = 3; // [2:0.5:5] /* [Befestigung] */ // Gewünschte Lochzahl lochzahl = 4; // [2, 4, 6, 8] /* [Hidden] */ innenbreite = breite - 2 * wand; ``` Der Code ist ein Gestaltungsmuster, kein vollständiges Bauteil. Beachten Sie insbesondere die Grenze des Customizers: Ein Ausdruck wie `breite - 2 * wand` sollte nicht als direkter UI-Parameter erwartet werden. Berechnete Größen bleiben im Skript; machen Sie die einfachen Eingaben sichtbar und leiten Sie weitere Maße daraus ab. Ein sinnvolles Standardmaß und prüfbare Slider-Grenzen machen die Bedienung vorhersehbarer.
Varianten reproduzierbar speichern
Wenn ein Modell mehrere typische Konfigurationen hat, sind benannte Parametersätze hilfreicher als lose Notizen zu einzelnen Werten. Das OpenSCAD-Handbuch beschreibt das Speichern von Customizer-Werten in JSON. Für Stapelverarbeitung nennt die Kommandozeilendokumentation `-p` für eine Customizer-Parameterdatei und `-P` für den auszuwählenden Parametersatz. `-D` weist Variablenwerte direkt zu; bei Zeichenketten muss die Shell-Quotierung berücksichtigt werden ([Kommandozeilenreferenz](https://github.com/openscad/openscad/blob/master/doc/openscad.1.in)). So lässt sich derselbe Modellgenerator für mehrere Varianten aufrufen, ohne die Eingaben im Skript jedes Mal manuell umzuschreiben.
Vor der Weitergabe prüfen
Prüfen Sie das Modell mit den Standardwerten und an den sinnvollen Enden jedes Wertebereichs. Kontrollieren Sie danach mindestens eine Kombination über die Oberfläche und – falls Sie exportieren – einen gespeicherten Parametersatz. Das ist eine empfohlene Prüfroutine, keine Behauptung über automatisch erkannte Fehler: klare Parameter machen Absichten sichtbar, ersetzen aber keine Kontrolle der entstehenden Geometrie. Zum Schluss fragen Sie bei jeder sichtbaren Eingabe: Ist Zweck und Einheit erkennbar? Ist der Standardwert brauchbar? Kann die Nutzerin den Wertbereich verstehen, ohne den Quellcode zu studieren? Wenn mehrere Eingaben zusammengehören, sind sie gruppiert? Wenige gut erklärte Parameter ergeben meist eine bessere Bedienoberfläche als ein vollständig offengelegtes Skript.