More Railing inconsistencies in Revit
The (not so) new capabilities for adding 'Handrails' and 'Top Rails' to railings can be very useful, but the UI is riddled with weird settings and inconsistencies - this one relates to their Height Properties.- Handrail has height property built into handrail family type
- Top rail has height property in the railing family type (not built into top rail family type)
- The Handrail height is displayed in the railing property dialog box, but is greyed out
- Top rail height is controlled directly in railing property (much better)
- Meanwhile, if you want to change the Handrail height, you have to click on the hidden button to the right of the Type name - this opens the Handrail type properties for the selected handrail.
- The height can be changed here - but of course it will affect all railings that use that particular handrail type, so you probably need to duplicate type.
- This means that you need a separate handrail type for every possible height.
- It is possible to right-click on a Handrail type in the family browser, and 'select all instances in project' - it does actually highlight them individually.
- Since Revit users are never quite sure what has been used, they seldom check by this method, but typically duplicate type anyway, leading to a profusion of similar or identical types.
- For this reason, it is wise to name the handrail types accordingly - either with a specific height or with a purpose
- This will ensure that when selecting a handrail type in the railing property, you have some chance of getting the correct height.
It is not clear to me why these settings are different - I would much rather that both had height properties in the railing. That would give us consistency instead of confusion. It would also mean creating fewer handrail types - we already have enough variations of those to cope with the extensions.
And all this doesn't even address the fact that the old 'Rail Structure' method is still available for use to create handrails, top rails and mid-rails - and that has a totally different method and UI. Aaargh, what a mess!
This series is going to be a great resource when they will pick up work on the railing tool again.
ReplyDeleteI often wondered whether they are trying to do the impossible with the Rail/Stair tools...perhaps there are just too many variables, maybe every tool that offers all the options will become impossible to use because of all these settings and the way these settings will interact with eachother (or it will only work for Revit power users who had the time to train themselves in it).
I'd perhaps prefer some more manual controls over the 'set-a-hundred-settings-and-then-create-a-perfectly-detailed-railing-with-one-click-method'.
With this approach focus would be on getting a 'close-enough' railing quickly and intuitively and then allow for manual overrides for everyone who needs really fine detail.
For example, if we have some better sweep options (multiple profiles in one sweep and easier 3d path creation by for example using the stairplane as a host for a sweep) I might prefer to do most of my railings as an in-place model. This wouldn't work if you had to do hundreds of railings, but often we only need to do a few and it's not worth struggling through all the intricacies of the railing tool for that.