Developer forum
cancel
Showing results for 
Search instead for 
Did you mean: 

Archicad API in .NET???

leceta
Enthusiast
Just a question from a noob: Would it make sense an Archicad API in .NET?? would this make easier to develop connection plugins in other platforms like Grasshopper?

Would it make sense to wrap ArchiCAD C++ library to other languages?

Cheers
aitor
25 REPLIES 25

Ralph Wessel
Mentor
leceta wrote:
Just a question from a noob: Would it make sense an Archicad API in .NET?? would this make easier to develop connection plugins in other platforms like Grasshopper?
Would it make sense to wrap ArchiCAD C++ library to other languages?
Not remotely – .NET isn't something you bolt onto a product. It has to be at the core of your development. And the implementation would have to be cross-platform, but not even Microsoft supports that idea for its own Office software.
Ralph Wessel BArch

stefan
Booster
It seems possible for some other software. E.g. Unity is a C++ Game Engine running on most platforms (Windows, macOS, iOS, Android, PS4, Wii, Xbox, WebGL...), but it allows editor and runtime scripts but also plugins in UnityScript, Boo and C#. It uses the Mono runtime which allows it to also work on other platforms. For performance reasons, they even have means to re-translate the "intermediate code" back into native C++ code to speed up things when running a published game (IL2CPP).

With Microsoft open sourcing a part of the .NET framework and better support on Linux and OSX, it may be technically possible. Probably very complex for a 30-year old software such as ARCHICAD which was never written that way.

What you could do is create your own wrapper around the ARCHICAD C++ API and expose that to other systems. Not ideal and lots of work, but not impossible. But you are limited to what is exposed via the API and you probably need your own native ARCHICAD C++ add-in which does all the communication.

We've created an add-in which communicates with ARCHICAD via HTTP requests. But this is mostly for querying parameters & quantities and not to fully control the software.
--- stefan boeykens --- architect-engineer-musician ---
ARCHICAD25/Revit2022/Rhino6/Unity2020/Solibri
MBP2019:i9Octo2.4GHz32GBVega20/BigSur+Win11
ARCHICAD-user since 1998

Ralph Wessel
Mentor
stefan wrote:
It seems possible for some other software. E.g. Unity is a C++ Game Engine running on most platforms (Windows, macOS, iOS, Android, PS4, Wii, Xbox, WebGL...), but it allows editor and runtime scripts but also plugins in UnityScript, Boo and C#. It uses the Mono runtime which allows it to also work on other platforms. For performance reasons, they even have means to re-translate the "intermediate code" back into native C++ code to speed up things when running a published game (IL2CPP).

With Microsoft open sourcing a part of the .NET framework and better support on Linux and OSX, it may be technically possible. Probably very complex for a 30-year old software such as ARCHICAD which was never written that way.

What you could do is create your own wrapper around the ARCHICAD C++ API and expose that to other systems. Not ideal and lots of work, but not impossible. But you are limited to what is exposed via the API and you probably need your own native ARCHICAD C++ add-in which does all the communication.

We've created an add-in which communicates with ARCHICAD via HTTP requests. But this is mostly for querying parameters & quantities and not to fully control the software.
Anything is possible, but the benefits have to be weighed against the cost. Game engine development is an edge case that doesn't share the same constraints as other applications – they have to live on the bleeding edge to stay relevant. That's why I made a comparison to software like Microsoft Office. There's probably a strong argument for having cross-platform .NET-based plugins in that context, but it doesn't appear anywhere near happening. Nobody could argue that it's because MS doesn't support .NET – there are clearly significant drawbacks.

There's also a very strong case for simply sticking with a C++ API. As you noted for Unity, there are significant performance gains (in speed, memory and energy us) from unmanaged C++. It's already strongly cross-platform – we already use a significant amount of C++ code across multiple platforms including ARCHICAD, Revit, Vectorworks and SolidWorks. And changes to the C++ standard have given the language a huge shot in the arm for modern computing.
Ralph Wessel BArch

leceta
Enthusiast
i see. My interest is particularly centered in a conversation between Archicad and Grasshopper.

the fact is that Grasshopper, wich is completely written on .Net framework,t is actually communicating with Archicad.

I saw that Archicad-GD *.GHA file comes accompanied by DLL file called newtonsoftJSON so seem from my inexpert point of view that the connection is made also via HTTP request and seems that there is no a wrapped C++ library as I was guessing...

My point is that graphisoft should path the way for non-professional programmers, as is my case, to be able to develop little tools to solve specific problems that as a bim manager want to solve for the firm I work. Chances are that an architect is not properly prepared to develop in C++ and other managed languages but instead is more a more common to found architects able to write little scripts in python or C#.

In that sense, and if as Ralph said, it does not make sense to put an effort in .net API, wouldn't be beneficial to open to the community the technology or the technics or whatever it is behind the GH-ArchiCAD connection tool, in order to boost the ecosystem of components of this promising marriage?

cheers
aitor

Ralph Wessel
Mentor
leceta wrote:
i see. My interest is particularly centered in a conversation between Archicad and Grasshopper.

My point is that graphisoft should path the way for non-professional programmers, as is my case, to be able to develop little tools to solve specific problems that as a bim manager want to solve for the firm I work. Chances are that an architect is not properly prepared to develop in C++ and other managed languages but instead is more a more common to found architects able to write little scripts in python or C#.
It might be better to focus your requests on statements like these, i.e. what you want to achieve rather than how. Injecting .NET into the discussion opens a big can of worms.

There have been a number of requests on the forum for general-purpose scripting within ARCHICAD. It might be a good idea to search for them and bump any that capture the same idea.
Ralph Wessel BArch

Akos Somorjai
Graphisoft
Graphisoft
Ralph wrote:
leceta wrote:
i see. My interest is particularly centered in a conversation between Archicad and Grasshopper.

My point is that graphisoft should path the way for non-professional programmers, as is my case, to be able to develop little tools to solve specific problems that as a bim manager want to solve for the firm I work. Chances are that an architect is not properly prepared to develop in C++ and other managed languages but instead is more a more common to found architects able to write little scripts in python or C#.
It might be better to focus your requests on statements like these, i.e. what you want to achieve rather than how. Injecting .NET into the discussion opens a big can of worms.

There have been a number of requests on the forum for general-purpose scripting within ARCHICAD. It might be a good idea to search for them and bump any that capture the same idea.
The GrassHopper add-on uses HTTP communication with a Rhino-side add-on, and ACAPI_Command_CallFromEventLop to achieve its purpose. The Rhino/GH side uses the Mono.framework, but the ARCHICAD side is pure C++.

The main problems of adding a C# layer are the non-cross-platformity of the code (even with Mono we had to rewrite the Mac GH add-on due to incompatibility), and the translation of the non-managed C data structures to managed C#.

But fret not, we are continuously experimenting with better ways of accessing the vast ARCHICAD database! What is the functionality you require most?

Best, Akos

leceta
Enthusiast
not looking for a particular functionality, I am the kind of person to prefer to solve his problems by himself. In that case C++ its an obstacle to me. comments like this by David Rutten keep me aside of investing time to learn C++, although, may be i am in a mistake:

"Have you seen the amount of plug-ins available for Grasshopper? How many of those do you think would have been written if C++ was the only available language? Developing in C# is vastly simpler than C++. Good IDEs and compilers are available for free, the same binaries can be executed on multiple operating systems (provided they do not rely on something which is specific to one of them), there is a huge amount of highly readable information on writing C# code, and with the open sourcing of .NET it has become less part of the Microsoft ecosystem."
<h1>comment</h1>

Ralph Wessel
Mentor
leceta wrote:
David wrote:
Have you seen the amount of plug-ins available for Grasshopper? How many of those do you think would have been written if C++ was the only available language? Developing in C# is vastly simpler than C++. Good IDEs and compilers are available for free, the same binaries can be executed on multiple operating systems (provided they do not rely on something which is specific to one of them), there is a huge amount of highly readable information on writing C# code, and with the open sourcing of .NET it has become less part of the Microsoft ecosystem.
It could also be said:
- C++ can be written every bit as easily as C#, but has far more scope and depth if actually need to call on it.
- C++ has vast resources (including free compilers and IDEs, documentation, libraries etc) on all platforms and is far more portable than C#
- C++ has always been standards-based, non-proprietary and heavily used for open-source development.

What's to be gained from C# when C++ is already far ahead of it in so many respects? MS would now like to give the impression that it's a great platform for cross-platform development, but the reality is that it's still very Windows-centric. I've seen too many reversals from MS to have much confidence in the "all platforms will be equal" message.
Ralph Wessel BArch

leceta
Enthusiast
What is the functionality you require most?
Programmatically access to Archicad database from Grasshopper.

stefan
Booster
Have you seen Paupertools? This is a plug-in that promises to open up the ARCHICAD SDK to Python.

https://github.com/iotong/PauperTools

Haven't been able to test and a bit unclear how it works and what it is currently capable of, but I find it interesting. I don't have the knowledge how wrapping the ARCHICAD C++ SDK into Python would work, but apparently, it seems feasible. I does seem to open up a whole world of possibilities for other CAD, 3D and BIM software... Vectorworks, Revit (Dynamo), Rhino, Maya, ...
--- stefan boeykens --- architect-engineer-musician ---
ARCHICAD25/Revit2022/Rhino6/Unity2020/Solibri
MBP2019:i9Octo2.4GHz32GBVega20/BigSur+Win11
ARCHICAD-user since 1998

Laszlo Nagy
Community Admin
Community Admin
Yes, the interesting thing is that Revit, Rhino, Vectorworks and Allplan all have Python support.
ARCHICAD is behind in this area.

Seems to me that although Python is more complex than GDL, it is very capable, yet much simpler than C++, so it offers a way for people to add functionality to their BIM application.
....................................................................................................
Laszlo Nagy, Lead Moderator, Community Admin
Get Archicad Tips at https://twitter.com/laszlonagy
AMD Ryzen 1700X CPU, 48 GB RAM, NVidia GTX 1060 6GB, 500 GB NVMe SSD
2x28" (2560x1440), WIN10 PRO ENG, AC20-AC25
Loving Archicad since 1995

Tibor Lorantfy
Advisor
LaszloNagy wrote:
Yes, the interesting thing is that Revit, Rhino, Vectorworks and Allplan all have Python support.
ARCHICAD is behind in this area.

It's not a big secret that GRAPHISOFT is already working on an official Python API.

I'm curious about your opinion, for what would you use the Python API if it would be as powerful as the C++ API?

Laszlo Nagy
Community Admin
Community Admin
I am not a programmer myself, I am pretty good with GDL in general.
C++ for me is a much more complex of a programming environment to learn.
My understanding is that it is much easier to learn Python than C++.

I would probably use it to add functions to ARCHICAD that do not exist yet.
For example, there was a thread where someone asked if it is possible to find out how many groups there are in the project. That would probably be a simple case of writing a Python script to achieve that.

Or, another recent question was: how to find missing library part instances. I imagine one could write a simple Python script that could find and give info about these missing library part instances not only in Floor Plan Viewpoints, but in any Viewpoint.

Or, another one: create a Python script to give a list and info about all the SEOs in the Project.

Or, there could be a Python script that would highlight or change the Pen of all Dimension Texts that were modified from their measured value. There are just so many cases to mention.

In general I think an API should give access to the whole project database (all Viewpoints, Project Map, Layouts, Publisher Sets, etc.) and enable you to do anything you can do using your mouse and keyboard. It would open the door to automating a lot of tasks and creating a lot of functionality that is not available (mostly because of development priorities by GS).
....................................................................................................
Laszlo Nagy, Lead Moderator, Community Admin
Get Archicad Tips at https://twitter.com/laszlonagy
AMD Ryzen 1700X CPU, 48 GB RAM, NVidia GTX 1060 6GB, 500 GB NVMe SSD
2x28" (2560x1440), WIN10 PRO ENG, AC20-AC25
Loving Archicad since 1995

poco2013
Advisor
Hopefully, Graphisoft won't forget to include a debugger or allow one like PyCharm to be attached?
Gerry

Windows 10 - Visual Studio 2019; ArchiCAD 25

leceta
Enthusiast
Automate whatever is possible to automate.
Access to model data on big files, without the need to graphically display then.
Programatically manage attributes.
Programatically rename hundred of layouts, views, etc...
Create custom forms to feet on office idiosyncratic workflows.
Programatically manage Graphic Overrides.
programatically import dwg plans to layouts, properly naming the layouts.
Connect to SQL database to I\O data for whatever reason.
Connect to external applications using Rest Api to optimize workflows and interoperability.
Create GDL objects using python syntax (well, one can dream), OOP and hopefully with a +modern IDE with code autocompletion and syntax highlighting.
Empower GDL objects with external modules, in particular with 3d geometry processing libraries.

leceta
Enthusiast
It's not a big secret that GRAPHISOFT is already working on an official Python API.
really, it wasn't??? c'mon...

kzaremba
Newcomer
Tibor wrote:

It's not a big secret that GRAPHISOFT is already working on an official Python API.


That's good to know. Are there any details of this development and timeline?

I was wondering recently is it so hard to make C# running in C++ code. All of the languages C#, C++ and Python are .Net languages so there are technically capable of working together. As far as I know, there are some techniques, for example, C++/CLI to do this kind of stuff.

Ralph Wessel
Mentor
kzaremba wrote:
I was wondering recently is it so hard to make C# running in C++ code. All of the languages C#, C++ and Python are .Net languages so there are technically capable of working together. As far as I know, there are some techniques, for example, C++/CLI to do this kind of stuff.
Only if you're working in a .NET environment. C++/CLI should really be thought of as a different language – it's a Microsoft spec that isn't compatible with C++. We've used it as a 'glue' to implement software originally written as standard C++ in .NET environments, but you can't do it the other way around. It's part of the standard MS 'embrace, extend, extinguish' approach to software.
Ralph Wessel BArch

dfintha
Newcomer
Hello,

As Ralph said, these are only true in a .NET environment. Otherwise, neither Python nor C++ are .NET languages, although .NET implementations of them exist (C++/CLI and IronPython). ARCHICAD is not built in a .NET environment, as it would highly impact its performance, which would be a great cost.
Since Python is implemented in C, it isn't difficult to use and extend it in C/C++ programs. Their documentation* even has a whole section about such process.

Best regards,
Dénes

P.S.: I'm eager to hear more about what users would like to do in a Python API, I've already wrote down what I could find in this forum so far.

* https://docs.python.org/3.6/extending/extending.html

Still looking?

Browse more topics

Back to forum

See latest solutions

Accepted solutions

Start a new discussion!