Umfrage - Allplan Grasshopper Connection


Lieben PythonPart Entwicklern,

Wir prüfen derzeit die Idee, Allplan mit Grasshopper zu integrieren und würden Ihre Einsichten sehr schätzen. Bitte klicken Sie hier, um auf die Umfrage zuzugreifen. Es sollte etwa 10 Minuten dauern. Ihr Feedback wird entscheidend sein, um dieses neue Feature zu formen und sicherzustellen, dass es Ihren Anforderungen entspricht.

Wir danken Ihnen im Voraus für Ihren wertvollen Beitrag. Wir freuen uns auf Ihre Gedanken.

Mit freundlichen Grüßen
Xinling Xu

Product Owner API, Allplan GmbH

Show most helpful answer Hide most helpful answer

Hallo Xinling

Logisch ist Grasshopper ein geiles Tool, aber ist das wirklich die richtige Zielgruppe (Durchschnittliche Allplan User)?
Ich wünsche mir in Allplan Tools von denen möglichst viele Anwender profitieren können.

Wenn Ihr schon über Schnittstellen nachdenkt wäre der Multi-IFC Export sicher viel höher zu priorisieren.
Sowas habt Ihr ja in eurem Entwicklungsteam ja via Phyton schon gemacht.

Ein anderes Projekt "Grafische Überschreibungen" (analog Archi*** auch im Nem-Konzern) ist bei mir seit Jahren zuoberst auf der Wunschliste.
Bitte investiert eure Zeit doch besser mit diesem Thema, dass würde nämlich viele Allplan User glücklich machen.

Gruss Thierry

https://www.cds-bausoftware.ch
https://www.cds-bausoftware.ch/bundle
https://www.cds-ausbildung.ch

1 - 10 (18)

Hallo Xinling

Logisch ist Grasshopper ein geiles Tool, aber ist das wirklich die richtige Zielgruppe (Durchschnittliche Allplan User)?
Ich wünsche mir in Allplan Tools von denen möglichst viele Anwender profitieren können.

Wenn Ihr schon über Schnittstellen nachdenkt wäre der Multi-IFC Export sicher viel höher zu priorisieren.
Sowas habt Ihr ja in eurem Entwicklungsteam ja via Phyton schon gemacht.

Ein anderes Projekt "Grafische Überschreibungen" (analog Archi*** auch im Nem-Konzern) ist bei mir seit Jahren zuoberst auf der Wunschliste.
Bitte investiert eure Zeit doch besser mit diesem Thema, dass würde nämlich viele Allplan User glücklich machen.

Gruss Thierry

https://www.cds-bausoftware.ch
https://www.cds-bausoftware.ch/bundle
https://www.cds-ausbildung.ch

Hallo

Meiner Meinung nach sollten die Ressourcen besser für die Weiterentwicklung von Visual Scripting eingesetzt werden.
Mit der Implementierung von ein paar Dutzend zusätzlichen Nodes könnte Visual Scripting ohne großen Aufwand verbessert werden.
Der Programmcode der meisten Nodes besteht ja nur aus wenigen Zeilen.
Generell sollte zunächst die von Visual Scripting verwendete Python-Schnittstelle für alle Allplan-Elemente erweitert werden.

Gruss

Ich sehe das wie meine Vorschreiber!
Grafische Überschreibung wäre schon cool!

Mit besten Grüßen!
Jürgen

Allplan Ingenieurbau V10 bis V2025

Schöne Idee - wenn deswegen nicht alles andere liegen bleibt. Es gibt wirklich eine lange Liste an Punkten, die der Qualität von Allplan gut tun würde. Das Kontzept des Werkzeugkastens ist irgendwie auch nicht schlecht, fordert aber den Nutzer. Trotzdem, wenn Zeit dafür da ist - dann los.

Nun ja, es war eine Frage der Zeit, bis man bei Allplan realisiert, daß eine "Insellösung" Allplan-Visual-Scripting nicht so gut funktionieren wird. Warum mußte man das "Fahrrad auch nochmal erfinden"?
Grasshopper war zum Start von Visual-Scripting in Allplan längst "Marktführer" und hatte einen enormen Vorsprung! Diesen hat nicht mal die übermächtige AutoDesk mit dem Visual-Scripting-Tool Dynamo einholen können. Graphisoft hat das richtig erkannt, und sofort eine Schnitstelle zu Grashopper implementiert, statt noch eine Eigen-Lösung zu bauen. Mittlerweile gibt es sehr leistungfähige Tools für Grasshopper , z.B. LadyBug für Simulationen und Optimierungen. Wer implementiert sowas für Allplan-Visual-Scritping?

Nun muss man ehrlicherweise sagen, dass Allplan versucht hat, statt der geometrischen Formerzeugung andere Aufgaben mit Visual-Scripting zu lösen, z.B. automatisierte Bewehrung und Attribut-Verwaltung!

Die Fortschritte bei den Reinforcement Components (zu sehen wieder im letzten WIP-6) zeigen, daß man so etwas nicht in Allplan-Visual-Scripting versucht hat und auch nicht versuchen sollte.
Auch mit der neuen Information-Palette ist eine Attribut-Verwaltung sehr viel einfacher und effektiver, als es in Visual-Scripting jemals möglich wäre!
Es gab mal eine Präsentation von Modell einer Brücke in Allplan-Visual-Scripting. Spätestens bei
der Wartezeit von mehreren Minuten bei der Aktualisierung sollte auch dem letzten klar geworden sein,
dass man so etwas nicht in Visual-Scripting machen sollte, und schon gar nicht mit Python-Unterbau!
Zum Glück hat das auch Allplan eingesehen, und ein eigenes Brücken-Modul in nativem Code gemacht.

Das sind 3 Beispiele, die zeigen, wozu Visual-Scripting eben nicht geeignet ist!

Mich würde tatsächlich mal interessieren, wie viele wirklich brauchbare "Visual-Scripts" es so bei den Anwendern gibt, die diese auch täglich einsetzen. Ich meine damit wirklich so welche mit "Wow-Effekt", wo man sagt, das kann ich NUR mit Visual-Scripting machen, nicht mit Allplan, nicht mit SmartPArts, nicht mit PythonParts! Möglicherweise wäre das auch für Allplan von Interesse, bevor man jetzt wieder mit viel Aufwand wieder etwas macht, was keiner braucht und von begrenztem Nutzen ist.

Für mich ist Visual-Scripting genauso ein "Hype" GEWESEN, wie es derzeit große Sprachmodelle (ich weigere mich das als KI zu bezeichnen) sind. Nach ein paar Jahren wird man herausgefunden haben, wofür man das gut einsetzen kann, und wofür es nicht taugt. Diese Zeit ist für Visul-Scripting schon um, und man sollte es als das sehen, was es ist: Ein weiteres Tool, was aber nicht alles kann!

Grafische Überschreibung ist etwas, was hier im Forum schon mehrfach diskutiert wurde. Das würde allen Nutzern helfen, da jeder Planer der Pläne auf die Baustelle liefern muss, farbige angelegte Übersichtspläne aus Attribut-Werten der Elemente erstellen können muss, und zwar am besten auf "Knopfdruck"!

Man bzw. ich kann Deinen Link "Grafische Überschreibung" nicht öffnen. Obwohl ich angemeldet bin kommt die folgende Meldung?!

Mit besten Grüßen, Kai

-Ingenieurbau & Allplan seit V15-

Adjuntos (1)

Type: image/jpeg
Descargado 32 veces
Size: 20,22 KiB

Moin,

wie Xinling schon geschrieben hat richtet sich die Umfrage eher an PythonPart- Entwickler, weniger an "Durchschnitts-ALLPLAN- Benutzer".
Das wird meiner Einschätzung nach mit der Grasshopper- Anbindung genauso sein.

Da aber alle Anwender von möglicherweise besseren, einfacheren und/ oder günstigeren parametrischen Objekten profitieren würden ist die Überlegung auch von daher grundsätzlich schon berechtigt und genaugenommen schon lange überfällig.
Ob Grasshopper für diesen Anwendungsbereich besser ist als Visual Scripting oder ob Visual Scripting in die Grasshopper- Richtung aufgebohrt werden kann vermag ich nicht einschätzen.
Wenn dadurch allerdings z.B. mit vergleichsweise wenig Aufwand bestehende Grasshopper- Scripts in ALLPLAN verwendet werden könnten (keine Ahnung ob das realistisch ist...) wäre die daraus möglicherweise resultierende höhere Vielfalt an parametrischen Objekten schon ein Vorteil, auch für den "Otto Normalanwender".

Interessant zu wissen wäre ob damit langfristig auch parametrische Gebäudemodellierungen (wie man sie an den Unis immer so hübsch präsentiert bekommt) möglich werden oder ob ALLPLAN da an seine Grenzen kommt.

Insgesamt ist das sicher auch eine produktstrategische Frage/ Entscheidung.

Ohne Zweifel dürfen die hier bereits genannten und noch so einige andere "Großbaustellen" in ALLPLAN dafür nicht vernachlässigt werden.

BG
Jens Maneke
AAP Sommerfeld

>>> Stell Dir vor, es geht und keiner kriegts hin...

Der link verweist auf ein WIP-Forum. Dazu musst Du Beta-Tester sein.

Aber eine Suche im Forum nach "Grafische Überschreibung" findet die anderen Beiträge...

Vielen Dank für alle Feedback.

Cita de: ThierryMetzler
Logisch ist Grasshopper ein geiles Tool, aber ist das wirklich die richtige Zielgruppe (Durchschnittliche Allplan User)?

Der Grasshopper oder Visual Scripting sowie die Python API zielen nicht auf normale Allplan-Benutzer ab, deshalb habe ich die Umfrage nur in diesen Forenbereichen gepostet.

Da unser Team hauptsächlich an API-bezogenen Themen arbeitet, habe ich diese Umfrage erstellt, um einige Einblicke von euch allen (einschließlich WIP-Teilnehmern) zu erhalten.

Cita de: ThierryMetzler
Wenn Ihr schon über Schnittstellen nachdenkt wäre der Multi-IFC Export sicher viel höher zu priorisieren. Sowas habt Ihr ja in eurem Entwicklungsteam ja via Phyton schon gemacht.

Das Thema Multi-IFC-Export wird von anderen Teams behandelt. Wir haben zwei PythonPart-Skripts erstellt, um IFCs und DWGs/DXFs ohne Benutzerinteraktionen zu exportieren. Es funktioniert sogar mit dem Windows Task Scheduler. Der Grund, warum wir es damals erstellt haben, ist die Verbesserung der API. Wir planen, es später als Plugin in einem neuen allep-Paket zu veröffentlichen, damit zumindest jeder Benutzer, der auf einen Multi-Export wartet, es als Zwischenlösung nutzen kann.

Cita de: ThierryMetzler
Ein anderes Projekt "Grafische Überschreibungen" ist bei mir seit Jahren zuoberst auf der Wunschliste.

Bezüglich der "Grafischen Überschreibungen" ist unser Team nicht zuständig. Was ich sagen kann, ist, dass andere Teams derzeit an einer Lösung arbeiten. Aber es gibt noch kein Release-Datum.

Cita de: hrsommer
Meiner Meinung nach sollten die Ressourcen besser für die Weiterentwicklung von Visual Scripting eingesetzt werden. Mit der Implementierung von ein paar Dutzend zusätzlichen Nodes könnte Visual Scripting ohne großen Aufwand verbessert werden.

Wir werden die Entwicklung des Visual Scripting fortsetzen. Aber die Grasshopper-Verbindung könnte beeinflussen, welche Art von Aufgaben mit VS erledigt werden sollen, und den Rest für die GH-Verbindung lassen. Wir möchten auch sicherstellen, dass dieser Unterschied selbst fortgeschrittene Allplan-Power-User nicht verwirrt.

Cita de: Nemo
Das sind 3 Beispiele, die zeigen, wozu Visual-Scripting eben nicht geeignet ist!

Ja. VS ist derzeit nicht gut genug, um die von Ihnen genannten Anwendungsfälle auf einfache Weise zu erfüllen. Und niemand wird erweiterte professionelle Grasshopper-Plugins erneut für VS erstellen.

Aber das bedeutet nicht, dass VS bedeutungslos ist. Wenn Sie verfolgen, was ArchiCAD tut, führen sie auch den PARAM-O nach der Veröffentlichung ihrer GH-Verbindung ein. Der PARAM-O ist ihre einzige visuelle Programmierlösung, aber nur für benutzerdefinierte allgemeine parametrische Objekte. Dies wird wahrscheinlich auch in naher Zukunft der Schwerpunkt unseres VS sein, da native Objekte, die von GH erstellt wurden, ihre in GH definierten Constrains und Parameters in Allplan verlieren. Wir haben derzeit auch keine andere einfachere Möglichkeit, benutzerdefinierte parametrische Objekte schnell zu erstellen. Basierend auf dem aktuellen Umfragefeedback ist dies auch die Hauptaufgabe, die unsere Benutzer mit VS erledigen.

Product Owner API, Allplan GmbH

1 - 10 (18)