Reference Planes without Names

It is a common practice to add a name to the reference planes we create. If it isn't common where you work then it ought to be. The name helps give a hint to anyone that works in the model that this reference plane is more important than those without a name. It can also help understand what it is for, why it was made.

There are some who make the effort to clear out reference planes that are not named periodically, just another of any number of model/housekeeping chores. I've even seen Dynamo scripts intended for this task.

If you're using Ideate's Explorer you'll find it easy to see a summary of all the reference planes in the model. In the following image I've created two reference planes, one with a name and another without a name.

Notice that there are five (5) reference planes listed though. As it happens, when the Edit Profile concept is used on a wall four reference planes are created and internally applied against the sketch of the wall. They are only visible to us while editing the wall's profile sketch. We can't see these reference planes in the regular user interface, it only becomes very apparent with their Explorer tool.

It is also possible for us to create reference planes while creating any sketch based element, like a floor or stair for example. These reference planes are only visible to us while editing their related sketch.

The reference planes associated with a wall's edited profile can't be deleted via IDEATE Explorer. It can delete them when we've created our own within a wall's profile and other sketch based elements.

Attempting to clean up these unnamed reference planes might also be an issue if you're writing your own code or Dynamo script to delete them. We can/could add names to these internal reference planes (wall profile) but I don't think that's a task that worth the effort.

Something to keep in mind.

Dimension Inline and Dynamo

(Edit: If you download and apply an update to his Rhythm package after 1/17/2018 you'll have this node too)

From time to time I've heard people ask about putting the dimension value on the line (inline) instead of above the dimension line the way Revit prefers. The only way we can do it within Revit is to manually grip and drag the dimension value down to the line.

More recently I read a thread at the Autodesk Forum asking about this. The premise in their situation is that it is a significant roadblock to using Revit for one of their client's projects, it doesn't meet their drawing standard unless the dimensions are inline.

I was trading messages with Aaron Maller and mentioned it to him. Aaron was trading messages with John Pierson and a few minutes later I learned it is possible with Dynamo and a custom node. This morning he shared this with me, as well as replying to the thread. Nicely done John! We are sooo connected these days.

How Often to Synchronize with Central - SwC

Grist from a recent support conversation..."How often should we use Synchronize with Central (SwC)? We have some users doing it every minute."

Well....every minute seems a bit much...but...

The number of people actively working on a file affects the truth of the statement too. Every 30 minutes, for example, is too infrequent in my opinion. My own habit is to SwC as often as I complete any given task. I tend to take small bites, tasks that are 1-10 minutes, and SwC as soon as they are done.

More frequent SwC is less data transmission than every 30 minutes, potentially. Replacing or reloading a title block for 1,000 sheets is not a small task and probably ought to be done at lunch, advising people to create new local files afterward. Otherwise each sync will need to needlessly update each local file's copy of the sheet's title block too, for everyone. If that is done while they are all away they just inherit the new version of the project with their new local file.

It's all relative though because the transaction comparison between syncing that kind of change and closing a model and opening it later is subtle. In fact opening a file again might be slower, but reasonable, depending on how many people are involved. It can be justified though, especially if they are out of the project anyway such as out for lunch or after hours etc.

I think it is more important to be aware of other users also using SwC, than imposing a specific time requirement. When more than one person uses SwC at the same time Revit has to parse those changes and it does so, more or less, in a single threaded manner, not like a multi-thread OS (though they are improving that all the time) doing simultaneous tasks. It has to reconcile changes and move to others once it is satisfied it can finish successfully. The more people forcing Revit to do that at the same time the slower it gets for everyone. That's where the advice to schedule or increase the time between SwC came from. One client decided to build their own tool so users can see if someone is syncing. A button on their Quick Access Toolbar parked next to the SwC button is red when someone is syncing and green when nobody is. Green means go for it.

Any sort of "Every 30 minutes" rule is often an over simplification, a rule meant to be easy to implement. In practice it can be just as harmful as helpful. If I slip and go 60 minutes or longer then that starts to slow down SwC times for everyone else too. Pushing and pulling data through a pipe takes time, smaller chunks of data generally take less time and less time to reconcile with the model too.

I'd focus on developing awareness of other users syncing as the priority and it's increasingly important the more users that are working on the same project file.

New Book - Delivering COBie Using Autodesk Revit

A team of authors led by Bill East (COBie inventor) has finished a book dedicated to COBie and Revit. His team consists of: Shawn O'Keeffe, Richard Kenna and Emma Hooper.

Bill writes:

"This is the first comprehensive COBie How-To Guide! We explain the implications of COBie requirements on your professional standard-of-care. Next, we describe the architectural and engineering design best-practices we adopted to help us capture COBie as part of our standard design process. We show you how to unlock the power of the Revit COBie Extension and Classification Manager Add-Ins to automate COBie file production details. And we show you how to share your new found knowledge with your team, company, and stakeholders."

David Philp, Global BIM Director, AECOM reviewed the book and had this to say:

"This book offers a comprehensive and real-world insight to the COBie value proposition but most importantly it demonstrates HOW this can be practically achieved. This book is an essential read for anyone that is interested in effectively capturing and using project information. If you want to better understand how to deliver COBie from a Revit environment then this book is a must.”

David Light, Autodesk Senior Customer Success Manager also reviewed the book and said this:

"Finally, the AEC industry and the Revit user has an unparalleled guide for helping you understand, as well as deliver COBie from Autodesk Revit!

Delivering COBie should not be scary, as noted, the guidance provided in “Delivering COBie Using Autodesk Revit'” is designed to help AEC industry deliver COBie on any building, as easily as possible.

East and the authoring team provide a detailed history of COBie, so you understand the background of why COBie? It helps demystify some urban myths around COBie, allowing you to better understand the value of this industry standard digital exchange format. The book runs through best practice tips for model development, model configuration and data preparation for Autodesk Revit.

The guide leads the user onto the configuration of the free Classification Manager and the COBie Extension. Lastly, 'Delivering COBie Using Autodesk Revit' teaches the reader how to apply various concepts on a Dormitory Project example, through shared best practice from recognized industry experts, explaining how to prepare the Revit model for repeatable COBie deliverables."

The authors of “Delivering COBie Using Autodesk Revit,” Dr. Bill East, Dr. Shawn O’Keeffe, Richard Kenna, and Emma Hooper look forward to showing you how to make COBie an integral part of the standard design process for yourself and your team, company, and stakeholders. The pre-release spiral-bound “workbook edition” is now available for individual Revit users. The version for purchase by libraries, institutes, and companies available 15-Sep-17.

You can Order your Copy HERE.

My Kingdom for a Dimension...or Two...Three

A Friday thought...

I've spent the last couple years doing a lot more modelling work than I expected to do. If you asked me in years before I'd have told you 80-90% percent of my time was dedicated to training and implementation activities.

Much of the modelling I do these days is from the contractor's point of view, for them. I quite enjoy it. I learn a lot and it keeps me on my toes.

This work is requested often because the documents they are using are not created from models to begin with. Sometimes they are but they (the contractor) have to build based on drawings so they find it informative to attempt to build things in the computer before doing it in the field. Where have I heard that notion before?

Chief among the things that trouble me doing so is the lack of dimensions. If there are lots of dimensions then the issue is their message or rather the lack of clear intent.

All too often I find a slab edge plan is lacking that one dimension, between adjacent slabs for example, that I could really use. In other instances the decision to start plotting the dimensions is based on a datum that involves a fussy site related angle (like based on a property line); when other orthogonal options are available.

I've also seen far more effort and devotion applied to dimensions for parking stripes in a parking garage than for the structural elements that make it possible to paint those stripes eventually. Then you have the dimension value bust. Such as, setting out the building grids reveals a subtle mathematical inconsistency or outright typographical error or override.

Then there are the dimensions that describe how to place something relative to other elements that get installed later during construction. How do we place a concrete column by referencing interior partitions...when those dimensions don't relate back to grids or structural elements? That issue is both missing dimensions and logical progression.

Often I have to endure the game of look over there, as if a hockey puck is getting smacked back and forth, when one says look at those guy's drawing for more information and then the other says the reverse. Slab edges that are required to overlap (per nearly matching details) are a real chore to sort out when you have to flip back and forth constantly and double check against the reflected ceiling plans...oops they're inconsistent with the plans...note to generate an email...

Then there are arcs. Thanks for all the radius and diameter information. Could I get dimensions for their endpoint locations and chord height/width? Better still, could I get something that tells me where their origins are supposed to be? Yes I do realize that one or two might be located somewhere on the outskirts of town. Then again if doing so exposes that issue up front when they are sketched, maybe we could get some other localized notion of how to place them on site too?

Though I've rarely encountered it in real life, I've really learned to appreciate the my documents stand on their own philosophy. In other words, a structural set of documents could be used in isolation to build all the the structural elements required, correctly, even if the rest of the work never got funded. It IS harder to do because it requires concerted effort to coordinate the disciplines well.

Yes I know, it's complicated, building stuff is messy. Now that I mention it, have you noticed, like me, that those ugly fractions people don't like seeing on drawings still crop up everywhere in real life.

Ah well, enough complaining. I've got some slab edges to reconcile. Back to grumbling to myself again. May we all enjoy a dimensionally accurate weekend!

Revit 2017 - Reference Plane Subcategories

As I shared in the What's New post the other day, we can create our own Reference Plane subcategories; in both projects AND Families.

It is my opinion that Families should NOT bring Object Style subcategories for Reference Planes into Projects when they are loaded.

I realize that this is carry on baggage because Object Styles are loaded from a family into a project, that's how it works. However, it would be much better if something we can't even see or actually use in the context of the project doesn't get added to its database.

If people really like this enhancement and start using in all of their content then it could get really messy. The only people that won't incur the wrath of this are those that manage their content library aggressively. I really hope we don't end up with this...

I sure hope this is something the folks at the Building Content Summit will consider discussing to get out in front of it some.

Clearance Subcategory in Linked Files and Families

You've linked a model that has families which include clearance elements. That's excellent for doing clash detection. However you may not really want to see the graphics they've provided for this in all of your own documentation views.

Hopefully the clearance elements have been assigned to a unique subcategory that you can control by overriding the link's Visibility/Graphics.

If so and you'd like to control the subcategory without overriding their linked file you can use Copy to Clipboard on one of the families (TAB to select it) with the clearance elements in them. Then paste a copy somewhere in your model. Now the family's subcategories are part of your own model. You'll be able to control it via V/G without overriding the link, assuming the link is assigned to By Host.

You probably realized that doing the above is a shortcut to creating a matching subcategory assigned to the correct category in Object Styles ourselves. It is a shortcut because we probably won't know what subcategory the family is using without examining the family more closely, by opening the linked file and editing the family directly. Using Copy and then Paste provides us with a copy we can interact with directly instead and any subcategories it has are brought into our project for us.

Families are prone to inconsistency because they can be obtained from a variety of sources. Consider that even the families from Autodesk aren't entirely consistent from one to another. It may still be necessary to crack open a family to find out how their clearance elements are controlled. For example, the lines that form the "X", and the "box" around them, in this family are assigned to the Hidden Lines subcategory, not Clearance.

In 3D there are forms to indicate clearance requirements and they are assigned to a Clearance subcategory but they also have their Visible parameter unchecked which means we can't see them in the project at all, anywhere.

This family does not intend for us to turn off the clearance "X", at least not via its Clearance subcategory. It has a subcategory called clearance and the solid forms for its clearance zones are assigned it but then it was decided they shouldn't be visible at all. By the way, doing so does not prevent Revit from seeing the clearance forms when using its own Interference Checking. However in Navisworks they don't show up. That might be considered bad form (pun intended). From a family editor perspective (and user), it would have been more flexible if the Visible parameter had been associated with a Yes/No parameter to allow us to turn it on or off if necessary. Unfortunately, keeping in mind that this post began about families in a linked file, it wouldn't make any difference for us.

Consistency is easier to manage and achieve when it is your own content library and your project files. It can be a bit trickier dealing with the content that is part of the linked files you need from other disciplines. It's easy to create a family that makes me happy, or my team. It may not make the other consultants happy though. Something to think about while you're being happy making content.

Temporary View Templates

View Templates are quite useful and potentially powerful when they are allowed to be aggressive, placed in charge of Views. To make a View Template the Boss we just need to assign one to a view via its View Template parameter.

Using the Right Click option to Apply Template Properties does not a boss make. It just applies the template settings but then leaves the view open to abuse.

When we do take advantage of placing a View Template in charge of views we bump into this Boss and its rules whenever we want to change the way the view looks. Normally that's good because the View Template is preventing arbitrary changes. In the following image I've mocked up structural walls and separate Veneer walls because I want to accentuate the structural wall in plan views (a common request). It also allows for fussy exterior finish changes (though these are hardly fussy).

In the plan view I've reduced the intensity of the veneer walls. When we need to change the way a view looks and it has a Bossy View Template we can use the Temporary View Properties button on the View Control Shortcut Bar. Usually it is sufficient to click Enable Temporary View Properties. Notice the other choice; Temporarily Apply Template Properties.

If we often find ourselves needing to apply the same kind of override to certain views it makes sense to create a View Template for that and then use it to apply an override to the view, like this next image. I've changed the appearance of the veneer walls to make them stand out; so it is easier to adjust them.

I created a Filter that is looking for a specific value in Type Comments. I picked that because it was easy for this example but it could be any parameter you like, as long as it sets the element(s) apart from others.

I also made another Filter to change the wall the other walls look so they don't compete graphically with the veneer walls as much as they would normally.

When I'm done adjusting the veneer walls I just need to click Restore View Properties and the Boss is back in charge.

Next time you find yourself using Temporary View Properties and Visibility/Graphics to tweak a view again, for the same reason as the last couple times, consider creating a View Template for it.

Revit Schmevit

Plan, Section and Elevation...the bread and butter of architecture. Why would anyone want to work on these three kinds views of a project and not find that the elements (doors, windows, walls, etc) they present don't match? If I create an enlarged plan shouldn't it match the plan it was generated from, but have greater detail? Shouldn't the windows called out in a plan match those called out in an elevation? Even if you get it perfect at the first submission I guarantee you'll miss stuff when the next design submission is due. By the time you get to the fourth...faahgeddaboudit.

BIM... I don't care if you ever learn what those three letters mean...

PLEASE, in the year of Two Thousand Fifteen, finally abandon your disconnected ways and use Revit (or ...Archicad).

Seriously, because the people that have to read your drawings aren't impressed.

Starting View

I was reviewing old posts for something I thought I wrote about Starting Views. I was befuddled when I didn't find anything. I guess that's to be expected when I write things here and on several other webs sites like AUGI, RevitForum, and Autodesk Newsgroups. Enough about my confusion. Since I don't seem to have one already, here's one now.

Revit developers observed that users were creating simple drafting views that contained some project information and then encouraging or insisting users remember to open this particular view when they saved and closed their projects. This way when someone opened a project for the first time they'd always be greeted by this special view. It also takes Revit less time to open a simple view with no model representation involved. In response they introduced the Starting View as a feature. This special view can be assigned to any view including a sheet view.

Initially people were pleased and just referenced the view they were already using. Then some began experimenting with other view types. The Sheet View is particularly useful because it can use a custom title block family to provide the framework we might want for our Starting View, imagine the office bulletin board with a variety of important and often timely info about office parties and upcoming events. In the context of a project that means we can reference actual project information through labels/parameters instead of having people type some of this same information into text. This connection to live data is a natural progression, even expectation.

More recently Andre Carvalho shared (at RevitForum, see link below) how he uses a linked project file to manage project notes that need to be visible to projects that have several or many models or even expand beyond one project to all projects in the office. He can update the master project file and since all the related projects have this file linked into them the information is updated automatically for him each time any project file is opened. Pretty clever stuff, working within the confines of the tools we've got. If you'd like to read more CHECK IT OUT.

If you aren't taking advantage of Starting Views, let me encourage you to consider doing so.

Family Orientation

It is quite common to find the orientation of families confusing, both when we make them and when we attempt to place them in a project. What we consider front, back, left and right doesn't seem to follow consistent logic. Okay, there is some consistency it just seems opposite of what we might expect. What do most of us expect? Speaking for myself at least; Front is the bottom of a plan view, Back is the top of a plan view, Right and Left are the right and left sides of the plan view.

If we examine every family and family template in the stock content we'll find that Front IS at the bottom of every plan view in all of them. The View Cube also matches that convention. The thing that confuses us is that a portion of the stock content has been modelled in the reverse. That which we think of being the front of the object being modelled is the back. Even in those families however, upon closer inspection, we will find that the reference planes are oriented correctly (if they are named at all), the geometry orientation is wrong. The direction the geometry is facing is wrong.

If we consider a chair family most if not all of them are modelled with their front toward the top of the view (which is Back). If we compare that with a desk we'll find that it is modelled with the drawers (can we agree that they'd be the front?) toward the top of the view. These two families oriented this way don't allow the user to place a desk, horizontally for example, and then a chair horizontally so that they are oriented correctly with respect to one another. In the case of this desk there is no visible clue to know which way the desk is facing during placement. We'd be rich if we got a dollar every time we noticed the desk was backward when we open an elevation view later.

Looking at the View Cube the chair looks wrong, but only if we happen to agree the front of the chair is the side our legs are on. In the context of being placed next to a table or desk it means that the chair is facing the wrong side of the desk or vice versa. They had to pick an orientation but in the case of a desk that has drawers they picked wrong. Other work surfaces and tables might not matter nearly as much. It would make more sense to me if the desk were modelled with the drawers facing front, the bottom of the plan view. This would allow us to place a desk and chair and their orientation would make sense regarding each other.

Another apparent mismatch of orientation logic is base cabinet and wall/upper cabinet casework. Base cabinets are modelled with front facing the bottom of the plan view but the wall hosted upper cabinets are facing the back, the top of the plan view, opposite of base cabinets. Placing them in a project however defies the apparent orientation mismatch because the origin of the base cabinet is at the back and it is for the upper cabinet too. This means they orient logically when used together despite being modelled facing different directions in the family editor.

Also contributing to confusion is that the original content for doors and windows all assume that their Exterior side (and Placement Side) is what Revit considers the back side of the family. I've always thought of the exterior side as the Front of a door or window, the side that faces people as they approach the house. A door was the very first family I made with Revit. Afterward I believed that Front was the top of a plan view in the family editor. At least until I encountered enough other families to realize I was wrong.

To appear more consistent, while working in the Family Editor, Autodesk would need to revise most if not all of their hosted content (and others) so that the geometry orientation respects the bottom of a view being the Front view. The placement logic it uses must compensate for the placement side orientation of the geometry not being consistent with the notion of Front. If they revised the orientation of content to please Family Editors then they'd have to be careful to also revise the placement side logic.

Standards are Unicorns

Pointed to it by Don Rudder (with Case), I read this post titled Programming Sucks on the blog Still Drinking yesterday and loved it, I particularly liked this line:

...The first few weeks of any job are just figuring out how a program works even if you're familiar with every single language, framework, and standard that's involved, because standards are unicorns... (bold is my emphasis)

I can attest to standards are unicorns even in the work I do, let alone programming. I'd be rich if I had a nickel for every time I heard, "Oh, we just use the standard symbol for this".

Another favorite is...

...There's a team at a Google office that hasn't slept in three days. Somewhere there's a database programmer surrounded by empty Mountain Dew bottles whose husband thinks she's dead. And if these people stop, the world burns...

And another, I've not seen this particular approach to WTF, reminds me of my habit of using EyeTee instead of IT.

...You're all up to date, so that's cool, then everything breaks. "Double you tee eff?" you say, and start hunting for the problem...

After reading his essay see if you understand why Revit is different from AutoCAD, and Microstation, and ArchiCAD, and... See if Tom and Harry's feud over units resonates?

I've mentioned it before that Revit and AutoCAD had different biological parents and then Revit got adopted by AutoCAD's parents. Except we need to factor in the world that Still Drinking's author describes.

okay, back to work, here's to hoping those people don't stop and the world doesn't burn!

2014 Revit OpEd

Dutch Revit Standards and Template

Luke mentioned this the other day but it bears repeating to help spread the word for the Dutch Revit community at large.

Dutch Revit standard (template) is now available for download:

Download - RevitGG.nl
A Translated Version
This is made available using Creative Commons licensing.

There is a link to download version 0.8 from Dropbox at this page.

The download includes:

• Project Template
• Families
• Family Templates
• Materials
• Resource Files (CAD import / export maps, Shared Parameters and more)

Saving or Sharing Export DWG Layer Standards

The process has changed a bit for exporting to dwg (or DGN for that matter). We used to be able to export our own settings to a .txt file format for use with other projects. In Revit 2011 we had this dialog and Save As button.

With 2012 they've decided to capture our settings in a project file itself. They let us choose one of these four standards to use, or to use as the spring point for our own version.

The fifth option is to "Load settings from file...". Interesting that there aren't any files to use though. We are to capture our changes in the project and then, when desired, pass it along to other projects via the Transfer Project Standards tool.

I've posted the source files that the four export settings templates use because they don't appear in my 2012 installation anywhere. I recovered them from my 2011 installation. Interestingly the other three besides the AIA version didn't show up until I loaded each one in to replace the previous. As soon as I did that, the other files appeared alongside the AIA version. If you really want to edit the .txt version, to grow your own version, you can download them here:

exportlayers-dwg-AIA.txt
exportlayers-dwg-BS1192.txt
exportlayers-dwg-CP83.txt
exportlayers-dwg-ISO13567.txt

Revit Content Standards - ANZRS

The Australia New Zealand Revit Standards (ANZRS) has been formally released. In March this year I wrote that they were drawing close to releasing it and that they hoped to do so at the Revit Technology Conference in Goldcoast. They did hold a meeting there but held off on the formal release a bit longer.

They made their first digital public version available for download. You need to register with modest information before you'll be able to download it. It is delivered in a PDF package that is comprised of these sections:

• L1 Introduction
• L2 How to use the pack
• L3 Generic vs Specific
• L4 Glossary of Terms
• C1-C8 Compliance
• R1-R2 Advanced Features and Best Practices
• Full Pack for printing including shared parameter txt files

Revit Style Guide 2.1 Available

As I mentioned in October, The Revit Style Guide is intended to help those who create content develop consistent coordinated families. The previous version 2.0 and version 2.1 is now posted. Hope it is helpful!

Standards - Everybody's Got Standards, their own!

Wherever I go I get the same story, we use the "standard". Yep, "you" and everyone else. Only trouble is the "standard" the last place is using doesn't look like the standard "you" say is the standard... No I'm not really going down this rabbit hole, as much fun as it might be.

I am however going to point out an issue that users have with content that comes from Autodesk, out of the box (OOTB), consistency or rather the lack of it. We'll look at two examples; the (RAC) stock door family template and the (RME) stock Automatic Transfer Switch family.

The door template looks like this in plan.
When you first start to use it you notice that there is no Width parameter in the view. You think, reasonably so..."I need a Width Parameter!". You add a dimension. Then you start to add a Width parameter but find one is already there!


Naturally you think, "I'll just use this one!". Now Revit yells at you!

Hmmm...if it is overconstrained by adding this, how might that be?? Well this forces you to examine the rest of the views in the template. Taking a closer look at the Front Elevation view we find that the Width Dimension and parameter are lurking here. What? What "standard" does this follow?

Moving on...

The Automatic Transfer Switch family looks like this in plan view.

Maybe I'm just a bit of a crank but this is one messy view. Reference planes all over the place. Nothing confuses me quicker than a messy layout. Next, notice the orientation of the Switch Width and Width parameters? If the front of the panel is at the bottom of the view wouldn't this Width parameter really be the "depth" of the cabinet? Now notice the Switch Length parameter, wouldn't this be "width"? Naturally there is another "width" parameter...yep...it is in the elevation view.

At least these two are consistent in this way.

It is my opinion that dimensions/constraints should be added to views such that X and Y information is described plan views and Z information is displayed in elevations views, primarily the front view unless that is unsuitable for some reason. Dare I say...consistent with drafting "standards" 8-). Further families that represent real equipment should be organized in the same way as their catalog "cuts" or data sheets indicate. Width should be width and depth should be depth, not length = width etc.

"Soapbox" explodes...and I'm done!