Project2 "aufbohren"

[Hmooslechner]

Ebenso wie der Ebenenwunsch wäre dies eine wirkliche Verbesserung.

Derzeit gibt es schon einige Derivate von Project2 - alle für bestimmte Situationen sinnvoll.

Was ich mir wünsche wäre eine Möglichkeit - im 3D-SCRIPT - Bereiche festlegen zu können, also - welche 3D-Elemente nun in 2D mit Project2 dargestellt werden sollten - und welche nicht.

Nur ein Beispiel:

Im 3D-Script kann das Element herausfinden - in welchem Geschoß es sich in welcher Höhenlage befindet.. Leider kann man diese "Erkenntnis" nicht ans 2D weitergeben und muß dies über Umwege im 2D wieder herausfinden.

Wenn also ein Element über mehrere Geschoße eingesetzt wird, wäre es viel einfacher - die jeweilige korrekte Darstellung des jeweiligen Geschoßschnittes dann ins 2D zu projezieren und müßt enicht aufwändig programmiert werden - was ja auch zusätzlich fehleranfällig ist.

[Frank Beister]

Das kannst du schon heute. Unter der Verwendung von gloablen Variablen kannst du die 3D-Ausgabe steuern. Da braucht es kein spezielles PROJECT2. Außerdem kannst du auch mit den Attributbefehlen den GDL-Elementen Kategorien zuordnen.

[Hmooslechner]

Was ich mir eigentlich wünsche - wäre die Möglichkeit wie bei Dächern, Wänden, Schalen und Morphs - usw - dass ich ein 3D-GDL einfach im jeweiligen Geschoß in ein Meter Höhe geschnitten dargestellt bekomme. Nicht wie bisher eine projizierte Darstellung von oben aus unendlicher Höhe, sondern eben den Meterschnitt im jeweiligen Geschoß.

Natürlich kann man im 2D sehr umständlich - symbolische Darstellungen herstellen, aber dies ist in Wirklichkeit doppelt gemoppelt, wenn ich es im 3D ohnehin schon programmiert habe.

Im Sinne eines durchgängigen Systemes sollte genau dies - was für andere 3D-Elemente gilt ( Dächern, Wänden, Schalen und Morphs - usw) - auch für GDLs gelten und funktionieren.

Von der symbolischen Darstellung braucht ja nichts wegzufallen.

Nur würde es vieles vereinfachen, wenn man beispielsweise mit einem aufgebohrten "project2" festlegen könnte, dass man eben einen Geschoß-Meterschnitt darstellen will - ohne alles im 2D nachzuprogrammieren (was bei komplexen Elementen oft gar nicht möglich ist.)

Wenn ich nur an mein relativ neues Stahlkamin-Objekt denke, welches ja in verschiedenen Geschoßen ganz anders aussehen soll, wäre dies für den 2D-Script wirklich eine Vereinfachung.

Im KG sehe ich den Anschluß, das Putztürchen usw. aber nicht die Dachabdeckung
Em EG sehe ich das Rohr und vielleicht auf den Deckendurchbruch und nicht wieder die Dachabdeckung usw.

So ein Kamin ist aber noch relativ einfach auch im 2D-Meterriss nachzugestalten, andere Objekte sind da wesentlich komplexer..

[Frank Beister]

Du kannst im 3D-Skript checken, ob das Skript gerade für eine 3D-Projektion verwendet (durchlaufen) wird. Dort kannst du auch das Geschoss bestimmen, in dem das Skript gerade abgearbeitet wird und die Schnitthöhenparameter auslesen. Damit kannst du den CUTPLANE setzen. Den einzigen Wunsch, den du da haben kannst ist zu wissen wie. 🙂 Such mal in den globalen Parametern. Ich kann dir das jetzt nicht raussuchen, aber es geht. Schau mal in meinem Höhenschnittobjekt nach. Da sollte es draus ersehen zu sein.

[Hmooslechner]

Hallo Frank!

Natürlich kennen ich einen Teil Deiner Anregungen - Danke für den Rest, den ich noch nicht kannte.

Allerdings trifft dies nicht des Pudels Kern.

Es ist einfach zu kompliziert.

Wenn es im GDL so wie im Dach- Morph, Schale usw funktionieren würde, könnte man sich das alles sparen. (Soll nicht heissen, dass die jetzigen Möglichkeiten rausfliegen sollten.)

Mein Wunsch ist : Vereinfachung für den User - eben mit Hilfe des oben Erwähnten.

Viele andere Dinge sind ebenfalls viel zu kompliziert.

Schön, wenn wir es kapiert haben gehören wir zur Elite 😁 - aber allen anderen hilft das nichts.

Beispielsweise dass man mindestens 3 Zeilen schreiben muss, um einen editierbaren Hotspot zu gestalten - ist - verzeiht mir - Blödsinn.

Sowas sollte die Programmiersprache vereinfachen - und Userfehler abfangen. Schließlich haben wir hier keine Maschinensprache vor uns, sondern beinahe eine "Hochsprache" 😁

Ebenso viel zu komplex - wenn man sich das Script für einen "sich selber erweiternden Polygonzug" ansieht. Dies sollte alles für den User viel einfacher möglich sein. Man muss für solche Nebensächlichkeiten viel zu viel Zeit reinstecken.

Schön, das es überhaupt geht - aber alles kann das noch nicht gewesen sein!

Unser Archicad - Programm steckt noch in den Kinderschuhen - noch mindestens 20 Jahre - so würde ich es sehen - und ich seh mich immer als "Anwalt der User" - nicht der Archicad-Programmierer.. 😁


Ach ja - Flux-Kompensiert es schön? 😁