Wednesday, 12 December 2018

Weird Railing Stuff - part 14 - Railing Baluster Height Top Offset

Balusters have always been completely confusing in Revit Railings.   However, one baluster property used to be quite straightforward:  the baluster Height, which Revit seemed to handle quite well - providing the baluster top constraint was set to the appropriate rail element.  In earlier Revit days, baluster height could be set as an absolute value, or could be attached to one of the rail elements:

Revit Railing Rail Element Definition


Each of the named 'Rails' were available as a top constraint for balusters - whatever names you gave to the Rails were shown in the drop-down menu 

In the old Revit railing method the highest 'Rail' usually represented a handrail or top support/fixing rail of some kind - and this would be a good constraint for the balusters - if its height changed, all the balusters would adjust accordingly.  It didn't really matter what you called the Rails (but it does matter now - see below).

A Cat Among The Pigeons

A few years ago, we were given new specialist system defined railing elements "Top Rail" and "Handrail".

The original rail elements remain available in the UI for use as mid rails for example (although can still be used to represent handrails).  This means there are now three different ways to define the continuous rail elements.

At this point, Baluster top constraints became very confusing and inconsistent . . . .

Baluster heights can still go up to the old Rail elements.  They can also go up to new 'Top Rail' Elements but not to new 'Handrail' elements. 

Some railings have only handrails without top rails, so that is a totally ridiculous restriction.

Rail Naming

The old style Rails, might have the same name ("Top Rail") as the new system name of "Top Rail", particularly as that was a common naming convention in old style railings.


This could be very confusing as they both appear in the Baluster dialog drop-down menu - in order to avoid a conflict  the word "Element" is added as a suffix to the system family.  This drop-down menu is the only place it is so named.  Get used to it!

What I recommend is to rename any old style Rails that may represent handrails or top rails - this will avoid any confusion. 



A better solution is to use the new system family rails for either handrails or top rails and then remove the old style rails that used to represent handrails.  Even though the new system Rail families have been available for at least five years, you will find many railings that are set up the old way, so you will need to fix them.  The reason for the old style railings hanging around so long is partly because old railings are not upgraded to new style ones when an old project or template is upgraded - this is amply demonstrated when you look at the Autodesk sample file, which has never been fixed!!!  Thankfully Autodesk did fix their supplied project templates - but your company templates need to be manually corrected.

* NB. The new style handrails/top rails are mostly better than the old ones - but not in every situation.  The old rails could go around a tighter corner on a half landing, where you have limited space [they both break but the older ones in a better way].  However, on balance I prefer to go with the new ones and live with that shortcoming and the many confusing inconsistencies built into them.

Warnings

When you do fix your old railings, and you replace old style handrails with new ones, you may get an error message when you delete old handrails/top rails:

When you try to delete an old rail from a railing definition, Revit may warn you that it will reassign the height reference (for balusters).  If you say Yes, you might expect Revit to make an attempt to resolve it.  This is in fact quite misleading, because it usually fails abjectly:


The balusters cease to exist until you go in and manually correct their top constraints, which will most likely be unassigned:

Confused by all this?  That is not surprising - go in to your project template and check all the railings, and it may start to make sense.

2 comments:

  1. I spent way to many hours of (dis)pleasure in the past 5 years trying to figure out ways to do it like in the real world... what you are pointing at is great, and emphasize my motto for stairs design in revit: do not try to have a real looking handrail for stairs, just make it close enough, don't waste your time. making a close enough representation for a scale up to 1/100 and then work your way out in your details sheets...

    The stairs tool has never ever been mature in Revit from day one.
    Even the archicad 2003 version of the stairs tool was more advanced and more accurate than the one we have now in Revit 2019...

    Maybe by doing them such a bad advertisement regarding that failed tool will help Autodesk understand they need to put people to work on that (I mean people that understand what is a stair, how you build it in the real world, craftmen not coders!)

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete