Eine sich wiederholende Reihe von Elementen n GDL zu programmieren ist eigentlich keine große Sache.
Meine grundsätzliche Herangehensweise an sowas ist es, möglichst viel Outcome aus möglichst wenig User-Action zu generieren.
Deshalb habe ich A und B als grundsätzlichen Parameter genommen, aus denen ich mit jeweils den Teilungs-Zahlen in X und Y und prozentuellen Angaben für die Größen der "Knöpfe" und "Streben" die größen eines einzelnen Elementes in der Masterscript berechnen lasse.
Normalerweise wird das Masterscript immer VOR den anderen 2D und 3D-Scripts ausgeführt. Deshalb wende ich den kleinen Trick an, in der Masterscript gleich mit einem frühen ersten Aufruf ans Ende des Masterscripts zu springen, damit ich dort Funktionen reinbringen kann, die ich dann SPÄTER von allen Scripts aufrufen kann. Geometrische Berechnungen mache ich so immer von allen Scripts aus erreichbar.
Im 2D-Script zeichne ich dann nur ein umschließendes Rechteck. Man könnte im 2D auch mit einem Project2-Befehl arbeiten, aber das Ergebnis wäre dann in diesem Fall überschießend komplex.
Im 3D schreibe ich immer zuerst mal ein "End:" rein, und scripte die Funtionen darunter.
Oberhalb des End-Befehles rufe ich dann die jeweiligen Funktionen mit gosub auf. Dies sorgt für eine gute Übersichtlichkeit.
Dann habe ich mir gedacht, das ich im 3D einige Vektoren sparen kann, wenn ich mit Gruppen arbeite, denn mit "isectgroup" und "addgroup "verschmelzen Elemente ganz gut und die Zwischenlinien verschwinden aus dem 3D.
Möglicherweise leidet aber durch diese sehr einfache Vorgehensweise mit Groups die Performance und man könnte durch direktes Programmieren der Form und Binnenlöchern mit Prism-Befehlen eine Beschleunigung erreichen....
Das Gruppieren hat auch einen Einfluss auf die Material-Darstellung, weil Gruppen die verschiedenen Materialien dann wieder zu einem Material zusammenfügen. Dies könnte man durch geschicktere Gruppenbildungen, als ich es gemacht habe, in den Griff bekommen.
Weiters könnte man die Teilungen nicht durch eine Teilungszahl programmieren, sondern durch die Angabe von Block-Größen, denen sich das Programm dann möglichst annähert, so, wie ich es bei meinen Fingerzinken für den Lasercutter gemacht habe.
Ich habe das ganze als normales Element im Grundriss liegend entwickelt und es danach als Fenster abgespeichert, wodurch es vom Liegen in die Ebene der Wand gedreht wird. Außerdem muss man es beim Fenster noch um die halbe A- Breite verschieben, dass es als Fenster dann passt.
Als normales Bibliothekselement könnte man es einfach mit einem rotx 90 Befehl aufstellen.
Als grundsätzliche Programmstruktur: Direkte Koordinatenlisten an Poly2 übergeben - also Flächen mit beliebig vielen Löchern im Raster herstellen - nur mal als 2D - aber die Koordinatenlisten kann man grundsätzlich gleich im 3D verwenden.
