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

Revit 2020.2 Internal Origin Redux

Happy Thanksgiving to those who observe!

One little thing I'm thankful for, I got a file yesterday from Autodesk (TurnOffInternalOrigin.Dyn) that is meant to be run in Dynamo Player (it's a custom node in testing ATM). You can download the file, place it wherever your Dynamo Player is looking for files already or in Dynamo Player just browse to wherever you placed the file. Click the play button (see image) and it will turn off the Internal Origin in all views. This approach means very little Dynamo knowledge is necessary, just enough to get Dynamo Player open and find the file.

Since I already put in some time with my own graph which included the Survey Point and Project Base Point I decided I'd like to be able to turn on/off all three or just the internal origin or some combination. I modified my graph (Control Coordinate Graphics.dyn) to provide input options (see image).

When you use Dynamo player you can edit the input options through On/Off switches (see image).

Click the little Properties button (looks like a old Macintosh computer to me). Clicking the toggle will make the statement either true or false for each "hide" question. All three true = all off for example. Remember my graph is dependent on a node from the Archilib package, make sure you've installed that before trying to use it.

Revit 2020.2 Turn Off Internal Origin - Dynamo Option

In a thread at RFO John Pierson (Parallax Team, and Dynamo guru) got the ball rolling with a video link that described overriding graphics in views. I picked up the ball and created the graph but missed an essential but tiny setting for one node to make it work (Lacing - Cross Product).

The Dynamo Graph looks like this (click to Download).

You can use Dynamo, with this graph, to turn off the Internal Origin, Survey Point, and Project Base Point in floor and ceiling plans, sections, elevations and 3D views. Change the code block from False to True and it will turn them all on instead.

Regarding Jean-Marc's comment: I think he was suggesting this instead.

Zoning Clearance Thoughts

A long time fellow Revit traveler reached out to me via Revit Lifeline last night asking about zoning clearance ideas. Where he lives and works they want designers to demonstrate the building is not too tall. They also want them to prove it doesn't extend into a zone that leans back into the site. All in all the code reduces the size of the building that can be built on any given property that falls under its jurisdiction.

I have heard and read about this concern many times over the years. But in response last night, I mocked up a quick example to see if it met his needs (waiting to hear back). I thought, "Blog post? I just posted something the other day...don't get carried away. Yeah, but you've only posted like twice this year slacker! So a blog post it is then..."

Here's a few images to ponder first. Pretty fancy house design eh? Doors and windows are so last century. I CAN design YOUR next home, just call when you're ready...operators are standing by.

The upper surface is a thin floor which is manipulated through Dynamo and Shape Editing. Lauren Schmidt's LandArchBIM blog is a very nice source for land techniques and I stole her graph ideas in this post to make it. Her post explains the technique relies on a sub-region to match whatever hardscape shape (property boundary in this case) is necessary. I used the floor's offset parameter to move it up above the surface by the zoning height required.

The front and back property boundary clearance requirement is built with a railing and profile. The fact that railings can be hosted by toposurface now opens this door wide. The surface form might not lend itself to a nice clean railing though, mileage will vary. You can see the rear railing is a little deformed in a couple spots. I built parameters into the profile so I could (using types) vary the height of the angle portion, change the angle, change the height above property (spring point of the lean) and the thickness of the railing.

I created a specific material to assign to it all so it can be mostly transparent.

My example is admittedly simplistic. How many property boundaries are really a simple rectangle? Pretty rare, about as rare as a purple unicorn that uses Revit? A front or rear boundary that has arcs and many segments will probably pose some issues creating a hosted railing. I can imagine things going wrong but I'll wait until I'm dealing with something specific to worry about that.

The file I mocked this up is in Revit 2020.2 and the dynamo graph (link has both RVT and Graph) is so simple that this screen shot would help you build it nearly a fast as downloading and opening it up. That's what I did with Lauren's example. You do need the packages I've circled.

Oh, the mockup has a massing element too, you'll have to turn massing on though. At first I thought I'd sweep a profile along the property edge defined by the upper surface. After I did that I thought of the railing. The learning curve is much less steep for a railing than massing, bonus being much faster too.

Decided to add a couple more images. I realized that I could have turned off the sub-category Interior Edges for Floors to hide the tessellation in the other images. It also occurred to me that another railing and profile configuration could deal with the top. I just created another type from my existing profile family to make it a 90 degree railing. A separate wide profile without a vertical portion would provide just a top surface. The floor and railing approach don't result in the same surfaces but within reason? If reason can be applied to a zoning requirement?

Here's both visible...

Reveal Elements - Hidden Viewport

The other day I was looking at a sheet a user reported it was impossible to select a floor plan view on. It seemed as though Revit did not see the view port on the sheet. People frequently pin views to make it a bit harder for other people to move them on a sheet accidentally. That will still allow a view port to be seen by Revit, it will still highlight as the cursor travels over it.

Then I thought of right-click Hide In View > Element. I used Reveal Elements and I could select the viewport. Using that tool does not hide what is visible in the view, it just disables the ability to select the view port.

Good? Bad? It isn't expected, well I didn't expect it.

Change a System Parameter from Type to Instance - Not Length

It is fairly common knowledge that we can change a built-in parameter like Width from Type to Instance by going through the side door, selecting a dimension assigned to the parameter and changing it to Instance on the ribbon (see the image).

Kurt Thompson wrote to me to share how he gets around this issue when the parameter isn't something a dimension can be associated with. Specifically he was referring to a thread at the Autodesk User Forums where a member (electrical focus) was asking Autodesk to change the default parameters for Mains (instance), MCB Rating (type) and Subfeed Lugs (type). They argue that each parameter should be the opposite of the current configuration based on how the information is really dealt with (not that he needs me to, but I agree with him).

Kurt writes:

"To change a System Type parameter to Instance...(specific to the mentioned thread)

Create a Shared Parameter built exactly like the built-in parameter you need to change but make it Instance instead of Type. Starting out with a Generic Model family, add the new parameter. Now assign the family to the category Electrical Equipment, Revit will replace the shared parameter with the built-in parameter but it will retain the Instance (or Type) property setting from the shared parameter. Give it a try."

Thanks Kurt!

Property Boundary and Coordinate Data - Dynamo

Alternate title: Mr. Revit OpEd finally does something (tho basic) with Dynamo!

I used this problem as an excuse to dig into Dynamo a bit. I created the attached graph to read a text file with coordinate values, one line per X,Y,Z values.

The text file format is very basic, it looks like this:

I created a 3D cylinder and model lines to form a target symbol family, 3D and fairly large so I could see it anywhere in the model. The graph places a target family at each coordinate location. Before running the graph, I assigned the Project Units for Length to Meter. Then I ran (manual) the Dynamo graph to place the target families. The last step was to start the Property Line tool and sketch the property boundary segments from target to target, which looks like this.

It was necessary to move the points closer to Revit's origin so they were not so far away, since Revit hates that. After doing that, I moved the Survey Point (not clipped) to one corner of the property (target family location) and then used Specify Coordinates at Point at that location using the coordinate values for that corner. This will allow me to export the result to DWG, if necessary. I also created a specific Spot Coordinate family type so I could identify some or every target location and make sure each reports the correct coordinates, double checking my work so to speak.

I probably spent a couple hours on this, mostly trying to get my head wrapped around which nodes in Dynamo to use. The next time I'll be twice as fast!

Troubleshooting - Start an Email or Forum Post

I find it helpful to resolve an issue by starting to write an email or forum post (or a blog post) to ask for help or complain about it. Trying to write an explanation for what is happening so someone else might be able to help me focuses my thoughts. Very often I find it isn't necessary to finish writing.

The answer presents itself during the writing.

Next time you're puzzling over something, consider writing down what you think is wrong and the solution may arrive as you type.

Worth mentioning that a short break can also help a lot. Grab a beverage, talk to someone else, or stretch your legs; or all the above. The change gives you chance to work on the problem in the background of your attention.

Moving a Viewport Error - Disjoin

The Move tool offers us an option called Disjoin. When it is used Revit deletes the original and creates a new element at the new location. That isn't obvious to us but if you examine the GUID (ID's of Selection) you'll find it has a new GUID after the Move is complete.

The option is sticky, we have to remember to disable it when we use the Move tool again. When we are working on sheets and adjusting views we now have an opportunity to run into a confusing error message.

If you run into this or people you support do, just remember to Disable da Disjoin.

Per a comment: My previous post on re Disjoin.

Remember Linked Files Have Two Workset Parameters

I find this overlooked regularly. Each link has an Instance AND Type parameter called Workset. If we select a link (RVT) in the Project Browser we can see the Type parameter for workset, even if the link isn't loaded.

If we right-click and choose Select All Instances > In Entire Project we can see the Instance parameter value, unless there is more than one instance (copies of the link).

The best way to ensure that both parameter values are assigned to the same workset is to make sure the Active Workset is set correctly first, before we link the file. If not then we have to check both values.

Why are there two parameters?

The Type parameter governs the existence of the link in the database while the Instance parameter governs the actual instance you can see in the model views. The linked file can be copied, for example House Design A can be copied so we can show that it will be located on several lots within a development, each likely oriented differently.

The instance parameter allows us to assign each copy to a unique workset while the Type parameter affects all of the copies. That means closing the workset assigned to the Type parameter will close all of the copies of the link, none of them will be visible.

If we close the workset assigned to just one copy then only that linked file won't be visible.

If we experience erratic issues with linked file visibility it is the first thing I check. I'm also in the habit of looking at all the linked files every time I get introduced to project. This also applies to other linked files (CAD,Point Cloud).

Section Line Annotation Alignment

No, not the 2019.1 feature that allows us to use the Align tool on sections...

If you find yourself wondering why you don't the get the telltale dashed lines to help you line up section heads or tails check Visibility/Graphics for the view and make sure Lines are checked (visible). If the category is turned off, so too are they. These...

Check this...

Project Units Matter - Specify Coordinates at Point

When we use the Specify Coordinates at Point (SPaC) it is possible that the units in use will affect your results. For example, this project is using Feet and Fractional Inches (FaFI) but for SPaC to match the available survey info it was changed to Decimal Inches (DI) with six decimal places. After using SPaC the units were returned to FaFI.

Some time later the elevation needed to be changed thus causing us to revisit using SPaC. The following image shows the original values used for SPaC.

Leaving the Project Units assigned to FaFI resulted is this subtle change to the coordinate values.

When the units were revised to match the earlier DI settings the SPaC coordinates are not altered.

Shorter story, be careful with your unit settings when using SPaC.

Move to Room - Element ID - Review Warnings

If we use Review Warnings often enough, and we should be, we'll run into this warning eventually.

Check the item and Click Show to have Revit try to find a view to show it in. Once it is selected we can either drag the Tag where it is suppose to go or Click the Show Related Warnings button on the ribbon to show the dedicated warning it has again.

When this warning is isolated like this the dialog includes the Move to Room button. An aside, is it amusing or worrisome that Revit seems to think the best way to fix warnings is to delete the offending element (via Delete Checked)? Regardless, Move to Room will resolve the issue whether we can see where the tag is meant to be or not.

Another way to tackle it from the Review Warnings dialog is to make a note of the Element ID referenced in the warning. Now we can then use the Select by ID tool. Enter the ID value and click OK.

This will select the tag, even if we're not in a view that it can be seen in, and then we can use the Show Related Warnings button on the ribbon again followed by the Move to Room button.

Five Minutes with Shape Editing a Bay Roof

I posted this screencast in response to a thread at the Autodesk Forums. Figured I might as well share it here too. I used shape editing to create the bay roof condition shown in this image.

It's based on an image of a DWG roof plan that was shared in the original post in the discussion. The sketches of the main and bay roofs look like the following image. It also shows the sketched Split Line elements I added to make raising the bay ridge up easy.

Here's the screencast I created to post at the forums.


FWIW, I made the main roof partially transparent so I could see the walls more easily. In the video I commented about using the Two Cut Plumb setting with a 12" value. The Shape Editing disables that for the bay roof but it did start out with that setting in play so it all worked out as I intended even though I was confused about it at the time.

Sketching Tangent Lines

A post based on my responses at the Autodesk Forum: Tangent Circle to Tangent Circle.

It could be easier...

I see Revit behaving this way, they regard the first point as ineligible to being tangent because it depends on the bearing of the line, With that assumption or bias, the first point is necessary to make a tangent condition possible. I can easily snap to a location on the circle (a pulley for example) that couldn't be tangent to the next pulley.

AutoCAD deals with this in a clever fashion (when we invoke the tangent snap) by fixing (changing) the first point to be tangent after the second point is placed. If we aren't careful with our second pick point (snap tangent too) the tangent line might end up on the opposite side of the pulley.

In contrast, Revit handles it naively, because it regards our first point as ineligible to tangents because it isn't considering this particular end result: "I want to draw a line tangent to two circles". AutoCAD appears to know this by virtue of snapping tangent for the first point so it can adjust the final bearing, and attachment to the circle, of the line.

To get around this naiveté, I place the first point on the pulley where it looks like it can be tangent, to my eye. The second point snaps to tangent with the icon. I return to the first point and grip/drag it away and back to let the snap icon appear, to fix it for tangent, just to see if I was close. If my guess wasn't accurate, it is now.

After reading a reply to my comments I did a quick sketch in AutoCAD and then did the same sketch in Revit using the same pulley sizes and offset from one another (see Footnote). The tangent lines have the same x/y properties for start and end as the AutoCAD version, that I made using its snap tangent.

This is the native DWG sketch and properties screen captures for each element.

This is same information but for the Revit drafting view exported to DWG. When I create an External Reference of the exported Revit drafting view it lands right on top of the native sketch. If you look really closely you'll see a value is slightly different in the Revit version. I think that might be my fault, sketching. Regardless, I think close enough is fair.

Footnote: Regarding a drafting view aligning with a DWG file after export: It might not be obvious but drafting views have an origin. To test that claim link a DWG, that has a marker at the WCS origin, into one and you'll see where the origin is. I did that before I did any sketching so I'd know how to place the pulleys in the same place. That made it possible to compare the tangent lines after exporting it to DWG.

Also the Start and End X/Y values are reversed. That's either just how Revit interprets the vector of each line segment or it's because of the direction I chose to sketch them in Revit. In AutoCAD I started at the smaller pulley. I didn't make sure to sketch in the same way in Revit, sloppy scientist.

Revit Coordinate Systems Video

A lengthy exchange at Autodesk's User Forums about this subject reminded me that I've meant to create a short video to describe how they relate to each other for quite awhile. This morning I saw our cutting boards drying next to the sink and realized they could serve as metaphorical coordinate system planes (Project and Survey) work in Revit. I am curious if readers find it helpful.



The original post at the forum dealt with a few projects that had been modelled very far from Revit's Internal Origin/Startup Location. I looked at one of the project files and found the Survey Point and Project Base Point had been moved very far away while unclipped. The modelling started there, really far far away. They started to experience some of the negative symptoms that can occur and started looking for solutions...thus the original post. The short answer is they needed to move their model closer to the origin. No other way around it.

Shared Coordinates - Autodesk Reference Information

It's September already...no posts in August...time flies.

This post is brief, merely a referral. If you struggle with understanding Revit's coordinate system then THIS LINK, at Autodesk's Knowledge Base (KB) site for this subject might be helpful. I like the images and some of explanations or interpretations it offers.

Check it out, it may help!

Edit: I wrote this on Sept. 7th originally, received an unflattering comment about it, returned it to draft, revised it, and restored it to published on Sept. 14th.

I was lazy. I thought the information was an addition to their formal help documentation. When I saw the comment I read through the KB article again and realized that it was written by an Autodesk User Group member and submitted to their Knowledge Base system, which happens to be curated by different people than the product documentation group. I might quibble with some subtlety of it here or there but its approach may help someone get a grasp on the bigger picture. Just keep in mind that its claims are not gospel, nor written by Autodesk's own people.

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.

Reset Shared Coordinates Update

During April 2012 I wrote about using a separate file as a diversionary tactic to allow us to reacquire coordinates from a model we used Acquire Coordinates on before; now that it has changed and no longer lines up with our own work.

In the years since that post Revit seems to have decided it should remember more than one file has had the Acquire Coordinates tool used on it. Revit used to be monogamous but that's no longer true.

The reset process is still necessary but an extra step is required now: we must deliberately disable the link's Shared Site setting first.

Usually it is necessary to move the linked file to align with ours and so its new position can be reacquired. If the setting isn't disabled first it will trigger Revit's desire to change the Shared Coordinate system of the link. Keep in mind that Acquire Coordinates is a pull transaction but moving a file that is sharing coordinates causes Revit to think it must push that change out to the related file. If that's what is really needed then consider using Publish Coordinates instead.

Select the linked file and in the Properties Palette click the Shared Site button (by default says Internal unless someone has changed the name). In the Choose Site dialog that appears click the radio button for Do not share site of selected instance.

It should say <Not Shared> like in the image above after choosing that option. It should be possible to move the linked file into the desired position so it lines up with our model correctly again. If it works correctly you won't get a warning to save the changes to the link nor will you get prompted to do so when you save the file.

It is now possible to link a Reset File to use the Acquire Coordinates on. As soon as that is done successfully the original linked file can be used to Acquire Coordinates again, from it instead.

If the disabling step was not taken we'd find that Revit remembers it has a shared coordinate relationship with both files, the original link and the reset file. Examining properties for both linked files would reveal a Shared Site setting in play (Internal) for both.

However, Shared Coordinates and its Survey Point only acts according to the last file Acquire Coordinates was used on regardless how many files Revit is keeping track of. Trying to use Acquire Coordinates on either file in this condition will just generate this warning.

It's almost as if Revit is treating using Acquire Coordinates like a marriage and keeping a record of each marriage, regardless how many divorces the file goes through. I'd recommend it moves on, focus only on the active marriage and make that work.

To recap - if you find your shared coordinate relationship has failed you'll want a divorce. Then you'll fall for someone else quickly, on a rebound, only to discover that your previous love was the best. Just remember you need to get a lawyer involved to disable your first marriage before you start your rebound. This way you'll legally be able to get married again when you come to your senses.

Revit 2018 - GEO Reference and Shared Coordinates

I replied to a thread at RFO that asked about Revit 2018 touting support for AutoCAD's GEO Reference feature.

On the surface, there is no obvious difference between how things worked in 2017 (or older versions) compared with 2018. Over the years you may have noticed that the Location Dialog, the one that allows you use a map to locate your project did not do anything at all related to the Shared Coordinate system. All that action did was provide a way for Revit to; originally calculate sun position (and therefore shadows) more believably and more recently to allow for energy analysis estimation to be done.

Now...in Revit 2018, assuming the source DWG file is using AutoCAD's GEO Referencing feature, it is possible for Revit to inherit this data to affect not only the Location (Sun and Energy Analysis) but also the coordinate location of the project (Shared Coordinates).

The thread at RFO also asks about the 20 mile threshold Revit has regarding model size and warning us about model accuracy. The following is a restatement of things I've written in the past. Specifically they asked if there was any change to this in 2018. There isn't that I know of. I included the following to superficially explain the reason it exists.

The 20 mile threshold is a math and computer science problem that Revit developers choose not to lie to us about. They want us to keep the model as close to the file's mathematical origin as possible. External files (and internal modelling) that have data whose extents are larger than 20 miles begin to influence the accuracy of the calculations required to generate and display the model faithfully.

More often than not a civil file is not really larger than 20 miles. It just has elements that are farther away from the origin than that. Revit doesn't mind that issue and it doesn't mind assigning very large coordinates values to the shared coordinate origin (Survey Point).

It only cares when there are elements that are beyond the threshold. For example a file that only has two short line segments that are 30 miles apart will cause a warning. A file with an entire set of contour lines 40 miles away from the origin won't cause an error IF all the contours themselves and other annotation don't cause the extent of elements to also be larger than the 20 mile threshold. Distance from the origin is one aspect and the total extent (X,Y AND Z) of the elements in the file is the other.

Ultimately, the error appears because they want us to know that this external data could negatively affect the accuracy of what we work with inside Revit.

I wrote THIS POST to discuss how I deal with survey files that violate the threshold. It starts out with one issue (transparent elevations/sections) that occurs when the threshold is crossed.