Hidden Parameters: The Key Under the Mat

Locking parameters inside of Revit content is sometimes a necessity: getting logic to work properly requires some gears to turn and parameters that hold and relay data. In very complicated families that include arrays, moving components, or even error messaging if multiple incompatible options are chosen, the amount of parameters can quickly build up. Revit has a built-in solution to hide those parameters, to keep families clean and only present information that will be important to users of the content: hidden parameters. Little known and under-utilized, hidden parameters can really clean up content when used properly. The best part is it only requires one extra step after the parameter has been made – so they’re fast, easy, efficient, and add functionality. What more can you ask for in a modelling technique? As an example I will be making a simple box with three types of different dimensions and colors, locked out, with the “key” hidden from the user.

The process of creating a hidden parameter begins like a normal shared parameter. When adding a parameter to a family, select the “Shared” option instead of family. It might make sense to create a new file specifically to hold hidden parameters, to keep them segregated from other shared parameters and to make them easy to access. There is no obvious way to tell if a shared parameter is hidden without loading it into a Revit project, so a separate hidden parameters file would make that distinction: any parameter within the file, will be hidden. No guessing or testing involved. For this example I made a new shared parameter file simply called “Hidden Parameters” and a group within the file named “Constraints”.

Hidden Parameters 1

Hidden Parameters 2

Create a new file if needed. Groups can be added to the file once it is made.

Revit Quirk Alert: An important note here before continuing is to go through the entire creation process, including the step to make the parameter hidden, before adding the shared parameter to a family. If it is added to a family before being turned into a hidden parameter it will be visible.

Add any necessary parameters to the file as they are required: there is no limit on the data type of a hidden parameter. Once any parameters have been created and added, they can be used inside of the family as normal. Since these are shared parameters, I prefer to name all of my hidden parameters with a “z” in front, such as “z Type”, “z Width”, “z Model Number”, etc. This will put them at the bottom of the parameter list inside of a project and also signifies that the parameter is hidden in the family editor.

Now for the final step (really, that’s it!): open the shared parameter file in a .txt file editor such as Notepad. The first thing you’ll see is a message to not edit the file…

Just ignore that.

You’ll then see a list of parameters as well as how they are organized inside of Revit and some data that lets Revit know how the parameter is used. Change a single value: the second integer. It will be a “1”. Change it to a “0”.


Hidden Parameters 3

Save the file and you’re done. Now that parameter is hidden in a project when added to a family.

For my example I made two hidden parameters: “z Type” and “z Material”. The visible dimensions are locked out using z Type, and the material (which can not be locked – just the nature of material parameters since they are unable to use formulas) is hidden so it cannot be modified in a project.

Hidden Parameters 4

Hidden Parameters 5

Dimensions locked and materials changed by hidden parameters. Note that there is no “Constraints” category in the Type Properties.

Revit Quirk: Mismatching Units and Hidden Parameters

Revit has a lot of quirks that need to be worked around, and that means finding those workarounds and taking advantage of them. There was an issue with units in previous versions of Revit (that has since been resolved – thankfully) that led to developing a useful trick: using hidden values to drive visible ones.

Before Revit 2014:

There were parameters that had issues displaying the correct way. For example, setting a piping flow rate to GPM with a formula would give an incorrect value using Air Flow units. Revit 2013 and earlier treat all flow formulas as Air Flow – it is hardwired in – even when dealing with piping, so using formulas can get tricky inside of families.

Project units set to GPM

Project units set to GPM

New parameter - Piping, Flow

New parameter – Piping, Flow

Formula uses CFM, Parameter's Units are in GPM

Formula uses CFM, Parameter’s Units are in GPM

As you can see in the above images, even while project units were set to GPM for flow the formula field only accepted values in CFM, the Air Flow project units. What’s more, it will only accept whole values: no fractions and no decimals. While the GPM field itself can be set to any value, locking it out with a formula is where the issue comes up.

Here’s where the workaround comes in.

If you use other parameters to store the value, and then only reference those parameters inside of a formula, it skips the conversion that normally takes place and displays the desired value. – in the correct units, to the correct unit accuracy. If the ‘storage’ parameters are made as Hidden Parameters, then they are not visible in the properties palette in the project.  Parameters that present value to the user remain visible while the ‘Storage Parameters’ do not (in this case, Flow Rate).  The great part about this is that whatever your project units, they will always be accurate. Even though the parameter that holds your “actual” GPM is hidden, changing project units to L/s will convert its value to L/s, etc.

To create a Hidden Parameter, all that needs to be done is to change a Shared Parameter’s “Visible” value to 0 inside of the shared parameter file prior to writing the parameter to the family.  A future post will focus on this little known feature and how INVIEW uses it extensively.

Revit 2014 and Beyond:

In current versions of Revit, the Formula units now match the units shown in the Value field.  However, the rounding increment shown in the formula field doesn’t always match what is shown in the Value field.  If a number gets rounded inside of a formula, its true value is lost: as far as Revit is concerned, the rounded value is the value that was initially input as soon as the Types dialogue is closed. For example, while still working in the same instance of the Types dialogue, a 1.5 that was rounded to 2 inside of a formula will read as “1.5” in the output, but once the dialogue is closed and reopened, it will read as a 2. Changing unit precision will not resolve this problem since the formula itself was “edited” to have the rounded value. This issue is most prominent with small values: fractions of a unit that when rounded, are lost.

A simple way to recreate this is to set Project Units to Feet and fractional inches. Unit precision does not matter in later versions of Revit: formula fields are very precise, regardless of project unit precision. If you were to create a Length parameter and set its Formula to a static value of .05”, it automatically converts to a fraction of 13/256”. Press okay to close to the types dialogue, convert project units to decimal inches, and reopen the types dialogue. You’ll see that the original value was lost and is now .051”. Values that small are not usually an issue – but it is something to keep in mind and is solid evidence to easily reproduce. Once a unit is rounded, its original value is lost in the family editor.

Storage Parameters:

Storing values inside of hidden parameters have quite a few uses, and prevent mistakes inside of families: values that would otherwise be unlocked and rely on the user to not change them can be locked completely, and unit accuracy can be guaranteed.

Let’s say there was a family that absolutely needed ¼” accuracy at all times. If you do not want Revit to ever round that value up or down, create two Hidden parameters: “Number” (Discipline: Common, Type: Number) and “Unit” (whatever your desired unit is. In this example, Discipline: Common, Type: Length). They will feed into a third parameter, “Visible Value” (same unit type as the “Unit” parameter. This parameter will be what users see). Set the “Number” parameter to be .25. Now use the “Unit” parameter, unlocked, to hold the value you want to set: if you want that ¼” accuracy, set the parameter to be 1”. In the formula field of the “Visible Value” parameter that users will be using, multiply the two hidden parameters together: in this example Number * Unit. Since “Number” and “Unit” are hidden they will not be seen inside of a project, but the Visible Value field will always be accurate – even if it’s rounded up or down by the project units, its value remains constant.

The usefulness does not end there: you can also use Storage Parameters to lock the values of parameters that always exist in a family, like Model and Description. If you had four separate types with unique values (such as a Part Number, Ordering Number, or SKU) you could use a hidden storage parameter to lock them out by Type instead of leaving the values open. The same goes for changing dimensions – multiple types with different Width, Height, and Depth could all be locked using a hidden value.

When I create a family, I usually name that Storage Parameter “z Type”, and there are very few families that I make without it: set “z Type” to be a different value for each of the types in a family, set all of the formulas to look for a specific z Type that informs them what their value is supposed to be. Voila: completely parametric family with locked values to prevent mistakes wherever they are needed. Correct “Cost” values for every type, security cameras that have the correct horizontal and vertical field of view, depending on lenses… The possibilities are endless.

Geometric Point Manipulation: Parametrics Made Easy

You should always try to be as efficient as you can when making Revit families. Always try to keep them as neat and organized as possible. Sometimes doing things the quick way can cause issues and take up more time down the road if updates are needed.

When creating families for Revit content it is important to get the most out of your models. Sometimes it’s more efficient to have one parametric family that contains twenty configurations rather than twenty static models: it helps to lower the impact on your project’s file size and gets things running smoothly. Another bonus is that time is saved when making an edit: changing multiple families when they could have been one is a time-waster. However, if a family is not built properly from the ground up it can still have a big impact on your project.

There are quite a few methods that lead to more parametric models. One of the biggest impacts on file size is from having a large number of lines (or geometry). Keep in mind that Revit doesn’t just track each extrusion but every line they are created from, so it is best to keep that number as low as possible.

One way to build numerous products into a single family is to use multiple sets of geometry and visibility parameters. Say, for example, that you need a table family with differently shaped table tops. By using this method, you would make all the different table tops as separate extrusions and control their visibility through parameters. This may not always be the best approach: each additional table top drawn adds more file size.

Another, more economical, method includes having a single extrusion that is manipulated to change between different configurations. One way to accomplish this would be to constrain the points (edges) of the extrusion. For this example we will build a table family that will have multiple table tops all varying in size and shape. It’s best to start with the most complex version, or the one with the largest number of sides. We will start with an octagon and have it change into a hexagon and then to a square.

  • The easiest way to start this extrusion would be to use the polygon tool to draw an eight sided shape.
  • Draw reference planes at every intersection where two lines meet. There should now be a total of ten reference planes, including the Center Left/Right and Center Front/Back if drawn in plan view.

Image 1

  • Now you can constrain all of the points of the polygon to their respective planes. Consider this creating an axis for each of the points. Keep in mind that at an intersection of two lines only one needs to have its point constrained.
  • Draw dimensions between the outer reference planes to set the overall width and depth of the table top.
  • Set dimensional parameters from the inner reference planes to the outer ones. These will be the offset parameters that allow you to control the number of sides on the table. To change the table top from an octagon to a hexagon, we just need to reduce the right and left offset parameter to zero. Similarly, if we want a square top we need to also change the front and back offset parameter to zero. This allows us to manipulate extrusions a little more by controlling the number of sides of our polygons: complexity of the geometry is altered using only length parameters.

Image 2Image 3

Another way to make families more parametric is through the use of nested families. Nesting families is a great way to save time and add more functionality to your models – but using nested families also brings up your file size quite a bit. Nesting a lot of families into one model can quickly bloat file size, especially when there are families nested several levels deep (nestception). If a nested family is needed it is best to have as few of them as possible. Try to make your nests as efficient as you can, since one complex nested family will have less of an impact than multiple simple ones.

For complex models, getting lost in your reference planes is a common issue. There are a few solutions for this as well. If you have overlapping planes, it is best to name the individual planes so you can keep track of what is locked to which plane. You also have the option to constrain within the extrusions by drawing reference planes within the sketches. When you do this, the reference planes will not be visible outside of editing the extrusion. When constraining inside the sketch, make sure that you don’t find yourself drawing redundant reference planes. Also, one of the major issues to watch out for is if someone else is trying to modify your model, it might not be apparent to them that the reference planes are there. If someone tries to constrain geometry (that is already constrained inside the sketch) to an outside plane, then they will start to get over constraint issues. It is always best to try and make the families in such a way that anyone can open it up and make changes without any prior knowledge of the model.

Shedding Some ‘Light’ On Type Catalogs

For each family category, there are certain built-in parameters such as ‘Model’ and ‘Description’ and in the case of the Light Fixture category there is also ‘Lamp’ or ‘Coefficient of Utilization’. Furthermore, for the Light Fixture category, additional parameters are added when ‘Light Source’ is checked in the Family Category and Parameters dialogue.  I call these parameters the ‘Problem Children’ because their values are tricky to control. The difficult thing about building a light fixture that represents a manufactured product is knowing how to best do this.

These parameters are held inside of buttons, which makes controlling them via formula impossible.  The only alternative to formulas is to utilize Types or Type Catalogs.  Revit Quirk Alert:  the names needed in a type catalog to control these parameters are different than the actual parameter name.

Problem Children

“The Problem Children”

I worked on a family with well over 500+ types when all of the options were accounted for, so a type catalog was the best solution to make sure only the necessary types were loaded into a project.  I had struggled with the parameters for a while before coming across the solution, which is this:

For “Initial Intensity”, the type catalog needs to use the name “Luminous Flux”, and for “Initial Color”, “Initial Color Temperature” has to be used. When data type and unit are added in, that translates to:

Luminous Flux##Electrical_Luminous_Flux##Lumens


Initial Color Temperature##Color_Temperature##Kelvin