My favorite Comunication Tool is: MS Paint... And it now has LAYERS!

A picture speaks a thousand words. Yet, we most often communicate in a maddening string of 140 characters give-or-take.

In an engineering setting, I find myself often grabbing a quick screenshot and marking it up to get a point across. I use the tool (Snipping Tool - courtesy of Microsoft) at hand when I don't need something more finessed than the awkward squiggly lines drawn by a mouse can afford. Beyond that, the next accessible tool is MS Paint. It's quick, dirty, incorrigible, and gets the job done. I just noticed that MS Paint now has Layers. That's it! I'm all set - I no longer have to re-capture the snip if I make a mistake Yayy! 

 Wait, but there's more. If you are willing to pay, the AI co-creator panel might just make your dreams true.

Wake up! we are already living in the future... waiting for our minds to catch up.

I may be living in an utopia where crime only exists in the news. Ironical, since the news describes the crime that happens around me, a few feet, a few hundred feet away from me. Yet, I wake up everyday, not thinking about the harm that may befall me due to crime, but more likely about annoying machinations of a colleague. What has this got to do, if anything, with the video I embedded above?

One word:'protect ourselves....'

It is interesting because for a lucky few who happen to live in circumstances where we don't have to think about safety, we are living in a world that is only limited by the constant tug-of-war between the technology that hasn't caught up to its potential and the mind that hasn't recognized the technology that has. It also provides an insight into the moral and political perspectives of the narrator in that self-preservation is the upper most concern of all humanity. But a mind dwelling in an Utopian landscape of ubiquitous and intelligent technology, self-preservation has already been surrendered: it is irrelevant in a post-theistic world.

Keeping Revit Origins Sane in the Real World

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.

Revit: Creating Slab Edges With Voids

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.

Project 3D Lines Onto Topography

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.

Place & Update Generic Annotation Tags in Revit using Dynamo

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!

From Revit to Excel and Back

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)