For quite a few years, I've been unsuccessfully trying to wrap my head around this particular portion of Revit. All sorts of experts came up with explanations, processes, and best-practices to tackle the issue. All of the explanations seem like the picture below to me:
Fig 1: Blind men trying to comprehend an elephant. From Wikipedia. Read the Story here.
This is not an allegory for the folks who have written about this topic. It is a metaphor for my (and a lot of my colleagues') difficulty in comprehending the topic based on their writing.
For anyone transitioning from an AutoCAD workflow to a Revit one, it is often a given that one would instinctively take the a laissez faire approach to handling the issue of setting out Origin Points for a project. Revit as an application, is fairly good at downplaying the whole issue. It usually does not matter until one has to link other models into the Main model where all the documentation is being recorded. Even then, someone in the team magically figures out how to use Shared Coordinates and make the linking work. Then someone accidentally removes a link, or overwrites a Shared Coordinate and then this whole setup suddenly fails to make sense anymore. It is often worse when, later in the project, one has to aggregate all the models in simulation platforms such as Navisworks or Synchro due to the simple reason that other programs are usually unable to read Revit's Shared Coordinates or the teams do not export projects consistently. One can certainly ensure that the project is exported using Shared Coordinates. In practice however, I've found that there are always one or two models that somehow slip between the cracks. So, the work-around seems to be one where one imports all the models, then painfully find objects that belong to the same coordinates and then align everything. Life would be a lot easier, if someone had set the ground rules from early on in the project.
Slab edges with a depression to accommodate a Window wall seems to be somewhat pesky at this point. That is because the Slab-edge family within Revit is additive. So, if your slab edge is smaller than the depth of the slab, then you have to pull the slab boundary towards the interior of the building and then add the slab-edge family as an extension to the slab. In short, this workflow is less than ideal both in terms of performing the actual work and in terms of managing the model in the long run.
Projecting Lines onto Surfaces within Revit has been tricky for various reasons. One could argue that projecting lines and modeling with primitives are precisely the kind of things Revit was designed to avoid; and I agree with this attitude. But, there are times when you simply want something done a particular way. Fortunately Dynamo can let you be that impish individual that you want to be within the Revit world.
Dyanamo and Adaptive Lines
This recipe documents the process of using
Dynamo to project Property Line elements on to the Toposurface within
the Revit Project. The actual line work is somewhat tricky. One cannot
use Revit's Model Lines for this purpose because each Model Line needs to be associated with a Sketch Plane.
With a Complex Toposurface, this approach can be extremely convoluted. A
simpler approach is to use a linear element that is not tied to a
Sketch Plane. The only class of elements within Revit that allows
non-associative placement is the Adaptive Component Family.
Accordingly, the projection lines are traced at the start point and end
points using a single Adaptive Component consisting of two _Adaptive
Points and a Model Line stretching between them. The complete graph and family can be found here:
The Uncomplicated Approach
One can of course eschew the complicated
approach of using Dynamo and simply use the Sub Region within the
Massing and Site toolset. The results are acceptable except for the fact
that one cannot change the Line Style or host any other family along
the line. The image below shows the results of using the Sub Region.
As of Revit 2017, the task of displaying Area Tags in Floor Plans outside of Area Plans (such as Rentable Areas) is a manual one. An example of such an application would be an Apartment Building where the total floor area of every Apartment needs to be displayed in addition to room names and dimensions.
Unfortunately, one cannot place an Area Tag in a view other than an Area Plan. Although one can place a Room Tag in an Area Plan, a workflow where the primary plan views are based on Area Plans becomes quite restrictive as the Area Plan View Type does not allow some annotation types such as the call out head to be displayed. Additionally, the Area Boundary Lines themselves can be very annoying.
Many firms resort to a work-around where one places a Generic Annotation Tag in the Floor Plan views and manually updates the Apartment Number and Area. It feels like one is going backwards after adopting a powerful platform like Revit. This chapter is about automating the process of both placing Generic Annotation Tags and updating the same using Dynamo.
The first video of this post shows the placement of Generic Annotation Tags. The second video below, shows the process of updating the tags based on Area properties.
I've documented the rest of this process in the Gitbook and the source files are available on Github. Enjoy!
Excel and similar spreadsheet programs have
always been the mainstay of data entry and analysis operations. Even
with acess to more sophisticated applications, most architects and
engineers, still prefer to modify parameters of projects and components
with a fluid interface such as a spreadsheet so that they can take the
data elsewhere and do interesting things with it.
The
Revit Project being a database, always lent itself to extension using
Excel. Dynamo made it even more accessible. This recipe is a small
demonstration of all the pieces needed to not only extract Revit
component parameters to Excel, but also push back updated data back to
Revit after performing operations within Excel.
Surprisingly,
the biggest challenge turned out to be not the actual connection to
Excel, but the smaller nuances of how the parameter data gets modified
during the process of transferring between the two applications. If you
would like to skip the explanations, you can download the dataset here.
Check out the complete recipe at the work-in-progress GitBook (which, by the way is an awesome platform)
Dynamo is to Architects & Designers what Scratch is to toddler geniuses learning to code. It gets us thinking in terms of manipulating the machine in terms of instruction sets rather than punching individual commands at the computer all day. More importantly, it is a platform that is designed to span between the world of coding and the world of assembling architecture. This, by definition, makes this extensible in both directions, seemingly without limits.
The Case for a Project Twitter
Personally, I'm not a tweeter (sic), but after a recent natural disaster, it was the only place to gather information about loved ones in a particular neighborhood. A typical architectural project is not a place where random strangers gather for a round of Kumbaya. However, a platform such as Twitter certainly breaks barriers when broadcasting to a team or a group. It could be anything from a gentle reminder, a recently discovered piece of vital information, or, live tweeting meeting notes. With Dynamo's Iron Python Interface and the ability to add .dll libraries, along with Twitter's well documented Application Programming Interface (API), the rationale for building a connection between Twitter and the Revit Project quickly went from 'Is there a need?' to 'Why not?'.
The Process
As of the writing of the post, Dynamo does not have a package to retrieve Twitter timelines. PYTHON on the other hand had plenty of easy-to-use libraries to run circles around the twitter library. 'It would be a One-day fun project' I thought. It was... Until I discovered that the beloved 'Tweepy' library for Python does not work for Iron Python that Dynamo allows. I spent three days scouring google and attempting all sorts 'pip' installs - but to no avail. Finally, I gave up and went to my go to code kitchen: Visual Studio using C#. I had recently discovered that Dynamo had a Zero-Touch Plug-in environment that lets one import *.dll libraries and leverage their functionality. After finding a sufficiently simple library (Tweetinvi), I set to wrap the simple instruction sets so that it can work seamlessly with Dynamo.
00. Getting Started:
If you would like to try this on your own, you will need to import the Dynamo Twitter Connector. Unfortunately, I don't have this as a published package, but you are welcome to download the build the connector from GitHub source. Alternatively, you can simply download the Binaries (Debug) folder. Then you can 'Import Library' from the Dynamo 'File' menu to have the Connector show up in the tool palette.
01. Authentication:
In order to connect to Twitter, Twitter needs to know who we are. Basically this involve creating an 'App' via your twitter account. You can do so by going to https://apps.twitter.com/ and signing in.
After, we can create four keys: the consumer key, consumer secret, access token, and access token secret.
02. Retrieving Time Lines:
Once you are authenticated, the rest is relatively simple from a coding perspective. All that is left to do is to hook-up your Dynamo Nodes to retrieve and convert tweets in your time line to a string.
03a. Displaying Time Lines:
This step involves setting up a 'Text' parameter in a Generic Annotation Family and hooking it up to the output of the previous step. Strangely, I'm finding that it is not easy to select annotation families in Dynamo. I had to jump through a couple of hoops - but it was the least of my problems.
03b. Tweeting from Revit:
Tweeting from your Project is a breeze with the 'Publish Tweet' node.
