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
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
The 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.
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.
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
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.
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.
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.
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.
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!