Managing RVT Link Visibility

 I stole this idea from Autodesk Revit Forum member de_smith, sharing it here now. 😀

Another member asked: We have multiple view templates set up for various types of plan views, so when a change needs to be made to the visibility of a linked model, that change must be carried over multiple times, for each view template. It easily becomes hard to track that the visibility is consistent everywhere. 

Is there a way that the linked model visibility settings can be applied independently of view templates, so that when modified, they can carry across the entire project?

de_smith replied with (some editing on my part): 

Control linked models with their own view template then layer the regular view's template back over it. 

Create a "REVIT LINK CLEAN UP VIEW"  view template (for each unique link)

• in the view template dialog box untick the 'include' column for everything except V/G Overrides RVT Links
• in this template do all your required visibility modifications to the revit link
• in all your other view templates under the 'include' column untick V/G Override RVT Links

Apply the 'REVIT LINKS CLEAN UP VIEW' to all your views in your project browser at once

• then go back and apply the other view templates to the views.
• This holds the info from the Revit Links Clean up view

If there are any changes needed to the linked models, make the changes once, in the Revit Link's view template, apply it to all views at once and then reapply your other view templates. This is much quicker than changing the Revit links in every single view template.

I've done similar for Imported Categories (DWG links) and try hard not to override RVT links but this should work nicely when it's absolutely necessary.

Dept of Subtle - Select Everything in a Property's Field

Sharing this because someone observed me selecting a parameter value and was curious about how I selected everything. If they didn't know...maybe you don't either?

When you just click in a parameter field in the Properties Palette or Type Properties dialog the cursor will usually land where you click. You can use Home or End keys to move the cursor to beginning or end of the entry. You can also use the CTRL + A button to select everything in the field.

If you want to select all of (with the cursor) what is entered, in order to replace it entirely, this is very subtle...

When you move your cursor over the field, as you click...drag the cursor arrow down (or up) away from or out of the field. Done correctly it will select everything in the field. Once familiar with the motion it is quite easy to do.

Originally I realized that clicking in a field past the end of the entry (in empty space) would select everything. That was useful to me but the width of the field is usually not wide enough to do that every time. Yet, every now and then when I clicked in a field I'd select everything. Eventually I took time to notice why it was happening. Happy selecting?!

Slanted Walls Don't Miter

What if I'm asked to create a vertical bottom wall that will transition into a slanted upper wall? Initially the wall configuration looks like the walls on the left in the following image. I added another vertical wall at the top of the slanted portion just for fun.

Each wall doesn't know anything about the other so there is no attempt by Revit to miter them together. We might have expected them to join? If we consider what happens in plan views for a similar layout (see image) I don't think it's unreasonable to think that might have happened. If an automatic join occurs in plan views maybe using Join will work in a section? No. Wall Join tool? No. Attach? YES!

To resolve the clumsy look of the left walls and end up with those on the right side of the image we can take advantage of the Attach tool. We just need to add reference planes to define where the miter joint should occur. Then Attach - Top will fix the bottom wall and Attach - Base will fix the upper wall. Repeat as required until all walls relate to each other better.

Sanitary Pipe Calculations and Venting

I wrote THIS POST years back regarding adding vent pipe to a sanitary system of pipe and fixtures. I'm happy to write that it's simpler now than then.

Just use an endcap family (made to look more like a vent cap) the vent pipe at the top and your fixture count should propagate all the way to the building connection as expected. That of course assumes you don't have open connections somewhere else along the way. The example above shows vent pipe using a separate type and a view Filter based on Type Name.

Use the Show Connections feature to identify them if any exist. I won't be shocked if you find some.

Entering Values using the Project Base Point

A recent message asked how they can enter values into the Project Base Point (PBP) like we used to be able to do when the PBP had a clipped/not clipped status.

The answer is Specify Coordinates at Point (SCaP).

They wanted to enter 8,000,000/8,000,000 as their example. R2021 won't accept that value but R2019 would.

In the past, when we selected the PBP, entered coordinate values, it actually shifted the Survey Coordinate System (SCS) away from the Origin/PBP. It was easy to assume we moved the PBP because it is easy to overlook the information that displays above the selected PBP. It says PBP but right underneath (see image) it says Shared Site: and the coordinates it displays are relative to the SCS.

Entering values in the PBP directly (in the past) is same as using SCaP (now). The Survey Point will move to mark the 0,0 origin of the SCS after we enter our values. The PBP will still be at the Internal Origin (IO). The following image is 2019 and 2021 showing the same end result, just using a different tool.

Entering values directly into the PBP now will move it away from the IO, something it did not do in the past. This invokes a Local Coordinate System (LCS) that uses the PBP as its origin. Spot Coordinate/Elevation annotation can reference this LCS. This why Revit won't let us move the PBP too far (10 miles) from the IO.

I think Autodesk should change the PBP reference to the Shared Site since it is confusing. I think the PBP should show reference coordinates back to the Internal Origin. There is probably some room for disagreement though, which is why it probably still references the SCS.

This change seems to annoy people the most because we can't just enter values into the PBP directly and get the "old" result. We can enter values but not to alter the SCS, which is what really happens with the clipped PBP of old. The unclipped status of old is when the LCS is invoked.

The PBP only moves in an unclipped state now, thus no clip.

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.