Hello,

Before deciding which solution to adopt, it seems to me that the advantages of a programming tool in Allplan are:
- to be able to customise elements
- to be able to perform repetitive tasks
- to be able to create new specific items
- to be able to reduce work time
- to be able to use external plugins or content

Users expect all Allplan's capabilities to be involved. Everything must be controllable: all the objects (walls, slabs, openings, rooms, etc.), all the drawing and modification functions, all the management of attributes and formats (colors, hatchings, patterns, layers, etc.), all the animation management (environment, position, lights, etc.), all the rendering functions, all the specific functions (reinforcement, terrain, etc.) and all the exchanges (imports, exports and printing). In fact, total control of Allplan!

Allplan's effort must therefore be to make all the functionalities available. And this effort is very important. It is the basis for "passionate" or "experienced" users to be able to make full use of Allplan's performance in their fields. It also allows partners to develop complementary tools without being limited or constrained. Overall satisfaction can only be improved. It therefore seems that using something like Grasshopper would enable us to achieve this goal, where visual scripts and additional functions in Python, C# or VB can be used and mixed. It could replace all Allplan's attempts (NOI, SmartPart, PythonPart, Visual Scripting). With one complete environment, everyone would win: concentrated effort for Allplan, simplified learning for users, extended possibilities for users and partners.
Allplan would then be a real platform that covers all areas of construction.

Hello Betrand!

What immediately jumps to my mind when reading your lines is the following:

Allplan (like many others) has a long list of additions to the software while still keeping all the older (often outdated) technologies.

You may be an intern in terms of programming tools and gadgets for Allplan users, wheras I am just an experienced user. So my question is, whether implementing Grashopper might be a chance to get rid of old, then useless stuff and additions in the heart of Allplan. Make it light and probably stronger ...

Or is this wish far to good, to be true?

Just my thoughts...

Greetings, Martin

Hello Martin,

These are 2 different subjects that can be done at the same time. It is true that it would be preferable to clean up Allplan before implementing a new development interface. But the old functions sometimes need to be kept to manage compatibility with old projects. It's very complex and sometimes almost impossible to solve.

Outdated technologies: in 30 years since my involvement with Allplan I am still waiting for implementation of real 3D Objects for Architectural elements without polygonisation. For me this is the most frustrating part of Allplan.
Not to mention the tranformation of 3D objects from the module 3D modelling into Planes that still doesn't work correctly.
So my 2 cents: invest the time into something more important for the mayority of Allplan users (developers can be transfered to other departments, can't they?).

Jurij

Guten Tag,

zuerst freue ich mich sehr, dass endlich über die Implementation von Grasshopper in Allplan ernsthaft nachgedacht wird und möchte hier auch noch meine Gedanken einfließen lassen:

Nun, vielleicht nicht für den durchschnittlichen Allplan-Nutzer im Jahr 2024, aber für die in den kommenden Jahren. An meiner Uni habe ich im Masterstudiengang intensiv mit dem Tool gearbeitet und viele Workflows kennengelernt, die mir das Leben als Planer angenehmer gemacht haben. Wie alles Neue muss man Grasshopper erlernen, und die Lernkurve war für bereits technisch bewanderte Leute wie mich sehr steil. Dennoch denke ich, dass der zukünftige Allplan-Nutzer dieses Feature begrüßen wird.

Ich schließe mich einigen Vorrednern an: Man muss das Rad nicht neu erfinden. Zudem würde Grasshopper auch in vielen Bereichen Türen öffnen. Thermische und Lichtsimulationen wären dann über bereits existierende Extensions möglich und sind auch gut beschrieben (Ladybug, Honeybee, Dragonfly uvm.).

Außerdem würde man sich viel Entwicklungsaufwand sparen und könnte sich auf die Erstellung von eigenen "Allplan-Plugins" in Grasshopper fokussieren. Hier würde ich mich auch über Plugins der Schweizer Kollegen von CDS freuen.

Darüber nachzudenken, Grasshopper Raum in Allplan zu bieten, finde ich einfach einen wichtigen und richtigen Schritt in Richtung Zukunft!

Grüße
Adrian

Hört sich auf den ersten Moment spannend an ... auf den zweiten bin ich ein wenig kritisch. Das Visual Scripting find ich genial für schnell mal etwas zusammenhacken und die Verbindung mit Python ist auch genial. Wenn es keinen Node hat nimmt man den exec Python node. Es wäre jammerschade wenn man hier die gute Arbeit vor dem Ziel wieder stoppen oder abschwächen würde.

Was heisst CrasshopperConnection, ganz simpel erläutert?

Ich habe Rhino mit Grsasshopper und Allplan offen und dann starte ich die Connection und dann passieren all die wundersamen Grasshopperdinge nicht in Rhino sondern in Allplan.

oder

Ich kann in Allplan eine Grasshopperdatei öffnen und ausführen. (ich glaube kaum das dies realistisch funktionieen wird)

oder

???

Ich bin selbst kein Allplan-User, aber wir betreuen Kund:innen mit Allplan. Anders als bei unseren Archicad-/ Revit-Kund:innen können sie nicht von den tollen Scripts aus Rhino Grasshopper profitieren... und Speckle ist auch noch nicht vorhanden. In meinen Augen ein absolutes "Muss", wir lösen damit viele Themen, welche die Software selbst noch nicht kann. Anwendungsfälle in anderen Software:
- Reduktion von Geometrie jeglicher Art, steuerbar über verschiedene mathematische Parameter, welche ich selbst steuern kann (Terrain, komplexe Fassaden, Gekrümmte und doppelt gekrümmte Elemente, Nasszellen-Apparate)
- Ableitung von verschiedenen 2D-Geometrien, welche mit dem Modell verknüpft sind, Ableitungen, welche ich z.T. im CAD nicht hinkriege und Dinge doppelt modellieren muss
- Import von Daten und Bereinigung der Daten (z.B. Bereinigung Architekturmodell, statt Import, Verknüpfung)
- Verknüpfung von Daten
- und dann noch jegliche Elemente, welche doppelt vorkommen und ich per Parameter steuern kann