Defining Revit Custom Hatch Patterns

Over the years I have defined quite a few Revit custom hatch patterns, and each time I do it I get a headache!  It is usually about 6 months between each attempt at this so I pretty much have to learn it all over again each time.   The format for defining the hatch files (.pat) is so bizarre that it almost defies logic.  Almost, but not quite . . . .

The Autodesk help files have never changed much over the years, and just reading them gets me baffled each time.  So I decided to write my own help file that is actually understandable by human beings, so I can refer to in six months time.  And well, why not put it out there to see if anyone else finds it useful?  Of course there are now lots of  clever little hatch builder programs available, but sometimes you just want something quick and you may not have access rights to download and install that hatch builder.

For examples of stretcher bond brick or tile patterns refer to this post

The more complex example I am showing here is a series of octagons that are quite widely spaced - I originally created it to represent those 'tactile surface indicators' at the base and top of stairs.  The octagons do a pretty good representation of circles on a stair drawing.

The first step is to create a sample of the pattern using lines - say detail lines on a drafting view.  You probably need to show a couple of repeats in each direction - true octagons are simple to create using the 'Polygon Tool' with only two mouse-clicks.

When the octagon is repeated in a Revit pattern, it does not replicate the octagon shape - it actually treats each line as totally separate, and repeats those in two possible directions.  So in order to understand which lines are repeated where, I have colour coded them.  This pattern is based on a 1000 mm square grid with the space between each octagon exactly the same as the octagon width, which means that the orthogonal lines are repeated every 1000mm, exactly offset from each other - a very simple pattern.  The diagonal spacing between octagons is quite different to the octagon width - so the repeats of diagonal lines are much more complex . . . .

Pattern Definition Format

The pattern file is just a text file, saved with a '.pat' extension.
The overall file can have descriptions at the beginning;  it can also have an overall definition of units (important for metric):
;%UNITS=MM

Each pattern definition needs a header prefixed by an *:   a title and description separated by a comma
      *Octagons 1 x spaced,   1000mm spaced and width octagons
It also needs a type definition (Drafting or Model)
      ;%TYPE=MODEL
Each line repeat (in the pattern) is described in one line of text, with comma delimited format.  eg:
0,     1200, 1000,         0,  1000,       400,  -1500

• Angle  = angle of line from horizontal measured in an anti-clockwise direction
• Origin x = horizontal distance of start of line from setout point (always orthogonal)
• Origin y = vertical distance of start of line from setout point (always orthogonal)
• Shift u (x) = offset distance of start of repeat line measured parallel to start of line
  (in the direction of the line,  ie. to match the angle)
• Shift v (y) = offset distance of start of repeat line measured perpendicular to start of line
• Pen down = length of solid line measured in the direction of the line
• Pen up = length of gap in the line before the next segment of the line starts repeating (measured in the direction of the line);  is always a minus value.

Notes.

• The Shift values define the repeats in the direction perpendicular to the line.  The Autodesk help files mislead by calling them x and y values - I prefer to think of them as u and v values, which are not necessarily orthogonal.  The Autodesk help files completely omit to mention that they are measured parallel & perpendicular to the line.
• The Shift values are measured from the start of the line, not from the setout point - another vital piece of information that the Autodesk help files neglect to tell you.
• The pen down/up values effectively define repeats in the direction of the line.  They are optional.  If they are omitted, you get a continuous line
• The pen down/up repeat is inconsistent with origin & shift because the coded value of Pen up is the distance from the end of the line to the start of the next - the repeat distance is actually the total of Pen down and (minus) Pen down.

Octagon Pattern Example

The horizontal lines (black)
Angle = 0
Start line x from origin = 1292.9
Start line y from origin = 1000
Shift u of repeat from line start = 0   (ie. it is a direct perpendicular offset)
Shift v of repeat from line start = 1000
Pen down = 414.2    (length of octagon side)
Pen up =   -1585.8   (distance to start of next octagon line from end of first)

0,   1292.9, 1000,         0,          1000,       414.2,  -1585.8

The vertical lines (blue)
90,  1000,    1292.9,     0,          1000,       414.2,  -1585.8

The 45° angle lines (red)
45,  1707.1, 1000,        1414.2, 1414.2,    414.2,  -2414.2

The opposite 45° angle lines (purple)
45,  1000,    1707.1,     1414.2, 1414.2,    414.2,  -2414.2

The -45° angle lines (green)
-45, 1000,   1292.9,      1414.2, 1414.2,    414.2,  -2414.2

The opposite -45° angle lines (orange)
-45, 1707.1, 2000,        1414.2, 1414.2,    414.2,  -2414.2

Pattern File
*Octagons 1 x spaced,
;%TYPE=MODEL
0,   1292.9, 1000,         0,          1000,       414.2,  -1585.8
90,  1000,    1292.9,     0,          1000,       414.2,  -1585.8
45,  1707.1, 1000,        1414.2, 1414.2,    414.2,  -2414.2
45,  1000,    1707.1,     1414.2, 1414.2,    414.2,  -2414.2
-45, 1000,   1292.9,      1414.2, 1414.2,    414.2,  -2414.2
-45, 1707.1, 2000,        1414.2, 1414.2,    414.2,  -2414.2

This needs to be saved as a '.pat' file type before it can be used in Revit.  It can be edited in a simple text editor like 'Notepad'.

Notes:

• The angle for the last two could be 135° instead of -45°, but the measurement direction would then be in a backward direction, which could be confusing to figure out.
• If the width and spacing of octagons are not the same, you would need to define two lines at zero and two at 90 degree angles (like the 45 degree line definitions).

I hope this saves me hours of grappling with the file format and help files next time I need to create a quick pattern in Revit.

For examples of stretcher bond brick or tile patterns refer to this post

Hollow Section Sweep with Adaptive Profiles in Revit

Two years ago I posted a description on how to use adaptive component profiles to create a swept blend form in the Conceptual Massing Environment (CME).  Recently someone asked how to create a hollow steel section sweep in CME.  I realised that I had neglected to mention something about adaptive component profiles that makes them different in yet another way from the traditional family editor:

Traditional Family Editor vs Conceptual Massing Environment - (again)

When you create a profile family in the traditional family editor it is by nature a 2D element (this is dictated by choosing the profile template to create the family).  It also has rules about what it should contain - basically it must be a single closed loop (or chain) of lines/arcs.  When you try to assign it to another family, Revit will pretty soon tell you what is wrong with it if you don't follow the rules:

 In the CME, you have to just create an adaptive component that has some lines in it.  Only you (and your naming convention) know that it will be used as a profile for sweeping or lofting forms.  If you try to create a form using an adaptive profile that has a loop inside a loop, Revit will tell you that it does not like it at all - but absolutely no explanation why:

Select a path and two profiles with nested loops

Extremely unhelpful error message when you try to create a form

How to create a hollow section sweep in the CME

The first step is to create an adaptive component profile that only has a single chain of lines/arcs - this is by nature a flat 3D family.

• Then the profile can be loaded into another adaptive or mass family (external or in-place) 
• Host the adaptive profile on the sweep (preferably using points to get maximum control).  Refer to the post on swept blends for more detail.
• In this example I have only hosted one profile at each end of the sweep, and they are the same size, but you could have different sizes and intermediate profiles to create a lofted form.
•  Select the path and two profiles

• Create Form - it should create a solid sweep form providing the path is not too tortuous for Revit to handle.

• Place two more profiles (smaller this time), preferably hosted on the same points

• Select the same path plus the two smaller profiles

•   This time create a void (use the drop down arrow on the Create Form icon)

• Revit should then carve out the inside of the sweep to create a hollow form

If it does not do so automatically, you may need to use the 'Cut' command to cut the void from the solid form. 

Voila - a hollow steel section sweep.  Both the solid and void forms are hosted on the same sweep path so they will move when it changes.

Tagging what is in a Revit Key Schedule

What, no Shared Parameters in Key Schedules?  It is a total pain.  If you'd like Autodesk to fix this Revit Roadblock, please vote for the enhancement on their Revit Ideas:
Please Fix Key Schedules
 This request has been 'Under Review' for several years, and it needs kicking along.

I have been endlessly frustrated by the fact that you cannot include shared parameters in Key Schedules in Revit.  This means that anything you put into a key schedule can only be used in other schedules - it cannot ever be tagged.
Or so I thought. . . . .

I recently discovered that you can add some system parameters to key schedules, which means that you can use those in schedules and tag them too.  As with most things Revit, the rules for this are weird and (not so) wonderful.

Rule no. 1:   

Shared parameters, have a secret GUID that ensures their uniqueness - you have to add them to schedules by picking them from a list of already available parameters or by adding them from the shared parameter list.  Likewise system parameters in a schedule or key schedule need to be picked from a list of available ones.  It is only too easy to create new parameters by typing in names that seem to have the same name as system parameters - you won't know which is which, as they appear together in lists.  It is only when you start populating them or using them in (key) schedules when you realise your mistake.
For this reason it is really important never to create your own parameters that are the same name as system (or shared) parameters.  With shared parameters it is a little easier as you can go into the definition and check if it was shared or not.

Rule no. 2:  

Once you use a system parameter in one key schedule, it cannot be used in other key schedules of the same category

When you first create a key schedule, you get a list of available fields on the left.  This is a jumble of system parameters and project parameters that you might have created (but not shared parameters).  Because the list is radically different for each category (and varies with subsequent key schedules), I never realised the significance of that list

Rule no. 3:  

Different categories allow different system parameters to be used in key schedules.  There is no rhyme or reason as to which ones will work - you just have to know.  For most categories it is just "Comments".

Categories that do not allow any system parameters in a key schedule include:

• Grids 
• Levels

Categories that allow 'Comments' as a system parameter in a key schedule include (NB. I only checked the ones that show up when listing "Architecture" categories):

• Assemblies
• Casework
• Ceilings
• Columns
• Curtain Panels
• Curtain Systems
• Curtain Wall Mullions
• Detail Items
• Electrical Fixtures
• Entourage
• Floors
•      Floor Slab Edges
• Furniture
• Furniture Systems
• Generic Models
• Lighting Fixtures
• Mass
•      Mass subcategories (I only checked Mass Floors)
• Mechanical Equipment
• Parking
• Parts
• Planting
• Railings
•      Handrails
•      Supports
•      Top Rails
• Ramps
• Roofs
•      Fascias
•      Gutters
•      Roof Soffits
• Site
•      Pads
•      Property line segments
•      Property Lines
• Specialty Equipment
• Stairs
•      Landings
•      Runs
•      Supports
• Structural Beam Systems
• StructuralColumns
• Structural  Connections
• Structural Foundations
• Structural Framing
• Structural Rebar
• Structural Stiffeners
• Topography
• Walls
•     Wall Sweeps
• Windows

Categories that allow multiple system parameter in a key schedule include:

• Areas

         Wow, the programmers really spoiled us by allowing the use of the Name System Parameter - but don't get too excited because this has to be shared across all Area Schemes.  So if you use it for a Rentable Area Key Schedule, it will not be available for a Gross Building Area key schedule

• Doors

         Out of all the 40+ door system parameters, they gave us those!  How useful.

• Electrical Equipment

          It looks like the Electrical engineers are being favoured for a change.  But not the mechanical engineers who only get 'Comments' for their equipment.

• Plumbing Fixtures

• Rooms

Now this should give us something to work with - although we only get text and material parameters, that should be very useful as those are the ones we most likely want to tag.  I can't imagine wanting to put the finishes into a key schedule as most likely each room could have different finishes - but if you have say a hospital where there are many similar rooms, you might create a key schedule of room types, and those could have preset finishes in a key schedule?

The list of categories/system parameters above is not comprehensive - structural and MEP engineers will need to do some inestigation on the categories that do not show up when the list is restricted to "Architecture" categories.

Conclusion

Well, at least we do have some system parameters we can use in Key Schedules.  However the list is very limited, so use them wisely - plan your schedules and tagging needs before you start creating key schedules.  Don't forget that if you have multiple key schedules for a category, the available system parameters can only be used once per category (not once per key schedule).

An example of when you might use one of these precious system parameters could be for rooms or areas - naming the apartment type as say '1 BED' or '2 BED'.  This value could then appear in a schedule, a tag and in properties.  Associated with each apartment type could be all sorts of standards such as minimum areas, rates and parking requirements etc - these would only appear in schedules and properties (and they could be there just for use in calculations).  Things you would not include in the key schedule would be unique information that varies per room or area.