SharpDevelop IDE supports C#, VB, Ruby and Python
Today we discuss a couple of Dynamo considerations, Revit family and element fundamental concepts, and an exception handler required for a custom exporter:
FamilySymbol and ElementType Execute may throw Question: Does anybody have a matrix comparing the capabilities and functionalities of the Revit API versus Dynamo for Revit?
My understanding is that Dynamo targets designers, engineers and architects who don’t know or like text-based programming.
I am often asked by people interested in Forge in the BIM domain about differences between Revit API and Dynamo. Often they are not programmers, but are interested in spreading BIM info and data to a wide audience. In considering the use of Forge, they face the terminology of ‘API’ and remember that Revit has such a thing. Forge is also a kind of API. So, clarifying the different possibilities provided by these APIs would be useful. Maybe a comparison matrix will help?
Answer: The Revit API is pretty clear, isn't it?
It is the one and only API for Revit.
Dynamo makes use of it, and you can use all of it.
So, Dynamo is a layer over the Revit API, and you can use all of the Revit API from Dynamo.
Dynamo also includes other functionality, e.g., DesignScript and its own geometry library.
So, in some areas, you can do more in Dynamo than in the native Revit API.
However, for manipulating RVT files, Dynamo has nothing more to offer than what is provided by the Revit API.
For architects, Dynamo seems to be the more effective path, cf., e.g., this compelling suggestion to learn dynamo.
The Dynamo Primer slide deck by Paolo Emilio Serra, Autodesk Implementation Consultant and author of the Punto Revit blog, includes some references to the Revit API and how to access it via Python Script. For more details, please refer to his own presentation of his Dynamo Primer Slide Deck.
As said, from an API standpoint, Dynamo objects are wrappers around Revit objects, there are some 'shortcuts' to convert parameter values to match the Display Unit Types, or alternative syntax to manage transactions etc. but there is nothing out of this world. The good idea behind Dynamo for Revit, with the full user interface, is that it has a serialization/binding feature with Revit elements for free, so it’s like adding intelligence to your Revit model rather than mere automation of tasks you can achieve with traditional programming. For an end user not accustomed to coding, it is much easier to set a value using the units they are using in the project rather than
The visual programming approach is different, the way Dynamo handles namespaces, inheritance and polymorphism defines how to read the find the nodes in the library. The way a function is called multiple times on a list of inputs, the lacing strategy, replication guides, etc.. are concepts that belong to visual programming and don’t even find a good parallel in a traditional coding language sometimes.
Not all the Revit API calls are converted into nodes (i.e. the MEP objects are completely missing and customers complained a lot, but in those cases you just use the Revit API. People started to create Dynamo packages to expand the out of the box functionalities. For example, for the Forge users, there is a package called DynaWeb that enables REST API calls from Dynamo… It was developed wrapping the System.Net objects into Dynamo nodes and the end users can use them in a visual programming context. The dependencies are still a pain to manage and the 'graphs' (read the Dynamo code) cannot be compiled into an unmodifiable .DLL, with risks, IP concerns etc.. Even so, Dynamo is really popular because, as Rob Todd once said, it 'commoditizes programming', and it enables our customer to do more, with better results with less effort.
For Dynamo scalability, also COM and .NET can be included, as they can be used via Python scripting (it’s in fact IronPython that supports managed .DLLs for example).
For example, one developer wrote an extensive library in C# for Dynamo that uses multiple frameworks at the same time such as COM for Civil 3D and .NET for Revit.
Another impressive example of interoperability between the different .NET languages is provided by the Python code external command loader and compiler implemented in F# shared by tailoryourbim. I have repeatedly pointed out that the Revit API can be used from any .NET supporting language. Ching shows how this can be taken to extremes by implementing an external command in F# that loads and compiles an external command implemented in Python. In his own words, he 'wrote a simple Python code loader in F#, which loads a Python script into Revit as an external command, combining with IronPython.'
In fact, macro and add-in functionality is identical in all respects, I would say. You can probably find an exception to that statement, but it would probably be something rather obscure.
Both VS and SharpDevelop support C#, VB, Ruby and Python. Probably, IronRuby and IronPython for VS need optional installation. SharpDevelop installs Ruby and Python as default while Revit installation:
SharpDevelop IDE supports C#, VB, Ruby and Python
You might also want to check out the FAQ in the Revit online help, which says:
What languages are supported for Revit API development?
C#, VB.NET, and C++/CLI are supported for addin development. C#, VB.NET, IronPython, and IronRuby are supported for macro development. Other CLR languages may work with the Revit API, but they are untested and unsupported. Note that for mixed managed/native applications using C++, Revit uses the Visual C++ Redistributable for Visual Studio 2015, specifically, version 14.0.23026.0. Add-ins compiled with other versions of the VC runtime may not work correctly since the Revit install does not include any other VC runtimes.
I'm not sure this FAQ is completely accurate and up to date, though.
Talking about Dynamo, here is a question on the different versions floating around, and which of them to use, from the Revit API discussion forum thread on Dynamo 2.0.X vs box shipped 1.3.3 – Which to use for production environment?:
Question: Been searching online for some answers and thought maybe the best would be to post this here as I don't have a login for Dynamo's git hub to post there. We have some conflicting opinions in our department and I am looking at getting some "good" "professional" concrete advice.
One of the guys here has been putting together some dynamo scripts using 2.0 and now upgraded to 2.0.1. We are running Revit 2019.1 for the most part. Autodesk however packages 1.3.3 (?) with their 2019 software releases.
For scripts we release to production/end users to use, would you recommend we stick with 1.3.3 or develop in 2.0.X. From what I understand 2.0 is a pretty big overhaul of dynamo and it's node packages. So, I am aware of the upgrading and compatibility issues with trying to write scripts in 1.3.3 vs 2.0. Pretty much have to re-write them. However, with the stability of 2.0 up in the air, there is some hesitation to move forward with this. What are some thoughts out there on the subject? Is there "real" definite reasons on why a person would or would not want to use 2.0.X or 1.3.3 ?
Answer: 1.3.3 is the latest version that was shipped with a point release of Revit, and 1.3.4 is in the pipeline for the next update release.
Users and offices who are comfortable going ahead of the Revit shipping product can access both 1.3.4 and 2.0.2 currently on the Latest stable release download pages:
As far as why they would upgrade and what the impact is, Dynamo 2.0 does represent an upgrade process for 1.x scripts, and does have enhancements to what is offered. The bigger feature items are:
The bulk of feature information is here from the original 2.0 release features.
Here is additional feature information on extensions.
Keep in mind that users can also have 2.x installed side-by-side with 1.x, so if they want to do their own comparison, this is pretty easy.
Again, if the user is going to upgrade, definitely take the latest build (2.0.2)
More information on what it takes to upgrade packages.
Finally, here are the more granular release notes.
I hope this provides a good and professional complete answer to your question.
Addendum: The Dynamo team is working to have a more regular 'heartbeat' of releases that allows for steady integrations with host applications. This will establish an update process that allows users to get the latest version of Dynamo with the latest release and point release of Revit. Additionally, we intend for future releases of Dynamo to not have a shared library, allowing for different versions of Revit to have different version of Dynamo and remove the "cross talk" of Dynamo in new installations. This will allowg Revit v.A to have the most up to date version of Dynamo available when Revit v.A was released, and Revit v.B to have the most up to date version of Dynamo available when Revit v.B was released without version B installation interfering with version A.
Another recent Revit API discussion forum thread concerns
the difference between FamilySymbol and ElementType:
Question: Both FamilySymbol and ElementType seem to represent the same idea. What is the difference between the two? (I know one derives from the other)
A related question is: what's the difference between Element and FamilyInstance? I can't understand why stairs are of class Stairs (derived from Element), while doors are of class FamilyInstance. Are stairs not an "instance" of a particular "family"?
Answer: Families come in several flavours.
The two main ones are standard and built-in.
Actually, they are called 'component' and 'system', as I just learned from the developer guide section I point out below:
System versus component families
Standard are defined in RFA family definitions.
Built-in are built into Revit directly.
Standard families define family symbols, and when you place a family symbol, it is represented by a family instance.
Other elements placed in the model are not called family instances; they are just elements.
Element is a super-class of FamilyInstance.
Analogously, ElementType is a superclass of FamilySymbol.
I hope this explains.
For more info, check the Revit API developer guide in the online Revit help, in the section Introduction → Elements Essentials → Other Classifications.
Let's wrap up with a final Revit API discussion forum thread on mesh data export to json:
Question: I try to retrieve the geometry info from a Revit model to JSON data that I can load to draw geometry by three.js like in the ADN mesh data custom exporter to JSON.
Of course, the demo is right and works well with some changes from Revit 2015 or 2016 to 2019.
However, working with a different Revit model, an error comes from the call to exporter.Export(view), saying cannot divide by zero.
Answer: Run the add-in in the debugger and see for yourself which line of code is causing the problem.
Then you will probably be able to see how to fix it as well.
Response: The debugger does not help, because the exception is thrown inside Revit internal code while executing the Export method.
The debugger will just raise an error on top of the built-in logic.
Finally, I added a try catch handler and caught the error.
Thank you very much, and thanks for your demo about the use of CustomExportContext.
Answer: Glad to hear you resolved your problem.
By the way, rather belatedly, may I point out that others ran into the same problem in the past.
The exception thrown by the internal custom exporter implementation can simply be caught and ignored.
Uploading Paolo's Dynamo primer PDF triggered the GitHub warning about large files exceeding 50 MB in size.
The warning includes a suggestion to turn on the Git LFS Large File Storage.
I read about it and did so for three file extensions:
$ git lfs track
Listing tracked patterns
a/zip/*.mp4 (a/zip/.gitattributes)
a/zip/*.pdf (a/zip/.gitattributes)
a/zip/*.pptx (a/zip/.gitattributes)
Hence, the tbc repository hosting all The Building Coder blog posts and support material should be significantly smaller now.