2026-02-26 09:10 AM - bearbeitet 2026-02-26 10:16 AM
Wir haben regelmässig grosse Projekte, sprich Überbauungen mit Mehrfamilienhäusern und grosser Tiefgarage.
Die sind alle nicht klein. Der Teamworkplan hat online auf dem (BIMcloud Basic) Server 6252 MB.
Letzten Winter haben wir extra unsere Internetleitung anpassen lassen (1 Gbit/s Down- und Upload, resp. /8 = 125 MB/s).
> 6252 / 125 = 50 Sekunden zum downloaden resp. laden., Also vom Internet her wäre es absolut kein Problem, 1 Minute.
Das grosse aber ist, bis der Plan offen ist, dass ich ihn bearbeiten kann benötigt regelmässig!!! 5, 10, 20 oder sogar 30 fette Minuten bis der Plan offen ist! und der 3D-Rundgang ruckelt auch extrem (mit Top Hardware macOS).
08:44 Uhr start Polygon zählen (1-Verarbeitete Element) / 08:54 fertig gezählt.
Die Projekte sind eben halt gross, mit grossflächigen Decken, langen Wänden, vielen Öffnungen, SEO-Verschneidungen (die können wir leider nicht verhindern > Der Plan sollte ja gut aussehen!), mehrere Laufmeter eigene Balkongeländer (mit eigenen Staketen als Profil). Sehr vielen Layouts (Ja das müssen wir auch haben! > Grundrisse, Gesamtschnitte, Detailschnitte, etc. etc.).
Hier paar Screenshots:
Wie kann man dann alles "optimaler" programmieren, dass die Performance so wenig wie möglich darunter leidet? Und auch eben laden und empfangen.....
Wenn man solche Projekte hat, wie sollte das alles anders gehen. Bei diesem Projekt benutzen wir auch Hotlinks, wo ein Geschoss dieses Geländer hat und im Gesamtprojekt eben x-mal dargestellt wird. und und und.....
am 2026-02-26 09:35 PM
Also in meiner konservativen Milchmädchenrechnung komme ich auf etwa 400 Polygone – je Stakete!
Das ist einfach viel zu viel.
Die Staketen sind ja auch "GDL" – nur eben Morphbarf. Ich denke, wenn man die richtig programmieren würde, dann wäre schon viel gewonnen, da man dann die Anzahl der generierten Polygone auch dynamisch machen könnte.
An sich ist es ja gut, dass man sich abhelfen kann, in dem man selbst Geländerpfosten erstellen kann, aber man muss eben aufpassen.
am 2026-02-26 10:22 PM
Guten Tag Torben,
D.h. jedes Geländerstück separat als Objekt speichern, resp, die die gleich sind mehrmals einsetzen.
Was aber dann nicht ganz verstehe ist, warum dann als Objekt gespeichert, der Plan, sprich die Datei kleiner werden sollte, da doch genau die gleichen Elemente wie beim Geländertool mitgespeichert werden?
Danke für mein Verständnis.
am 2026-02-26 11:07 PM
Torben deutet ja an, dass dann einfach die ganzen Hintergrundberechnungen wegfallen.
Reines GDL, gut gescriptet, ist sehr performant in Archicad.
Ich glaube trotzdem, dass schon der Einsatz "besserer" Staketen viel bringen würde.
Hier mal so als Beispiel. Mit knapp 50 Polygonen nur ein achtel so schwer. Würde deine Geländer auf weniger als eine halbe Million insgesamt zusammen stutzen.
am 2026-02-27 10:17 AM
Hallo zusammen,
Ich habe jetzt mal das Geländer auseinander genommen, extra alles separat gespeichert um alles zu testen.
Vorab gesagt, Polygone bleiben gleich, nur der Speicherplatz wird 90% kleiner.
Wie hast du deine Stakete mit so wenigen Polygonen erstellen können? Wir haben ein Morph Stab bearbeitet, so dass wir die Krümmungen bekommen haben.
Dein Beispiel besteht dadurch nur aus 54 Polygonen (wunderbar!), unser Beispiel besteht aus 385 Polygonen; also satte 7x mehr....... Wie hast du das so hingebracht?
Hier nochmal mein Stand mit Bildschirmfotos;
Polygonzähler hat beim Standardplan bei separater Auswahl nicht funktioniert, keine Ahnung wieso (ArchiCAD 26)
Hier konnte ich es darstellen, wo ich einen leeren Plan öffnete und einzeln die komplette Auswahl als Polygone auswählen konnnte.
Und hier zum Abschluss wegen Speicherplatz der einzelnen Teile;
Also konkret also, meine Stakete mit deiner Variante neu zeichnen, alles neu abspeichern und alle Geländer neu als Objekt speichern?
Nur das Problem ist, als Objekt, kann man diese wieder schlecht rasch bearbeiten, wenn man es als Geländer länger oder kürzer haben möchte.
Zum Abschluss mit deiner Variante, wären die Anzahl Polygone 7x weniger, und Speicherplatz (wegen Geländer) 90% weniger, resp. nur bei den Geländern und dementsprechend besser für den gesamten Teamwork, oder Solo-Plan.
am 2026-02-27 11:09 AM
Ich weiß, ich weiß, Architekten sind keine Programmierer, aber nach meiner Erfahrung ist es in der Regel zielführender, wenn man komplexere Objekten in GDL programmiert, anstatt sie über ein Werkzeug zu erstellen. Ich habe gerade mit Geländern ganz viele ganz schlechte Erfahrungen gemacht (Performance, AC-Abstürze), sobald es mehr ist als nur das stabförmige Balkongeländer.
Das kann ich aber leicht sagen, weil ich etwas Erfahrung mit GDL habe. Und vor allen Dingen, weil es eine SWEEP-Funktion in GDL gibt, die gernau das macht, was Du möchtest:
am 2026-02-27 11:12 AM
Aber mal eine ganz andere Frage: ich habe mir Deinen verdrehten Stab nochmal angesehen. Der wird ja nicht über die Mittelachse verdreht, sondern über die Randachse. Wie soll das denn hergestellt werden? Habt ihr mal einen Schlosser gefragt, ob es dafür überhaupt eine Maschine gibt?
am 2026-02-27 11:25 AM
Dieses verdrehte Geländer wurde vom Schlosser, resp. Metallbauer schon bei einem anderen Bau angewendet.
Bekam von ihm dazumal Beispiel Fotos wie sie gedreht und verbaut wurden.
Da die Programmierung eben schwierig ist (hoffentlich mit KI in Zukunft einfacher), haben wir es 0815-mässig mit einem Morph gemacht das man bearbeiten kann.
Bei der KI wäre so was sinnvoll, wenn man im ArchiCAD dieses Morph Objekt angeben könnte und dann der Befehl lauten würde: Erstelle mir das Morph als Sweep GDL Objekt oder so......
Programmieren ist immer so viel Frust dabei, da gewisse Beispiele nicht immer funktionieren, bis man den Code richtig versteht. Wenn es aber klappt, dann ist es natürlich super.
am 2026-02-27 12:06 PM
In der Schweiz kann man sowas wahrscheinlich eher herstellen als bei uns im Großkanton ...
am 2026-02-27 01:33 PM
So wie Torben es schon verraten hat: Es ist eben ein "richtig" programmiertes Teil – und Sweep kommt drin vor; das macht 1:1 das, was du brauchst.