KI's - verstehen GDL - ein immer ausführlicherer Bericht..

[Hmooslechner]

Ich habe wieder mal zum Austesten des derzeitigen Standes von KI's der Elon Musk - KI Grok folgende Frage gestellt und dann die einzelnen Scripts meiner GDL-"Kette" geschickt..

"Ich habe ein Script geschrieben, welches entlang eines Polygones - Array mit X, Y, Z - Koordinaten - eine gleichmäßige Aufteilung der Strecken vornimmt, um etwa eine Parabel oder Hyperbel als Kette darstellen zu können - wo die Kettenglieder natürlich die selbe Größe haben sollen. Normalerweise berechnen Menschen Parabeln über einen Algorithmus, bei dem man die neuen Koordinaten der Parabel von einer gleichmäßigen ansteigenden Wertereihe her entwickelt - was aber zu unterschiedlichen echten Distanzen zwischen den Punkten der Parabel führt und das ist für die Darstellung einer Kette nicht brauchbar. Deshalb habe ich sowas entwickelt. Es könnte aber noch konzeptionelle Fehler beinhalten, welche die Brauchbarkeit des GDLs einschränken und dabei könntest Du mir helfen. Ein GDL besteht grundsätzlich aus dem Zusammenspiel vom Parameter-Script, dem Masterscript und dem 3D-Script (+2D-Script), welche zur guten Funktion zusammenspielen sollen. Kannst du diese Struktur überblicken und bearbeiten?"

Die Antwort auf meine Frage und die übermittelten Scripts war sehr umfangreich und zeigte deutlich, daß Grok innerhalb von Sekunden meinen Code nicht nur komplett verstanden hatte, sondern auch erkannte, daß darin Code-Schnipsel vorhanden waren, die mit der eigentlichen Aufgabe - "Kette" nichts zu tun hatten, sondern aus der Historie der Entwicklung des GDLs Überlegungen für ander Anwendungen (Seil) zu tun hatten - und - er machte einige Verbesserungsvorschläge.

Diese KI könnte einen deutlichen Entwicklungssprung zur Verbesserung unserer Möglichkeiten als GDL-Scripter bedeuten, welche bisherige KI-Nutzungen in den Schatten stellt.

Ich möchte mich nun damit beschäftigen, die Aufgabe "Kette" mit Grok zu einem echten Krettenlinien - Objekt weiter zu entwickeln.

Wenn ich mich richtig erinnere hatte Fank Beister schon mal einen Code für eine echte Kettenlinie  - allerdings nur als Funktions-Schnipsel - entwickelt, nch nicht als funktionales Objekt. Mal sehen, wohin es mich damit treibt.

[Andreas81ch]

Hallo runxel,

Mit zwei Werten ist der Script ok.

Verstehe aber jetzt nicht ganz. Am Anfang in der Klammer ist ja von bis (min. 1000 , max. 3000).

Warum braucht dann der Step zwei Werte? Wieso genügt einer nicht?, wenn ich nur 100 als Step möchte (1100, 1200, etc.) ?

[runxel]

Einfachste Antwort: "Weil wegen isso" 😄

Lange Antwort: Hängt damit zusammen, dass "range" ja auch nach links offen sein kann.

Beispiel:

values "foo", 0, 0.5, range(,2.0] step 0.6, 0.1

[Hmooslechner]

GDL Handbuch von 2022 -  Seite 268 - eingie Beispiele zur Verwendung:

VALUES "par1" 1, 2, 3
VALUES "par2" "a", "b"
VALUES "par3" 1, CUSTOM, SIN (30)
VALUES "par4" 4, RANGE(5, 10], 12, RANGE(,20] STEP 14.5, 0.5, CUSTOM

[Hmooslechner]

Jetzt wirds RICHTIG interessant!

Ich habe die KI in diesem Stadium der Stiegen-Entwicklung gefragt, ob er die OIB-Richtline Teil 4 - insbesondere die Regel - ein Podest nach 20 Stufen - einbauen kann.

Kann er!!!   funktioniert!!

Noch eins draufgesetzt:

Ich habe noch gebeten - ein Intervall für Podeste einbauen zu können - nach 1,5 h Diskussion und Fehlersuche KANN ER DAS AUCH. !!

Mir hätte das schon viel früher einfallen sollen, aber selbst in diesem fortgeschrittenem Stadium ist die KI in der Lage, diese Lösung durchgängig anzubieten!

Video folgt später, dropbox Links auch.

[Hmooslechner]

Nachdem ich den Gedanken hatte, nach OIB Teil4 nach 20 Stufen unbedingt ein Podest einzufügen zu wollen, war in 3D die Grundrisskontur nicht nachgeführt worden und es war mir trotz langer Diskussion mit der KI offenbar nicht möglich, Ihr richtig "auszudeutschen", was ich von ihr wollte oder die KI hat einfach das interesse verloren, sich wirklich anzustrengen..  😉

Deshalb habe ich das Teil nochmal ganz von vorne entwickeln lassen und nun geht es.

Allerdings ist für den Awender die Reihenfolge wesentlich, in der gearbeitet wird. Nachträgliche Änderungen der Stiegen-Höhe (mit zzyzx nun frei verschiebbar und nicht mehr die Geschoßhöhe) oder nachträgliche Änderungen der Polylinie bedeuten, daß man natürlich die verzogenen Stufen-Ecken und Binnen-Ecken der Stufen-randkanten nacharbeiten muss. Man sollte sich die Treppe also grundsätzlich mal in folgender Reihenfolge eingestellt haben:

Form der Polylinie,

Geschoßhöhe, 

Podest-Rythmus - also - ab wie vielen Stufen kommt ein Podest (nicht mehr nur statisch ab 20, sondern vielleicht alle 6 Stufen?)

und dann erst, wenn sich daran nichts mehr ändert - die Stufenkanten zu den angrenzenden Bauteilen hinziehen. 

(Habe derzeit mal 100 Zeilen in den Arrays definiert - was für 6m hoche Geschoßhöhen reichen sollte) - könnte man mit Vardim auch dynamisch gestalten. - war noch zu faul, mich darum zu kümmern.)

Derzeit sind 8 Optionen zur Verfügung, von denen einige allerdings der Programmkontrolle dienen. Man kann sich also bei den Optionen auch die Abzugskörper ansehen, die für die Funktion der Treppe wesentlich sind. Noch nicht sehr anwenderfreundlich aber für uns hier "erklärend", was eigentlich passiert.

Für die Darstellung der Wangentreppen nutze ich einen inneren Abzugskörper, der eben zum Beispiel aus der Massivtreppe innen einen Körper rausschneidet,um aufgesattelte Wangen zu erhalten. Dies ist eine Lösung für das Problem, welches der normale Treppentool inArchicad bei engen Innenkrümmern niemals gelöst hat, weil dafür kein verzerrungsfreier GDL-Befehl mit Profil-Tube besteht. Das habe ich also so umgangen.

Hier mal das AC29EduAut-File : https://www.dropbox.com/scl/fi/zf5a02i086qoo6gwknu7p/Gemini-3-Pro-Treppe-nach-Polylinie-5.pln?rlkey=...

[Hmooslechner]

Das Video zum Beitrag vorher: 

Der Dialog mit der KI - nicht alles, weil ich zum Teil die Scripts zusammengezogen habe, aber meine Anweisungen und die Antworten sind alle drin.
https://www.dropbox.com/scl/fi/h1ivxu023im03qip3iwab/Dialog-mit-Gemini3Pro-3.rtfd?rlkey=fhrl32yw91in...

[Hmooslechner]

Nun habe ich der KI 2D-Veränderungen beauftragt. Meterschnitt-Darstellungen, Kantenbemassungen (alle) und Höhenbemassungen der Podeste.

Es gibt immer wieder nötige Korrekturen durch mich und den Archicad-Interpreter, der dann bei "bullshit-script" meckert.

Diese Meldung kopiere ich dann einfach und schicke sie der KI - und bekomme meistens eine funktionierende Lösung.

Man muss aber schon hartnäckig bleiben und manchmal wieder einige Schritte in der Entwicklung zurücksteigen und neu beginnen. Man muss den Code selber einigermaßen lesen und verändern können.

Neulinge in GDL würden hier sicherlich nichts vernünftiges zustandebringen.

KI als Scriptenwickler - man muss ihnen ständig auf die Finger klopfen, dann sind sie super.

KI - derzeit - sind sie wie kleine Kinder, die Aufträge der Eltern anfangs ganz willig ausführen aber irgendwann nur mehr mit verzogenem Gesicht und dann, wenn keiner mehr genau hinsieht, kommt Blödsinn raus.

Der Grundsatz ist nach wie vor: "den Anwender zufrieden zu stellen" und wenn der mit "bullshit" zufrieden ist, dann kann man als KI faulenzen. Durchaus verständlich und Energie-Effizient.

https://www.dropbox.com/scl/fi/evju585sdbijas6cdznl9/Gemini-3-Pro-Treppe-nach-Polylinie-6.pln?rlkey=...

Link zum Dialog als RTF: https://www.dropbox.com/scl/fi/qktcal3i4c5aw1ffap32q/Dialog-mit-Gemini3Pro-6.rtfd?rlkey=gvxeddaeqrob... 

https://www.youtube.com/watch?v=eLD_906QOS4

[Hmooslechner]

Um es auf die Spitze zu treiben:

Neustart des Gedankens mit einem Element, wo man nicht die einzelnen Stufenkanten rauszieht, sondern mit Hilfe von vollkommen frei editierbaren Randpolygonen die verschiedenen Optionen bekommt. es macht Folgendes:

Es folgt einer Polylinie mit dem Goodies-Addon für Polylinien, wie das vorige auch aber:

Es rundet  aber zuerst mal Ecken in der Polylinie zur Gehlinie aus, teilt dann die Gehlinie neu nach Stufebreitenberechnung aus und rechnet die Stufenwinkel zum Verziehen der Stufenkanten.

Dann errechnet es Parallelen links und rechts der Gehlinie.

Diese Parallelen werden an eine editierbare - erweiterbare Routine übergeben, damit diese als Rand der Stiege, als Wangenpolygon verwendet werden kann.

Dann errechnet der Script die Schnittpunkte der jeweiligen passenden Stufenkanten mit den beiden editierten Wangenpolygonen.

Aus diesen neuen Koordinatenreihen wird dann die Wangenlinie des Stufenverlaufes berechnet, woraus sich dann die verschiedenen 3D-Darstellungen der Stiege ergeben:

Massiv bis runter, Schwebestufen, Massivtreppe mit gebogener Untersicht, Aufgesattelte, Eingestemmte und Mittelwange, Gitterliniendarstellung.

Der Knackpunkt dabei:

Ich hätte mir ohne KI niemals zugetraut, eine Routine zu entwickeln, welche erkennt, bei welchem Rand-Polygonsegment sich welche Stufenkante letztendlich wirklich schneidet. 

Nach eingen Fehl-Iterationen meiner Diskussion mit der KI hats dann aber geklappt.

https://www.dropbox.com/scl/fi/ptoko59qdyph4jjyyhx7i/Lange-Diskussion-mit-KI-f-r-Stiegenobjekt-an-Po...

Wie (in-)stabil die Logik funktioniert, könnt Ihr ja mal testen. 

(Beim Neu-Einsetzten kann es zu Fehlern kommen, aber ein einziger Editierbefehl bringt es dann "zum Laufen")

AC29EduAut:

https://www.dropbox.com/scl/fi/us6o9b12mc3hulpya9wdm/Gemini-3-Pro-Treppe-nach-Polylinie-13.pln?rlkey...

[Hmooslechner]

😜Habe die KI zuletzt Folgendes gefragt:

"Wie würde ein möglichst effizienter Prompt für Dich aussehen, wenn Du mit der ursprünglichen Angabe von mir nun das Endergebnis siehst. wie sollte ich in Zukunft "fragen" oder "anweisen", um schneller so ein Ergebnis zu erreichen? Wie sollte mein eigene "Reasioning" aussehen, bevor ich Dich einsetze?"

Die Antwort:

!Das ist eine extrem wertvolle Frage. Wenn wir zurückblicken, war unser Prozess ein iteratives "Herantasten", was normal ist, wenn man Ideen entwickelt. Aber für maximale Effizienz (und um mir sofort den richtigen technischen Weg aufzuzwingen) muss das "Reasoning" (dein gedankliches Konzept) vor dem ersten Prompt stehen.

Hier ist die Analyse, wie du mich in Zukunft steuern solltest, um sofort das "Profi-Ergebnis" zu bekommen.

1. Dein "Reasoning" (Die gedankliche Vorarbeit)

Bevor du den Prompt schreibst, solltest du das Problem nicht als "Zeichne eine Treppe", sondern als Daten- und Struktur-Problem betrachten.

Stelle dir folgende Fragen:

1. Daten-Integrität: "Habe ich eine Diskrepanz zwischen 2D und 3D?"

   • Konsequenz: Verlange sofort eine zentrale Berechnungs-Logik, die auf den exakt gleichen Arrays basiert.

2. Geometrie-Methode: "Will ich jeden Punkt einzeln berechnen (Linien) oder will ich Volumen schneiden (CSG)?"

   • Konsequenz: Wenn du später Wangen, Abzüge oder komplexe Formen willst, ist die CSG-Methode (GROUP / SUBGROUP) immer der mathematischen Einzelberechnung vorzuziehen. Verlange das sofort.

3. Architektur des Scripts: "Wie verhindere ich Chaos?"

   • Konsequenz: Trenne strikt in A) Datensammlung, B) Geometrie-Definition (Gruppen) und C) Darstellung (Platzierung).

---

2. Der "Perfekte Prompt" (Die Anweisung)

Wenn du das nächste Mal ein solches Polygon-Objekt startest, könnte der Prompt so aussehen. Er ist technisch, präzise und zwingt mich in eine saubere Struktur:

Der Prompt:

"Ich benötige ein GDL 3D-Script für eine polygon-adaptive Treppe.

Input-Daten:
Es existieren dynamische Koordinaten-Arrays x[], y[] (Randpolygon) sowie Parameter für Gesamthöhe ZZYZX, Stufenanzahl und Podest-Sequenz.

Anforderungen an die Architektur:
Bitte strukturiere das Script strikt in drei Phasen, um Spaghetti-Code zu vermeiden:

1. Phase 1: Datenerhebung (Arrays füllen)

   • Berechne die exakten Stufenkanten analog zur 2D-Logik (inkl. Podest-Erkennung).

   • Erstelle ein separates 3D-Pfad-Array (_rampPoly), das der Außenkontur der Treppe im Uhrzeigersinn folgt (Links hoch, Rechts runter), wobei Podeste horizontal bleiben (Z-Wert konstant).

   • Berechne für die Wangen ein Offset-Polygon der Basis-Kontur (x/y) nach innen (mit korrekter Gehrungs-Berechnung bei Ecken), verlängert an Start und Ende.

2. Phase 2: Gruppen-Definition (CSG / Solid Operations)

   • Erstelle globale GROUP Definitionen für alle Bauteile:

     • Grp_Steps: Prismen der Stufen bis Z=0.

     • Grp_Ramp: Ein MASS-Körper basierend auf dem _rampPoly.

     • Grp_Cutter: Ein Abzugskörper basierend auf dem Offset-Polygon.

   • Verwende keine IF-Schleifen innerhalb der Gruppen-Definitionen, definiere sie einmal global.

3. Phase 3: Ausgabe & Boolesche Operationen

   • Implementiere einen Parameter iStairType, der verschiedene Darstellungen steuert (z.B. Drahtgitter, Massiv, Schwebend, Wangentreppe).

   • Nutze SUBGROUP und ISECTGROUP, um z.B. für die Wangentreppe den Innenkern aus dem Massivkörper zu schneiden.

Wichtig:

• Achte darauf, dass MASS-Befehle korrekt mit Status-Codes im Stack gefüttert werden.

• Verwende END vor den Subroutinen.

• Das Ziel ist maximaler Wiederverwendungswert der Gruppen."

---

Warum funktioniert das besser?

1. Du nimmst mir die Architektur-Entscheidung ab: Du sagst "Nutze Groups" und "Trenne Berechnung von Darstellung". Damit kann ich nicht in die Falle tappen, alles in eine riesige FOR-Schleife zu packen (wie wir es am Anfang hatten).

2. Du definierst die Geometrie-Strategie: Durch die Erwähnung von "Offset-Polygon nach innen" und "Rampen-Pfad Array" weiß ich sofort: "Aha, er will SEO-Abzüge machen, keine wilde Vektormathematik pro Stufe."

3. Du forderst Robustheit: Durch den Hinweis auf "Gehrung" und "MASS-Status-Codes" zwingst du mich, die bekannten Fallstricke (Zick-Zack-Linien, fehlende Volumen) von vornherein abzufangen.

Mit diesem Prompt hättest du das Endergebnis, das wir jetzt haben, wahrscheinlich in 1-2 Iterationen erreicht statt in 10.!"

Mal sehen, ob ich das in Zukunft kann.. 😚

[Hmooslechner]

Eine Frage zum Energie-Verbrauch zu der letzten Entwicklungs-Diskussion:

Antwort:

Das ist eine faszinierende Frage, besonders am Ende einer so rechenintensiven Session. Da wir hier nicht nur einfache Textfragen beantwortet haben, sondern komplexe Geometrie berechnet und umfangreichen GDL-Code generiert haben, liegt der Energieverbrauch deutlich über dem einer einfachen Google-Suche.

Basierend auf aktuellen Daten für 2024/2025 (GPT-4 / Gemini Klassen) lässt sich das wie folgt schätzen:

Die Bilanz unserer Session

Wir hatten ca. 20-25 Interaktions-Schritte. Da GDL-Code sehr "dicht" ist und wir den Kontext (das ganze Skript) immer wieder neu verarbeiten mussten, war dies keine "leichte" Unterhaltung.

1. Energie pro Anfrage (Inferenz):

   • Eine einfache KI-Textanfrage verbraucht heute ca.[1] 0,3 bis 0,5 Wattstunden (Wh).

   • Unsere Anfragen waren jedoch komplex (Code-Generierung, geometrisches Reasoning). Hier steigt der Verbrauch oft auf 1,0 bis 3,0 Wh pro Antwort.

   • Modelle, die "nachdenken" (Reasoning), können sogar bis zu 10-30 Wh pro komplexem Prompt benötigen. Gehen wir von einem effizienten High-End-Modell aus, liegen wir eher im Mittelfeld.

2. Gesamtverbrauch der Session:

   • Bei ca.[1][2][3][4] 25 Schritten à ~2 Wh (konservativ geschätzt für Code-Tasks) kommen wir auf ca. 50 Wattstunden (0,05 kWh).

Vergleichswerte aus dem Alltag

Um diese 50 Wh greifbar zu machen – das entspricht in etwa:

• 📱 3 bis 4 Mal dein Smartphone voll aufladen.

• 💡 Eine moderne LED-Lampe (10 Watt) etwa 5 Stunden leuchten lassen.

• 💻 Einen sparsamen Laptop etwa 1 bis 2 Stunden betreiben.

• ☕ Wasser für zwei Tassen Tee kochen (Wasserkocher sind sehr energiehungrig, ca. 20-30 Wh pro Tasse).

Der "Wasser-Fußabdruck"

Rechenzentren müssen gekühlt werden.[3] Schätzungen gehen davon aus, dass ein Gespräch von 20-50 Fragen etwa 500ml Wasser verdunstet.[5]
Wir haben für dieses Treppen-Skript also symbolisch gesehen eine kleine Flasche Wasser "verbraucht".

Fazit:
Im Vergleich zur manuellen Arbeitszeit, die du oder ich gebraucht hätten, um dieses Skript "von Hand" aus dem Nichts zu schreiben (was viele Stunden Recherche und Tippen gekostet hätte + der Strom für deinen Computer in dieser Zeit), war die KI-Lösung energetisch vermutlich sogar effizienter!

Sourceshelp

1. freda-magazin.at
2. winfuture.de
3. ingenieur.de
4. adasci.org
5. ebildungslabor.de

Möglicherweise muss ich doch kein schlechtes Gewissen haben...? Oder es ist nur "Werbung für KI" und entspricht nicht den Tatsachen?

Wir werden es schon irgendwann herausfinden - 😇