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

20 Mile Threshold on Import

This is a follow up to my earlier post this week regarding the 20 mile threshold. A comment to that post mentioned that the governing extent is equivalent to a 10 mile radius sphere whose origin is at 0,0,0. In my own testing I've observed the threshold is more closely defined as a cube.

This image is a 10 mile radius sphere with a line segment that travels beyond the edges of the sphere but within the boundary that a cube would have.

You can see the highlighted square is the extent of the DWG file and line extends outside of the sphere at each end but is still inside the boundary of where a cube would lie instead.

This image is the same file but the line is altered to extend beyond the edge of the sphere/cube extent.

This is the message that appears when I reloaded the file after altering the line's extent.

The warning can be avoided if we ensure that the DWG file doesn't have any elements that extend beyond the 20 mile cube (10 mile radius). The cube can be quite far from the origin of the DWG file but nothing can be outside the cube's boundary.

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.

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.

Insert using Auto-Center to Center

Whenever we insert a linked file we find that Revit is wired or biased to using Auto-Center to Center. It doesn't matter if we've just used another placement option Revit faithfully returns to its favorite.

The reason for this preference or bias stems from the reality that DWG files are a perfect storm of chaos that we cannot reliably expect that the elements in the file are located near the origin of the file. Floating Point math calculations rely on constraining the size of the world we work in to a practical scope so that calculations can be "accurate" enough to roughly 12 decimal places. Revit uses double precision which technically extends to 16 decimal places but it only displays 12.

When elements in the imported/linked file are very far from the file's origin then Revit's ability (of all CAD software by the way) to accurately display and describe information begins to suffer. The Revit development team is a bit more fussy about this than how other software confronts us with this concern. One visual clue that this is affecting your project is snap icons fail to appear directly on the element it is related to.

Using Auto-Center to Center is safer from the developer's mindset, protecting us from BadCAD and or ourselves.

Now we've been bringing this up for years, asking for Revit to remember what we've used before and/or letting us set which option we prefer. The good news, from my perspective, a recent conversation with someone at Autodesk has made me optimistic that we will get our way sooner than later.