Purge Unused


Autodesk has confirmed the problem in 2016.  The criteria are a bit weird but you should be able to re-create the problem like this:

  1. Create a section (possibly any view type) of a custom type with a shared and/or project parameter.
  2. Change type to another type after placement.
  3. Run Purge Unused and you’ll see your original type as an option (assuming you have no views already created with that type). Select that original type for purge
  4. Your section previously created will disappear.

So many problems with this.  But I’ve found even more weirdness.

What am I purging?

You’ll see that if I select a few sections 1) They kinda work in tandem for some reason and 2) I’m selecting a ton of groups somehow.  Those are model groups by the way so I don’t know how section types and model groups are tied together.

I’ve already notified my teams to stay away from the tool.  I’m a little hesitant to use it myself but there aren’t many options without macros, plug-ins or some Dynamo.

In the video below, you’ll see what I’m talking about.  Autodesk can’t tell me why it does this but I am able to reproduce it over and over with a particular file.  It is unclear why these particular views are marked for deletion but when Purge Unused is invoked they disappear along with “unused” view types I have in the project.  What is really strange is the view types associated with these views are NOT deleted.  Just the views.  Which is bad enough.

Link because WP.com won’t let me embed the iframe.  

I opened a ticket a few days ago about this, along with a before and after version of file, journal and a link to this screen capture.  Initially the response was, I’m paraphrasing, “well don’t select those types for deletion”.  Um… no. I actually tested that scenario of only selecting the section view types and purging them alone.  Nope, still deletes the views.  Ok, maybe it is because they aren’t on a sheet.  Tried that, while looking at the sheet, nope, viewport removed from sheet when you click “OK” in the dialog.  The tech I talked to suggested that a similar problem has been fixed in 2017, which is a fairly typical, and incredibly frustrating response from Autodesk.  I made a point to explain a likely scenario:

  • Project just finishes DD and is gearing up for CD
  • Maintenance time and the coordinator decides to purge unused to help lighten up the model.
  • In the process, with no indication, random views are deleted.
  • Next time the sheets is issued, people swear views are deleted, tech insists someone must have done it.  Doesn’t matter, time to do some rework.

I’ve had this scenario happen and I’ve ALWAYS written it off as someone deleting things they shouldn’t (like a section mark on a random plan, without thinking about deleting a view).  And, I rarely let Purge Unused run with all items checked.  Doesn’t matter, this seems to happen regardless of what exactly is checked.  Especially given that the views are of types that aren’t identified in the purge dialog.


I’m waiting to hear back from Autodesk but I’m afraid that the answer will be “it is fixed in 2017”.

Happy Weekend!


Stephen F. Austin

I got sucked into Texas history recently.  My dad has been telling me stories about growing up in rural Texas and it got me curious.  So I picked up a dense biography on Stephen F. Austin.

After reading through it I’m amazed at what he went through and how he did what he did.  The scale of the land he traversed and surveyed by horse in the early 1800s is incredible.  What he sacrificed to accomplish goals that were driven by honor and a sense of responsibility for the early settlers was incredible. The story of his life was fascinating to say the least.

The biggest take away I had from the whole thing was how little I really knew about Texas and its history from a Mexican frontier to Mexican state and finally a republic and member of the United States of America.  Granted, history in high school isn’t going to get into the nuances of politics and colonization but so much over simplification seems like a disservice.

Austin wasn’t going to colonize Texas.  His dad was.  Austin’s family had made fortunes and lost them well before he ended up in Texas.  In fact, Austin owed about $9,000 ($175,000 today) to various folks and was doing his best to get on his feet in New Orleans.  His dad owed even more but was going to make it all back as an empresario in Texas for the Mexican government, bringing settlers in to colonize Texas.  But elder Austin died a few months before he started his contract.  SFA, out of a sense of obligation to his dad and family, took over the job.

What really surprised me was how Texas ended up leaving Mexico.  Austin loved the country of Mexico and did his best to be a part of it, the government and making it a modern participant in the new economy developing in North America.  But numerous regime changes and government upheavals left him little room for anything but Texas becoming independent.  Fascinating story.

And finally, less than a year after gaining independence, Stephen F. Austin died with no wife and no children of his own. For years many talked of him as just a bit player in the whole history at best and as a self-serving land baron.  It took nearly 100 years before he was properly lauded.

So if you want to talk Texas history at the next conference, come talk to me.

A Modest Proposal (not like that)

First, you should know this has nothing to do with Swift’s essay. Just a clever title as there is a proposal in here.

While at RTCNA in Phoenix this year I had loads of great conversations.  At previous events like this very few conversations diverged much from the AEC industry, BIM, or related technologies.  This year was quite different in that respect.  I spent a few hours after midnight discussing the early history of Texas.  I was in the midst of reading Stephen F. Austin, Empresario of Texas and I was fascinated at how much I didn’t know. Of course politics came up at one point, a few times actually but I did decent job of keeping my foot out of my mouth (I think).

Overall I was thinking about connections.  Tying different bits across fields, connecting the dots on how to accomplish things, trying to figure out what was next.  I doubt I did the perfect job but I was looking at things that would help users.  What would make a tedious job easier and faster? How can I show my co-workers what is happening with the model? Things that a lot of people are working on.

So at one point I was telling someone about what my wife does.  Without much detail she’s part of an open source software project.  It was difficult for some folks to get their head around the idea of a company making money out of software that is free to download and use.  Also free to modify, append and customize.  But it works well and the company is profitable.  People work on this code base around the world fixing bugs, refining features and providing support.  In many cases for free.  In others as a part of their everyday job.

During one of the sessions, Harlan Brumm, Product Manager at Autodesk, finished his talk up with a very candid Q&A session.  I decided I’d ask about the status of Revit Sever.  Our local reseller has intimated that it is only a matter of time before Revit Server is no longer available and the only option is C4R.  Their argument was that, since Autodesk doesn’t charge for it, there is no motivation to improve or update. And given the push for everything “cloud”, why keep an alternative available? So I asked Harlan, “Revit Server. Is it dead?”  He answered basically that it wasn’t going away anytime soon.  Not that he was being evasive, just that is the basic truth.  It isn’t really going away, but it probably isn’t being updated much.

So here’s the proposal.  What if, Autodesk open sourced Revit Server?  Made the code base free to download and install on a IIS or LAMP/WAMP stack?  Basic functionality would be there but nothing fancy.  Pretty much just as it is now.  There’s no file or folder privileges, only authentication is for the admin window.  REST would still work as it currently does, and you could use the basic commands to export files, lock folders, etc.  C4R would effectively be the SaaS version.  Autodesk would add some additional features and manage the servers for a fee, you just add users and files.  Revit Server would require you configure it, possibly edit a .config file or via a web interface, set up the required services (http server, store, possibly a xSQL database).  But beyond that you could customize it.  And others could too, beyond the api level but actually changing the code or adding additional features.

You might think initially this is a crap idea.  But there are many models of this working out in the world.  This blog runs on one.  Here’s a list of a few more.  With WordPress you can set up your server or VM, configure a few things, download the source code, install it and within a day you have your own blog/content management system/online store.  Something doesn’t work the way you want? There’s a plugin for that (really there are thousands).  Tweak the UI, functionality, appearance, anything.  But if you don’t want to do that you can pay someone to set it up or just pay for a turnkey (mostly) solution.  The code base is the same, albeit altered a bit.  But you don’t have to know about html, php, css, or configuring Apache, SQL or the OS.  And you can’t alter it as much, it is stable and reliable.

Imagine what it could be like if Revit Server was open sourced.  You could download RevitServer base files, install on your platform of choice, configure it, then add some functionality. Maybe you tie it into your Slack instance so that Slack replaces your colleagues’ need for Worksharing Monitor.  I’d try to poll the projects to see when they reach critical size limits, send me a message and maybe post to a message board.  Wonder if I could tie in an Arduino and have the stats show on a scoreboard…

That isn’t to say it isn’t without cost.  Configuring a server is a lot easier today than it was years ago but even with our IT departments this isn’t a slam dunk.  In fact there are quite a few firms where there isn’t such an infrastructure to just spin up a VM and install Windows Server.  But in an open source environment maybe someone would develop a version that runs on Apache and a Linux variant? Or what if you could run it on a Raspberry Pi?  And there could be plugins that would tie into other services like Newforma.  It would open up a ton of opportunities.

There would still be a need for C4R.  I know that in a busy environment I want something that just works and I can call someone when something goes awry.  For large, distributed organizations or working within multiple discipline teams it would take quite a bit of customization to get near the level of functionality of C4R.  Yes there are shortcomings but I have no doubt they will be resolved.  All of the pieces are there, they just haven’t been pulled into a cohesive set of services.  With their knowledge of the programs and power to light up AWS instances, Autodesk will still have a product to sell.   There are days I wish I was using C4R instead of troubleshooting our servers.

This isn’t something Autodesk hasn’t done.  Most recently Ember comes to mind, Dynamo is another big one in the AEC world.  There’s actually a lot out there. And I bet it would go a long way in positive PR to open the source up to be rebuilt, tinkered with, and allowed to grow.  There are many firms that would utilize it and appreciate the gesture. And lots of those firms would still use C4R.   I’d bet it would grow some brand loyalty in the smaller firms.

So how about it Mr. Bass? Why not turn Revit Server into an open source project?  I think it would be a great boon for the Autodesk brand, ease some minds and maybe help you develop better products.

BIM Workshops Presentations

This year I was lucky enough to get the opportunity to participate in two BIM Workshops.  I made my first trip to Omaha, Nebraska and the second to lovely Anaheim in Southern California.

In both instances I meant to have everything ready for use for the people attending my class but alas, that didn’t happen.  Since I didn’t do my job there, I figured I should post it here.  So without further fanfare, here you go:

Strategies for Stud Wall Projects

Converting Standard Details in Revit

Strategies for Stud Wall Projects


Wood and steel stud projects are purposefully vague.  The structural engineer doesn’t specify where the walls will go or how long they are, just what they are made of and if they are “important”.  Framing is a guess in most of the building.  Granted, the engineer will specify spacing and sizing of joists but when it comes to precise placement that is outside of their realm.  The framing contractor will make minor adjustments as necessary to accommodate conditions.  In fact, some inspectors will balk if the structural drawings show all wood joists and expect the framer to follow the lines as shown.  Pre-manufactured trusses and even open web wood joists cannot be accurately modeled in Revit as the structural engineer has no idea what exactly the manufacturer will build to solve the particular conditions of a building.  Granted the engineer may have some say in their capacity but that’s about it.  And if the structural model shows a member that ends up being different in the field, who’s responsibility is it when a duct can’t be placed due to the truss not matching what is in the model? Bundled studs and posts are located generally not specifically due to the needs of the window or door frames and what is needed to hold up the building.  As such many engineers are reluctant to model much of anything inside of Revit.  Revit is intended to provide a real model of the building, even if the output drawings are intentionally vague.  You’ll rarely see posts or bundled studs dimensioned for this reason.

Walls are especially troublesome for structural engineers.  In some firms and with some plan checkers it is important that the shear wall is indicated at all levels.  Non-bearing walls, if modeled according to conventions in Revit won’t even appear on structural drawings (i.e. Discipline set to “Structural”) but many times the structural drawings need to show these walls for the supporting structure below to be relevant and accounted for.  Never mind the constant coordination effort that is required when working with large projects.  Bearing and shear walls are slightly easier to manage as typically they are less likely to move significantly throughout the project but still need to be flexible. Copy/Monitor function is rarely a viable solution due to inherent problems with the tool and with the way it handles walls in particular.  In our firm the “shear wall” quality is actually just an additional attribute to the wall indicating increased frequency of fasteners and sheathing.  But again, the problem lies with vagueness.  In most cases the contractor wants to decide which side the sheathing is on for one reason or another and as such, we don’t actually specify which side should have the sheathing.

So how does one handle this efficiently and convey the information to other consultants without completely dumbing down the model to effectively very expensive lines?  In some cases it is worth it to make a very complete model with everything as accurate as possible.  But in larger cases this is unrealistic and not really viable.  The structural engineer can only provide a road map.  That doesn’t mean the roadmap can’t be smart.

Utilizing the tools within visibility graphics and one custom family you can get a very good system quickly. With a bit more effort and your favorite Revit to Excel plugin you can get VERY efficient quickly.

To restate our requirements: Shear walls need to be indicated on framing and stud & shear wall plans.  Framing plans show elements from the deck and below.  Stud & shear wall plans show just the walls above the deck and call out posts/columns, shear wall attributes and possibly length, and indicate hold down/tiedown attributes.  In some cases these are actual callouts for specific models from Simpson or just forces for compression and tension so that a third party can specify a system.

Build the Model

Obviously we have to model something.  But with our responsibility in mind we’ll model what we are specifying.  To a degree this is entirely based on LOD for these categories.  We can specify sizes and some general attributes but can’t account for really accurate placement of every member.  If we did the chances of the built building matching would be slim to none. And the biggest issue with this is other consultants or even the GC assuming that because it is modelled, it is accurate to real world conditions. So let’s get it modelled as best we can.


Since our walls generally are specified by the architect (stud size) the wall itself is mostly a place holder.  Walls are drawn from origin to end from top to bottom.  Meaning that walls do not stop at each floor unless the wall shifts or changes size. Walls stop at openings as for most cases, the wall above a window or door is structurally insignificant.  Where shear walls are indicated the “Structural usage” attribute is changed to shear.  This comes with its own pitfalls and limitations.  Shear walls commonly won’t follow the changes


Example of typical floor

Example of typical floor

Floors are generated with a compound floor that indicates typical framing depth as a layer in the floor, along with the specified sheathing.  Floors are broken up where span direction changes or depth changes. This provides a way to indicate a “no fly” zone for other consultants.  Typical framing members are modelled with attributes to indicate spacing.  Non-typical members are placed as accurately as possible. This is intended to generate clashes where appropriate.  Will every clash in the “no-fly” zone be a problem? No but it does indicate that a discussion needs to happen about coordinating that area ahead of time.  The same is true for deeper beams and non-typical framing.

Posts & Columns

The biggest issue here is placement.  I have yet to see a plan for a large stud project that had every piece of the doors or windows modeled to the degree necessary to place nearby bundled studs or posts.  In our firm we typically have a schedule that indicates sizes based on callout.  We tied all of that together with shared parameters and tags.  The column itself has 2 sets of extrusions.  One for coarse that indicates the extreme extents of the studs (takes largest dimension and generates a square on plan that size) and another for medium and fine that has all studs modeled if needed.

Coarse view of Bundled Studs on left, medium and fine view on the right

Coarse view of Bundled Studs on left, medium and fine view on the right

Tie Downs/Hold Downs

Location is more ambiguous when it comes to tie-down systems where the engineer only provides forces that the bidder designed elements should be sized for.  We, as the consulting engineer, don’t have that information and typically won’t until the project is in construction, which in most cases would be too late for the clash detection we want.  But applying the same philosophy as floors we can generate another “no-fly zone” that is only used to generate discussion.

This is where our custom family comes into play. Not only can it be built to generate clashes but it will also house our parameters needed to specify either hold downs, tie-down forces or a combination of data for tags.  It is fairly simple, just build a wall hosted family that has shared parameters for the info you need, model it roughly as the space needed for a hold down system and build a tag to support your needs.

Make it look right

You might have guessed there would be a problem here.  If the walls go past the floors (continuous from bottom to top) how will they show hidden?  How do we indicate a wall is shear, traditionally shaded?  It is all driven by adjustments to Visibility Graphics and Filters.

Floor Framing Plans

In an AutoCAD world we just drew what we needed, on whatever file we called “Framing Plans”.  Here it is a little more complicated.  The top of the plan view should be right above the deck, as little as possible.

Blue is view range for Stud & Shear plans, green for Framing Plans

Blue is view range for Stud & Shear plans, green for Framing Plans

The depth should be the same for your typical structural plan, about 3’-0” below.  At this point you’ll see walls as solid lines, which isn’t what we want.  So our first override is to make the walls appear hidden, adjusting CUT line to match our typical hidden lines for walls.  We also need to see the hatch for our shear walls for plan check reasons.  Just filtering based on usage and overriding the fill pattern won’t work because effectively the walls are hidden by the deck.  Our next override is to set the floors to be transparent to any amount.  For plans Revit doesn’t really adjust transparency it is more like an either/or Boolean.  Meaning that either something is transparent or it isn’t.  There is no partial transparency or alpha applied.

Our floor span directions are called out using the span direction symbol.  If the floors are modelled correctly this will just amount to picking the correct tool and clicking on all appropriate floor elements.  Framing members are tagged with a custom tag that indicates spacing and any other information on our example elements and the non-typical or deeper beams.  Depending on your standards the typical framing members could be called out in a floor tag. For your custom hold down family you would normally hide this either by category or sub-category depending on exactly how you built it.

Stud & Shear Wall Plans

On this plan columns/posts/bundled studs, shear and bearing walls, and related information is indicated.  Our filters are employed here to shade the shear walls but the overrides for hidden lines and transparent floors aren’t needed.  The bottom of the view range stops at the deck here.  Bundled studs are shown in coarse detail level partially to draw attention to the fact they aren’t placed exactly.

The hold downs are shown at coarse level very simply, maybe even just a dot.  The annotation/tag displays relevant information.  Since the parameters are shared you could easily create a schedule with that information and possibly edit.  With a Revit to Excel plugin you could easily manipulate the data via a spreadsheet.

In our office the length of shear wall is indicated roughly on plan along with the type.  The shear wall type indicates spacing of fasteners, specifies the sheathing, and by cross-referencing the schedule some load qualities.  It isn’t possible to directly get wall length into an annotation.  Since we don’t want to indicate what side the sheathing should be on a wall tag was somewhat useless as most of the information is independent of wall type.  I developed a line based, detail item that reports its own length rounded down to the nearest 6” increment.  In a sense this isn’t a true annotation but given the rest of the process this is the best that can be done.  It is worth noting it isn’t entirely smart without constraints. And too many constraints will cause your model to lag, especially with larger projects where you’ll have literally dozens of these constraints.  To do it properly you’d have 3 constraints per shear wall per level.  This would definitely be detrimental to your model except for small buildings. It also won’t update with the wall if the wall changes.  But there is an alternative.

An Alternative for Shear Walls

In an effort to get more speed out of the process I started looking at how we scheduled shear walls.  And I realized that really for us a shear wall is just added attributes to a wall. Something that wouldn’t constitute a different type but an added element.

steel stud wall

Typical Steel Stud Shear Wall Schedule

wood schedule

Typical Wood Stud Shear Wall Schedule

Then it all came together.

I needed an element that was hosted in the wall, could have a length that was adjustable, graphically similar to what we were using and could contain information for tags.

My firm’s graphic requirements meant that my only option was a door family.  You may have different requirements but the concept is the same.  The hold down elements are shared, nested elements in this family to provide tagging for hold downs.  Another requirement was to have each “system” we use be separated to avoid confusion by the modellers.

The “shear” element reports back its length via a round down formula and shared parameters, which are usable in a tag.  There are also parameters that drive information in each of the hold downs which aids in documentation later.

Shear Element in Family Editor – Extrusion is constrained to the faces of the wall host, Length is passed to a shared parameter via a round down function.

Shear Element in Family Editor – Extrusion is constrained to the faces of the wall host, Length is passed to a shared parameter via a round down function.

Because in some cases there will be different hold downs for each end of the wall, thus there are formulas and a Boolean field to determine those conditions.


An Example in use

After creating appropriate tags to annotate the plans the system was faster than before and, via simple schedules, I could quickly export data for engineering. And it made it faster to adjust as only the shear wall element needed to be edited instead of a wall, a detail item, hold downs and possibly adjacent walls.  Graphically it does the job with fewer overrides and filters and updates if wall moves or length changes automatically.


But wait, there’s more.

With a spreadsheet import/export tool this really flies.  After discussing with my engineers and realizing I had a plugin that would suite my needs I came up with a workflow that cut our time dramatically.

  1. Model the bearing walls as mentioned above.
  2. Engineering indicates which walls should be shear
  3. Production inserts shear element
    1. Tags all elements and adjusts lengths
    2. Assigns, via spreadsheet, ID information to each wall
    3. Assigns directionality information (NS vs. EW) to each wall
    4. Assigns Level information
    5. Prints a map for engineering of shear elements with Level, ID and Direction indicated via tags.
    6. Generates a spreadsheet with Level, ID, Direction, Shear Length, shear type and appropriate hold down information columns.
  4. Engineering edits spreadsheet based on calculations. In our firm this was done via spreadsheet also so it was fairly easy to connect data from Revit to engineering data.
  5. Production updates model by importing data from spreadsheet.
  6. Any major updates from engineering can be done by just importing spreadsheet again. Minor updates can be handled in Revit or via plugin.

It is worth noting that this could theoretically be handled via the API or any bulk element manipulation plugins.  You could conceivably build up all your shear wall schedule information to be attached to these modelled elements via shared parameters also.  And the concept should work with any spreadsheet import/export plugin.  The point isn’t the details, it is the concept.  Revit, at a very basic level, a database and this is a way to extend and utilize that database to easily produce the documentation you need.


Is available right here.

Converting Standard Details to Revit

With any firm, there are details that are used over and over. Even with the 3D and well-coordinated nature of BIM, there are firm-developed “standard” and “typical” details that are used on every job. Some of these provide speed and in other cases provide standards to ensure that a very common condition is properly called out. Over the years, I’ve worked with two firms to convert details from AutoCAD to Revit.  In the process we learned lots about what works and what doesn’t, encountered pitfalls and snags, and developed lots of best practices that will make these essential items work smoothly and reliably. 

Devil in the Details

Converting your entire standard detail or typical detail library is a huge task.  Most of us are at firms that have spent a lot of time developing those details, over decades in many cases.  In fact, some firms converted their details from mylar and velum decades ago to AutoCAD and even now haven’t gotten over the transition.  But the detail library is a huge and important asset.  It allows critical and repetitive design information to be added to a project quickly and efficiently.  In some cases, it provides junior engineers and architects prompts and guidelines for proper and vetted design.

I’m here to tell you that it is possible to convert your library.  I’m not going to tell you it is easy or quick.  But the reality is, converting those hand drafted details to AutoCAD wasn’t easy or quick… but we all survived.  The fact is, this is your opportunity to add functionality and flexibility to those assets that should last you almost a decade.

If you are reading this you’ve been thinking about your library of details for a while.  There are lots of reasons NOT to have done this up until now.  And you are probably busy getting the jobs out the door and keeping everything running.  The effort to convert to a new platform is not a billable activity for most folks and as such, there is a certain amount of pressure not to spend too much time on it. In my experience across four firms, none of them considered converting to be advantageous.  It is a huge uphill battle, and as a result there are lots of coping mechanisms people have come up with.

A hybrid combination of DWG and Revit (a hobbled solution, to my mind) seems to be one of the more common ways to keep up: keep all of the details (or just the standard ones) in their native AutoCAD and keep churning through jobs.  This allows everyone moving with a few hiccups.  Views sometimes are coordinated through dummy views and sheets to keep everything in Revit ticking.

When I first started working with Revit, our reseller and training consultants told us that we should just import the DWG files and use them as-is.  In fact, it was touted as a clear path to getting going as fast as possible, damn the torpedoes.  There were problems with RTEXT elements, and at one firm we went through the entire library of DWG files and converted all text to MTEXT for that reason alone. Then the fonts were a problem, but it still allowed folks to move forward.

Another strategy was to either produce DWF files or just keep them in DWG and link the files as whole sheet views or individual details.  Again, fonts were an issue and after a while, performance became an issue.

Why those don’t work

all the pieces!

Exploded Detail in Autodesk Example file

The fact is, those were all similar to band-aids for gunshot wounds.  As we all know, Revit is a completely different animal compared to AutoCAD.  The workarounds mentioned were slow, produced inconsistent results, and at times caused damage to design documents.

For almost every workaround, the end result produced sluggish models and usually generated more work for the production crew.  With hybrids, the problem was constantly coordinating the sheets between the two platforms.  Excel import/export tools have made it easier, but it was still chock-full of ways to make a mess.  Creating “dummy” views would allow folks to create native Revit sections on plans, but resulted in coordinating those and missing updates when a detail moved from one location to another in the DWG and massive chasing of info in the model.

With all the workarounds, the conversion of certain DWG elements was always an issue.  Fonts are notoriously problematic, as the entire underlying font format for DWGs (SHX) is only used by DWGs and as such, produces all kinds of problems.  Legacy objects like RTEXT (single line text entities) didn’t space the same way in Revit and converted into multiple chunks of overlapping text.  Drafting allowed for geometry that the Revit engine couldn’t handle, which then caused performance issues.  Since AutoCAD treats dimensions as static collections of objects for the most part, those became separate objects, never capable of stretching or altering in Revit.

Straight up conversions were probably the worst lie told to users.  Due to the differences between the programs and given that some details were created in some of the first versions of AutoCAD, there were bound to be problems.  Imagine converting a formatted word processing document from 20 years ago into a modern spreadsheet program, and you’ll begin to understand the problems.  AutoCAD, in its beginnings, was great at mimicking drafting techniques (lines) in a computer and then printing those on a machine that used a set of pens to adjust thickness.  Revit was designed for building a complete model of a building and plotting it on a laser printer.  As a result of these differences, importing AutoCAD files carried the risk of completely corrupting your project file to the point of no return.

A Better Way

There is a way to get those details out and into production.  You’ll get to leverage all the advantages of the incredibly well-connected building and drawing database that is your Revit project file.  If you need to re-arrange your details on a sheet, the callouts update immediately, throughout the whole project.  Your sheets are all happily in the same project and a change to a title or sheet number doesn’t mean pouring through your plans to find any references that need to be updated.  Is it easy? No, but what you’ll find out today is how to leverage these assets to their fullest potential.


There are a few things we have to assume before we get started. For any of this to work efficiently, your details have to be ready or nearly ready for the 21st century.  What I mean by that is that your details should be approved and considered ready for production.  You could pick up a few adjustments to them on the way, but this isn’t intended to be a creation process.  Your details need to be vetted by the powers that be; they should be well organized and should all follow your firm’s drafting standards.  Consistency is key, and I will emphasize that often.  In short, your standards need to be nearly perfect.

With that said, plan your attack.  Are there things you want to add, functionality-wise?  Would it be great if you had keywords attached to every detail so you could find them quickly? How are you going to handle “noplot” elements and “notes to drafter”?  There are lots of easy things you can do to make these things happen, but your homework is getting it all thought out before you start.  My strongest recommendation is to think everything through completely and with an eye toward your end-product, because it is rarely easy to make corrections halfway into a project with Revit.


I’m sure you’ve set up your company template by now.  If you aren’t happy with it, I suggest taking a look at it before you start this trek.  There are lots of things that will come into play in this process that will be driven or possibly conflict in some cases.  Do your line styles and line weights take care of all the conditions you need? Are naming conventions set across those?  This is the foundation you’re about to build on, so make it solid. Keynotes ready to go and set? Just imagine what all you are about to touch and think about if there is functionality you’ll need in the details that will facilitate some larger goal.  Effectively you are pull planning an upgrade to your whole workflow.


A consistent naming standard or scheme for everything will save you huge amounts of time when you are transitioning in new data or training new people.  Think about what pieces are important to quickly identify a family, a detail, line usage, etc.  For example from “Text 1” doesn’t tell you anything about a text style.  But “S_Normal_Opaque” would at least indicate that it might be the standard text, with an opaque background.  S_1/8” Arial_T definitely tells you its size, font and can be interpreted to be a standard and possibly transparent.  Your goal here is speed and ease of adoption.

Lines Subcategories and Detail Items Subcategories

linestylesThe nomenclature here might get a little confusing, but stick with me.  Lines on drafting views are in the “Lines” category under Additional Settings->Line Styles.  Detail Items have their own separate category and the subcategories there relate to the lines in Detail Items only.  Therefore, you’ll want to create subcategories in “Line styles” that match the subcategories in your “Detail Items.”  This will allow your individual lines (under annotate tab, Detail Lines) to match those in the Detail items.

Detail Item subcategories and how adesk messes with us.

These two are different dashes. And you should make sure you have Linestyles that match your Detail Items subcategories

It might seem silly, but this will be very important. As you bring in these views, all objects on the view come with them.  Line styles, line patterns, and subcategories that don’t exist in your template but are in these views will be migrating into projects.  There are quite a few subcategories by default in the out of the box (OOTB) Detail Item families.  Unfortunately, it isn’t completely consistent.  Some items will have a subcategory “Wide Lines” and another will have “Thick Lines”.  The best strategy is to make alterations to your standard template that adjust those line weights/styles to your preference.  When the views are imported, the settings in your template take over.  An alternative is to edit all of the OOTB families to a common set of subcategories or use a 3rd party tool to align them to your standard.

Some firms feel the need at this point to mimic all the layers they had in details in AutoCAD.  I would strongly advise against that.  The effort will not provide much in the way of added functionality, but will incur a huge cost in coordination, maintenance, and general productivity.  You’ll need to take a hard look and decide if you really need layers for every different material type (wood, concrete, metal, etc) and every condition (hidden, cut, beyond).  In this situation, the data boils down to representing cut, edge, and hidden conditions with a few different patterns and weights for other conditions.  Use caution when working through this.

I recommend that the lines and detail objects all be set to have a very obvious color besides black.  This makes them easier to spot when an item in a plan, elevation, or section is a detail object instead of being modeled.  An alternative is to just do this at the project template level, but leave your details in black.  When these views are brought into a live project, the settings from the project will override what was in the view if the subcategories exist.


Now that your template has been seeded with data for the OOTB detail items and you’ve decided what you are going to do about the subcategories, you’ll probably want to generate a few families to use in your details.  They are some of the easiest families to create and can provide huge speed gains if done well.  The best way is to look at your details and see what graphics are used over and over.  Repeating pieces of rebar in section? Easily done in a repeating detail.  Make a couple: one for spacing based on number and another based on spacing.  Same for brick courses in section: make one for a generic level, work points, rebuild the weld symbol, etc.  Since you’ve worked out your subcategories, create a family template with those object styles in there so you aren’t starting from scratch each time.  The easiest way to do this is to create a family file that has just the subcategories and hatches you need in it and save that .rfa as your base file.  There is a way to create an actual family template file, but I don’t think it saves you too much effort in this case.

Brian Mackey’s Techniques

Given you are looking at possibly touching every one of your detail item families at this point it might be worth noting Brian Mackey’s strategy of making detail components for almost everything including hatches and fills so that you can tag everything with little left to be generic text.  It is a lot of work but this would be the perfect opportunity to launch such an effort.  He’s presented this topic numerous times at AU and RTC. Essentially, the strategy is to build every piece of your details out of detail items so that you can tag them to produce your annotations instead of text.  This way the annotations are “stuck’ to the elements and are easily reproduced and aligned to documentation standards. You can learn more about this process here.

Naming Standards

Circling back to our naming standards, you’ll want to look at the best way to identify your details at this point.  Some offices reference their details internally based on 6 digit numbers related to classification standards like MasterFormat or Uniformat.  Others base them off of alphanumeric codes.  To a degree this doesn’t matter.  The point is to have or develop one at this point so that you’ll be able to quickly locate and place the details you need.  This will be what we use as a view name for every detail we create. Later, we will use these view titles to find what is needed via the “Insert Views from File” command.

View Name vs Title on Sheet

view properties

Title on Sheet vs View Name


Using Ctrl-Enter in the “Title On Sheet” parameter you can break the title where YOU want instead of at field extents

Since these codes or classification numbers don’t normally work for view titles on sheets, we’ll use the “Title on Sheet” parameter for all the details.  The added advantage here is that you’ll be able to add carriage returns in your view titles where you couldn’t when using just the View Name.

Extra Data Fields

In 2015, Autodesk added the ability to create Project Parameters for views and use those in View Titles.  In one firm I worked for, this allowed us to provide the same naming code on the detail. It also gave us a way to indicate if the detail had been modified from the approved standard detail.  You could also add a field to indicate when the detail was last updated, so that you can tell if which version was used on a particular project. These are only instance-based parameters, but still a great feature that was previously done with some trickery.


At this point we are ready to dive into the actual translation.  The following steps will ensure that your resulting Revit files will be clear of extraneous data (Imported categories and materials) and be very stable and easy to access.

Separate and Organize DWGs

First, make sure each of your DWG details is its own file.  This will aid in linking in the files and positioning them on a drafting view properly.  If you previously had them all in sheets, the easiest way is to copy the items that make up a detail and pasting them in a new document, oriented with the bottom left at the origin.  Ideally, the new documents will be free of layers and styles, and only the elements you bring in will be present.

Create Drafting Views & Link in DWGs

Starting with your template file, create a drafting view at the appropriate scale and link in the appropriate DWG origin-to-origin only for that view.  We are linking to insulate the Revit content from that AutoCAD content. If your AutoCAD standards indicated line weight in relationship to color, it is a good idea to preserve the colors, since this will allow you to translate those to your new lines in Revit more efficiently. At this point, I generate lots of drafting views of the right scale and import DWGs in an assembly line, setting up the names and title on sheet parameters as I go, in a batch fashion.  If you have an excel export/import tool, you could use it here.  Otherwise a View schedule could suffice in most cases.

Detailing Strategies

did you know about this one?

Show Hidden Lines… not just for model elements.

Once you are ready to fill out the drafting views, it is worth looking at the detail for a second and strategizing your attack.  What items could be a detail item?  What is at the “back” of the detail, meaning what will be eventually hidden by elements in front. This is important as, in my opinion, the “move to forward” and “move to back” tools in Revit are a bit cumbersome. You want to start with the elements in the back then overlay elements on top. Remember that there are OOTB detail items for lots of things you might not have had as blocks in AutoCAD; studs in elevation for example. When you layer in the objects properly you can leverage the hidden line functions quite easily, saving yourself lots of extra line work.

What I’ve found is that once you understand the process, assuming your detail items are easily accessed or already in the project, this will go much quicker than you think. If you find yourself drawing things over and over, it is worth considering building additional families at this point. It is highly unlikely they were all caught in your previous steps.  Also, try to be cognizant of areas that might need to adjust when placed in a live project.  Some firms use these typical details as a starting point and expect some modification to happen from job to job.  Try not to lock the entire detail with elements that won’t move easily.

View References

You can also leverage some great features of Revit into your details.  Do you have details that need to cross reference other details?  Set up a view reference family that matches your normal text size and place it where these occur.  Then, once the details are in use in a project you can adjust those view references to point to the right views.  If the view referenced is moved, the callout is updated automatically.

Line work

For line work, you can pick lines or draw over the top of them.  Each has advantages but I prefer to pick lines with caution.  If you get any of those pesky “Line is slightly askew” messages stop and correct immediately.  You don’t want to be introducing these kinds of errors in your projects every time you add a standard detail.

Remove Links

Once you’ve got your details done, remove the links from the files.  Theoretically you are moving platforms and any further changes to those details will need to be done in Revit.  After you’ve removed the links, purge the file to clear out any random bits left behind.  You want these files lean and pristine which means purging until the counter drops to zero, saving the file, and then purging again just to be sure.


Group your details in logical sections per file.  In other words, put all your concrete foundation details into one file, all your wall sections in another file, standard steel details in another, etc.  In those files, make sheets that could be placed wholesale in a new project.  For example, if you have a sheet of wall sections that always contains 10 set details, set that sheet up with your standard titleblock and place the needed details on it.  This will allow users to bring the whole sheet in, pre-populated and ready to go with just a few mouse clicks.

Quality Control and Verification

Given the nature of what you are working on, quality and accuracy is the utmost importance.  As such, you should have someone pore over every detail once they are complete, and correct any mistakes.  I specifically recommend arranging to have someone other than yourself reviewing, if you were the one actually producing the details. This practice is as old as drafting itself, but is commonly overlooked.  Every person will miss their own mistakes on a job because they are so accustomed to what they are seeing.  It is also important that this isn’t just done on a piece of paper, but inside the application.  The QC person should be looking at all the parameters in the view if you have them, checking that detail items were used where appropriate and that AutoCAD elements are hanging around.  A print should also be used to spot any oddball problems with hatches or graphics but it will be your secondary test in my mind.


Congratulations!  You’re now ready to set your awesome details out into the world to build projects.  There are lots of firms out there that don’t want to spend money on lots of extra tools beyond the $7,000 investment in Revit.  So putting your incredible work out into the field is your next challenge, luckily this is probably the easiest part of the process, even without a content library system or a developer in your firm.

Since we organized all of those files earlier into logical groups and set up the standard sheets, the insertion process is incredibly easy.  Obviously the files need to be accessible by your users, but I would recommend they only be editable by a select few.  When a user needs to insert details in their project, all they need to do is use the “Insert Views from File” button in the “Insert” tab.  You can bring in whole sheets, and the associated drafting views will come with the sheet or select the specific drafting views you need.  This is where that naming standard for view names is put into action.  Utilizing the most common way that people refer to the details, they should be able to identify what they need quickly from the list of what’s available.

If you are at a firm that is utilizing one of the content management systems like Unifi that allows drafting views to be uploaded, even better. Create libraries that organize the details in a similar fashion to the way we’ve organized the project files, and upload away. An alternative is that some of these CMS offerings have ways to tag elements as they are uploaded. Tag your details to group them and assist in searches.


I am always amazed at people that say there is only one way to accomplish something in Revit.  And I would be one of those people if I didn’t at least mention a couple of alternatives to the methods I’ve outlined here. I’ve implemented this workflow directly, so I know it works.  In fact, some of it was developed before we had an ability to add extra data to views and have it show up in titles.  But this workflow was successful based on what I had at the time. In case you find yourself in a different situation, I’ll mention a few common alternatives and my take on them.

Import, Explode, Convert

When I first started the process of converting a bunch of details, we started with some version of this.  The strategy is simple: create a drafting view, import the cad file, explode and convert the lines as needed to make it work.  It also adds a step of sandboxing this process in a secondary Revit file to insulate your projects from the risk of corrupting elements coming in with that import.  My experience is that this method tends to remove the advantages of detail items and meant more work in the end as most of the AutoCAD elements became a mess or at least very static when brought into Revit.  Dimensions being the most obvious example, as they converted into individual objects that would no longer update or flex.  That said, the firm I know that used exactly this method is happily using their details 5 years after I had that conversation with them.  Your mileage may vary.


You or your firm might think what we’ve just outlined is a lot of work that isn’t “billable” and won’t make them money so they’d rather just pay to have someone to do it.  Congrats on having so much work! But beware of what you are paying for.  I’m sure there are firms here in the US that could take care of this for you and do it quite competently, though I have yet to work with one.  My experiences have only been with firms that have just sales people in the US, but hand off the production work to overseas workers. In these cases, what we asked for repeatedly did not match the end product. It could be literally in translating our vernacular specific to AEC to another part of the world that doesn’t use the same measurements or building nomenclature. Each firm will have a particular way of documenting their work and mostly where these operations break down is in translating your standards to another firm that is working with dozens of such standards.  I also think that there is a certain amount of care that is missing from a remote worker from the other side of the planet versus a BIM Manager sitting in the firm.  That distinction means that if you see a problem, you’ll correct it to ensure the details are perfect when implemented.  A far-off consultant is more concerned with finishing the contract in the allotted time.  Again, I sincerely believe there are consultants in the US that could and do perform this type of work with great success.  Just be wary of the ones that will be shipping the actual work elsewhere.

Additional documents that went with the original presentation are available from this location until Box says no!