Showing posts with label Family. Show all posts
Showing posts with label Family. Show all posts

Thursday, May 21, 2020

Revit 2021 - W Shapes-Column Family is Missing

The stock imperial architecture template has the W Shapes-Column family loaded with two types: W10X33 and W10X49. I was experimenting with new features and noticed the family isn't part of the 2021 content deployment, weird. I had to reload from the 2020 version to add a size.


If it's not one thing it's another.

Monday, March 09, 2020

Parameter is Missing for Some Types

From a thread at RFO, Aaron explains what's gone wrong...

Aaron wrote:
"If someone deletes a family that is also the default option for a Family Type, with that Shared Parameter: Yes, the entire parameter gets deleted. It's terrible behavior, and its been that way for years.

In case I wasnt clear: This is a known issue, and it's easily reproducible.
  1. Take any Family that uses a Shared Family Type Parameter, that has a default value.
  2. Find the family in the project browser, that is the Family and Type that's in the default value.
  3. Delete that family from the Project Browser.
  4. After you've clicked *DELETE* in the warning, go back to the original Family (the parent family with the parameter).
  5. For JUST the types that had that default value set, that parameter is now gone.
And yes, the instances in your project are hella broken, now."

Saturday, November 30, 2019

Work Plane Based Families and Rotate w Copy

I participated in a thread at Autodesk's Revit forum and it took me far too long to catch on to the issue described at the outset. I should have retraced the thread sooner, but I did get there eventually.

I'm referring to the Rotate tool and its Copy option, this...


The issue boils down to this: the Rotate with Copy option works/affects a Work Plane-Based (and face-based) family differently than when a family is merely hosted by a Level (all non "based" families). Let's start here, imagine I want two screens on my desk like this.


These are stock families: TV - Flat Screen.rfa and Desk.rfa The desk has a top surface that isn't visible in plan view so it can't act as a face to host the TV. I changed that. The TV isn't a work plane-based family. In a plan view, when I place it on the desk it ends up eaten by the desk because it looks like this in a 3D view.


Sure, I can use its Elevation from Level parameter to put it on the desk (an illusion of a relationship). When I move the desk I need to remember to select the TV too (or make a group...or...I digress). I get the clever idea, "Make this family Work Plane-Based, that's easy!"


Using Rotate with Copy should give me the result I want in the first image and it does until I check the box for Work Plane-Based. The angle I decide I want between the screens is 22.5 degrees. I added a couple reference planes for the images to help see what happens, the desired result.


That's what I want except that they should be hosted by the desk, not relying on using the Elevation from Level parameter. When I use Rotate with the Copy option after editing the TV family to make it Work Plane-Based (also Always Vertical is checked) I get this result.


Notice the TV angle itself is correct but it's location is wrong...and a warning message appeared to help me notice... It's been moved/copied by double the input value of 22.5 degrees using the origin of rotation correctly and managed to maintain the angle I wanted. This next image summarizes what happened.


That's weird enough on its own but I can go weird by one more, un-check the TV's Always Vertical parameter. After running through the exercise again I get this outcome.


This time it applied the rotation input angle of 22.5 degrees x 2 = 45 degrees to both rotating the family and its position. This time it did it fully wrong while the previous time it only did it half wrong.

Introduce a Floor, instead of a desk family, into the mix and place the TV family before it is Work Plane-Base with Always Vertical and this happens. No rotation, just copy and in the same place no less.


When the TV family is Work Plane-Based and Always Vertical is used then it works wrong in the same way as relying on the desk's face as the host did.

I imagine Revit is attempting to relate the rotation and copy actions to the family's host, since that is the work plane the family is hosted by. Clearly it is unable to do so properly. I think it is reasonable to expect to get the same result whether level based or work plane-based. This post and the images are from using Revit 2020.2 but I did the same things in Revit 2016 with the same results. This has been around for quite awhile now.

If it is any consolation, the Mirror and Polar Array tools don't suffer from this malady but each have their own prep work required to make them a ready replacement.

Thursday, September 27, 2018

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!

Thursday, April 28, 2016

Revit 2017 - Associate Family Parameter Tool Tip

It's the little stuff...

Revit 2017 is missing the tool tip for the Associate Family Parameter button that it took awhile to get. Now it's tool tip-less again.


It makes me sad for that little sneaky button :(

Saturday, April 23, 2016

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.

Sunday, February 21, 2016

Clearance Subcategory in Linked Files and Families

You've linked a model that has families which include clearance elements. That's excellent for doing clash detection. However you may not really want to see the graphics they've provided for this in all of your own documentation views.

Hopefully the clearance elements have been assigned to a unique subcategory that you can control by overriding the link's Visibility/Graphics.


If so and you'd like to control the subcategory without overriding their linked file you can use Copy to Clipboard on one of the families (TAB to select it) with the clearance elements in them. Then paste a copy somewhere in your model. Now the family's subcategories are part of your own model. You'll be able to control it via V/G without overriding the link, assuming the link is assigned to By Host.


You probably realized that doing the above is a shortcut to creating a matching subcategory assigned to the correct category in Object Styles ourselves. It is a shortcut because we probably won't know what subcategory the family is using without examining the family more closely, by opening the linked file and editing the family directly. Using Copy and then Paste provides us with a copy we can interact with directly instead and any subcategories it has are brought into our project for us.

Families are prone to inconsistency because they can be obtained from a variety of sources. Consider that even the families from Autodesk aren't entirely consistent from one to another. It may still be necessary to crack open a family to find out how their clearance elements are controlled. For example, the lines that form the "X", and the "box" around them, in this family are assigned to the Hidden Lines subcategory, not Clearance.


In 3D there are forms to indicate clearance requirements and they are assigned to a Clearance subcategory but they also have their Visible parameter unchecked which means we can't see them in the project at all, anywhere.


This family does not intend for us to turn off the clearance "X", at least not via its Clearance subcategory. It has a subcategory called clearance and the solid forms for its clearance zones are assigned it but then it was decided they shouldn't be visible at all. By the way, doing so does not prevent Revit from seeing the clearance forms when using its own Interference Checking. However in Navisworks they don't show up. That might be considered bad form (pun intended). From a family editor perspective (and user), it would have been more flexible if the Visible parameter had been associated with a Yes/No parameter to allow us to turn it on or off if necessary. Unfortunately, keeping in mind that this post began about families in a linked file, it wouldn't make any difference for us.

Consistency is easier to manage and achieve when it is your own content library and your project files. It can be a bit trickier dealing with the content that is part of the linked files you need from other disciplines. It's easy to create a family that makes me happy, or my team. It may not make the other consultants happy though. Something to think about while you're being happy making content.

Wednesday, January 20, 2016

Worksharing - Loading Content Part 2

In my previous post I recommended a point person be assigned to manage the loading of content for a team. That might sound like a beauracratic minded recommendation. Not me at all. It is more a matter of self preservation, wishing to avoid having to fix the resulting duplication before it becomes a bigger problem. As such there is a another minor measure we can take to help catch the issue when it occurs and fix it.

Always use Synchronize with Central (SwC) immediately after loading new families or types (or duplicating system family types). Don't place any instances.

If we can't get a single person to manage this loading then using SwC immediately afterward will increase the odds that a warning message will appear as soon as the transaction is completed. This does assume that we all develop this habit. If the warning appears than we need to examine the new family(ies) and or type(s) in the Project Browser and resolve the issue.

The goal is to avoid creating the duplicates and even more importantly using them in the project.

Thursday, October 29, 2015

Revit 2016 R2 - New Family Types Dialog Format

My friend Rolly sent me a screen capture of the new Family Types dialog. It's been revised to use similar buttons as some of the other dialogs, like the Filters and View Templates dialog for example.


It is slimmer now. I liked the larger buttons with words personally. I struggle (a little) with the tiny pictures (see what I did there) on these icon only buttons. At least I can rely on muscle memory to click on them after awhile. It will be helpful require less screen real estate for the interface and allow for more practical editing of those really long pesky conditional formulas...if dabble with those.

It seems I have a growing number of friends who are concerned about my lack of new blog posts :) Thanks Rolly! It's so much easier when you send me pichurs :)

Thursday, September 03, 2015

Finding Families - IDs of Selection

When we need to track down a family that might be loaded into one or more project files we can use master schedule project that includes links for all the relevant project files. If one of the project files already has links to all the others then we can just use that one for this instead.

A schedule focused on the relevant category that also uses the option Includes elements in links can be quite useful.


It can help us track down which models and how many there are in each of them. A little clever use of the Filter tab in the schedule can be a big help. Once we've figured out where the family is we can deal with each of them in each project.

We can search through the Families branch of the Project Browser and then use the right click option for Select all Instances in Entire Project.


Now I can reach for IDs of Selection.


Revit provides a list of Element ID numbers for each family.


It is not unusual for the list to be quite long so I often reach for Notepad (or better still Notepad++...which reminds me I need to install it on this new PC). I use CTRL+C to copy the element IDs to the clipboard and then CTRL+V in Notepad. Notice the commas between the Element ID numbers.


In Notepad I can be selective about which ones to start examining more closely. I just select one or more of the element IDs and then use Select Element by ID (CTRL+C and CTRL+V again in reverse).


Notice the instruction in parenthesis (in the image below)? It says to use a semicolon between the numbers but Revit used commas earlier. Odd.


...and...believe it or not, this is the reason I decided to write this post... commas work too. Yeah, that's definitely subtle.

As for the element hunting and selecting process, I'll be interested and waiting to see what sort of Dynamo approaches pop up in comments.

Wednesday, June 17, 2015

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?

Friday, March 13, 2015

View Reference Example

Related to a past POST or TWO...or THREE.

Here's a quick example of a poorly crafted Plan View reference that can be used to indicate what sheet a plan view is from a Section or Elevation view.


Want to reverse engineer it? Download the View Reference family.

Thursday, June 13, 2013

This Family uses a Type Catalog

A family that has a type catalog must be loaded properly, either with Load Family while placing a component or via Load from Library, or using a right click > reload in the Project Browser.

If you don't select at least one type from a catalog Revit will load the default type, don't do it. Select at least one type to reload or load. Don't drag and drop from Windows Explorer either.

A family that has a type catalog really ought to only have one "default" type. Lately I have settled on using the name: "This family uses a Type Catalog". If I find that type in a project I know it has been loaded at least once improperly. That type will never appear in the project if the catalog is used.

Do NOT use Edit Family (from inside a project) with families that have type catalogs, it puts all the loaded types from the project in the family. If you edit a family that uses a Type Catalog and it has a bunch of types "inside" it either wasn't cleaned up well or someone used Edit Family from a project. Related to this is, do NOT use Load into Project while working on the family, it does not look for or offer the type catalog and you end up with the default type in the project.

An earlier post included most of this but I decided it bears repeating, separately.

Tuesday, June 11, 2013

Family Templates and View Orientation

An exchange of posts at Revitforum.org with Alfredo regarding family templates prompts this post. The thread began with a question about orientation. I've written about this in the past. I was confused by the use of Exterior/Interior labels then.

I find a fair number of new Revit family editors seem to start out with door families. If that's your first foray into content you might starting thinking the top of the view is "front". It's labeled Exterior. I tend to think of the exterior side of a door panel as the front side when making one. This tripped me up for awhile. I wrote the post thinking the other templates were wrong when compared with the door template, at the very least different. Technically they are all the same, front is at the bottom of the page.

I recently examined every imperial family template (release 2014) that is used for 3D geometry. They all respect the notion of orientation where the bottom of the view is front, the top of the view is back, the right side is ride and left is left. Some templates have labels like Exterior/Interior and Placement Side. In the thread at RFO Alfredo noted that the Generic Model Adaptive template does not respect this orientation. In my view it does but when the template was created the front and back views were named incorrectly. The front view is really the back. If we examine geometry using the view cube we'll find every family will show the geometry the same way when we manipulate the cube.

He also mentioned the Profile Mullion template. They've provided labels to help orient yourself when you sketch your profile. In this image you can see that I've created a bullet shaped mullion profile and applied it to a curtain wall. The bullet ends up on the exterior side.



What is curious is that if the profile is not symmetrical the result is a mirrored condition when applied to the mullion in the project. That's a little unexpected.



If, in an elevation view, I place a detail section that looks up the profile matches what I see in the mullion family.



So we have to twist our perspective around a bit to get a sense of orientation. The short story is that mullion profile is a mirror of what we see in plan with respect to right/left orientation. Exterior and interior are displayed as the labels imply.

Definitely quirky...

Thursday, May 23, 2013

Adaptive Point Family and Ramps

Luke (What Revit Wants - original URL to blog site was lost) wrote a post the other day that shows how to use the "scary" adaptive point family to tag a ramp's slope, since the slope tool doesn't work on ramps.

I used them to identify sloped "ramps" that are really floors for a client last summer. We used a three point family that allowed us to click on a corner of the start of the ramp, then at the midpoint of the end of the ramp and finally at the other corner at the start of the ramp. The resulting triangle is what they wanted to see. Using model lines allowed us to see them in many views without having to resort to placing many annotation families in all sorts of views.



Don't be afraid of the adaptive point family!

Thursday, January 31, 2013

Keep Readable

Text elements have a property called Keep Readable. This prevents the text from being displayed upside down and reorients rotated text elements so they are "readable" from left to right and bottom to top. As soon as text transitions past 90 degrees and then between 180 to 270 you'll find the text flips to ensure that it is easier to read. All of this is true for text in a project view.


In a family the text elements share this parameter but it doesn't matter if you check it or not because the family governs whether text remains easy to read. This setting (Keep text readable) governs all text, even nested label families, in the family setting.



If you are working in the Family Editor you only need to worry about this one setting to force all text and nested label families to behave, so to speak.

Saturday, March 31, 2012

Wishlist - Families and Hide at Scales Coarser Than

A casual post at AUGI asked if it is possible to connect a parameter to the Hide at Scales Coarser Than behavior that the annotation for sections and elevations have. This lets us chose a scale (threshold) where the annotation won't display below. It makes it easier to keep certain sections (details/wall sections) and elevations (interior) off of overall floor plan views for example.

Imagine if we could assign this behavior to a family? Nested annotation could be assigned much more effectively because we could design them to only show up at the minimum appropriate scale. Combine this with the Detail Level concept and we'd have even more granular control over the information and geometry in a family.

Related to this is the notion that there are representations that we'd like to control for floor plan orientation and offer a different appear for the reflected ceiling plan (RCP) version. Currently what we show in plan will show the same in the RCP. That's just not specific or granular enough control.

Well, we can keep wishing...and hoping...and wishing...

Friday, February 10, 2012

Grips Location - Reference Planes vs Lines

When you apply an instance parameter to a strong/weak reference plane you'll get grips that let you alter the element directly in the view. When you do this to a reference line you get them too. There is a difference between the two Reference types in how they affect the grips though. Here's a pair of "desk" families. Compare the two forms in the image below, look carefully at where the grips are located in this one.


If you build the "bones" with Reference Lines and limit them to the size of the geometry they are meant to constrain you can define where the grips are displayed with much more control.


Don't worry, be "Grippy"!

Tuesday, April 19, 2011

Trolling the Past - Model Text Family

A couple years ago (try nearly seven!!), in June 2004 I responded to a thread at AUGI regarding some model text and it being used on a sign:


These are the general steps I took to make it:
  • First create a generic family
  • Add model text to it, center justify it and put it at the origin
  • Add a parameter for the text value and assign the model text value to it
  • Nest that family into your sign family
  • Assign the text to the text parameter in the host
  • Lock the nested model text to the center reference plane
In playing with the seven year old example that was a rush job if I recall correctly I was able to break it again. It may be a bit unfair but I fixed the family in 2012 today. I've posted the revised working family and the nested model text family so they can be downloaded:
 (now you have another minor excuse to get 2012 installed)

I also wrote:

Oh...I coined a new term while fumbling with words a little while ago...Family and Formula are now;
FAMULA

Wednesday, May 05, 2010

New Autodesk Revit Blog - Family Jewels - Revit Content

Autodesk staff members have started a new blog with content as its focus - called Family Jewels.


As long as Gene Simmons doesn't go after them they should be fine. Authors, William Spier, Ian McGaw, Martin J. Schmid and Jason A. Spleha are teaming up to contribute to the blog. Their first post appeared, according to the archive, on April 26, 2010. Might want to add it to your reading list?!?