[Frage] Möglichkeiten von PythonParts Programmierung [Gelöst]

Schlagworte:
  • PythonParts
N_Weber42
N_Weber42
09.06.2020 - 13:16 Uhr

Hallo,

ich habe mich ursprünglich mit SmartParts Programmierung beschäftigt. Nun habe ich aber einige Anforderungen, bei denen ein PythonParts eher in Frage kommen könnte.
Bevor ich aber nun einiges an Zeit investiere und mich damit auseinandersetze, habe ich ein paar Fragen.

1. Ist es möglich eine Eingabe Palette wie bei den SmartParts zu programmieren, damit man verschiedene Modelle zum Beispiel erzeugen kann mit ein paar Klicks?

2. Bei den SmartParts kann man ein Objekt generieren, dass mehrere Objekte mit eigenen Attributen umfasst. Bei dem platzieren erstellt man somit eine SmartPartGruppe, die bei den Reports auch als eigene Objekte angesehen werden können. Kann man so etwas auch mit PythonParts programmieren?

3. Eine SmartParts Programmierung ermöglicht es verschiedene Folien zu erstellen. Dabei ist mir nur das erstellen von zwei Folien wichtig. Die eine Folie soll nur in der 2D-/Grundriss-Ansicht zu sehen sein und die andere Folie nur in einer 3D-Ansicht. Ich nehme an, dass man nur mit Folien solch eine Einstellung in Abhängigkeit der Ansicht einstellen kann. Falls es noch irgendwie ohne Folien gehen sollte und das mit PythonParts möglich ist, bin ich auch interessiert.

Ursprünglich hatte ich überlegt mit VisualScripting anzufangen, aber ich scheitere mit dem Punkt drei meiner drei Fragen. Vielleicht irre ich mich auch, aber soweit ich verstanden habe kann man bei VisualScripting nicht alle meiner drei Punkte erfüllen.
Ich würde mich freuen, wenn mir da jemand mit diesen Fragen weiterhelfen kann!

Lösung anzeigen Lösung verbergen

marekczyborra
marekczybo…
11.06.2020 - 11:15 Uhr *

Hallo,

1. eine Eingabe-Palette gibt es in Pythonparts natürlich auch. Diese wird aber in einer separaten .pyp-Datei abgelegt; nicht so schön integriert und bequem wie bei SmartParts. In Pythonpart ist es meines Wissens nach noch nicht möglich, wie bei dem Fenster-smartPart eine interaktive Zeichenfläche in die Palette zu integrieren. Auf der anderen Seite kannst du im Prinzip auch Visual-Script als eine zusätzliche Eingabe-Palette ansehen und das ist dann schon sehr beeindruckend.
2. ja gibt es natürlich: class PythonPart und class PythonPartGroup
3. ja gibt es natürlich auch: visibility_layer_a, visibility_layer_b und visibility_layer_c als Folien; plus visibility2d und visibility3d unter class view unter PythonPart.py

Was ich vermisse ist eine verständliche Dokumentation zu Python in Allplan. Zu Python in Revit gibt es zig Videos. Zu Allplan nur ein einziges veraltetes Video, was kaum über die Installation hinausgeht.
Ich denke, ohne Schulung wird es aber schwierig.

Anders als die übersichtliche Smart-Part-Umgebung, ist für Python neben der Python-Kenntnis ein tiefgehendes Verständnis des CAD Programms notwendig und das ist naturgemäß sehr komplex. Ohne Erklärung sehr schwer verständlich.

Warum man entschieden hat, die SmartPart script Sprache, seit über fünf Jahren überhaupt nicht mehr weiterzuentwickeln ist von Nutzerseite aus gesehen sehr schade.
Vielleicht fehlen dir ja gar nicht viele neue Funktionen im SmartPartscript, so dass auch SmartPartscript deinen Anforderungen genügen würde. Mit einem guten Dialog zwischen Entwicklern und Nutzern könnte man an einigen wenigen wichtigen Funktionen weiterarbeiten. Ich denke zum Beispiel an die Interaktivität mit den Allplan-Objekten. So wie sich zum Beispiel smartparts in Fensteröffnungen einschreiben können, gäbe es ähnliche nützliche Funktionen. Python ist sehr gut im Auslesen von dem was da ist, das fehlt in SmartPart etwas.

Bei Archicad scheint man dem GDL, was der SmartPart-script bei Allplan eins zu eins entspricht, treuer zu sein. Treppen usw sind GDL-Objekte.

Klar ist Python moderner und kann wegen der ähnlichen Funktionsweise direkter auf das CAD Programm aufdocken. Aber ohne Erklärung ist die PythonPart Schnittstelle in meinen Augen für Architekten noch nicht wirklich ausschöpfbar.

czyborra klingbeil architekturwerkstatt - http://www.cka.berlin

marekczyborra
marekczybo…
11.06.2020 - 11:15 Uhr * [Lösung]

Hallo,

1. eine Eingabe-Palette gibt es in Pythonparts natürlich auch. Diese wird aber in einer separaten .pyp-Datei abgelegt; nicht so schön integriert und bequem wie bei SmartParts. In Pythonpart ist es meines Wissens nach noch nicht möglich, wie bei dem Fenster-smartPart eine interaktive Zeichenfläche in die Palette zu integrieren. Auf der anderen Seite kannst du im Prinzip auch Visual-Script als eine zusätzliche Eingabe-Palette ansehen und das ist dann schon sehr beeindruckend.
2. ja gibt es natürlich: class PythonPart und class PythonPartGroup
3. ja gibt es natürlich auch: visibility_layer_a, visibility_layer_b und visibility_layer_c als Folien; plus visibility2d und visibility3d unter class view unter PythonPart.py

Was ich vermisse ist eine verständliche Dokumentation zu Python in Allplan. Zu Python in Revit gibt es zig Videos. Zu Allplan nur ein einziges veraltetes Video, was kaum über die Installation hinausgeht.
Ich denke, ohne Schulung wird es aber schwierig.

Anders als die übersichtliche Smart-Part-Umgebung, ist für Python neben der Python-Kenntnis ein tiefgehendes Verständnis des CAD Programms notwendig und das ist naturgemäß sehr komplex. Ohne Erklärung sehr schwer verständlich.

Warum man entschieden hat, die SmartPart script Sprache, seit über fünf Jahren überhaupt nicht mehr weiterzuentwickeln ist von Nutzerseite aus gesehen sehr schade.
Vielleicht fehlen dir ja gar nicht viele neue Funktionen im SmartPartscript, so dass auch SmartPartscript deinen Anforderungen genügen würde. Mit einem guten Dialog zwischen Entwicklern und Nutzern könnte man an einigen wenigen wichtigen Funktionen weiterarbeiten. Ich denke zum Beispiel an die Interaktivität mit den Allplan-Objekten. So wie sich zum Beispiel smartparts in Fensteröffnungen einschreiben können, gäbe es ähnliche nützliche Funktionen. Python ist sehr gut im Auslesen von dem was da ist, das fehlt in SmartPart etwas.

Bei Archicad scheint man dem GDL, was der SmartPart-script bei Allplan eins zu eins entspricht, treuer zu sein. Treppen usw sind GDL-Objekte.

Klar ist Python moderner und kann wegen der ähnlichen Funktionsweise direkter auf das CAD Programm aufdocken. Aber ohne Erklärung ist die PythonPart Schnittstelle in meinen Augen für Architekten noch nicht wirklich ausschöpfbar.

czyborra klingbeil architekturwerkstatt - http://www.cka.berlin

Nemo
Nemo
12.06.2020 - 09:44 Uhr * [Hilfreichste Antwort]

Hier mal eine kleine Einordnung der verschiedenen "Programmier"-Schnittstellen: SmartParts, PythonParts, Visual-Scripting(auf PythonParts aufbauend)

Man muss zunächst mal differenzieren, was man erreichen möchte.
Braucht man ein parameterisches Element (z.B. Stahlträger, Treppe, Fenster => Content) kann man dafür alle drei Schnittstellen einsetzen. Wenn es um leichte Erlernbarkeit/Bedienbarkeit und einfache Geometrien geht, fährt man mit den SmartParts am besten. Auch hinsichtlich Gestaltung der Eingabe-Dialoge/-Palette sind die SmartParts sehr einfach und zugleich sehr leistungsfähig.
Das gilt ebenso bei der Definition von grafischen Eingabe-Möglichkeiten (Griffe).
Wie leistungsfähig die SmartPart sind, kann man sich bei den verschiedenen Öffnungselementen (Fenster, Türen, Oberlichter etc.) anschauen. Und man kann mit SmartParts auch Bewehrung scripten.

Erst wenn man mit einem SmartPart-Script nicht weiterkommt, sollte man "einen Gang höher schalten", und sich Python-basierten Schnittstellen ansehen. Dort gibt es einige sehr leistungsfähige Geometrie-Klassen und -Algorithmen, die man via Python benutzen kann, z.B. Schnittpunkt zweier Linien ermitteln lassen. Auch die neuen allgemeinen 3D-Körper (Parasolid BRep's) kann man nur mit Python erzeugen. Hinsichtlich Bewehrung ist Python sehr viel leistungsfähiger als die SmartParts. Obwohl die Bewehrung auch im Visual-Scripting integriert ist, ist die Umsetzung von Bewehrungs-Algorithmen mit Visual-Scripting sehr umständlich und auch schwierig!

Wenn man eine eigene Funktionen mit Allplan realisieren möchte, geht das nur mit Python.
Beispielsweise eine Abfrage von Attributen anderer Zeichnungselemente, oder Vergabe von Attributen an diese.
Auch dafür gibt es in Visual-Scripting Nodes. Allerdings sind diese z.T. sehr eingeschränkt, und die interne Funktion ist nicht dokumentiert.

Generell ist die Programmiersprache Python natürlich eine größere Hürde beim Einstieg, als es die Basic-verwandten SmartPart-Scripts sind. Erschwerend kommt hinzu, dass die Dokumentation der Python-API in Allplan leider nicht über eine Beschreibung der Klassen- und Funktionsschnittstellen hinaus gekommen ist. Die Typen der Funktionsparameter sind häufig falsch dokumentiert. Durch die dynamische Typisierung von Python erkennt man solche Typ-Fehler erst zu Laufzeit, was das Debuggen sehr schwierig macht. Da hilft es nicht, dass man dafür bei der Allplan-Python-API auch noch die Profi-IDE Visual-Studio benötigt. Immerhin werden die noch vielen fehlende Funktionen in Python nach und nach durch Allplan vervollständigt.

Mit Visual-Scripting wurde versucht, ganz ohne Script-Code auszukommen, und sich das Flussdiagramm für die Daten grafisch zusammenzustöpseln. Das funktioniert natürlich nur so gut, wie die Nodes und deren interne Funktion dokumentiert sind.
Ausserdem fehlen noch sehr viele Funktionen als Nodes, aber immerhin kann man sich eigene Python-Scripts in ein Node einbauen.
Da Visual-Scripting eigentlich ein Daten-Fluss-Diagramm darstellt, sind Programm-Schleifen in Visual-Scripting in Allplan derzeit nicht umsetzbar. Wer so etwas braucht, sollte lieber auf ein klassiches Python-Script zurückgreifen. Das Überprüfen des Datenflusses ist derzeit noch nicht möglich, da es keine "List-Panels" gibt, mit denen man sich die Daten anschauen kann.

Generell hat Visual-Scripting seine Stärke eindeutig in der (spielerischen) Formenfindung oder Optimierung mit Hilfe geometrischer Algorithmen. Da ist es vergleichbar mit den Anwendungsgebieten von Grasshopper(Rhino) und Dynamo(AutoCad/Revit).

Auch das Abfragen und Filtern von Elementen der Zeichnungsdatenbank von Allplan kann man mit Visual-Scripting aufgrund der guten Mengen-Operationen von Python effizient umsetzen. Man ist aber immer darauf angewiesen, dass Allplan die entspr. Funktion als Python-Wrapper zugänglich gemacht hat.

Fazit: Es gibt für jeden etwas! Man muss sich aber darauf einlassen, und mit der Materie beschäftigen.

Wenn man mit diesen an eine Grenze stößt, kann man als letzte Stufe auf die Allplan-API (NOI) umsteigen,
und sehr performante und flexible Plugins (wie die von CDS) entwickeln. Allerdings braucht man dazu schon etwas bessere Kenntnisse von C++, C# (WPF) and den Allplan-Interna.

Hinweis:
Es handelt sich um meine persönliche, auf langjährigen Erfahrungen basierende Meinung ohne Anspruch auf Allgemeingültigkeit.