AECbytes Tips and Tricks Issue
#49 (March 31, 2010)
Type versus Instance Parameters in Revit: When to Use What?
Shawn C. Zirbes
CAD Technology Center, Integrated Content Solutions
Let’s think back to our younger days, and the games we played in the playground. Remember that pastime favorite, “Duck, duck, goose?” In this schoolyard game, a picker walks around a circle of classmates and taps the kids in the circle one by one on the head saying, “Duck”… “Duck”… “Duck”… until one is chosen to be the “Goose.” This of course was intended to be random, but the “Picker” in the game would likely pick a classmate that they felt they could outrun, allowing them to run around the circle and sit in the “Goose’s” seat before the “Goose” who was chasing them was able to tag the picker; otherwise the picker had to sit in the middle of the circle until another picker was caught.
What does this have to do with Revit? I thought of this game one day while teaching a Revit family class, after asking whether the class thought a parameter should be an “Instance” parameter or a “Type” parameter. The answer seemed random. Half of the class believed it should be an instance, and the other half felt it should be a type. After a lengthy description of why, in this case, one was better than the other, we began the process of defining the next parameter. Of course, the discussion ensued again. Following this, I sat down and tried to decide if there was a way to easily describe when a parameter should be a type or an instance, minimizing this random guessing game a few of us seem to play while defining parameters.
In this article, we will discuss a few topics. First, we will look at the difference between type and instance parameters. Second, I will describe why one should be chosen over the other. Third, I will show some examples of each in use in families. Fourth, we will cover a few of the nuances between type and instance parameters.
The Difference between Type and Instance Parameters
All parameters of a Revit family work together to define the Element Properties of that family. They can hold many data types from simple length and material properties, to HVAC air flow and structural load information. None of this, however, describes when the parameter is used. The when is what we are discussing today.
When a family is loaded into a project, it has inherently built into it at least one type. This type is a single variation on the main family. The main .RFA file (Family file) describes what this family is, for example, Door, Window, Chiller, Water Sourced Heat Pump, etc. The type(s) that exist within that family define the parameters that will be the same for every insertion or instance. The parameters that appear within the family’s type are called Type Parameters.
At some point, that family will get placed into the project. While placing the family, the user must choose one of its types to be placed. Once an insertion point is chosen, the user has created an instance of the family. This new instance has parameters of its own called Instance Parameters. The family will always have the same parameters, but the values of these parameters can change at different times.
Let us assume that the user inserted five instances of “Type A” and five instances of “Type B.” Let us also assume that the family contains only 2 parameters. The first is Width, and this is a Type parameter. The second is Paint, and this is an Instance parameter. The five families that are “Type A” will all have the exact same width. They are the same type, and since Width is a type parameter, whenever “Type A” is inserted, it will automatically contain the value for Width that all of its “Type A” brothers and sisters have. Likewise, whenever “Type B” is inserted, it will also have the exact same value for Width that all its “Type B” brothers and sisters have. The Width value may be different between “Type A” and “Type B” but whenever a “Type A” is inserted, it will have the same Width value as another “Type A.” The property of the Paint parameter can be changed at any time regardless of which type is used. Any “Type A” could be red or blue. Any “Type B” could be red or blue.
When to Choose What?
When defining parameters for a family, there are many factors that define whether a parameter should be an Instance or a Type. The following factors can be used as a guide for determining which it should be:
Frequency of Changes: Generally, the more frequently a parameter’s value changes, the more likely it is that the parameter should be an Instance parameter. Though this is not always a fair comparison, it is often a valid technique that can be used to determine if parameter should be an Instance or a Type.
Reliance on Other Parameters in Formulas: Formulas often dictate to which side that decision will swing. If any parameter is going to use an Instance parameter in its formula, then both parameters must be an Instance. Here are the rules:
- An Instance parameter can reference Type and Instance parameters in its formula.
- A Type parameter can only reference other Type parameters in its formula.
Model Number Relation: If the model number of a family is nominally based on the values of parameters, then those parameters should be Type parameters. The “Model” parameter is built into every component family, and is always a Type parameter. This means that any parameters that exist whose values are indicated by the “Model” number should match that part of the model number. This is only remotely possible if those parameters are Type parameters.
When in Doubt…: When you define a parameter, if you are ever in doubt, it is far better to err on the side of Type. The main reason for this is that use of Type parameters assists in keeping the Revit model size as small as possible. More on this will follow in the section on “Nuances.”
Examples of Families
In the example shown below, note that both doors are the same Type, yet both require a few different properties in their unique situation.
The door to the left has a constraint in the corridor that only allows the door to open 90deg. The door to the right can have the right panel open a full 180deg, while the left panel can only open 90deg.
Both doors may have special hardware requirements, or finishes, but they are still bound to the same base type, i.e., their size, panel type, and frame type are the same.
Moving on to another example, most of the parameters on the pipe elbows shown below are Instance properties. The diameter of the incoming and outgoing pipe could be different at every instance. The connection conditions could all be different.
In the above example, the parameter in this fitting family that is a Type parameter is the “Long Radius” parameter. It is used by the types to decide if the elbow is a 1R or a 2R elbow. The 1R “Short Radius” type makes the elbow’s centerline radius equal to the radius of the largest pipe. The 2R “Long Radius” type makes the elbow’s centerline radius equal to the radius of the largest pipe times 2. Thus the user chooses to draw a “Long Radius” or “Short Radius” type of elbow. The actual radius is still an Instance, it just decides which formula to use based on the family type selected.
Below are just a couple of nuances we have discovered while making families and experimenting with new, and not so new techniques. While only two are included in this article, there are obviously quite a few more, but these were the most appropriate given the topic covered in this article.
The file size of Revit is impacted by a multitude of variables. In my experience, one of these is the over-use of instance parameters.
Every time an instance is made in Revit, there is a reference made back to the original Type to obtain the Type parameter values, but for every new instance, there is also a new entry in the Revit database for every Instance parameter value. This can, if not properly managed, quickly balloon a file size.
Let’s make some assumptions:
- 1 instance parameter value adds 5 bytes of Revit file space.
- 1 lighting family contains 10 user defined instance parameters.
- This means that a single instance would add 50 bytes to the Revit model upon insertion.
- How many lights exist in a medium sized model? Let’s say 3000 lights.
- This means that the Revit model would increase 150,000 bytes or .15 MB.
- How many different families exist in a project? Let’s say 1000 different families are loaded, and inserted at the same frequency as the lights.
- This means that the Revit model increases 150 MB just from the Instance parameter values. If these were defined as Type parameter values, the hypothetical file size could have been greatly decreased.
Please no hate-mail because of this example. It is only an example to discuss how Instance parameters could influence the file size.
As mentioned earlier in this article, Instance parameters cannot be used to provide a value to Type parameters. Doing so would directly break the intent of a Type parameter. A Type parameter doesn’t care what the Instance parameters are doing. In fact, the Instance parameters don’t even exist at the Type level. The reverse is somewhat different. For the instance to exist, the type must already exist. For this reason, it is possible to reference a Type parameter in an Instance parameter’s formula.
Though there appears to be no exact formula that can be used to decide whether a parameter should be assigned as a Type or an Instance, there are some very strong guidelines that you can use to help steer you in the correct direction. There isn’t technically a wrong answer, but there sometimes will be a better one. And remember, if you aren’t sure, err on the side of Type—your Revit model will thank you.
We hope you found this article useful. Please send any questions or comments to firstname.lastname@example.org. We always look forward to your comments. Also, if you have any topics you would like to see us cover here, please feel free to use the same email for topic suggestions.
There are a few good resources that can be used to further your proficiency in Revit families.
- Revit 2010 Family Standards and Best Practices by Shawn C. Zirbes
- Autodesk SEEK Model Content Style Guide
- Revit MEP, Architecture, and Structure Help system and tutorials
About the Author
Shawn C. Zirbes works for CAD Technology Center, Inc. (CTC), an Autodesk Premier Solutions Provider, and consults daily at Integrated Content Solutions (ICS), an Autodesk Content Premier Member. He has over 10 years experience as the Chief Technical Officer at CTC leading Revit implementations and furthering the use of BIM in the upper-Midwest area. Currently working as a primary Revit content creation advisor, Shawn has published a book titled “Revit 2010 Family Standards and Best Practices” and consults with Autodesk SEEK to assist in the definition of Autodesk approved standards.
Note: AECbytes content should not be reproduced on any other website, blog, print publication, or newsletter without permission.
If you found this article useful and have not
yet subscribed to AECbytes, please consider
doing so. Subscription
is free, and more subscribers will allow this
publication to provide more of such content
Tricks > Type versus Instance Parameters in Revit > Printer-friendly