Reference Planes without Names

It is a common practice to add a name to the reference planes we create. If it isn't common where you work then it ought to be. The name helps give a hint to anyone that works in the model that this reference plane is more important than those without a name. It can also help understand what it is for, why it was made.

There are some who make the effort to clear out reference planes that are not named periodically, just another of any number of model/housekeeping chores. I've even seen Dynamo scripts intended for this task.

If you're using Ideate's Explorer you'll find it easy to see a summary of all the reference planes in the model. In the following image I've created two reference planes, one with a name and another without a name.

Notice that there are five (5) reference planes listed though. As it happens, when the Edit Profile concept is used on a wall four reference planes are created and internally applied against the sketch of the wall. They are only visible to us while editing the wall's profile sketch. We can't see these reference planes in the regular user interface, it only becomes very apparent with their Explorer tool.

It is also possible for us to create reference planes while creating any sketch based element, like a floor or stair for example. These reference planes are only visible to us while editing their related sketch.

The reference planes associated with a wall's edited profile can't be deleted via IDEATE Explorer. It can delete them when we've created our own within a wall's profile and other sketch based elements.

Attempting to clean up these unnamed reference planes might also be an issue if you're writing your own code or Dynamo script to delete them. We can/could add names to these internal reference planes (wall profile) but I don't think that's a task that worth the effort.

Something to keep in mind.

Revit 2017 - Filters and Reference Planes

Filters have been expanded to see Reference Planes.

You're probably aware that Reference Planes don't have many parameters, just these three instance parameters: Scope Box, Name and Subcategory. They don't have any Type Parameters because they aren't defined by types like grids or levels for example. If we examine the Filters dialog and see how those three parameters play out as criteria we'll find they don't.

The More Parameters... or Browse button to its right are tempting but we still can't create parameters associated with Reference Planes.

This makes it rather difficult to actually use a Filter for Reference Planes, criteria based filters anyway. We can select them (Reference Planes) first and create a Filter based on selection but that's not really much different than using Visibility/Graphics to turn them off or override their appearance.

While it makes for an enticing item in the list of what's new it will only serve to frustrate you if you pursue it. It's a shame that we aren't offered at least the Name parameter to use in a filter. It looks like the critical path for this feature wandered into the weeds and got stuck in some quicksand.

I'm sure we'll take good advantage of being able to differentiate them from one another and control their visibility using Visibilty/Graphics and View Templates despite this situation.

Family Templates and Reference Plane Inequity

This is subtle but still a source of amusement or annoyance. Start a new family using the Generic Model template and try to copy an existing Reference Plane. Nope, the Copy tool is disabled.

Now try it with the Furniture template. Ah, Copy is enabled.

Try it in the Casework family template. You'll find Right, Left and Front Reference Planes are forbidden while the Center (Left/Right) and Back Reference Planes are not. That makes sense. Wait, what?

Okay, the rule is copying a Reference Plane working on furniture is okay and doing that in Generic Model templates = BAD? Doing it in the Casework template is, well it depends...

Actually the only rule is that you can expect some reference planes in some templates to be forbidden to copy while others are not affected by such thinking. Ralph Waldo Emerson cautioned us to avoid a foolish consistency. In this case a little more consistency wouldn't be bad.

...I'm not asking for all of them to be forbidden either...if you're wondering.

Revit 2017 - Reference Plane Subcategories

As I shared in the What's New post the other day, we can create our own Reference Plane subcategories; in both projects AND Families.

It is my opinion that Families should NOT bring Object Style subcategories for Reference Planes into Projects when they are loaded.

I realize that this is carry on baggage because Object Styles are loaded from a family into a project, that's how it works. However, it would be much better if something we can't even see or actually use in the context of the project doesn't get added to its database.

If people really like this enhancement and start using in all of their content then it could get really messy. The only people that won't incur the wrath of this are those that manage their content library aggressively. I really hope we don't end up with this...

I sure hope this is something the folks at the Building Content Summit will consider discussing to get out in front of it some.

Reference Plane Wishes

Three wishes have I, wishes three... (for now)

• Reference Plane Types (control over how they appear and can be used)
• Split Tool works on them
• Trim tool works on them

Okay four...

• Filters can be used on them (for similar reasons to types)

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?

Temporary Dimension Size and Reference Plane Names

The name that appears on a selected Reference Plane is based on its name parameter. If you find their names a bit small to read we can take advantage of the Temporary Dimensions Text Appearance setting to increase it. This is what it looks like at 8 point text.

This is what it looks like at 14 point text.

Ah, more betterer...

Curtain Wall Panel Template - Reporting Parameter Error

If we attempt to attached a Reporting Parameter to a Curtain Panel Template we might see this error message.

It's the result of attaching the dimension to the reference level in the view.

If we are careful to attach the dimension to the reference plane that is lurking underneath it (the reference level) the reporting parameter will attach without complaint. I pulled the Level and the reference plane apart a bit so they can be seen more easily in the image.

Web Update 7 Killed Grid Level and Ref Plane Alignment

I was wrong, the update is innocent, sorry. The culprit is Snap to Remote Objects which was off.

Uh oh, I installed the recent Web Update 7 and now grids, levels and reference planes don't see each other like they used to. Existing grids and levels work normally. It seems to affect new elements when you attempt to place them in alignment with others. For example, try to sketch new parallel grids. Normally we see a green dashed graphic that indicates alignment with an adjacent grid end. I don't see this anymore. I also don't get the locked relationship between grids. Same for new levels.

If you copy them they'll recognize their alignment and behave normally unless you unlock that and alter them individually. Then they'll forget they can see (should see) each other. We can get around it, with grids for example, until they patch it by sketching a reference plane across the grid ends and dragging them so they touch the reference plane. The grids will start to behave normally as long as we don't separate them again.

Well at least a couple replies suggest I'm crazy but here's what's happening to me.

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.

Light Fixture Grid Positioning and Wires

I've seen some lighting content that has been modified to make it easier to align with acoustical ceiling tile grid patterns. For example this stock family is the Downlight-Recessed Can.rfa with some reference planes added so we can snap to the grid during placement, or use the Align tool easily afterward.

I didn't bother to assign any parameters to control them. I can use them to fit the fixture in a 2x2 grid or use the Align tool later to position it in the middle of a 2x4 grid. It might not be obvious but I can use one reference in a family to move the family over by selecting another part of the family as my second pick. This means it is easy to just set the reference planes at a fixed position and use the family's own references to move it over if necessary. It just means I don't have to have parameters to decide if the fixture is meant for a 2x2 or 2x4 grid. All this is seems good at first except when it comes time to add wiring to the fixtures.

These helpful reference planes end up affecting where the wire's graphical ends terminate. The fixtures are connected to their wire but they just stop at the extents defined by the reference planes. Not fun when you have to adjust a lot of wires to get closer to the fixture. This means Reference Planes aren't ideal for this task. This is what the family looks like if I use Reference LINES instead.

I've held the same attitude toward adding dimensions in this example too, with much better results as well! We can set the reference lines to Strong (IsReference) and uncheck the Visible parameter. They won't be visible when you select the family but the Align tool will "see" them and Revit will highlight the ceiling grid pattern when you place the fixture too. Fwiw, if you leave it checked they still won't be visible when you select the family.

Fwiw, Model and Symbolic Lines that are Strong References and assigned to Invisible Lines provide the same result. You can uncheck the Visible parameter so they aren't visible when you select the family.

(This is based on working in 2014, it does not work in 2012 or 2013. Nothing seems to resolve it in those versions)

Naming a Reference Plane

I read recently that just adding a name to a reference plane would cause it to be "strong". The notion of Strong, Weak and Not a Reference are related to the IsReference parameter, which I've written about before. It's my observation that adding a name to a reference plane has no impact on it's behavior in a project. To test my belief I created a small family with a collection of reference planes with various combinations of Name and IsReference parameter values.

The reference plane on the far right is set to Not a Reference and has the Name No 3. Its the only one that is invisible in the project environment. The two on the far left have IsReference values (Weak and Strong) but have no Name either, they still are detectable in the project. I sketched dashed lines from the detectable ends of the reference planes. The dashed line on the far right is sketched where the reference plane should be but I couldn't snap to the end because it isn't detectable there. I also added a dimension string across each detectable reference plane.

I think my beliefs are intact, just adding a name to a reference plane does not alter its IsReference conduct in a project. When we create a new reference plane Revit assigns Weak Reference to its IsReference parameter. If we copy a reference plane, those that Revit lets us copy, it also assign Weak Reference to the copy.

Window or Door Frame Positioning

We quite often want to be able to move a window or door assembly back and forth within a host wall. This is easy to do as long as the assembly is moving "in" but doesn't need to move beyond the host in the opposite direction. A relationship between reference planes does not generally like to be reversed. We usually get yelled at with a message like this.

When we want the flexibility to move something from or toward something else we need to define an alternate reference point, reference plane in this case. If we place a reference plane in front of the exterior side of the host we can set it far enough away to provide enough room to move the assembly without generating an error message.

In the image above I can move the Frame Offset reference plane "outside" the exterior face of the wall by using a negative dimension value and toward the Interior by using positive values. The fixed dimension value of 12 inches defines the reference offset value I used in the formula column. This means when I enter zero for Frame Offset that the assembly will be flush with the exterior of the wall. Here's what it looks like using a negative 8" offset to move it outside, from the exterior face.

There are firms that use multiple walls to define the layers of what many people use one wall with layers for. When you place walls next to each other a door or window family is hosted by one of them. If you need to move the family "forward or backward" you need to be able to change the notion of what host reference plane is relevant. This is one approach to solving the problem.

Is it Too Late to Change

Whenever I spend time in the Revit Family Editor I run into past decisions. Sometime they are my own and quite often they belong to somebody else. I've always encouraged people to develop good habits when it comes to using and defining reference planes. I've even been teased about wasting time in a demonstration by naming each reference plane even though doing so wasn't pertinent to the topic. Habits...

I recently encountered a bunch of families that were built by a few people for their project. I was asked to make some changes so a part of the family could be scheduled separately. That meant making use of the concept of making a family "shared". A family that is nested into another is only treated as a symbol when we see it a project. A family that is nested AND Shared is loaded into the project as an actual separate family (appears in the project browser) as well as being visible as part of the host family. This special condition allows for scheduling nested parts as though they are unique parts, apart from the host, as well as permitting us to place them separately. This subject could easily be few separate posts.

While I was digging in I noticed that few if any of the reference planes were named. I also noticed that most of them did not redefine the original reference planes so that they made sense in the context of the family itself. By that I mean that people will use the default Center (Front/Back) or Center (Left/Right) reference planes as a "left" or "right" or "front" or "back" or something...but not rename/redefine them as such. That means that when we examine a family the "center" (the reference plane that Revit thinks is center) of the family is really an edge or side. Autodesk's own content isn't immune to this either.

In this situation I thought like a mechanic, if I've already dropped the transmission I might as well fix some things that I can't get to otherwise, or "while I'm in here"...

Sadly if a project is using this content and people have done things like put hundreds, perhaps thousands, of them in their models, bad things can happen, when they are reloaded. As Mr. Maller says... it can be a "screwtastrophe". Families that have dimensions referencing them in the project will generate the dreaded "dimensions must be deleted" messages as soon as you reload them. Specifically if you change the IsReference status of a reference plane and reload the family Revit can't find the original reference plane anymore. Worse a family might shift its location, particularly if being swapped out for a different version.

I don't think it can be overstated or stressed enough, content needs to be created carefully and good habits need to developed and observed. It may not be too late to make changes but it can be painful.

Reference Plane Order

This is subtle. When you draw reference planes the order they were created plays a role in how a parameter will move them later. Draw two new vertical parallel reference planes, draw one on the left and then next to the right of the first. Add a dimensions and assign a label (parameter) to the dimensions. Flex the parameter value and watch the reference plane on the right move. If you have a lot of reference planes it can get confusing but this underlying behavior is lurking there.

You can force certain behavior by pinning reference planes, locking dimension or using the EQ constraint to force them to move equally about a center reference line. Like I wrote, it is subtle. Just keep it in mind while you do your family editing.

Two Minutes with Constraint Quirkiness

Okay it's a little more than two minutes but less than three. I've been running into a few things lately that I don't recall being an issue in the past. Then again maybe my memory isn't what I thought it was? Take a look at this image. Seems pretty straightforward.

I've got a pair of Reference Planes that I want to keep positioned on either side of a rail (as in stiles and rails for a door). In the past I could do what you see and then use the dimensions on the right to shift the collection of reference planes up or down a bit. Now I find that I can't unless I select all three together. In the past I just grab the one in the middle and use the referencing dimension to shift it up/down. Doing that now gives me some weird results. It's probably better and easier to explain it with a video so here's one at You Tube.

Invalid References

Ever see this message?

There are a number of reasons why it occurs. This is one example that can occur when swapping families. Not all families are created equal. Shocker I know...sorry. When you swap one family for another after applying dimensions you run the risk of confusing the dimensions. Let's take this simple family, GM01.rfa.

The Right and Left reference planes have corresponding names and IsReference settings. Now lets look at GM02.rfa

In this family I've made a mistake (on purpose of course), the Right reference plane has a different IsReference setting, it is set to Weak Reference. Technically the family is also a little bit wider than GM01, but that won't matter. If I've added dimensions that reference this family, as soon as I try to swap GM01 for GM02 I get the message I mentioned at the beginning.

The essence of the warning is that something has changed in a way that Revit can't transfer the dimension reference to the new object. The tricky part is figuring out what that "something" is. Sometimes it is how the family is made.

[Edit: Btw, I wrote, and scheduled this to post ahead of time, in response to an question via email and a last night I read a post at RevitForum.org that asks why almost the same thing is happening. Serendipity.]

Reference Planes Summary Post

Similar to the previous summary posts for Worksets and Shared Coordinates I've grabbed a number of past posts that have Reference Planes in common. I've put a link to each of them on the side bar.

Updated: August 9, 2013

Some of these might slip away from relevance but they do involve them.

2012 Small Collection of Family Editor Advice
2009 Family Editor - Bones, Muscle and Skin
2008 Door Templates

2012 Reference Planes and Wall Closure
2012 Reference Plane IsReference Parameter
2012 Grips Location Reference Planes vs Line
2010 Dept. of Subtle - Reference Plane
2013 Reference Plane Order

2006 Once Upon a Reference Plane
2011 Move Tool is Insensitive
2005 Family Origins
2005 Is You Is or Is You Ain't (IsReference feature)
2012 Invalid References for Dimensions

2006 Automatic Sketch Dimensions
2006 Once Upon a Workplane - Seeing is Believing
2010 IsReference Setting - Weak and Strong
2009 Grips in Families
2010 Flip Arrows and Exterior
2006 Face Off

2009 Air Terminal Doesn't See Grid
2008 Revit MEP - Air Terminal Troubleshooting
2008 Connectors and Their Arrows

2008 Standards - Everybody's Got Standards
2013 Is it Too Late to Change
2013 Naming a Reference Plane

Reference Plane IsReference Parameter

This post reiterates concepts I wrote about many years ago, regarding the IsReference parameter assigned to Reference Planes. The last post was titled "Is you Is or Is You Ain't", paying homage to Louis Jordan's tune.

IsReference settings break down like this:

Not a Reference - ignored by Revit in the project environment, still useful in a family to create "the bones".

Weak Reference - Seen in Project by dimensions, align tool, Revit ignores Weak References to display temporary dimensions, favoring only Strong References for those.

Strong Reference - Seen in project by dimensions, align tool and Revit sees these first. (the black lines you see during dimensioning or using the align tool are the weak and strong references in action). Temporary dimensions only see these.

The nice IsReference names like Right, Left, Top, Bottom are all Strong IsReference choices. A reference plane should be named so it is clear why it was created, to you and anyone else later. Programmers comment their code, as much to help them remember why they did what they did as well as what the code is supposed to do. Same concept for these reference planes properties.

The names don't have to match but if the nice names do match what you think they should be, then great. If your families are meant to be interchangeable for other families, like from the stock library you should examine them to see how they are done. I've seen doors that were built opposite when compared with stock Revit doors and when users swap a stock door for theirs, the door panel flips over...ouch.

When Weak and Strong references are combined with instance parameters you see grips in the project environment. You can drag the grip to alter the family dynamically. If you use the Align tool on a weak reference the family "moves" toward the alignment edge. If you use the Align tool on a Strong reference the family "stretches" instead.

Last, these help Revit maintain orientation and two intersecting reference planes can define the X/Y origin. One reference plane in elevation can define a vertical origin. Theoretically a reversal of Right and Left reference planes in two different families would flip their orientation if exchanged for one another. Haven't tried that in a really long time so I don't know for sure that condition still exists.

Not finished apparently. Alex quite rightly reminded me in a comment that I forgot a goody! So he wrote:

"Another advantage of naming your reference planes using the preset Named Planes is that in a project, it will allow you to pick on the dimension grip and bounce between the Left, Right, and Centre options and ditto (depending on orientation) for Front and Rear, Top and Bottom."