BILT

BILT
Speaker

Sunday, 17 March 2019

Glazed Doors in Window and Door Schedules in Revit

I started out writing this blog post about the behaviour of subcategories in nested families.  On closer investigation, the weird behaviour I intended documenting was not as I had thought - still a bit strange but not quite worthy of a post all to itself.  So I have changed tack and turned it into a discussion about how to get a glazed door family to appear in both door and window schedules.  Many experienced Revit users should already know this, but for those who do not, read on.

Schedules and Categories

Typically door and window schedules are created separately as single category schedules. Multi-category schedules have too many limitations to make them work efficiently for this task. A door or a window is usually either one of those categories, and therefore it can only appear in one of the schedules.  What if you have a window assembly that contains a glazed door? or a sliding glass door, which you want to show in the window schedule (because it is glazing), but also in the door schedule (because it hosts door hardware)?  This common requirement seems problematic in Revit, but there is a way around it . . .

Workaround:

Shared Nested Family

When a nested family is 'Shared', it behaves differently to the parent family in terms of subcategories.
For example, you might have a window parent family, that contains just a frame (or a fixed glass side panel).  Inside this could be a nested sliding door family.  Providing the door family is set to 'Shared', then it can have its subcategories independently controlled (by View Visibility) in the project;  it can also be individually selected, tagged and scheduled (as a door); the parent family can be tagged and scheduled as a window.

Nested Door Family Category Settings

Nested Door Family Subcategory

Parent Window Family

Parent Family Category

Parent Family Subcategories

Nested Door Family in Parent Family

Tagging and Schedules

Standard door and window families are normally tagged separately according to category
Once placed in a project, the combined door/window family can be tagged for either category:




Tag the whole family for the window category tag

Tab select the nested door family to tag it

Scheduling

  • The combined window/door family will appear in a window schedule. 
  • The Nested door family will appear in a door schedule

Category Visibility

This example shows a single swing door nested family in a window family (with fixed window panels either side).  In the project, both door and window categories/subcategories affect the sub-element display:
All Categories On

Door Panel Subcategory Off

Window Category Off - Door Category On

Non-shared Nested Family Categories

When a normal 'non-shared' family of one category is nested inside another family of a different category, it behaves as if it is part of the parent family in terms of categories.
Unshared Family Settings
In the parent family (in Family Editor), the nested family still shows its category when selected
Non-Shared Nested Door Family in Window Parent Family
When loaded into a project the whole window can be selected, but not the nested door family. 

Window family with non-shared nested door - in project

Changing the visibility of the Door category does not affect the nested door.
Door Category Off, Window Category Visible

Hiding the Window category, (while the door category is visible) hides the whole family, including the nested door
Door Category Visible, Window Category Off

This behaviour is as expected.

Weird Revit Behaviour:

Non-Shared Nested Families

However, if the nested families have elements of a specific subcategory (of the Nested family category - door) the element's visibility is still controlled by that nested family subcategory.  This does not really make sense if the nested family is not shared.
Door Panel Subcategory Off


This can be very confusing, as you have no way of knowing what category the nested family is, without editing the parent family.  As far as the user is concerned, the family is a window - since you cannot select the nested door in the project, the user will not be aware that it even has a nested family, let alone that a subcategory that has nothing to do with windows will still affect it.


Sunday, 17 February 2019

Stretcher Bond Hatching in Revit

A few years back I posted a description of how to create a complex custom hatch pattern for Revit - that example was for repeating octagons.  Since then I have often needed to quickly create much simpler patterns such as stretcher bond elevation views for bricks, blocks and tiles.  The Octagon pattern was quite complex and it still takes a while to get your head around the logic - so here is a much easier to follow set of examples:


Pattern Definition Format

The pattern file is a text file, saved with a '.pat' extension.
Definition of units (important for metric):
;%UNITS=MM

Each pattern definition has an * prefixed header :   a title and description separated by a comma
      *Stretcher 400x200,   400mm x 200mm stretcher bond
Drafting or Model definition:
       ;%TYPE=MODEL
Each line repeat (in the pattern) is described in one row 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 axis of line) = offset distance of start of repeat line measured parallel to start of line
    (in the direction of the line,  ie. to match the angle).  The Shift values are measured from the start of the line, not from the setout point.
  • Shift v (y axis of line) = 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 (optional - it draws a continuous line if omitted)
  • 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.  (optional - as per pen down)
NB. I have labelled the shift directions as u & v (not x & y, as Autodesk labels them) because the directions relate to the axis of the line, not the whole pattern - so a vertical line would have a u offset measured vertically (labelled as x direction by Autodesk, which is confusing).

Stretcher Bond Hatching Definitions


A typical staggered tile pattern (stretcher bond) consists of :
  • a series of continuous horizontal lines at regular spacing;
  • Short vertical lines that run between alternate horizontal lines, at a spacing equal to the length of the brick/block/tile
  • Another set of short vertical lines that run between alternate horizontal lines, at a spacing equal to the length of the brick/block/tile - but these are typically offset horizontally by half a length and vertically by one pattern height.
These should almost always be defined as MODEL patterns, as they are meant to be dimensionally correct on the surface of the material.

There are actually two ways to define this:

Option 1 - separate definitions for the two vertical lines

*Stretcher-450x150-1/2,      450 x 150 1/2 stretcher bond
;%TYPE=MODEL
0,         0,0,           0,150
90,       0,0,           0,450,        150,-150
90,    225,150,      0,450,        150,-150

The first row defines the horizontal lines
0,         0,0,           0,150
  • The lines are at zero degrees (horizontal)
  • The first line starts at 0 offset from the origin, both x and y (0,0)
  •  The repeat has a shift of zero horizontally (x or u), and 150mm vertically (y or v) from the line origin (0,150),
  • The next repeat is the same values (0,150) from the start of the previous repeat. 
  • The line is continuous, as the are no pen up/down values




The second row defines the first set of vertical lines
90,       0,0,           0,450,        150,-150
  • The lines are at 90 degrees (vertical )
  • The first line starts at 0 offset from the origin, both x and y (0,0)
  •  The repeat has a shift of zero vertically (u) , and 450mm horizontally (v) , from the line origin (0,450)
  • The next repeat is the same values (0,450) from the start of the previous repeat. 
  • The line is segmented, 150mm solid, 150mm gap (pen up/down 150,-150)
The v shift in this instance is horizontal, perpendicular to the line, with a positive value to the left of the line origin (same as pattern setout point in this case). 
  • As the pattern is symmetrical, it makes no difference if the v shift value is positive or negative
  • Seen below in context, the pattern repeats in both directions from the origin:








The third row defines the second set of vertical lines
90,    225,150,      0,450,        150,-150
  • The lines are at 90 degrees (vertical )
  • The first line starts at 225mm x offset from the origin, and 150mm y offset from the origin (225,150) - ie. half a tile along and one tile up.
  • The repeat has a shift of zero vertically (u) , and 450mm horizontally (v) , from the line origin (0,450)
  • The next repeat is the same values (0,450) from the start of the previous repeat. 
  • The line is segmented, 150mm solid, 150mm gap (pen up/down 150,-150)
 


Option 2 - one definition for both vertical lines

*Stretcher-450x150-1/2,      450 x 150 1/2 stretcher bond
;%TYPE=MODEL
0,         0,0,           0,150
90,       0,0,       150,225,        150,-150


The first row defines the horizontal lines as per previous method
0,         0,0,           0,150

The second row defines the vertical lines
90,       0,0,       150,225,        150,-150
  • The lines are at 90 degrees (vertical )
  • The first line starts at 0 offset from the origin, both x and y (0,0)
  •  The repeat has a shift of 150mm vertically (u) , and 225mm horizontally (v) , from the line origin (150,225)
  • The next repeat is the same values (150,225) from the start of the previous repeat. 
  • The line is segmented, 150mm solid, 150mm gap (pen up/down 150,-150)


  • As the pattern is symmetrical, it makes no difference if the u and v shift values are positive or negative
  • Seen below in context, the pattern repeats in both directions from the origin:


One Third Shift Patterns

The same principles can be applied when the bond is staggered by differing proportions.


Option 1 - separate definitions for each vertical line


*Stretcher-450x150-1/3,   450 x 150 1/3 stretcher bond
;%TYPE=MODEL
0,          0,0,         0,150
90,        0,0,         0,450,       150,-300 
90,    150,150,     0,450,       150,-300
90,    300,300,     0,450,       150,-300


 90,    150,150,     0,450,       150,-300

  • 90 degrees
  • 150mm x line origin, 150mm y line origin
  • Zero u shift repeat, 450mm v shift repeat
  • 150mm Pen Down, 300mm gap (Pen Up)




 90,    300,300,     0,450,       150,-300
  • 90 degrees
  • 300mm x line origin, 300mm y line origin
  • Zero u shift repeat, 450mm v shift repeat
  • 150mm Pen Down, 300mm gap (Pen Up)

Option 2 - one definitions for all vertical lines

*Stretcher-450x150-1/2,      450 x 150 1/2 stretcher bond
;%TYPE=MODEL
0,         0,0,           0,150
90,       0,0,       150,300,        150,-300
Horizontal shift (v) repeat has to be 2/3 of a tile (300mm)

As the joint offset is not half a tile, the same result can be achieved with a negative v shift repeat of -150mm:
0,         0,0,           0,150
90,       0,0,       150,-150,        150,-300



An offset by one third to the left could be achieved by a positive 150mm v shift:
0,         0,0,           0,150
90,       0,0,       150,150,        150,-300


Two Third Shift Patterns

Some patterns cannot have their vertical lines defined by only one row, as you can't define a consistent diagonal repeat.  Therefore you must have multiple rows for the vertical lines.

*Staggered-450x150-2/3, 450 x 150 2/3 stretcher bond
;%TYPE=MODEL
0,          0,0,        0,150
90,        0,0,        0,450,     150,-150
90,    300,150,    0,450,     150,-150








The direction of stagger can be changed with the x origin value:

*Staggered-450x150+2/3, 450 x 150 2/3 stretcher bond
;%TYPE=MODEL
0,          0,0,        0,150
90,        0,0,        0,450,     150,-150
90,    150,150,    0,450,     150,-150

Flemish Bond

More complex brick patterns require extra rows of definition:


*Flemish-240x86,     240 x 86 (Australian Brick size) Flemish stretcher bond
;%TYPE=MODEL
0,           0,0,         0,86
90,         0,0,         0,360,       86,-86 
90,      240,0,        0,360,       86,-86
90,        60,86,      0,360,       86,-86
90,      180,86,      0,360,       86,-86




You could continue this theme with increasing random looking patterns, but I'll leave that for you to figure out . . . . . .




Saturday, 26 January 2019

How Do You Solve a Problem Like Ma Railings?


Have you ever encountered a problem with out-of-control railings in Revit?  OK, so maybe the structure shown above is not a haywire railing, and was meant to be like that, but most Revit users have struggled with trying to model railings as they should be.

How Do You Solve a Problem Like Ma Railings (in Revit)?  *


* with apologies to Richard Rodgers for misappropriating his song title (How Do You Solve a Problem Like Maria? from the Sound of Music, By Rodgers and Hammerstein) - not to be confused with Richard Rogers (no d), the architect who designed many famous buildings, such as the Pompidou Centre in Paris (with Renzo Piano) and the Lloyds Building in London.

Richard Rogers surely did not struggle with trying to model railings in Revit, as those buildings were designed long before the advent of such software.  These days we certainly do struggle with the software - Revit has been around for almost 20 years and it still it does not enable us to model Railings the way we want them (except for the most simple handrail).  There are many problems with the railing tool in Revit, some of which have been documented on this blog - see the list below.  Over the years, we have benefitted from several minor improvements to the railing tool - for which we are very grateful.  However, there is one fundamental problem that has not been resolved - and that is the inability to control the location of individual balusters.

Baluster Placement - a Fundamental Flaw

The railing sample file shows some relatively complex looking examples - but these are just straight runs on the level.  As soon as you try to use them on stairs, things start going wrong with the baluster placement.

This example is done using two alternating balusters - one is just a post, while the other is glass with fixings.  The glass baluster is very good at adjusting the angle of its top and base (if you create the family properly). 
 
When it comes to spacing, it is pretty hopeless:  you get gaps whenever there is a break in the pattern.
Standard railing with glass balusters
There are some limited controls within the baluster placement type properties, but no single combination of settings will ever work on the whole stair railing.

Spreading the pattern to fit does resolve some issues, sometimes. . . .

Changing the 'Break-Pattern' property to 'Never' can have some weird results

Reverting the pattern to 'Centred' does not fix it either - you may end up with panels across a change in angle, where the panel is not trimmed properly.

Workarounds

There are a number of ways that people get around these problems, but none of them is satisfactory:

1.  You can try using 'Handrail Supports' to represent balusters, but that has at least two problems:
  • Handrail supports do not respond to changes in angle of the stair, so you need to build that in as a user control that has to be manually set every time
  • Handrail supports can be unpinned and then moved (or changed to another type), but the moving process is very tricky - see Moving Handrail Supports
    It is also possible to very easily lose the positions by accidentally resetting the railing.
2.  Model the glass as a continuous rail element, use balusters and/or handrail supports to represent the fixings and vertical joints in the glass.  More on that another time.

3.  Model the railing 'in-place'.  This is a really bad idea as it screws up the subcategories, visibility etc;  And worse still, it does not update when the stair changes

4.  Just model a Top Rail / Handrail (with no balusters), which shows up in plan.  Document the railing in 2D as drafting views or as detail elements on stair sections.  This is a terrible solution (very un-Revit-like), but it can save huge amounts of modelling time - so it is done quite commonly in the industry.  Of course, it can lead to errors on site . . . .

Railing Fixes

If we had the ability to control the baluster placement in much the same way that curtain walls operate, it would help resolve this fundamental flaw in the railing tool;  this would require the ability to include variable width panels too.  Of course there need to be many other minor fixes in addition to that. 

On the Autodesk Revit Roadmap, Railings were flagged as 'fixed', a couple of years ago, on the basis of a number of minor enhancements.  Clearly it is nowhere near being fixed - see this request on 'Revit Ideas'  Railing Overhaul - Resolution of Limitations - from Chris Price (Mr Spot).

Weird Railing Stuff Blogs

Over the last few years I have posted many blog articles on the many weird quirks of using Revit to model Railings.  Some articles just document the inconsistencies and strange behaviour - just so you know what is going on; other articles offer some workarounds and ground-rules that might help you along:

Revit Railing Enhancement Requests

Autodesk  have a 'Revit Ideas' website that allows you to vote for enhancement requests.  I have compiled a list of stair/railing related ideas - please, all of you vote for some of these requests - if you don't vote, Autodesk will continue to consider them as fixed.

Sunday, 13 January 2019

Weird Railing Stuff - part 16 - Rail Hand Clearance Property

Following on from my previous post about Railing Offsets, here is some more detail about the ludicrously inconsistent UI for Handrails and Top Rail offsets in the 'New-style' railings.

Handrail Offsets

Handrails can only be moved laterally within the Handrail Type Properties (not in the railing properties).  This is controlled by a property called 'Hand Clearance'


The Hand Clearance property dictates how far the inside face of the Handrail is offset from the 'Notional Railing Centreline', which is not necessarily where the wall or other railing elements are*.

  • The Handrail family has a ‘Hand Clearance’ property, and projection property (see below)
  • In trying to use a real-world term, Autodesk have muddied the waters and made it totally confusing to work with.  This property is only logical with certain types of railings:
    • one example might be a wall-mounted handrail that has no other linear elements; and even then it only works when the Railing 'Offset from Path' property is set to zero.
    • If the railing has balusters and posts, with a Handrail mounted on those, the ‘Hand Clearance’ property does not take account of the baluster/post width, so you'd need to add in half that width yourself.

Once the Hand Clearance property is set in the Handrail family, you have to go back to the Railing family to see the effect it has on the whole railing, where the calculated Lateral Offset is displayed (not shown in the Handrail properties).

The Lateral Offsets are calculated by the system, depending on the Handrail type properties.  Typically this should be:
  • Hand Clearance + (Profile Width / 2)    - in this case  40 + 30/2 = 55mm.  
  • The Lateral Offset represents the centreline of the Handrail relative to the notional centreline of the whole railing (which is itself moved around by the 'Offset from Path' property).
  • If you want a centred Handrail, you need to make its hand clearance property minus half the profile width
Projection Property
  • There is another calculated property that is displayed here: 
    'Projection', which is calculated as (Hand Clearance + Profile Width)
    It is again greyed out, and updates immediately after any changes to the profile width or Hand Clearance.
  • I cannot see the logic of having this property displayed here, while the Lateral Offset is not.

Changing Properties

The knock on effects of any changes you make is again, a little confusing:
  • If you change the profile type, and hence its width then the 'Hand Clearance' is likely to change.  What Revit is trying to do is maintain the 'Lateral Offset' value, and hence the centreline location of the Handrail.
  • This may be logical to the software programmers, but not to designers, who would want to maintain the Hand Clearance when the profile width changes.  
  • The end result is that you need to pay careful attention, and manually change the Hand Clearance yourself after every profile change.
Once you have made any changes to the Handrail Type properties, then click OK, it returns to the Railing Type properties (if that is where you started from).  There is a display bug here:
  • The Lateral Offset does not appear to be recalculated (although it is).
  • To cause a display refresh, you need to change the value of the 'Position' to something else, and then back again.
  • Alternatively you could close the Type properties and reopen.

Wall-Mounted Handrails

In the case of Wall-Mounted Handrails, where there are no Top Rails or Balusters, the settings need to be somewhat different - and this is about the only situation where the term 'Hand Clearance' makes any sense.

The Railing Instance property 'Offset from Path' needs to be set to zero.  It is very frustrating that this is not a Type property, or at least have a default value stored within the Type properties - as you need to remember to set it to zero every single time you place a railing of this type.

The Handrail Type properties should be set with the actual Hand Clearance that you want - say 40 or 50mm.

Make sure that you choose the correct profile size first, as Revit will alter the Hand Clearance if you change the profile.

The Railing Lateral Offset property will be set automatically.


Top Rail Offsets

  • The Top Rail family also has a ‘Hand Clearance’ property, and projection property.
  • This is confusing - the Top Rail is meant to be there to support other railing elements, although it may double as a handrail. Whether it serves as a handrail or not, it would typically be centred with balusters etc on the 'Notional Railing Centreline', which is what the Hand Clearance value is measured from. 
  • Just to make it doubly confusing, the Top Rail offset is inconsistent with Handrail offsets:  a positive Hand Clearance value moves the Top Rail outside the stair in plan (Handrail moves inside stair).
  • Although the calculation for Lateral Offset is the same, it moves the opposite way:
    • (Hand Clearance + Profile Width / 2) - in this case  -25 + 50/2 = 0mm
  • If you want a centred Top Rail, you need to make its Hand Clearance property minus half the profile width of the Top Rail.

If you set the Hand Clearance to zero, you would get a Top Rail offset by half its width from all the balusters (unless they also had offsets . . .)



Here is  more information on the inconsistency between Top Rail and Handrail Terminology