The Void and the Revolve

 A tale of mystery set in ancient times...a fairytale of majestic proportions...

Sadly it's more mundane than that. This morning I noticed a distinctly Reviteristic situation while answering a client's question. To get a void to cut a revolve, their orientation to one another seems to matter.

If I create a revolve in the Front view of a Generic Face Based template and then create the extrusion in a side (Right/Left) view the void won't cut if the extrusion extends too far toward the other side of the revolve (seem image).

It took two voids on either side of the Axis of the Revolve to get a full cut of the revolve form (see image).

However if I create the revolve in the Right side view AND create the void extrusion in the same view one void is enough (see image).

Perhaps this is old news to some but it's definitely subtley quirky (which defines a Reviteristic for me). Next time you're taking a journey with a revolve and void...remember this? I'll try.

This was done using Revit 2020.2.4 BTW

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!

Controlling a Solid Form with a Visible Parameter

Here's a video trip back to a basic family editing concept. It describes two solids, a cube and sphere. I assign parameters to their Visible parameter and then show how we can use a formula to toggle one of them on/off and using Family Types to manage them. This works fine for solids, voids are another matter...and the subject of a later video.

Line Styles Embedded in Families

Reading a thread at AUGI tonight prompted this post. Line Styles aren't a thing in Revit families, the option is disabled if you attempt to review them while in the Family Editor UI.

The family discussed in the thread seems innocent enough until it is loaded into a project file. These are the line styles that are in the default template (imperial).

This is the same dialog after loading the family; nearly 100 more (98) line styles show up.

The culprit is Transfer Project Standards (TPS). It is easy to transfer line styles from a project to a family. We need Object Styles in families not Line Styles. Make sure you don't select Linestyles when/IF you use TPS.

If you've already got many rogue Line Styles you can delete them from the project and in Revit 2016 you can select more than one at a time and click Delete. Just remember if Delete is disabled then you've got a built-in (system) line style selected.

What about cleaning out the family itself? They don't give us a tool to do that. Purge Unused doesn't see them unfortunately. Robert Bell, in the AUGI Thread, offers a solution though. Load the bad family into a empty template (choose the None option for example). Delete all of the line styles you don't want. Then Save the family and overwrite the original. If the family is already loaded into your project just do the same thing, delete the line styles (it's just a little harder to tell) and Save the family to overwrite the original.

While you're at it, don't use TPS on Line Patterns, like shown in the image above. You'll probably get many more than you really want too. Those can be deleted a bit more easily though.

I checked the Autodesk Exchange Apps site to see if any offer a way to purge line styles from families. I found one that does it for projects but none that claim to do it for families; at least not based on searching for that criteria. It might be something Dynamo can be used to resolve; I'll have to check into that.

---------------------

Update 08/22/2016: Dale Bartlett has shared an app to purge these embedded line styles.
Update 05/09/2017: The file is no longer where Dale shared it, I don't know where it is now so I've removed the link.
Update 05/15/2017: Dale provided a new link to a 2017 compatible version VIA THIS URL.

Family Critique - Overhead Storage Bin

In a past post I was critical of how it was made and described what could be done to fix it. With that in mind, let's examine another family and see how very minor changes will improve the user experience.

First a little background noise, I've been participating in a program that Autodesk started called Revit Mentors. It is focused on people that are using the trial version of Revit, trying it on for size before buying. They been running the same thing for AutoCAD for much longer and recently decided to do the same for Revit. The mentoring takes place in the form of a chat window and this family was the subject of one such session.

The family in my sights today belongs to the Furniture System category and is called Overhead Storage Module.rfa (see image).

You can see two instances are highlighted in red in the above image. What's wrong with the family?

1. When we try to place the family Revit does not recognize its sides so it is difficult to place it accurately on the first try.
2. It also isn't visible during placement unless we have already assigned the Underlay parameter to the same level the view is associated with.
3. It remains invisible after placement and that means we have to resort to tricks to make it visible in the view too.

The reference planes are the cause of our first issue. They are assigned to an IsReference value of Weak. This means Revit doesn't pay attention to them during placement. They need to be Strong or one of the preset named IsReference settings. This is what they look like now.

In the image below we can see (no highlighting visible) that Revit doesn't acknowledge the edge of the family so it can't snap into the correct position easily. When I'm confronted with this issue I usually place such families wrong and then use Align to fix them. Then I copy them around instead of placing them. If I was really smart I'd edit the family and fix the problem.

This is what the family looks like after I've fixed the IsReference parameters. I've also named the Reference Planes using the same words.

Now placing the family is easy because Revit sees the Strong Reference Planes. The nice IsReference names like Front, Back, Left and Right are Strong too.

The second issue is that the geometry of the family is entirely above the cut-plane of the family and most project views. To fix this we can use the Old Invisible Line Trick. I've placed a Symbolic Line using the invisible lines linestyle. It spans from the Reference Level up to the top of the cabinet. I've locked the end points to the top and bottom references so it tracks with the cabinet if its parameters are changed later. It looks like this now. I've also named and assigned the IsReference parameters using Top and Bottom.

The third issue is resolved by editing the Masking Region that has been used in the family. I changed the front linestyle to Hidden Lines so that it will use that linestyle in the project too.

Now the cabinets are visible immediately and without worrying about using the view's Underlay parameter at all.

If I want to make it obvious that there is a difference between hidden items below and above then I'd use (and create if necessary) a different linestyle for each such situation. The Project templates that Autodesk provides have a linestyle called Overhead. I'd just need to add this to my family and assign it to the masking region boundary segment instead.

The presence of these subtle issues demonstrate to me that nobody really tries to use these families in a meaningful way when they are created. In this case the family is quite old. It has probably just been upgraded every year for at least a decade. There are a lot of existing families. It would be nice if someone was routinely taking a closer look at all this content. With our wishlist getting longer and louder every year I'm not going to hold my breath.

It is subtle stuff like this that helps make each user's experience just a little bit better!

Detail Item and Reference Plane Settings

The stock Revit family Nominal Cut Lumber-Section isn't built very well. Here's an example of it being used in a Drafting View. Notice the dimension style I've used shows a center-line symbol when it comes into contact with a so called center line, which is determined by the use of the IsReference settings; Center (Front/Back) and Center (Left/Right).

In the family editor, this explains why the center-line symbol is showing up. When this family was made they paid no attention to the IsReference setting for the reference planes. The Center (Left/Right) IsReference setting is assigned to what should be the Left reference plane. In fact the none of the other reference planes have appropriate names or IsReference settings either.

The symbolic lines that form the "X" in the detail item are assigned to Weak Reference and that means dimensions will see them as well as the Align tool. That doesn't make much sense either. There is nothing to allow us to dimension to the center of the lumber section either.

This is what it ought to look like, I've revised all the reference plane settings and added two new reference planes to permit adding a dimension to the actual center of the lumber.

By the way, the intersection of the Left and Front reference planes are assigned to the Defines Origin parameter so that corner is the origin of the family, which is the same as it was originally. After reloading the family into my Drafting View the center-line symbol and dimension witness line references have shifted over to properly identify the center-line of the lumber section instead. They did that automatically because of the new reference planes using the correct IsReference values. The first dimension on the left is no longer showing the center-line symbol because it is still referencing the side of the lumber section. It shifted over too but I reassigned it to the side of the lumber section.

I also changed the "X" Symbolic Lines to use a IsReference setting of Not a Reference and now Revit won't see them when I use the dimension or align tools. In the following image my cursor is hovering over them but Revit only sees the Center (Left/Right) reference plane.

I wish I could tell you that this is the only one like this...

Perhaps this is just one more reason to attend the Building Content Summit just before RTC in DC this July?

Type Catalog - Just say NO to Load Into Project

If you are working on a family that uses a type catalog then these two buttons are bad!

Bad buttons!

Youz buttons are buttons non grata.

The same is true for the Edit Family button and right-click Edit Family option. Don't use them on families that use a Type Catalog because all the types that are in use get loaded into the version of the family that opens in the Family Editor. That's kind of counter productive.

Optional Instance Override Example Two

My post last Saturday reminded Daniel Stine of a situation where he used a similar technique.

Dan writes:

In an Electrical Equipment schedule, we want the Room/Space number to be listed automatically. However some items are not located within a room. So we use a Yes/No parameter (in the family) and a calculated value (in the schedule) to switch from automatic to manual. In the example below, the rooftop equipment is not within a room and would produce a blank cell if the schedule column just listed Space:Number. With the toggle, we can type in a custom value; a word in this case.

These are the two manual parameters associated with the content:

Calculated value in Electrical Equipment schedule:
if(Enter Manual Room Number Name, Manual Room Number Name, Space: Number)

The follow parameters need to be added to the schedule, but hidden:
Space: Number
Enter Manual Room Number Name
Manual Room Number Name

Thanks Daniel!

Optional Instance Override

Twice in one week I've seen people asking about using a Type Parameter for a door swing and wishing they could occasionally override it without making a new type for the door. That jogged my memory a bit and I remembered that Aaron Maller had told me about a technique he's used on the content he has built for Beck Group. It's quite clever, thanks Aaron!

These are the parameters you need (parameter names are italic - pick better names if you want):

• Type parameter (Angle: Swing - this the standard angle you want to use)
• Instance parameter (Angle: Swing Override - this is the default value for the override)
• Instance or type parameter (Yes/No: Override Swing - this is the switch to flip)
• Instance parameter (Angle: Swing Applied - Formula: if (yes, instance, type)

It looks like this in the Family Types dialog.

This is what it looks like applied to two door types; two are set according to their type and the other two are overridden to different angles.

This is what it looks like in the Properties Palette when a door is selected. Check the option and change the value or leave the default value.

Yes! You can have your Type and Instance too!

Family Orientation

It is quite common to find the orientation of families confusing, both when we make them and when we attempt to place them in a project. What we consider front, back, left and right doesn't seem to follow consistent logic. Okay, there is some consistency it just seems opposite of what we might expect. What do most of us expect? Speaking for myself at least; Front is the bottom of a plan view, Back is the top of a plan view, Right and Left are the right and left sides of the plan view.

If we examine every family and family template in the stock content we'll find that Front IS at the bottom of every plan view in all of them. The View Cube also matches that convention. The thing that confuses us is that a portion of the stock content has been modelled in the reverse. That which we think of being the front of the object being modelled is the back. Even in those families however, upon closer inspection, we will find that the reference planes are oriented correctly (if they are named at all), the geometry orientation is wrong. The direction the geometry is facing is wrong.

If we consider a chair family most if not all of them are modelled with their front toward the top of the view (which is Back). If we compare that with a desk we'll find that it is modelled with the drawers (can we agree that they'd be the front?) toward the top of the view. These two families oriented this way don't allow the user to place a desk, horizontally for example, and then a chair horizontally so that they are oriented correctly with respect to one another. In the case of this desk there is no visible clue to know which way the desk is facing during placement. We'd be rich if we got a dollar every time we noticed the desk was backward when we open an elevation view later.

Looking at the View Cube the chair looks wrong, but only if we happen to agree the front of the chair is the side our legs are on. In the context of being placed next to a table or desk it means that the chair is facing the wrong side of the desk or vice versa. They had to pick an orientation but in the case of a desk that has drawers they picked wrong. Other work surfaces and tables might not matter nearly as much. It would make more sense to me if the desk were modelled with the drawers facing front, the bottom of the plan view. This would allow us to place a desk and chair and their orientation would make sense regarding each other.

Another apparent mismatch of orientation logic is base cabinet and wall/upper cabinet casework. Base cabinets are modelled with front facing the bottom of the plan view but the wall hosted upper cabinets are facing the back, the top of the plan view, opposite of base cabinets. Placing them in a project however defies the apparent orientation mismatch because the origin of the base cabinet is at the back and it is for the upper cabinet too. This means they orient logically when used together despite being modelled facing different directions in the family editor.

Also contributing to confusion is that the original content for doors and windows all assume that their Exterior side (and Placement Side) is what Revit considers the back side of the family. I've always thought of the exterior side as the Front of a door or window, the side that faces people as they approach the house. A door was the very first family I made with Revit. Afterward I believed that Front was the top of a plan view in the family editor. At least until I encountered enough other families to realize I was wrong.

To appear more consistent, while working in the Family Editor, Autodesk would need to revise most if not all of their hosted content (and others) so that the geometry orientation respects the bottom of a view being the Front view. The placement logic it uses must compensate for the placement side orientation of the geometry not being consistent with the notion of Front. If they revised the orientation of content to please Family Editors then they'd have to be careful to also revise the placement side logic.

Setting Yes No Parameters with Formulas

Peter boards a train in Philadelphia bound for NY. Joe boards a train in NY bound for Philadelphia. If both trains... oh I don't care when their trains pass one another. Next question?

I want Revit to automatically check a Yes/No parameter but only when two other parameters are checked already. I read a post at RFO asking how to accomplish this. That member's issue was Revit complaining about inconsistent units, as it does. I replied that Revit doesn't accept 1 or 0 as a valid true/false value. The formula was written like this for parameter C:

if (and (A,B), 1, 0)

Since Revit doesn't like the 1 or 0 used in that formula we can use this instead:

and(A,B)

Revit reads that as, "I (Revit) can only check C if both A and B are checked too". In the Family Types dialog it looks like this.

If I'd like the opposite to happen it looks like this instead:

not(and(A,B))

Revit now reads it as, "I (Revit) can only un-check C if A and B are both checked too." In the Family Types dialog it looks like this.

Greg replied (in the RFO thread) that the formula would accept valid math statements for the true or false result. That means that the formula could be written like this, using the original formula above.

if (and (A,B), 1=1, 0=1)

It looks like this in the Family Types Dialog.

Either approach provides the same end result. Programmers often compete to write the leanest code, complete a task or tasks with the fewest instructions, fewest lines of code. My formula is leaner code but not by much. Regardless, I think it does help to see different solutions to help us solve the problems we encounter later.

Visible Parameter and Associate Family Parameter

When we work with Forms, Symbolic and Model lines and nested families they each have a parameter called Visible and we can use Associate Family Parameter to control their visibility.

If you decide to remove this relationship Revit applies the current state of the parameter that was controlling it to the Visible parameter. If it was checked (visible on) then removing the parameter relationship leaves it checked. If the reverse is true (visible off) then the opposite happens.

It's subtle and can cause a few minutes of confusion when you reload a family and find it isn't visible.

Stage Curtains

Back in January of 2004, about eleven months before I started blogging and a couple months before moving to California, I shared a couple stage curtain families at AUGI. They were made using Revit 6.0. I recently got a message thanking me for them which made me curious how well they'd upgrade to Revit 2015. I downloaded them from AUGI too since I'd lost track of the files since then. They upgraded fine. Well, without a warning message but they didn't retain all their parametric behavior unfortunately.

If you're like me, you can't help but second guess the things you did when you get to take another look at something you did in the past. This is no different. I didn't like my choice of parameter names and the logic I used to allow for them to be reconfigured. So I spent some time re-working them in Revit 2015.

Here's what they look like in play now, the main setting is a burgundy color, the olio setting is a lighter shade and the cyclorama legs, borders and rear traveler are just black (though they look gray). If you aren't familiar with theater terminology, the olio setting is traditionally fancy or at least a different color. It is typically used (closed in front of the stage set) as the background for the opening act of a show, comedian, magician etc., far enough forward to leave most of the stage for the primary production (hidden from view), close behind the main curtain setting but leaving some stage space for the intro act.

And in plan view

And in Section

If you'd like to download them here you go:

2015 Stage Curtain Border
2015 Stage Curtain Traveler

If you need them in an earlier version than 2015 these are the Revit 6.0 files. You'll probably have to tweak them a bit to retain their parametric relationships, such as changing the height of the curtain or length of the batten etc.

Revit 6.0 Border Curtain
Revit 6.0 Traveler Curtain

I'll close with a rendered view using some stage lighting fixtures that Andrew K shared at RevitForum.org (works with ARCAT) and a couple saxophones that Michael Anonuevo shared with me back when he was working on his family editor book.

I did consider rebuilding these using the new Adaptive Point divide and repeat concept. Perhaps another day. It would be interesting to compare the performance of that technique against these. These do put a bit of a drag on a model because of the blend array that makes the curtain.

Okay, now I'm just having fun...

Revit 2015 R2 - Load into Project and Close

Have you ever edited a Revit family and then used Load into Project? Only once or twice? Yeah you're like me then. Have you ever thought it would be nice if you could close the family without having to return to it or having to close it first and then use Load from Library > Load Family? Yeah, me too.

Apparently we've got someone from Autodesk listening in on our thoughts (or blog posts/tweets/wishlists/support requests) because Revit 2015 R2 thinks we are on to something and it has a new button called Load into Project and Close

Just keep in mind that you DON'T want to use this when your family is using a Type Catalog! If that's true you also DO NOT want to use the Edit Family feature from a project either. Using Edit Family creates a version of the family that includes all the types that are loaded into the project. The same is true when you use the Right-Click > Save As feature on a family from inside a project. If a family is using a Type Catalog then the family doesn't need the burden of all its types defined inside it too.

Sheet View in a Titleblock Family

Brian wrote to mention a quirky subtle situation that he thought I'd be inclined to write about.

Brian wrote:

Open a Titleblock family and then double click on the schedule in the project browser to open it in a separate view. With the schedule as the current view, close all the other active views. Notice that the view with the titlebock itself closes and now there’s no way to open it again, since it’s not listed in the Project Browser.

The subtle bit is that the view is still there in the project browser, it's just hiding under Sheets instead of Views where we'd expect to find it. It's that even more subtle dash listed beneath Sheets.

Yep, it's quirky enough for me.

Where are the Constraining Dimensions

When you edit a family that someone else created you may encounter a situation where the constraints that control it aren't readily visible. Yeah, it could even happen to you with content you created. These are a few things to consider when you start hunting for them.

Inside the Sketch - It is possible to add dimensions and parameters to control solids/voids while editing their sketch. If that's been done you won't see them unless you edit the sketch for that solid/void.

Associate Family Parameter - The little sneaky gray button (that has a tool tip since 2014) allows us to constrain some things without an actual dimension in canvas. We just connect the dots between the parameter of the form with a parameter.

Automatic Sketch Dimensions - These kick in when you start creating parameters and elements without tying them to anything specific. Revit guesses what you have in mind. They'll usually only be visible while you are editing a solid/void. They are definitely off by default in Visibility/Graphics. You'll find them under the Annotation Categories tab. I've written about these in the past.

Choice of View - Sometimes the dimension isn't in a view that we'd expect it to be in. For example the stock door template has the width parameter in an elevation view instead of the plan view. I certainly wouldn't expect to find it there. I try hard to put X/Y oriented dimensions in plan views and Z oriented dimensions in elevations, usually Front but occasionally Right.

Visibility/Graphics - Sometimes dimensions are just turned off in the family's views.

2014 Revit OpEd

Fun Formulas

Saw this via Twitter. Kirklyn provided an example of practical formulas with Revit. You may not need Revit to make this kind of decision for you but the logic can be applied to other decision making. Do you want a sandwich?

Finding and Loading Content

Dan Stine wrote the other day,more sharing somewhat related to your post…

Finding content: staff often call me asking if we have a “this” or a “that” family. I do a quick search at the highest reasonable folder level in Windows Explorer. Of course, I tell them how I found the content so they can do it themselves next time.

Windows-based previews: Windows Explorer and “File Open” dialogs (see images below) we can Ctrl+Scroll to increase the preview size. [this does not negate the need to clean saved previews as you mention]. Here are some examples.