How to Start Programming Revit Add-ins.

Part of the focus of this blog is how to manipulate and take advantage of the Data being generated by BIM. I'm happy to say I'm well on my way to learning to swim in this sea of data! I have started learning how to program the Revit API in C#.  I had some programming experience in college about ten years ago and in a different language.  So far, I have successfully written five different add-ins.  Yeah me!

Here is what I have done to learn what it takes.

I downloaded and installed the Software Developers Kit from Autodesk Developers Network.  I also tried several good tutorials they have available.  While this was good, it didn't give a lot of explanation to why things were done the way they were, especially for a novice programmer. Also, much of what I found available in this was written in C#, which inspired my learning the language.

First a free online Fundamentals for Beginners C# Programming course from Microsoft.  This gave me a good understanding of the basics. It also talked me through downloading and installing Microsoft Visual Studio Express 2012.  The express doesn't mean it runs faster. It simply means it is the free version with several features missing.  That topic could and likely will be another blog entry to itself.

Knowing C# alone is only part of the puzzle.  Next you must learn the specifics of using the Revit API in C#. I choose to purchase the Udemy on-line course from Harry Mattison, Founder of Boost Your BIM. The man knows his stuff, and does a good job of explaining it.  This course is what finally got me off the ground and running.  

Another training tool I found very beneficial was Don Rudder's book on programming for the Revit API, (also an excellent resource).  Most if not all of his examples are in Visual Basic. This I have learned is not a big deal for experienced programmers to utilize and swap between several languages, provided they are all part of the .net framework.  I won't pretend to understand all of that short of saying they are somewhat interchangeable.

Also along the way has been countless Google searches on topics, advise from friends in the programming industry and a trip to Autodesk University (focusing on API classes).  One class that stood out to me was David Rushforth's Automate your Revit-Based Software Workflows: Let the API Do the Work.

In the not to distant future, I hope to start selling some Add-ins through this site. I have several ides already. Do you have any suggestions/requests? If so, please leave a comment, or message me.

Divide and Conquer

The ‘when to divide’ and ‘how to divide’ topic has a million shades of gray.  The process does have some overhead time required to setup.  When needed though, there seems to be three schools of thought on how to divide a project. The first is across the match lines. The second is by floor. Then the third is by discipline.

Well, for Architecture it makes sense to be able to divide by the match lines, but not for MEP. As of Revit MEP 2015, system information cannot be passed through a linked file.  Yes, you can tag through a linked file, but that is not the same as passing system information along.  If the electrical panel that serves an outlet is in a different file, then it can’t be added as a load to the panel.  Air Handling Units in one file, can’t add CFM’s from terminal units in linked files.  Largely, this approach just does not work for MEP.

The second approach of by floor has the same limitations. If the systems need to be able to connect vertically though the building, they won’t be able to. This leaves only one viable option left, dividing the model by discipline.

On large projects dividing the models is a must to gain efficiency, but on smaller projects, where is the cut-off for a return on the time investment?  Buildings 30,000-50,000 Sqft and smaller are generally manageable as single project files.  For larger projects, it makes since to create separate Revit MEP models. I prefer to divide them per trade (Electrical, Plumbing, & HVAC), then interlink each into the others by placing them on separate worksets unique to each linked file.  Finally setup the central file to inquire as to which worksets to load upon opening. If the workset for electrical is not selected upon opening the HVAC model, then none of the electrical objects will be loaded into active memory.  This can free up huge chunks of memory.  Dividing worksets into logical chunks helps with linked files even more.  Let’s say the electrical model is linked into the HVAC model.  To coordinate the ceilings, the workset for lights can be the only workset loaded into the HVAC model.  To manage the worksets within linked files use the Manage Links tool as shown below.

Strip the Model

When the architect submits a model for use as a background, it is their working model.  It has lots of sections, elevations, drafting views, 3D views and schedules that are not needed as a background.  So open their model up, and delete out as much as possible.  Delete every 3D view, every section (unless you have a view linked directly to that section view), every schedule, every drafting view, every legend view.  Make these models as striped down as possible.  The same applies to structural.  In fact you can delete out every view leaving only one view in the project and all the geometry remains. Now that all this has been deleted, purge the files.  Purge, is found under the manage tab.  It removes any family and family types not currently in use.  Typically after this process is performed the finished files size is between a quarter to a half the original file size.  Your mileage may vary.