Friday, 18 April 2014

A Dozen Reasons Not to Use Adaptive Components in Revit

I love the idea of Adaptive Components in Revit - they have so much potential to allow us to break free of some of the traditional constraints of Revit.  But it is early days in their development - they have many of their own limitations.

However wonderful adaptive components are in Revit, they do have some downsides.  I have heard suggestions that we should all use adaptive components all the time instead of traditional Revit families.  Here are some reasons why you might not want to do that - and perhaps Autodesk can treat this as a checklist of things to address so that we can use them in more situations:

  1. Adaptive components do not have any 2D or 2½D capability - there is no Annotation tab in the adaptive family editor.
    - No text within Adaptive Components
    - No symbols
    - No symbolic lines
    - No detail components
    - No filled or masking regions within Adaptive Components
  2. You cannot add model text within Adaptive Components (except by nesting a traditional family with model text in it).
  3. Adaptive family file sizes can get extremely large, especially when you start nesting them or use repeaters. They don't seem to have the same capabilities of minimising file sizes that traditional families have when multiple instances of nesting occur.
  4. Visibility Settings are not available within Adaptive Components (for controlling display levels and 2d view visibility) 
  5. Controls are not available within Adaptive Components (for controlling flipping component orientation) - this is somewhat understandable as it could get complicated with multi-point adaptives;  nevertheless it is a limitation.
  6. If any one adaptive point is snapped to (hosted onto) an element that is subsequently deleted, the entire adaptive component also gets deleted, no questions asked.  Scary huh?  This means that adaptive components behave more like true hosted families (doors, windows) that are completely dependant on hosts;  it would be much better if they behaved like face-based families that exist quite happily after their host face is deleted (refer to Chris Price's blog on Face Based Families).
  7. Placement of adaptive component points in the project do not lock to orthogonal - they do not use the Revit smart snapping capability, except for snapping to vertices and edges.
  8. Placement of "Site" category adaptive component points in the project do not snap/lock onto toposurfaces, unlike traditional site families.
  9. You can copy levels in adaptive families but they do not behave like two-level families (columns, generic) that have the levels baked into their templates, which then automatically lock to assigned levels in the project.
  10. Adaptive components cannot have a host element baked into the template – so it is not possible to include a void element in the adaptive component that will automatically cut the host face it is placed onto.  “Cut with voids when loaded” capability is very limited in categories it can be applied to – it cannot cut curtain panels, curtain systems, mass categories etc.
  11. As adaptive family templates do not contain any host elements, it limits the possibilities for using reporting parameters within formulas to adaptive points only - no wall thickness dependant frames etc.
  12. If you tag an adaptive component that has more than one adaptive point, the tag moves if any of the adaptive points move in the project - meaning that annotation on drawings will become even more unstable.

This is not a list of reasons to never use adaptive components.  It is more a checklist to warn you of some limitations , so that you can plan when best to use them.  The list is not comprehensive - for example, it does not address issues of hosting, and analysis that might be vital for MEP or structural families. This list does not address the operational differences or difficulties within the adaptive family environment - for more detail on this, refer to Rival Revit Environments.

Don't plan to replace your traditional Revit library with an adaptive version just yet.

Friday, 11 April 2014

New in Revit 2015 - Schedules & Parameters

We still don't have a definitive list of what is new in Revit 2015, but here are a few more details about some of the new features - with the proviso that I don't have my hands on the final release version so I can't be a 100% sure I have the details right.  But you will be able to test the software as soon as you have it, and you'll know what to look for.
[Edit:  Autodesk have now published their v2015 help online, including the Whats New in 2015 section;  be sure to check out the Upgrade Information section]


Parameter Reorder

Up until Revit 2015, the sort order of Revit parameters in the family editor and in the project was a mystery to most people.  It starts off adding parameters in reverse alphabetic order;  but as you start changing parameter names it soon goes haywire and the order becomes unpredictable.  Various people have come up with ingenious workarounds to reorder parameters but those methods are painful to say the least.  A fix for this problem has been on wishlists for Revit from the early days.  In Revit 2015 a partial solution has been applied to a very tricky problem to solve.

This new feature has several parts to it:
1.  You can change the order that new parameters will be added in the family editor
  • It can be set to ascending or descending alphabetic order.

  • You might think that it will be a simple decision to make it "Descending" as this is how almost every (latin) alphabetic list is sorted.  The one exception to this in Revit is how the family editor used to work - reverse alphabetic (to start with).  So if you want semi-consistency with all your old Revit families you might go with the old method of "Ascending".
  • Personally I will set it to the normal alphabetic order "Descending" as soon as I get my hands on it - so that we can start getting some logic to new families (the old ones are all mixed up anyway).
  • If you change a parameter to a different group heading, it will honour the sorting order within that group - this may be a kind of workaround for reordering, rather than using the Move Up/Down tools described below.
  • This sorting order setting will not affect parameter order in existing families.
  • Will not control system parameter order (not visible in family editor)
  • Will reorder by standard unicode ascii character order - this means all special characters (accented letters) may go after the 26 characters used in English.  This sort order may not work so well for other languages (I am not 100% sure about this one).
2.  You can move individual parameters up and down in the list
  • If a particular parameter is not inserted in the order that you want, you can use the "Move Up" and "Move Down" buttons to get it in the right place
  • I believe that it only allows you to select one parameter at a time to move up or down.
  • You could obviously use this feature to reorganise all your old families - but I can't see myself laboriously going through thousands of familes, moving parameters one by one to fix them up!
What we really need is a batch method to reorder parameters in existing families in a library.  I believe that Revit 2015 may have some sample API code that could be used to do this - but you would need to compile that yourself.  If you haven't learned how to do that yet, it will be another skill you need for rolling out 2015 to get the most out of this new feature.
No doubt someone will write/compile the API fairly quickly, and hopefully post it on the web for us to use.  [Edit:  refer to the Upgrade Information section of Autodesk Whats New help online - it refers to the Software Developers Kit (SDK), but it does not say where to find the necessary code sample]

I would prefer to have it built in to the batch family upgrader that is supplied by Autodesk;  I believe that Aaron Maller may have devised a clever way to use journals to get this happening? 
I understand why an "automatic re-order on upgrade" is not built in to the software as it would not suit everyone.

Tooltips for parameters 

In the family editor, you will be able to add tooltips to each parameter that you create (or have created in the past).  This is accessible from the Parameter Properties dialog box.
This is a really cool little new feature, which works well.  It will enable you to give instructions to users about what the parameters might do and how to use them -
  • It has a character limit, which I think is about the same as a tweet, so most people should be able to cope with that.
  • The tooltips will show up in the project environment when the user hovers the mouse over the parameter.
  • Obviously this won't apply to system parameters as you cannot access them in the family editor.
  • You probably won't go back over old families adding tooltips to all parameters, but certainly it will be worth doing so for the cryptically named ones.  
  • Hopefully it will be possible to access this capability in the API in which case someone will probably write a tool to speed up the addition of tooltips to old families

Shared Parameters for View Titles

You will be able to add shared parameters to view title families - this will be done by editing labels in the family editor.  I see this as useful for things like bilingual drawings where you want two (or more) languages on each view title.


Images in Schedules

Revit 2014 introduced the ability to insert images to schedule headers.  In v2015, images will now be able to be put into the body of schedules, linked to instance or type parameters. The purpose of this is for such things as room data sheets - which is something that many people want to be able to do. 
I find that prospect really scary for a number of reasons:
  • Images cannot be linked into Revit - only imported (Aaargh!);
  • There is no method of controlling file sizes during the import process (unlike many email image attachment programs that let you reduce file sizes);
  • Project pressures and human nature is such that very few people take care to check image file sizes before they are imported;
  • We do not have proper image management tools in Revit - we need to be able to locate all instances of any image regardless of whether it is placed or not. [Edit:  The Autodesk online help tells us that the "Manage Image" dialog now has listings for Count and Path - this will help with tracking down some of those images, but it really needs to report the image Size too]
This means that our Revit project file sizes could be blown out of the water very rapidly unless great discipline is used to manage this process.

There are a number of other limitations to this new feature:
  • You must create the images - Revit cannot use the automatically created family previews in schedules.  It would be good if it could because they are already small file sizes
  • Schedules cannot be placed to automatically flow onto multiple sheets when they get too long to fit on one page, so this is only going to work if you place the schedules on large drawing sheets.  This kind of schedule is typically done on small sheet sizes (A4 or Letter)

Schedule More Parameters

More Wall parameters can now be scheduled:
  • Base Constraint
  • Base Offset
  • Top Constraint
  • Top Offset
  • Unconnected Height
What is not included in this list is "Top is Attached" or "Base is Attached".  I find this really worrying because it means that when a wall is attached at top or bottom, the "Unconnected Height" is almost certainly going to be displaying a false value in the schedule.  At least in the properties dialog you can see those "Attached" checkboxes so it might alert you to the issue.
If we could also schedule the "Attached" properties then we could use the schedule to identify attached walls, and perhaps use conditional formatting to highlight possible false height values.  Lets hope it makes it into v2016 . . . .

The same problem could also happen if a wall has had its profile edited - again the wall heights could be scheduling false values.  This is not so simple to solve as there is no property for "Profile is edited" - however, Revit knows if it has been edited or not because it displays a "Reset Profile" icon in the ribbon if a selected wall has had its profile edited

Custom Total Titles

You will be able to specify custom text to display for the Grand Totals title on the Sorting/Grouping tab of the Schedule Properties dialog.  This is one more small but welcome step in the process of improving schedules in Revit.

For info on other new features in Revit 2015, refer to Sketchy Lines

Sunday, 6 April 2014

Adaptive Component Origins in Revit

Have you ever wondered how Revit manages the "Origin" (X,Y,Z = 0,0,0) of an adaptive component?
It is somewhat different from the way it handles origins and insertion points of traditional Revit families.  So here is an analysis of the differences between the two.

Traditional Family Insertion Points

A traditional Revit family typically has three reference planes that intersect at the origin point - representing the X, Y and Z axes.  To start with, the origin is the same as the insertion point when the component is placed in a model.  For this discussion we will only think about the X and Y axes in plan because the vertical insertion point (in Z axis) is locked to the level (in the family) and does not change (unless you use the Offset property - see below).
At some point those X and Y reference planes might be moved within the family.  This may or may not affect the insertion point, depending on the reference plane properties:
  • If the reference planes are moved, and they are set to "Defines Origin" then the insertion point will move to the intersection of the two reference planes
  • Alternatively, one or two other reference planes might be set to "Defines Origin" - if they are in the X or Y axis, they will take over the origin property from the Centre reference planes (and the centre reference planes will have that property unchecked);  if the other reference plans are not orthogonal then Revit will ignore that setting, and use the centre reference planes or the original origin point.
  • If no reference planes in the family are set to "Defines Origin" then the insertion point will remain at the original X=0, Y=0 origin
  • If only one of the reference planes is set to "Defines Origin" then the insertion point will be at the intersection of the "Defines Origin" reference plane and the original perpendicular axis.
  • If the insertion point of a family is changed and then reloaded into a project  where some have previously been placed, it will overwrite the family definition in the project and will move the geometry in any placed components of that family (by the same amount that the insertion point moved).
For this reason it is good practise to make sure the two reference planes that define the insertion point are not moved from the origin once you have decided where it needs to be (keep them pinned).  Geometry should be moved relative to the origin if need be.

Hot Tip:  If you lose track of the true origin, just create an Autocad file with a cross intersecting at X=0, Y=0.  Save the dwg and import it in to your family at "Origin to Origin"; trace over the cross with reference planes or lines; delete the dwg; purge the dwg (since you can't link dwgs into a family, you need to import, then purge).

Most traditional unhosted Revit families have an "Offset" system parameter that is automatically created when you load the family into a project (this contols the Z offset from the placement level or workplane).  Recently we found some old plumbing families (baths) that did not have the Offset parameter - we believe that this is because they were created from very old family templates that pre-date the addition of this offset capability, from the dim distant Revit past.  Hosted and face-based families usually have an "Elevation" system parameter (rather than Offset), which works like Offset but only in the project vertical axis, whereas the Offset parameter works in the local z axis of the family, which may not be vertical in the project.

Adaptive Family Insertion Points

Adaptive components behave in a different way.:
  • Although they have a true origin with two reference planes intersecting there, the insertion point can be overridden by adaptive points.
  • If there is no adaptive point in the family then it behaves almost like a traditional family, except that the "Defines Origin" parameters appear to make no difference - the origin and insertion point remains at 0,0 regardless of whether any reference planes have that property checked
  • If there is an adaptive Placement Point in the family, then Revit uses that as the insertion point of the family;  however it still remembers the true origin
  • If the only adaptive points in the family are Shape Handle points, then Revit uses the traditional origin as the insertion point (not the adaptive point)
  • If a placement adaptive point is deleted (in the family) or changed to a shape handle point, Revit does not move the geometry when the family is reloaded into a project.  This is because Revit knows and remembers where the origin is even though it uses adaptive placement points for insertion - this is logical but can get confusing.
If a placement adaptive point is moved (in the family) then reloaded into a project it might move geometry of previously placed components - it depends if the geometry is hosted on the adaptive point or not.   In this example the hexagon is hosted on the adaptive point;  the circles are just placed on the level workplane, close to the origin point.
Geometry in the family
Geometry in the model
  • Any geometry hosted on the adaptive point remains where it was in the model when the family is reloaded; 
  • Any geometry placed in the  family but not hosted on an adaptive point will move relative to the 0,0 origin point - so if the adaptive point is moved/flexed in the family it will end up a different distance from the point in the family;  when reloaded, the unhosted geometry will move in the project so that it retains that distance, while the hosted geometry remains put at the insertion point
  • Once you are in the project environment, and you move the adaptive point, something different again happens:  all the geometry in the family moves together! (this can be hellishly confusing).
Adaptive components do not have an Offset system parameter.  Instead they have an "Elevation" parameter, which does not appear to do anything - neither unhosted elements nor elements hosted on adaptive points will move when this Elevation value is altered.

Adaptive Component Reference Planes

Most adaptive component demos that I have seen show the placement of adaptive points in random locations in the family.  Why?  Probably just because you can.
I am more careful - I always put adaptive point #1 at the origin (intersection of the two reference planes that exist in the family template).  I do it for a reason, even though it takes a few extra steps - I have to go to a plan view because points won't snap to ref plane intersections in 3D.  If there is a second adaptive point I will snap it to the X axis for the same reason:  . . . .
  • Let us assume that you place an adaptive point in a random location;
  • Make it adaptive
  • Then place some geometry associated with the point (set the work plane to its horizontal plane first)
  •  You could place a dimension just to check how far it is from the origin
  • Load the adaptive family into a project and place one (it uses the adaptive point for insertion)
  • Try placing a dimension to roughly the same distance from the adaptive point as it was in the family - the hidden reference plane in the family will highlight and allow you to snap to it
  •  Once you place the dimension, the highlighted reference plane disappears
  • You could do the same with the other axis reference plane
  • Revit will attempt to snap to those reference planes and their intersections during many other commands that involve snapping - even to remote objects.
Its not very helpful is it?  In fact it is downright annoying when you have lots of adaptive components placed.
  • Imagine what happens when you have two adaptive points placed in the family at random, with some geometry between them?  

  • The hidden reference planes are now at crazy angles in the project and cause all kinds of random snapping locations

Hot Tip:  In v2013 the developers gave us a solution to this issue by enabling the  properties of those reference planes to be set to "Not a Reference" [that did not work in v2012, I think]
Good Practise: 
  1. Chances are that you will forget to change this setting some time, so it is a good idea to get into the habit of putting adaptive point #1 at the true origin, and point #2 on the X axis so that these reference planes will be orthogonal to the geometry.
  2. Whenever you flex the family by moving the adaptive points, remember to put them back to where they were, so that you don't get strange behaviour where unhosted elements in the family might move in the model when you reload the family into the project.

For more differences between traditional and adaptive families refer to Rival Revit Environments

Tuesday, 1 April 2014

New Sketchy Lines in Revit 2015

The big new feature for architects in Revit 2015 is the Sketchy Lines setting for views.  I have found some interesting subtleties in the way that it works.

In the Graphics Display Options dialog box there is a new section for "Sketchy Lines"
  • Firstly there is an "Enable" checkbox to turn the effect on or off - initially it seems to do nothing because the default slider settings are zero.
  • Jitter does two things:  as the slider increases, all the straight lines in the view become more wavy;  at a certain point the lines start doubling up, and then becoming multiple lines - so you get a combination of the two effects somewhat like running a pencil back and forth to emphasise a line.
  • Extension does what you expect from the name - it "virtually" extends the lines past their real end points or intersections.  The extension obviously increases with the slider value, but it is not an equal extension on each line - it is proportional to the length of the line

It seems like the line extensions and jitter are applied to the model before any hidden line removal is done - this means that all lines are jittered/extended even if they would ultimately not be visible in a normal hidden line view.  This has some unexpected side effects that you need to be aware of:


  • Jittery lines seem to be actually waving in 3D, which explains why you will see sections of jittered lines disappear as they duck into or behind an adjacent surface.  On the roof in the Revit sample file that looks quite good because you don't want to emphasise the roof stripes.  Once you bump up the level of jitter past the halfway mark it starts to create multiple lines so that in most instances where a line partially disappears another one will be waving the other way so it remains visible.
  • On an outside edge the effect is less obvious - in fact it tends to emphasise horizon lines as the lines are less likely to be hidden by adjacent surfaces.
  • On an inside edge the effect is the opposite - the lines are even more likely to disappear as they have much more chance of being hidden by a surface - have a look at the coving on this image
  • Jitter is applied equally to all lines, categories, element types, internal and external edges, silhouettes, depth of view, scale etc.  What this means is that some elements get much darker as soon as you enable jitter - such as railings and window frames.  This is partly due to previously close parallel lines now overlapping, but also due to the multiple line effect on higher levels of jitter.  It is currently not possible to be specific about which elements become more jittery than others.  It may become necessary to start applying overrides like halftone to certain categories, so that they do not dominate.


  • Line extensions can have unexpected results if you bump the slider up too high - lines from elements that should be totally hidden can start showing through surfaces.  On the Revit sample house there are some internal walls (?) that start to project through the roof;  balcony lines project right through the side wall.  
  • This effect is also dependant on the overall line lengths, as shorter lines generally extend less at their ends.  The overall effect is more sketchy but the random lines might confuse people - so you need to balance the extension settings to match your desired effect.
  • If you have a few persistent line extensions you can always use the Linework Tool to make them invisible.  Likewise where jitter makes too many lines on a particular element - the Linework Tool will be your friend (or enemy if there are too many lines and not enough time!).


In order to get the effects that you are happy with you'll need to experiment, but it is probably a good idea to set both sliders at 3 and start from there.  The sketchy line effects are going to look better if you use them in combination with other view-based settings such as Smooth Lines, Ambient Shadows and Gradient Backgrounds.  It would be nice to be able to create standard combination settings of all these effects, to apply at one click.

Monday, 31 March 2014

U-Shaped Winder Stairs in Revit

In a previous post on Revit winder stairs I suggested that on a U-Shape Single Point winder it is not possible to control the number of parallel treads on the middle section between the two corners of the windersSo you could end up with a stair that has parallel treads on the lower and upper sections but looks more like a balanced winder stair in the middle section, with only one parallel tread.

"Single-Point" U-Shaped Winder
I doubt if anyone would find this acceptable.

Here follows a rather dodgy workaround:

2 x L-Shape = U-Shape

To create a sensible U-Shape winder stair you need to create it in two halves:
  • Start the stair command, and set the overall stair height to be half that you require
  • Go to the L-Shape stair tool
  • Place one as required
  • Select the L-Shape stair and make it a Single-Point winder style
  • Set the overall height back to the full stair height required
  • Place another L-Shape winder component - use the space bar to rotate it to suit and snap to the end of the first one
  • It will not create a landing if the two components are aligned (without a gap)
  • You would expect it to automatically start the second run at the correct height
  • But there will be a height mismatch
  •  You could try making the lower run not end with a riser and then add another riser to the run - that looks ok but when you finish the stair you get a railing height mismatch
  • To solve this you need to keep the lower run ending with a riser
  • Move the second run away by one tread
  • Notice that the riser numbers are different - they need to be the same
  • Drag the blue dot at the top of the lower run to add another riser
  •  Adjust the number of parallel treads on each run (if you can!)

  • When you complete the stair, the railings should now join each other at the same height;  but the balusters will not align to each other without adjusting them - if you can understand the baluster settings in the railing type properties !
  • Note also that the railing heights are not consistent - they are not even close to being the right angle to the run of parallel treads between the winders, nor the right height above them.

That is about as good as you can get with the railings, but at least the stair itself has the correct heights - assuming that your building code allows 3 winders on each corner.

If you try to put a one-tread-width gap between the two runs, and then join them with a landing, it might look almost ok . . . . .
Until you complete the stair and look at the railings, which attempt to put in horizontal or vertical sections for the landing
These railings are going to need some serious fixing up!!!  I'll leave you to figure out whether it is possible or even worth attempting it.

And if you want stringers on the stair you get a whole new headache.
So my recommendation is to use this workaround to get the plan working, but if you need a true 3D representation it isn't going to work well enough in most cases.

Saturday, 29 March 2014

RUGS - Oldest Revit User Group in the World?

Having joined the RUGS committee in 2008 as treasurer I finally got a promotion:
This year I took over as chairman of RUGS from Steve Fiorio - a post he had held since 2012.

We believe that RUGS is the oldest formal Revit User Group in the world.  This has been confirmed by Autodesk, and no other group has yet claimed the title.

Initiated by Wesley Benn, the first meeting was held in May 2003 in North Sydney, in the offices of Benn Design & AEC Systems.

The RUGS Website was set up in August 2005 - with much ongoing hard work by Bo Zhen

Go to the link for our 100th meeting in August 2012 to see more about the history of RUGS

Our original logo tells a story:

I am not sure if we are still Australia's largest user network, but the reference to "CAD Software" shows its age - this logo obviously predates the common usage of the acronym "BIM".  Time for an update, if I can only track down the original graphics.

RUGS meetings are held on the second Tuesday of each month (except January when everyone is at the beach enjoying the Sydney sunshine). 
The venue is very kindly provided for us by Ultimo TAFE -
Room W3-06,
Level 3 Marcus Clarke Building,
827-837 George Street,
[in Sydney, Australia, just in case any overseas readers are thinking of attending]

This year we are experimenting with a new approach of getting the 3 Sydney based Autodesk Resellers more closely involved - they will take turns in helping to organise speakers for the meetings.  We hope to get a wider audience as Revit users see this as "reseller neutral"  - RUGS is organised by Revit users for the users.

Proposed Schedule of RUGS meetings for 2014:
11 Feb
  • Ceilidh Higgins (Daryl Jackson Robin Dyke) - "BIMnomics"
  • Frank Crisp (PTW) - "Pattern based families for creating facades"
11 March - Cadgroup
  • Deepak Maini (Cadgroup) - Navisworks
  • Michael Sandel (Plansource) - Shadows on adjacent buildings
8 April
  • Greig Bannister (Panzura) - Revit file storage/sharing solution
  • Anthony Bowden (PVN) - Revit family templates
  • Tim Waldock (PTW) - Whats New in Revit Architecture 2015
13 May - A2K
  • Computational Fluid Dynamics (CFD) for architects and engineers
  • Whats new in Revit MEP 2015
10 JuneRedstack
  • Surveying and Scan to BIM, Recap
19 July ?  (TAFE Closed on 8th July).
  • Friday annual social event. Jointly sponsored by all 3 resellers. Venue TBA
12 Aug -
9 Sept -
14 Oct
11 Nov – 
9 Dec -

Monday, 10 March 2014

Revit Stair & Railing Selection

The new Revit 2013 Stair and Railing tools brought with them some tricky changes to the selection process that might catch you out.

Selection filters now have some new subcategories for stair components, stair annotation and railing components. All the new stair subcategories have been prefixed with the word “Stairs:”, which makes them easier to find in a list; new stair tags are likewise prefixed with "Stair". Sadly this logic was not applied to new railing subcategories: Top Rails, Handrails and Supports do not have a Railing prefix in the filter, so they don't show in the list in a sensible order.  In fact it can get quite confusing because we now have "Stairs: Supports" and "Supports", which are two entirely different things so you have to remember that the latter is for railings only.
When you look at a typical selection filter list the railing subcategories are jumbled up with the rest - this becomes important when you need to specifically exclude some of the subcategories from your selection (see further on).

The same naming convention is used in the properties dialog box.  At least it is consistent, if annoyingly wrong!

Railing Terminations and Extensions cannot be selected, nor do they list with separate subcategories - they are only accessible through the type properties of Top Rails and Handrails.

Visibility / Selection

Any of these railing or stair components can be Tab-Selected or selected by dragging across them.

The rules for selection/display of Railing Supports are mysterious and confusing:
  • In section and 3D views they are visible at all detail levels.
  • In plan views they are only visible in Fine detail level;
  • Railing Supports below the cut plane in plan views are visible (fine detail level only), and can be selected by dragging or tab-select;
  • Supports above the cut plane are only visible during pre-selection or selection highlight (fine detail level only);  they cannot be selected by any method except changing the view range cut-plane or going to another view on the next level up;
  • In Medium or Coarse detail level below the cut plane in plan view, they can be selected by dragging, in which case they display a pin only (no graphics);
  • In Medium or Coarse detail level below the cut plane plan view, they can be tab-selected (location by guesswork), in which case they do not display a pin but do show a highlight line at their origin (no graphics);
Medium or Coarse Detail Level

Fine Detail Level- railing supports visible

Hidden supports visible when railing is selected

It is important to note that railing supports can be selected even when not visible in plan - but only below the cut plane in medium or coarse level of detail.
Invisible Supports selected

Pinned Elements

If you select by dragging across a stair, you may get pins showing up on the stairs. These are actually for the Top Rails, Handrails or Supports, which are now separate sub-components (somewhat like curtain wall components) - this means that you can often get numerous confusing pins showing up on screen. This applies to new style railings on both old or new type stairs, but not old style railings.
You can also Tab-Select these railing sub-components individually.  Again, they display pins, but each behaves slightly differently (and differently to curtain wall sub-elements).

Once you have successfully selected a railing sub-component the displayed pin behaves slightly differently for each category, as described below.

Pinned Element Properties

You can unpin them to unlock and change some of the instance properties:
  • Type selector becomes available for all railing sub-categories when unpinned - so you can change the type (Type Selector grayed out when pinned)
  • Unpinned railing supports allow the "Hand Clearance" instance property to be changed
  • Type properties can be accessed and modified without unpinning them (any sub-category)
Pinned Railing Support

Unpinned Railing Support

Stair Component Properties

Stair components do not have pins, but some of their properties can be changed without editing the stairs.
  • Runs and landings allow height property changes - this will have knock on effects to adjacent components - refer to Modifying Landings
  • Stair supports may allow changes to cut properties of free ends

Sub-Category Selection Limitations

Depending on how you select elements (multiple selection by dragging across screen or tab-selecting), you will encounter some inconsistent limitations to what you can do with selected stair components or railing sub-categories:

  • Move Command (Multiple Selection).
    • If you have any pinned Railing Supports explicitly included in your selection of elements (ie, in selection filter list), it will not allow you to move the whole selection.  Therefore you have to remove the supports from your filter selection list before moving the selection.  This will surely catch out anyone but a railing expert.
    • This does not apply to Top Rails, Handrails or any stair components - whole selection can be moved even when they are explicitly shown in the selection list and pinned.
  • Move Command (Individual Selection).
    • If you individually select any stair components, they cannot be moved without first editing the stair - in fact the Move command is greyed out;
    • If you select a (railing) support, you can move it after unpinning it - within reason (beware of how much it moves - it measures up the diagonal even if you give a horizontal distance);
    • If you select a handrail or top rail, it cannot be moved even if unpinned - but it lets you try!
  • Delete Command (Individual Selection) 
    • Stair components cannot be deleted without editing the stair
    • Railing Supports, Top Rails and Handrails can only be deleted after unpinning them
    • Deleted Railing Supports can be reinstated by selecting the host Handrail and clicking Reset Rail, but it will reset all changes to supports on that handrail
    • Deleted Top Rails and Handrails can be reinstated by resetting the host Railing

  • Edit Rail Command 
    • Unpinning a Handrail or Top Rail seems to make no difference to allowing it to be edited - can be edited when pinned
    • However, if a pinned Rail is edited, it will flag the Handrail or Top Rail as unpinned
    • Repinning a Handrail or Top Rail will remove all edits and reset it to original state - beware, as it is easy to lose work, as you might think that the pin command will lock all your changes!
    • Likewise, repinning a Railing Support will restore it to its original location

  • Groups
    • If any stair or railing sub-component is explicitly selected, but its host is not selected, then the Create Group command will be greyed out and unavailable
    • In which case, you need only add the host element (stair or railing) to the selection to enable the Create Group command
    • If a railing is added to a group, all its hosted elements will go with it
    • If a stair is added to a group, its components will go with it (run, landing, support), but its railings will not be added (unless explicitly selected)
  • Design Options
  • The rules for adding selections to design options are subtlely  different from creating groups:
    • If Top Rails, Handrails or Railing Supports are explicitly selected along with their host railing they can be added to a design option
    • If Top Rails, Handrails or Railing Supports are explicitly selected without their host railing they cannot be added to a design option
    • The same rules apply to stair components
    • If a railing is added to a Design Option, all its hosted elements will go with it even if they are not explicitly selected
    • If a stair is added to a Design Option, all its hosted elements will go with it, including its railings, even if they are not explicitly selected.  This is different behaviour to creating groups