Archicad API in .NET???

[leceta]

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

[Ralph Wessel]

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.

[stefan]

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.

[Ralph Wessel]

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.

[leceta]

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]

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.

[Akos Somorjai]

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]

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]

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.

[leceta]

What is the functionality you require most?

Programmatically access to Archicad database from Grasshopper.