Exploding DWG Files

 "Just don't explode DWG files" is good advice, that is immediately ignored because...reasons...

Setting that aside, now that we've exploded that DWG, now what. First, there is full explode versus partial explode. A full explode will recreate all the DWG elements into native Revit elements (assuming it is possible) but a partial explode will produce some native elements and some new DWG elements (blocks).

Reducing all DWG elements to equivalent elements in Revit is fraught with peril. Not all blocks in a DWG are created well. Explode one block that happens to have very large extents and your project will now have display/graphics issues. A Revit project might have one imported DWG but many times that number after partial exploding.

I recently encountered three project files that had +95k imported DWG files. These were the result of partial exploding less than 20 DWG files. As most people are aware, Revit won't create an element if it is too short (less than 1/32" long). A scary number of these DWG files were invisible, undetectable by eye in any view, because I believe their contents were too short to display. Many thousands were in just a few views. I used IDEATE Explorer to select, open the view they were in, if they were invisible then delete them.

It was time consuming; for some of them it was fastest to just delete the drafting view entirely because the view/detail wasn't going to be used on the project anyway. It was part of the everything and the kitchen sink approach in their template. Many of these details were derived from existing DWG based details created over many years to varying standards.

Back to Revit and exploded DWG elements...

Each line, arc, circle, etc. element is recreated and assigned to a new line style named for the layer it lived on in DWG. Similarly each text element is created using DWG info to define it as unique. Line and fill patterns are created this way as well. Ditto for dimension styles...and filled regions...

Once these exist in a project they are prone to being used by others because they are there. It is hard to ensure the standards a company has developed are used when this additional noise is present.

If we must explode a DWG let's not do so in our active project. Use an isolated file, based on our project standards (template). Once exploded, take the time to convert everything to our standard types. The completed drafting view can be added to our active project using Revit's Insert from File tool.

Also consider the time is takes to do this well...might be as long or longer than sketching over a detail DWG instead. If our detail item library is pretty good we'll be able to create a detail faster because we have components to represent the same kinds of things the DWG has in block form etc.

Don't sweep the DWG remnants under the rug...

Large Extents -Can't Navigate in a View and-or View Will Only Show Wireframe

I've written about Revit's fussiness regarding large extents numerous times over the years. In some of those posts I mentioned a related view issue. A view that refuses to show the model in anything other than wireframe is a symptom of the large extent issue.

I recently encountered a project that didn't have any DWG files to blame for it. Not only did the view not show according to graphic style settings it didn't allow navigation of any sort. The view was frozen. We could open or close it but nothing else. I noticed I could use a crossing selection window but then using Filter to focus my troubleshooting effort was still too coarse.

I've been meaning to mention how much I like IDEATE Explorer (IE). It has been very useful to examine projects and track down issues. It permits examining a model in ways that Revit can't. for example, I can select a category of elements or instances of each family/type within the category.

I use it routinely to check for excess DWG imports (resulting from exploded DWG content), workset assignment, reviewing warnings (more effectively than Revit's own), phase assignment/usage, content naming/usage and resolve line style usage (and more).

After using the crossing selection window in various parts of the view I realized some structural elements seemed quite far apart. Keep in mind the view was a white screen of nothing...imagining gazing toward Earth from Mars and trying to pick out where California is or my house. The Project Base Point and Survey Point didn't even show up in the view.

I started with trying to isolate where in this vast white space the structural element was but no matter what I tried I seemed to always select some structural framing.

Once I knew which category to hunt in I used IE to look at individual framing elements. I found a single framing (W Beam) was 2+ million feet long. I expected to find a family very far away, not one that was just very long. I realized that a Structural Framing schedule could have revealed this element too, if I knew which category and to look at Length. I did make a schedule just to see if I missed any other really long framing.

One Beam, one verrrrry looonnng beam killed any view it was visible in. 3D views are where we were confronted with the problem but other views whose extent permitted the beam's true extent to affect the view were also victimized. In the end we rolled the project back to just prior to the beam being added. 

The views didn't "recover" from the harm when the offending beam was deleted. I surmise other aspects of the model were altered by the extent of the beam, perhaps scope boxes, crop boundaries, a connected or joined element...not sure. That will remain a mystery.

May your troubleshooting be quick, effective and "trouble" free.

DWG XREF Follow Up

 A year ago I wrote about XREF DWG files showing up in Revit even when they are assigned to Overlay vs Attached. It hasn't been resolved, meaning Revit is still doing it, no change...

Shortly after writing the post we arrived at our "solution", to assign all Xrefs (in AutoCAD/Civil 3D) to a unique layer(s) and turn that layer(s) off in Revit (via View Templates usually). This way the extra layers of the xrefs do not show up even though Revit is technically ready and willing to show them.

Linked DWG Xref Overlay vs Attached Bug - Part Two

Two options exists to work around this situation (last post). One is easy and Revit focused but depends on the AutoCAD user a little and the second is impractical and depends on the AutoCAD user entirely.

• Xrefs on their own layer
• Xrefs always unloaded

If we can count on the AutoCAD user being consistent to assign all of the file's xrefs to a unique layer not shared by any other elements then we can still turn off the overlay xref when it shows up. This shouldn't be too difficult to achieve and many firms already have that standard for xrefs.

If the xref's are always unloaded before closing a file then they won't show up in a Revit project. That's pretty unlikely. It's inconvenient for AutoCAD users and forgetting just once and the system fails.

Link DWG and Named UCS

Working through a couple support issues recently it turned out that the presence of a Named UCS prevented us from linking a DWG using By Shared Coordinates. Revit would force the DWG to link using Center to Center instead. We tried all the things to resolve it first until we remembered to check this too.

This has been a part of Revit for a long time, the "REVIT60" in the name is the Revit version when it first appeared, Revit 6.0. When we use Publish Coordinates on a DWG file Revit creates this UCS so it can be used from within AutoCAD to ensure any external references that need to align with it will do so. We can delete the Named UCS in AutoCAD by right-clicking on the name.

We have more than one site related DWG for each project to align within Revit. We used Acquire Coordinates on our benchmark file. When all the related DWG files share the same WCS origin we can tell Revit to use By Shared Coordinates when linking them.

An obtuse but factually correct message appears telling us the files don't share coordinates.

Aligning the file based on its WCS is precisely what we want so each of the files align in Revit, possible, again, because we used Acquire Coordinates on the benchmark file first. That aligned the Shared Coordinates with it so the other files could stack on top of each other properly when we linked them.

There are many subtle things that can affect the linking process with DWG files, add this to the pile.

Imported or Linked DWG Appearance as Generic Model Broken in 2017

Using Revit 2017, I have a 3D DWG file for some framing that I want to use as a coordination reference within a project file. Initially I linked the file directly to the project but that approach (unfortunately) doesn't respect the cut plane of a plan view which, for example, means cripples above a header show up in the plan view too (header as well).

I decided I'd use the old create an in-place Generic Model family trick.

If you're with me so far you're probably expecting what I expected; to find that Revit regards this imported 3D geometry as generic model (cuttable) category information, giving me the look I wanted. However, when I clicked Finish Model the linked file disappeared entirely.

I thought for a moment, "Am I just imagining that I could do that? I swear Revit used to do this?!?"

Hmm, I decided I'd create a component Generic Model family instead and use Import CAD. This way I could replace the source CAD file if necessary.and just reload the family later...if necessary. Also thinking, "...maybe it'll work this time, this way...?" Nope...

I gave in, I did a quick search using Revit Help and noticed a result called "Regression Revit 2017 - Cutting 3D DWG with section results in inconsistent model display".

NUTS! ...at least I'm not crazy (about this at least)...

Well I'm writing to declare that it's not just an issue in section views. The damn thing doesn't show up in a plan view at ALL.

It works as I remembered in Revit 2016...project is in 2017 though.

I did try creating the family in 2016 and let Revit upgrade it in the 2017 project...no joy...busted. I also created a Specialty Equipment family (in-place too) and it shows up in plan view but since that category doesn't cut...it's missing the point, my reason for traveling this road in the first place.

sigh ... next service pack, update release, patch...(whatever they're going to call...)

Link Positioning Manual - Base Point

AutoCAD has a feature called Base which allows us to specify an alternate insertion point that will be referenced (instead of the origin) when that file is inserted into another DWG file, either as an external reference or a block. Revit has a positioning option called Manual - Base Point. Sounds good except it doesn't work.

I created a DWG file (AutoCAD 2016) and sketched two squares, one at the actual origin and another one elsewhere. I used Base to reassign the insertion point to the bottom left corner of the other square, the one that isn't actually at the origin.

This is what I see when I use the Manual - Base Point option.

Help still says...

Short story...sounds good but doesn't work.

Follow Up - Importing DWG Files using By Shared Coordinates

As the title suggests, regarding an earlier post earlier post, recently I was participating in a thread at the Autodesk User Groups and an Autodesk support person wrote that Revit intentionally attempts to create a User Coordinate System. This means what I wrote about in the other post is happening on purpose, not a bug.

This means they (Revit's developers) are assuming the files we are linking don't already share an agreed upon file alignment strategy between the people that created them. If I understand their logic, it means that using Positioning: Auto-By Shared Coordinates when we link a file triggers a response in Revit that it needs to create a UCS (User Coordinate System) to permit AutoCAD users to align these files if they are combined (apart from Revit) in AutoCAD at some point.

Revit can't know if these files have an agreed upon relationship to the WCS origin because in AutoCAD that's a subjective user based agreement, not something captured in code. In other words we agree as users to draw things relative to 0,0,0 in a specific way so our files will line up when we use them as an external reference. In my view, for multiple survey file relationships, that's most likely not necessary and just creates confusion. I can imagine how it might be useful if we are mixing a variety of trade files that might not have discussed how their work relates to the WCS origin. However that seems like a rarer circumstance to me, especially if Revit happens to be the primary platform in use.

Imagine we link a survey file into our Revit project and use Acquire Coordinates. Revit establishes a relationship with this external file and moves our project's shared coordinate system to align with the survey file. It moves the Survey Point (when the icon is clipped) to mark the WCS (World Coordinate System) origin location of the linked file. Now imagine we link a DWG file that, to pick a discipline, is the fire protection design. It isn't very likely that they started designing by importing the survey DWG. That means their file and the survey file don't share in their understanding of how to start drawing relative to the WCS in their AutoCAD files. In my opinion it is much more likely that they started designing based on a plan we exported from Revit and sent to them. If true then we'd be better off importing their file using Positioning: Auto - Origin to Origin.

If they just started designing without a background file from us (not really likely, what context would they have?) then we could link their file using Positioning: Auto - by Shared Coordinates. Revit generates a warning (refer to the other post's images) that this project isn't sharing coordinates with this file so it will import it using the WCS of the file, which is still pretty arbitrary in this scenario. Revit however regards this positioning choice as significant and when we try to save our work it prompts us to save the changes to the linked DWG file too. It wants to create a UCS in that file and save it so that an AutoCAD user can reference it, making it possible to line up this file with the survey data if those files are combined in AutoCAD.

In my view this a feature that is conceptually broken. It is changing a file (creating a UCS) that isn't the primary file, just my copy of it. They sent it to me so I can link it. If all of the disciplines work at my company and in my office then perhaps all the files are stored on the same server and accessible to everyone. That's certain possible but it is still unlikely that this UCS will be necessary or that anyone will even be aware that it exists.

The shorter answer, when confronted with this dialog: Choose Disable Shared Positioning (for the file involved, not the one that was used to Acquire Coordinates originally).

Based on my bias, we should have a way to tell Revit we want to link a file based on the Shared Coordinate system without incurring the belief that a UCS must be created in the file too. Perhaps an option to link via the WCS of the external file and the origin of the Shared Coordinate system without the assumption that we think there is actually a shared relationship between the Revit project file and the DWG file?

Importing CAD Files and Invert Colors

Autodesk help documentation offers this explanation for what happens when we use the Invert option for interpreting the colors in a CAD file when we import/link them (my emphasis added).

Inverts the colors of all line and text objects from the imported file to Revit-specific colors. Dark colors become lighter, and light colors become darker. This can improve readability when the file is in Revit. This option is set by default.

The following image is a small sample of what occurs. The top row of lines, imported using Preserve, have been assigned to the basic color palette and a couple extended colors, such as Red, Yellow, Blue and #10 (red) and #30 (amber). The bottom row of lines, imported using Invert, are how they are changed from the colors assigned in the CAD file once they are represented in Revit.

Looking closely, red becomes cyan. If you examine #10, a red also, you'll see that the Inverted color is also cyan or at least cyanish. Shades of red will be converted to shades of cyan. Compare the others and you'll see similar logic.

I don't use Invert, or recommend doing so, because the results are rarely meaningful or useful. You don't know why something is assigned to a given color. The simplistic goal is to just reverse (invert) the intensity of the color once it is imported, to make it easier to see on a white background or balance their appearance in this way.

If we really want to retain or use the color in some way then I believe it is better to keep (preserve) the colors we may already be familiar with, at least if we are responsible for creating that data too. That's my two pence worth.

Importing AutoCAD File Fails

When you try to import AutoCAD data you might have seen this series of messages before? First we get a complaint about Elements lost during import.

If it is a Civil3D file that might not be too surprising if they created AEC elements like contours or road elements. Then we get this message.

It's especially confusing if you just were looking at the file in AutoCAD and know there are elements there. Worse you'll probably see the first dialog again if there isn't any data in Paper Space to import either. Even worse is when you find out it is all "your" fault. Well at least in this case it was my fault.

The culprit is saving the DWG file and then attempting to import that DWG file, which happens to be using a newer format than the version of Revit that is being used. In my case it was a AutoCAD 2013 file that I was attempting to open in Revit Architecture 2012. I keep forgetting to save it using the 2010 format. Once the file is saved in a compatible format Revit works much better. Too bad the messages don't give you any clue it is a version thing.

So if you see such messages remember it might just be the file format/version.

Dept. of Subtle - Text Output to DWG

With 2012 we can now map Revit fonts to fonts in AutoCAD. I can export Arial to Romans for example.

I got a request to check something out today and the results are curious. Here's a drafting view of four Arial font sizes: 1", 1/2", 1/4" and 3/32" (using view scale of 1:1).

Here's how it looks going from Arial to Arial (Revit 2012 - AutoCAD 2012).

Here's how the Text Height transferred (Revit/AutoCAD):

I used the "deepest" units setting in AutoCAD for Fractional of 1/256" so that's altered the value for 3/32" to register the "correct" amount. The decimal equivalent for 3/32" is 0.09375 though so the reported value (when I change the units to decimal instead) of 0.09220621 is also off a bit.

Then I exported from Revit Arial to AutoCAD RomanS, same sizes:

Here's how the Text Height transferred (Revit/AutoCAD):

Can't really measure text height accurately in Revit since none of the tools that measure or dimension can "touch" text. It's possible the fonts are "off" in Revit to begin with, just can't say for sure. I don't know that the inaccuracy is enough to get upset about but it doesn't result in text heights that match what you'd expect.

Export to DWG Layer Options

I responded to a question at AUGI about exporting to dwg. I decide to repeat some of it here. When you export there are three options for Layers and Properties:

• Category Properties BYLAYER, overrides BYENTITY - This deals with differences between elements that have the same layer assignment but "look" different in Revit for some reason)
• All Properties BYLAYER, no overrides - This forces all exported elements to be bylayer which will change line patterns and colors so that they ARE By Layer)
• All Properties BYLAYER, new layers for overrides - This allows Revit to create a new layer when an element has a representation that a single layer will not support)

To put this in a practical example, imagine a Revit Grid element which has text, a circle and a line that is usually drawn with a different line pattern than the circle. If this is exported to layer S-Grid and you want entities to use a BYLAYER setting, what should Revit do?

The first option will override the linetype of the line so that it maintains its appearance. It does so by creating a new linetype/pattern in the AutoCAD dwg that matches the line pattern name in Revit.

If you choose the second option you get a solid line for both circle and line which doesn't look so good when you see it or print it.

The last option will create a new layer for the Grid Line, S-Grid-1. You end up with S-Grid for the circle and text and S-Grid-1 for the grid Line. All the elements are By Layer.

If you are still with me, a little reminiscing... I remember a few years back (late 2004 or early 2005) when Jim Balding, my boss when I worked with WATG, and I were on a conference call with David Conant (Autodesk Revit Product Designer) for a couple hours discussing exporting to DWG.

We had just been through a fairly harrowing experience getting dwg files just so for an overseas client that was going to take over the project for construction documents. We even had our in-house programmer and cad manager in Honolulu, Danny Polkinhorn, create a clever little application to redress the dwg files after they were exported from Revit. He affectionately dubbed it "Revit DWG Fixer". One result of that phone call with David was these three options I just wrote about. I'm sure others echoed our desires but the result nearly matches what we expressed then. Not the solution but that we experienced these kinds of layer issues. The solution gave us an option that worked, for us at least. We usually chose Option 3...I still prefer it.

To digress a bit further, it is important to understand that the intended purpose for exporting to dwg is to create files that can be used as a background for other trades. It was never really intended to be a better way to make dwg files. Not to make files that a native AutoCAD user could just continue to work on as if they started the work themselves. The resulting files are not created the way a native AutoCAD user would create them. It does a really good job of getting close. Kind of like me claiming to speak Spanish. I know a few words but a native speaker will catch me in the lie pretty quick.

One practical example, AutoCAD users will usually create an overall floor plan file for each floor of the building. Partial plans are derived by using a sheet file that has the overall plan as a external reference (xref). The partial views are showing some of the same overall floor plan file and the viewport is adjusted for the correct scale and location.

If you export the same kind of information from Revit you don't get the same configuration. You get a sheet file referencing a model file that is the literal export of what was visible in the partial view in Revit. This means changing the dwg file of a partial plan is not really changing any other information in any other dwg files. There is an expectation that it does...but it does not.

Rather than driving Revit to create better and better exports I'd prefer that AutoCAD got smarter about extracting what it wants from a Revit model. Consider the goal really isn't for a Revit project to end up as dwg files. Dwg files are really just a common format that lets other firms that are not using Revit interact with the project using their own software choice.