RTC - Revit Families Advanced - M LOUW RAC Advanced...Before we begin with some of the more...

© Copyright Reserved by Michelle Louw

ADVANCED REVIT® FAMILIES Well made families make all the difference SPEAKER - MICHELLE LOUW

CONTEXT My aim in this segment is to share some of my knowledge and experience regarding Revit® family creation and content management. My intention is for you to understand how to get the most out of Revit® families and to make you aware of some of the ‘known’ and ‘less known’ pitfalls. MY PASSION In my experience I have found that there is a vast difference between a well designed and a poorly planned Revit® System. It is well documented that the efficiency of a Revit® System is largely affected by the quality of Revit® families that have been created as well as how this content is then maintained and managed. The discrepancies between a “well-made” or “badly-made” family may seem slight at times but the gold really is in the finer details. The quality of the family created can make ALL the difference to the accuracy, stability, performance and data output achievable from a Revit® System. This is why it is important to create neat and smart Revit® families. BACKGROUND I started my Revit® journey working for Wesley Benn at Benn Design Pty Ltd. I worked there for more than three years assuming various responsibilities from designing, drafting, offering implementation services to our clients and conducting classes for AEC Systems Pty Ltd for all skill levels in Revit®. I then moved across to Woolworths Pty Ltd where I became the Revit® Systems Manager and was accountable for streamlining their existing Revit® System, training staff, managing and maintaining their system closely, over 6 offices, across three Departments, nation wide. Woolworths Pty Ltd demands a high level of intelligence and data exporting capabilities from their Revit® System and much of it is generated through clever family usage, phasing and scheduling.

I recently joined Mirvac Design Pty Ltd as the National Revit Developer and I am in the beginning process of establishing, developing and designing their new nationwide system and content development strategy. I look forward to my continued adventure along the Revit® pathway knowing that there is always something new to learn or discover. Thank you to all the teachers, both formal and informal, that I have encountered along the way that have allowed me to expand my understanding of how to get the best out of Revit®.

© Copyright Reserved by Michelle Louw Email: [email protected] 2

ADVANCED REVIT® FAMILIES Well made families make all the difference

A WORD TO MANAGEMENT BEFORE WE BEGIN WITH TECHNICAL STUFF…. Before we begin with some of the more technical aspects of the Advanced Revit® families I would like to take this opportunity to discuss briefly some of the key elements that I find to be invaluable in getting started on the right foot when it comes to content creation. These are: GET THE RIGHT PERSON FOR THE JOB TO CREATE REVIT® FAMILIES Choose your content creator well. They need to be meticulous, patient and methodical in temperament in order to be suitable for creating Revit® content. They need to be one of the BEST and MOST experienced Revit® modelers in the office. If you really want good quality content then I can’t stress enough how important it is to make sure your content is created in a professional and consistent manner. There are several factors that can negatively affect the quality of a Revit® family namely;

lack of knowledge, carelessness or new Revit® users being given the task of creating families when they have too little experience in Revit®.

KNOW WHAT YOU WANT BEFORE YOU START – REVERSE ENGINEERING Rushing in and creating families without knowing the output you want or may need in future is not a good idea. Defining the initial brief may take some time but will save you hours of work and potentially tens of thousands of dollars in the long run. The benefits of defining a clear and thorough brief first will definitely pay off. This really is so important. Again – make sure you don’t have someone creating content that likes to rush in and never finishes things off properly.

I believe that the best way to develop a good Revit® System is to Reverse Engineer. I do this by first defining the output documents that are required at Marketing, DA and CC stages so that I understand the deliverables and work backwards to determine how best to deliver those documents and data through Revit®.

GENERALLY I AVOID FREE/ SHARED FAMILY CONTENT There are many poorly created families out there on the web and some of this content is free of charge to download and shared by users. I avoid using other user’s families as a starting point, unless I trust the author’s content, because I cannot be sure of how it was originally constructed and with what logic or degree of accuracy. Another risk is that the content may have a hidden corruption which I would not be aware of. I find it can be as time consuming to adjust or repair another user’s content to match my conventions than to create my own content. Most Content creators that do a professional job have spent many, many hours developing this skill and will expect to be paid for their efforts and will rarely share it unless it suits them to do so.

MANAGE & MAINTAIN YOUR CONTENT In a multi-user office environment it is imperative that you take precautions and create a process to protect your valuable content. You do not want any of your less experienced users editing the office approved content and then overwriting your library. I recommend that you nominate a few skilled Revit® users to be trained up and approved to be allowed to create content for the rest of the office. Someone will need to maintain the library and keep the inexperienced users in check by making sure they have no reason to edit office content.



WHY CANT EVERYONE MAKE FAMILIES? I don’t believe all Revit® documenters should be allowed to create content in an office environment. I realize that not everyone will subscribe to my ethos regarding this matter but I have found, in my opinion that it works really well to have a close control on what content is being created and by whom. Revit® is a tool, much like a pencil and I believe that it works best if most documenters are not occupied with creating content. If the Revit® Manager can make sure that the required content is available, given sufficient notice of course, then the documenters can continue to use their skills to design, document and interrogate the model and documentation output so that the company has the best possible outcome on site. I realize we are in a creative industry and that some designers, drafters and architects may feel limited if they can’t explore family creation as well but I believe it is in everyone’s best interest to limit the number of approved Content creators within a firm. I liken it to asking a chef to make his best lasagna but… before he begins creating his masterpiece to insist he first grow the vegetables or wire up the oven. Instead what we want the chef to focus on cooking. It is up to the Manager to ensure the chef has all the utensils and ingredients he needs to prepare the required meals. POINT TO PONDER? Perhaps it is time for your office to have a Revit® Manager, in a full-time or part-time capacity, to keep everything in check so that you have considerably less downtime in productivity in Revit®. Creating content for in-experienced Revit® users will prevent them from getting frustrated because Revit® is “not doing what they want it to do”? A designer’s resources and talent is far more valuable being used elsewhere instead of creating content. I have seen many a profit margin dwindle when inexperienced Revit® documenters are struggling to create, repair and edit content, taking days to do what a professional Content creator might be able to accomplish in several hours and probably with more accuracy and long-term sustainability. Revit® Managers can be used to

Continually interrogate working Projects Fix more complex Revit® modeling issues Train staff and document Office standards Create, maintain, repair and manage Office content Oversee deployments

FOR SMALL COMPANIES/ SOLE PRACTITIONERS Where you may not have the skill level or confidence to create families may I suggest that you consider either ordering components from a professional Revit® Content creator or get additional training to assist you in learning how to create the components needed? I have observed that sole practitioners and small companies sometimes invest too much time and resources in trying to figure family creation out and that the time spent for inexperienced users to create their own components ends up costing more than it would have to order the family from a professional content creator. If you want to learn to create more complex families and would like to devote your time to the adventure of discovering Revit® family creation, then getting some good family training and lots of practice will definitely get you on track.

MORE TECHINAL TOPICS TO COVER

Nesting family components Family Parameters vs. Shared Parameters(SP) Formulas Catalog families Reference Planes Office Standards (Type names/ Subcategories/ Family categories/ View Templates) Office Practices (Purging, Copy and Pasting, Origin Points) Good Practices



NESTED FAMILIES – ADVANTAGES & DISADVANTAGES Using nested families can be convenient from a content creator’s point of view and can seem to be ‘the only way” to make families. There are a few things to consider when using nesting in family creation and I want to make you aware of some of the ramifications of choosing nesting as a way to create your components. Here is a table of some of the advantages and disadvantages of nesting. I’m a big fan of using the right tool at the right time… and nesting isn’t always “it”, especially in project types where a large number of components are used. E.g. Retail stores or Hotel interior projects.

NOT NESTING NESTING Much better file size. Can be as much as a third of the size of a complex nested family.

Unreasonably large family sizes. (Probably not an issue on small projects or in projects that are using a modest amount of families)

From a Content Management point of view it is much simpler to avoid too much nesting. Content creators need to remember to diligently save out a copy of each nested family for their reference and to keep these separate from the library.

Unclean nested components can add huge amounts to file size. I saw one nested door handle family that had 26 unused families. Because of all these (and more) unused nested families this simple kitchen counter family was almost 6MB in size! You must be VERY disciplined when using nesting. See section on Purging in the Family Editor.

This is one time when I do encourage nested families if you want a family to tag twice.

Useful if you want to tag the nested family separately to the host family. E.g. Dishwasher (Nested :“CW @1200” & Host : “DW”)

More Reference planes are generally used and dimensioning needs to be done more carefully but it can result in a simpler family construction.

It is quicker and more convenient for a Content creator when nested components are being used in several different families. This may be where nesting is valuable. See below regarding reloading changes.

I usually find it can be easier to edit or repair non-nested families because I don’t have to go into nested families to locate the error, modify and then reload. Simply there is more immediate access to the geometry and constraints.

I have found it can be more time consuming to fix nested families when they are not working because identifying the source of the error can be more complicated. Editing or repairing can take longer especially when the parameter naming between the nested families and the host family are not identical. Coordinated parameter linking is critical.

No risk of families conflicting in a Project file unless you have identical family name.

When changing a nested component that is shared by more than one family you need to be careful when reloading it into the Project file because it will affect all other families in file sharing the same nested family. You will need to rename the nested family before reloading into the Project if the change is not to be global.

IS THE FILE SIZE SUCH A BIG DEAL, WHEN IT COMES TO NESTING?

These families can be created to have the same behavioral traits with or without nesting. As you can see below, if you don’t use nesting you need to be more meticulous since all geometry is live. Use Reference lines and labels to lock geometry in place. Compare file sizes below.

Live Geometry

Nested Family



SHARED PARAMETERS (SP) Shared Parameters are invaluable if you intend to schedule any custom parameter values now or in the future from a Project file. Predicting what you may wish to schedule will give you a good idea of how to define the parameters, constraints and labels to give you the data output that you may need. Here is an example of what can be scheduled using SP’s. (Note the Column headings in the schedule can be renamed.)

THINGS TO REMEMBER WHEN USING A SHARED PARAMETER FILE:

Make sure all content creators in your company are using the identical copy of the Shared Parameters (SP) text file.

PITFALL. Making the same Shared Parameter in your own local SP file will not be the same as using the official Office SP file. Essentially parameters that originate from two different SP files are given different data identifiers and therefore Revit® will see them as different from one another, even though they may be identical in every other way. As a result you will end up with duplicate parameters in a Project file that will schedule separate SP data. Unfortunately there is no workaround for this. To solve this problem you will need to swap out the uncertified SP’s (that originated from other SP file) from the affected families and replace those SP’s with the approved SP’s (that are being used in the Project schedule) from the official Office SP file and reload the amended families into the Project file.

Remember to only add specific SP’s into the Project files / Office Template that you wish to schedule (Only tick affected Family categories.)

TIPS

I find it best to plan what my users may need so that I can avoid content creators creating their own Shared Parameters in their own files. I find it works best if one person is the author of the file and redistributes it to all Content creators and Revit® Managers (If more than one office/ Interstate etc.) when changes are made. Establish an office naming convention and keep it consistent.

Avoid using symbol “–“ in the Parameter name because that will affect your formula

options. (E.g. Panel – Width) In the formula field this dash will become a minus. (Suggestion: Panel_Width)

I like to name SP’s so that they sort in a logical order. See Screenshot example to

the right. It’s easy to pick any panel SP that may exist or identify a missing one.

Useful Parameters to add to a family are ( “Addenda”, ”Made By”, “Edited by” and “Note to User”) “Note to user” allows you to put comments for user.(E.g. Max 4 panels)

Parameters that users will often need to be referred to in the Project file can be grouped under “Constraints” or

“Construction” to make editing these values in the Project or Family file quick and easy.



GOOD PRACTICES THAT MAKE OR BREAK A FAMILY The most important practice I believe to making good quality families is the practice of being diligent, consistent and methodical. Families are not technically difficult to make but it is HOW they are made that really makes all the difference. In my experience there are some ground rules that I (and some fellow professional Content creators) follow and have found to work well. Here are some of the habits we share when creating stable parametric families that behave in a predictable manner. REFERENCE PLANES

Get comfortable with using Reference planes when creating families. They are incredibly useful and I find them reliable and more consistent in their parametric behaviour than locking geometry to geometry.

Be sure to name the important reference planes clearly and consistently. Every Reference plane should be in the

family for a reason. I don’t necessarily name all the reference planes in a family but I recommend that you at least name Centre Front/Back, Centre Left/Right, Right and Left. This makes these Reference planes easy to access when working in Elevation if you need to set a work plane.

I don’t recommend that you hide Reference planes in views. They should be visible and easily referred to if you wish to

modify or repair the family in future.

Set the “Reference Is” value for ALL Reference planes in the family. If you don’t want to have a reference highlight in the Project file then you need to set the “Is” value to “Not a Reference” and if you want to dimension easily to the reference in a Project file then you must set the value to “Strong Reference”.

Instance based geometry should be set to Reference planes that are “Not a Reference” to avoid geometry stretching in

the Project file when the family is aligned to something else using that reference edge. (Therefore don’t set instance geometry to a “Strong Reference”.)

Always clean up the extents of ALL your Reference planes, in all views. If you leave them extended far beyond your

family extents it will affect how the family is selected in the Project file. I have seen families that have been selected, moved and deleted in Project files because even though the selection box did not intersect the family geometry, it did in fact intersect the Reference planes belonging to that family.

I prefer to keep all Reference planes outside of sketch mode so that it is quick to see the relationships and fix any

problems. It also means that the Reference plane can be used to associate several geometries to it.

You can control the distance of wrapping from the exterior wall finish of a door or window by creating a Reference plane that demarcates where you want it to wrap to, in plan view, label the offset and then modify the Construction properties by ticking “Wall closure” in the Reference plane “Element Properties” menu.

ORIGIN POINTS

The Origin point determines where the cursor will pick the family up from in the Project file. Select two intersecting Reference planes and go to Properties Menu to set Origin by ticking the appropriate “Defines Origin” check box. Tick grey check mark to activate new Origin point.

I advise that you take the time to set the Origin point right the first time and that you don’t change it once it has been

issued and it is being used across many projects. Reloading a family with a modified Origin point will automatically relocate the component in the project file. You don’t want doors and windows moving in files once they have been carefully placed in the right location.

Always set Origin point in Plan view. Also set origin point in elevation if object is going to be elevated by an offset value

from floor or ceiling level, or if it is going to be arrayed vertically. It is generally good practice to set it in both orientations to ensure most consistent behavior.



DIMENSIONS & LABELS

I suggest that you keep your dimensions outside of sketch mode where they are clearly visible at all times. It is quicker to see the relationships between geometry and to isolate any problems if you do so.

Develop a practice of dimensioning in one plan and one elevation view only, within the family. The only exception is of course if the element you are wanting to reference to is not visible in those views. It saves a lot of time fixing a family if it is over constrained if you can see all the constraints in 2 nominated views (one plan view & one elevation view), rather than hunting for other dimensions in sketch modes or other views. I like to refer to “Ref. Level” and “Front Elevation” wherever possible. Nominate preferred dimensioning views in families as an office standard.

Sort the dimensions that you want your documenters to have easy access to in the Project file under “Constraints” or “Construction”. These two group categories are at the top of the menu list, within the Family properties menu in the Project file, making it easier for users to edit the parameter they need without trying to hunt for the parameter they wish to edit.

Use formulas where you don’t want values to be editable in a Project file. They will be visible and will schedule but will be greyed out in the Project leaving the content creator in control of certain values. This is a good practice for protecting critical values or data. See Formula section.

DIMENSION ERROR The error below is a common one that seems to stump inexperienced family creators. Allow me to explain the issue…

Over constraining dimensions happen when you try to tell Revit® to apply two rules which could potentially contradict each other. E.g. Let’s assume that Revit® did allow us to add another overall parameter to this sketch, E.g. “Height_Overall”. That would mean that “Height_Overall” would now be 1600mm. PROBLEM: What if “Width_Main Frame” was changed to 50mm? Well, that would mean that the parameter value “Height_Overall = 1600mm would no longer be true. So this is why Revit® gives us this error message. The way around this is to define a formula in the Family Type Menu that equates the values of “Height_Overall” to = Height_Panel + Width_Main Frame. That way the value will remain correct and you will not over constrain the sketch if the formulated values change in future. (See below)

This dimension can’t be controlled by adding another overall dimension label in this view. A formula will need to be used in the Type menu. As shown >>>



VIEW SETTINGS

I recommend that you avoid controlling visibility of elements through detail levels such as Coarse, Medium or Fine, where possible, ESPECIALLY in 3D views. It becomes time consuming and frustrating to edit geometry when it appears inconsistently through views. Most of the time I find controlling the geometry in this way is not usually necessary. I have seen this done for louvre families to avoid dense line work in small scale 3d views, however, creating a louvre subcategory would be my preference to enable me to switch it off through Visibility Graphics, giving me more flexibility and graphical override options.

Make use of line style settings to communicate your plan or elevation representations more simply. For E.g. Select the glazing extrusion of your window and hide it in Plan view (both Cut and normal) and use the Window[Cut] Symbolic line style to represent a glass panel in plan view with a single line. This will hide the glass geometry in all plan views, since a simpler single line representation may be preferred rather than hiding the glass in coarse and medium view settings.

Avoid using wire frame as a view setting when creating families because it can become a nightmare when it comes to editing.

CONTROL FLIP ARROWS Here is a brief graphical summary of the impact when using a flip arrow control. Single arrows rotate a family 180° and a double arrow mirrors the family around the relevant axis. Note: Horizontal and Vertical single arrows have an identical affect, irrespective of axis. In this example: The Blue symbol is the original and the Red symbol is the flipped version

SINGLE ARROW - VERTICAL DOUBLE ARROW - VERTICAL

SINGLE ARROW - HORIZONTAL DOUBLE ARROW - HORIZONTAL

See Line styles/ Object styles section in document.



FAMILY STANDARDS I would like to briefly outline other considerations that form part of creating standardized office content. Even if you are a small practice I still believe it is worth developing some basic ground rules of consistency so that future editing is as easy and efficient as possible. FAMILY NAME Using a prefix to assign a folder location for a set of families can be very useful, especially for the drafting team when they are not familiar with the office folder structure. Something as simple as a two letter prefix can make all the difference in helping them locate a family on the server. GOOD PRACTICES WHEN NAMING FAMILIES:

Be Consistent in your naming convention Keep it simple and short. Avoid abbreviations. Avoid names that can easily be superseded. Specific sizing can be problematic, or

referring to manufacturer. Consider Prefix naming convention as shown. (Font case for prefix is ideal if CAPS) Provide sufficient information in the family name to enable drafters to make intelligent,

quick choices about which component to use. This applies to Type name too. Don’t get lazy and start naming families with a numerical suffix. E.g. Awning Window 1

TYPE NAME If you want to ever re-load a changed family back into a Project file it is important that the family have a type name in the family file. I will assume that you already know how to create Family types and why they are used but here are a few tips and some of the mistakes I have seen along the way when reviewing or developing an office system that I think are worth mentioning.

Determine what ypes will be needed and how the drafters may need to modify a family in the Project/s. This is important because it is not always best practice to force users to create new types every time they want a different size. E.g. – In project housing where standard doors and windows are always used I would create size specific types within a family, but in a designer apartment project I would consider having width and height as instance parameters and the types would refer to other conditions. E.g. Frosted Glazing/ With Louvres etc.

Use the Type name to clarify choices for your drafters. Avoid type names that are a repeat of the family name. Note: If you don’t create a type in a family Revit® will automatically duplicate the family name as the type name in the Project file when loading it into the file. E.g. Awning window: Awning window (Which is pointless and ineffective)

Avoid Type names that can become superseded if you are looking for long-term system sustainability. (E.g. Microwave Oven: 500 x 450mm ) If the supplier changes the size you will have to create a new type and so you are limiting your re-loading benefits to update Project files.

A tip I have learnt that I think is a useful one is to use “Type 1” as a type name to communicate to the documenters that there is only one option to choose from.

If you have more than 5-6 types in a family you should consider a catalog family instead.

I prefer to use sentence case for family names and type names instead of all uppercase. It is quicker to scan. Avoid wordy type names. Keep the naming simple but clear and try to avoid abbreviation where possible.

If size is appropriate in a type name then I suggest that you add length identifiers (w,d,h) behind every measurement. E.g. “500w x 450d x 500h”. At the risk of stating the obvious choose a direction identifier and stick with it! I have seen “width”, “length” and “depth” being used erratically in families in many offices which has caused needless confusion. If you prefer “length” to ”width” that’s fine…. Just be consistent.

I like to format all my sizes by Width (Left to Right) x Depth (Front to Back) x Height (Bottom to Top) I have wasted much time when fixing other user’s families just because the basics weren’t applied and the family author constantly swapped the direction of width and depth around, often within the same family file. This is poor practice.



TYPE CATALOG FAMILIES A Catalog family is a family that relies on a .txt file to define the values for certain parameters within a family. When loading the Catalog family into a Project file Revit® will automatically read the matching “txt” file and create the appropriate family types within the Project file, based on your selection. Catalog families do not save that much file size in my opinion. Their benefits are more about only having the relevant types listed in the Type pull down menu, within the Project file, if appropriate.

The .txt file will tell Revit® what values to apply to the various Type parameters within each family type so that the family types match the properties in the .txt file. A Type Catalog family is used when there are many types within a family and allows the Content creator to edit the defined values directly in the .txt file easily without even going into the Revit® family editor. Note:

The Catalog .txt file must match the family name exactly and be in the same folder location as the family in order to work. E.g. Family Name: AD_Broom.rfa and Catalog File name: AD_Broom.txt

These families must be loaded into a project file using the “File> Load from Library> Load family “option.

The user does not have to load in all the types within a family and can select which they want to load from the menu list which is automatically displayed by Revit®.

EXAMPLE OF CATALOG FILE FORMAT A simple example of a family where all we were controlling through the Catalog family is Type name, Manufacturer, Width, Height and Depth. E.g. Family name: OF- Workstation.rfa, Type name: Refers to timber finish STEP 1 Create a type Catalog file in Notepad where top row lists the relevant catalog parameters. The first parameter is always the Type name which is not entered by any identification, but is followed by a comma, thereafter followed by other parameters. Each parameter is separated by a comma with no space either side of comma. Parameters are defined in the following format: Parameter Type##Group##Unit(If applicable) See example below. STEP 2 Associate values to each type (One type per row) See example below.

STEP 3 Save the Catalog file as txt file. E.g. OF- Workstation.txt and must live in same folder as the Revit® family to work.

STEP 4 When importing the Revit® family the following menu window (above)will pop up allowing you to select which types to import into the Project file.



VIEW TEMPLATES IN PROJECT FILE Before creating Office standards in regards to Sub categories or Object styles allow me to suggest that you first establish what office View Templates you will be creating. The Project View Templates can be used to control or override any of the custom subcategories in the Project file or Office Template file and are likely to dictate what categories need to be created.

STEP 1 – Before creating any family subcategories first define what elements need to be visible or overwritten in specific views or on certain sheets, within the Project file environment. Determine your data output.

STEP 2 – Determine what View Templates you will need in your Project file/s to enable you to manipulate the visibility

and display graphics of the Family subcategories to achieve the required output in STEP 1.

STEP 3 – Once you have determined what you want to see on various sheets that could be controlled by View Templates you can work back from there. Create office standards of typical subcategories that you wish to have control over in the Project file through Visibility Graphics. Use these standards consistently.

SUB CATEGORIES/ OBJECT STYLES

Set the subcategory of ALL geometry in nested and host families.

Don’t create too many overly complicated subcategories. Keep it simple. Avoid naming that is too specific that forces you to create another subcategory for something that is essentially the same thing. For E.g. “Access Hatch” and a separate category called “Air returns”. Perhaps a subcategory that can be used for both is better suited. E.g. “Mechanical Rep”.

Make sure when using line styles that you choose the correct subcategories from the Type pull down menu. E.g. Windows [Cut] vs. Windows [Projection].

Make sure not to make spelling mistakes when using Family Subcategories across a range of families because it will import each variation separately into your Project file or Template. Consider creating an Excel spreadsheet of all approved subcategories and copy and paste text to ensure the name is identical in all families across your library.

Here is an example of what happens when several families are imported into a Project file using similar - but not identical Family Subcategories. This makes editing and creating View Templates a nightmare because it becomes very time consuming to work out which Subcategories belong to which families.

PITFALLS REGARDING LOADING SUBCATGORIES IN PROJECT FILES You should be made aware that if you create subcategories for a family and load it into a Project file that it is imperative that the “Family Category and Parameters” are set to the CORRECT type BEFORE loading the family into the Project or Office template file. Be absolutely certain you have everything right before loading any new family into the Project file, especially when loading the new family into your office Template. This is especially important for Content creators who use the “Generic Model” Family Template and then convert the family to another Family category (E.g. Doors) to avoid unwanted default parameters that are part of some of the standard Revit® Family templates.



Here is an example of why you need to check the Family category before loading a new family into a Project file and some of the associated pitfalls when getting it “wrong”: E.g. Cabinet Family originally created from Plumbing template. CASEWORK 1,2 & 3 are new subcategories created by author. 1 - FAMILY LOADED INTO FILE WITH WRONG FAMILY CATEGORY

If you import the new family into a Project File without checking the “Family Category and Parameters” you may have imported these subcategories into the project under the wrong Family Category permanently. E.g Casework categories have been grouped under Plumbing Fixtures.

2 – CHANGING THE FAMILY CATEGORY – LOOSING CUSTOM OBJECT SYLES If you now change the “Family Category and Parameters” to the correct one Revit® will remove all previously created Object styles in the family . Those same Object styles will need to be re-created and re-assigned to geometry and line work within the family that has had it’s “Family Category and Parameters” corrected .

3 - RELOADING FAMILY WITH AMMENDED MAIN FAMILY CATEGORY Reloading the family with the revised “Family Category and Parameters” and recreated Subject categories will not re-assign the previously defined Subcategories under the correct Family category. Revit® will simply create a duplicate of the custom Object styles under the new Family category.

4 – TRYING TO REMOVE UNWANTED SUBCATEGORIES

My findings are that deleting the incorrect or updated family from the Project file does not actually remove unwanted subcategories from the file. These Subcategories will now live in both family categories for the life of the Project file. As per the screen shots “CASEWORK 1,2 & 3” cannot be removed from the Plumbing fixtures.

PITFALL – ADDING SUBCATEGORIES TO PROJECT WHEN VIEW TEMPLATES ARE SET

It is important to note that any new Subcategories that have not previously existed in a Project file will default to visible in ALL predefined View Templates when they are loaded into the Project file. You will need to review all predefined View Templates to see if the new Subcategories will need to be hidden or overwritten.

FORMULAS Basic Sum symbols + Add - Subtract / Divide * Multiply Formulas can be very useful to enable a Content creator to (1) establish relationships between Family parameters and (2) to lock in a definite Parameter value. E.g. 5 Panel window with Awning panel on each end and three centre panels that are equal in width.

Note: Usually once a formula has been entered the Parameter name becomes ghosted and is no longer directly editable in the Project file or from the value cell in the Type menu. (As shown above)



With formulas the following rules apply: There should be a space between each parameter and the sum E.g. Parameter(space)+(space)Parameter = A + B Parameter names are case and spelling sensitive. Match the parameter name exactly. If you create a formula to lock a value of a Parameter, as shown above (Awning Panel Width = 900mm) then this value

will be locked for ALL types within the family. This is a good idea for values that should be consistent across types. E.g. if you are creating a suite of windows and you want all suite frame depths to be 150mm.

Enclose separate sums with brackets. E.g. As seen above in Centre Panel Width = (Sum 1) / 3 Instance Parameters cannot be included in formulas to determine the value of a parameter that is a Type parameter Revit Help menu has some more complex “IF”, “AND” and “Yes/No” formulas listed

LINEWORK / OBJECT STYLES & CUTTABLE FAMILIES Using symbolic line work can be useful when you want to control how a family is being graphically represented in a plan or elevation. By choosing the relevant line style. If you wish it to represent the sectional profile use [Cut] style or for elevation profile use [Projection]. See Cuttable Families.

For Section Profiles make sure that the following check box is ticked in “Visibility” Menu.

Here is an example of a Refrigeration case where the Elevation and Section views are different. This was done by controlling geometry visibility and creating Symbolic lines to represent the desired profile.

CUTTABLE NON-CUTTABLE Casework Balusters Lighting Fixtures Columns Curtain Wall Panels Mechanical Equipment Doors Detail Items

Parking Site Electrical Equipment / Electrical Fixtures Planting

Structural Columns Entourage

Plumbing Fixtures Structural Foundations Furniture

Specialty Equipment Structural Framing Furniture Systems Topography

Windows Generic Models

Section Elevation

Family Category: Casework (Cuttable)



OFFICE PRACTICES There are some common practices that can have a strong impact on the longevity of you library of components and also the accuracy of these families within a Project file. From a System Manager’s point of view it is always important to try and ensure that drafters are using the most current families in live Project files. Some seemingly harmless documentation practices, such a copying and pasting families or Purging Projects to remove family types can cause much damage to the integrity of your files and components. Instilling new office habits aligned with my comments below will help protect the integrity of your important library content. COPYING & PASTING ACROSS PROJECTS The quick “Copying and Pasting” mentality can appear to be harmless but should be discouraged by a Revit® Manager in an office environment that relies on a library of content that is being used across several projects or where it is important to maintain flexibility by avoiding losing family types within a Project file. When you copy and paste families across from one Project file (A) to another Project file (B) you will loose all the types that were not originally selected in (A). What is worse is that when you re-load the family it WILL NOT automatically add the missing types back into Project file (B). Allow me to demonstrate…..

BEFORE - There are two family types in Project A

AFTER - There is one family type in Project B

I strongly recommend that users don’t copy and paste across files since the following risks don’t make it worth while.

Users could be copying across old families that are no longer current, or could be corrupt. For this reason also avoid editing families from a Project file and saving them back to the library. By overwriting the

library component you potentially loose types. PURGING FAMILIES IN A PROJECT FILE Be careful to purge families from a Project file by using the Purging feature. Purging removes all unused types of a family, however if you require a type (that was purged out) within a family then re-loading the family will not simply add it back in. I prefer to delete all unused families manually in a Project file from the Project browser, one by one, and I don’t delete types within a family that are not in use. Use “select all instances” when using the Project Browser to see if a family is in use before deleting it from the Project file. If it is in use Revit® will automatically give you a warning message to say you are about the delete elements from you model. The warning message will give you the option to select CANCEL and you can then proceed to the next family in the list. I recommend that you remove any shortcut keys for Purging from documenters’ local Keyboard shortcut txt files.

Don’t Forget Me

Pick Me



SUMMARY OF BEST PRACTICES THAT I HAVE FOUND TO WORK WELL

1. Always keep family file size in mind. Get best solution with minimal file size. Avoid excessive use of voids and nesting where possible.

2. Make sure that ALL unused nested and host families are purged in the Family Editor (This is an instance where I

do recommend in purging) BEFORE loading into host family or Project file for testing. 3. Lock geometry into Reference planes rather than into other geometry. See section on Reference Planes. 4. Have a clearly defined, consistent Parameter naming convention. (Avoid abbreviations.) Ensure that these families

are methodically made and linked with consistency in mind

5. Model up the right level of detail for the desired outcome you wish to have.

6. Think about the output and how the component may need to change or the various options users may need BEFORE you make the family. Add the correct restrictions; use Instance and Type parameters appropriately.

7. Choose your type names well and with forethought. (See Type name section)

8. Avoid Copying and pasting families across Project files

9. Have a designated, experienced and well trained Content Creator/ Content Manager in your office or use

professional Content creators. The “First in … all can have a go” approach is far from ideal.

10. Set Origin point right the first time. Avoid changing Origin points of a family once it is in use in Projects. Changing Origins points after a family is in use negatively affects drafter confidence. If drafters experience families moving when re-loading they will be reluctant to reload any repaired families.

11. Have good Subcategory naming conventions that can control family geometry through View Template.

Subcategories are case specific. Be exact in your naming.

12. Choose the appropriate Family Category. See Cuttable and Non-cuttable families in Help Menu. The category you choose will determine whether the item, when cut, will display as an elevation or section profile.

13. Use Instance parameters if you want documenters to be able to adjust the family without creating new types.

14. Use Type parameters if you want to control type information and force drafters to create a new type if a critical type

value needs to change.

15. Use formula ghosting of Parameters to protect important Parameter values or the relationships between parameters.

THE END If you have any questions please feel free to contact me on my email address: [email protected] I am currently in the process of setting up a web blog which I would be happy to send you a link to once it I have completed setting it up. Please email me with the subject heading (BLOG UPDATE PLEASE) to the above email address if you wish to receive my blog link as soon as it is ready. Enjoy creating great Revit® families! Michelle Louw

RTC - Revit Families Advanced - M LOUW RAC Advanced...Before we begin with some of the more...

Documents

Transcript of RTC - Revit Families Advanced - M LOUW RAC Advanced...Before we begin with some of the more...