I'm sure I'm not the only one he gets frustrated by the Railing tools in Revit. I thought I'd put together this post to point out the type of day to day frustrations they cause and what I'd like to see implemented to solve the problem.
Extensions and Terminations
Here it can be seen a 180° railing termination and a standard 300mm extension.
|As you can see, dimensionally its accurate.|
|But look at the Length I had to give to achieve this?|
|As you can see that dimension doesn't seem to correlate to anything?|
- I've checked the Termination family and its origin is set as the Centre Left/Right Reference Plane which is located exactly where the 300mm dimension is, and the Extension Length is set to 0, as I don't want it to be subtracted from the Extension Length. IE: It should be 300mm and then the return.
- If I switch the Extension style to Floor and ditch the termination, I see it correctly ends exactly at 300mm with an extension length of 300mm. Although it stops exactly 163.424mm short of the floor... NOTE: That just happens to be exactly how far extra I had to offset the Extension Length by. But where is this value coming from?
- Similarly if I switch the Extension style to Post, its still 163.424mm short of the end of the Railing sketch. Anyone have any ideas where this number is coming from?
Another issue with Terminations is the fact that they do not display in linework in Plan. It seems they are there when you hover over them, but they never show the edges. If this is because of some standard elsewhere in the world, that's fine, but don't hard code it this way, make terminations a sub-category that we can control visibility of separately. Unfortunately, there is absolutely no smart workaround to fix this. Even masking regions and linework in the termination family don't show through...
Oh how I wish for Instance parameters!
- For Posts we can set "Space" adjustments for Start, Corner & End Posts. But lets say I want my posts to be spaced Equally. In this example, 2000mm spacing. I set my Main Pattern "Dist. from previous" value to 2000mm. Rarely do I want to have a post exactly where by Railing starts/finishes when hosted on a Ramp or Stair. There is always a change in level meaning I need to offset to allow the base plate to fit. In this case I've sent a start spacing of 100mm. But as you can see my first and second balusters are now 1900mm, and this space is not factored in by the rule...
- Similarly, if we have a space, either mid rails and bottom rails should automatically stop at the first and last baluster, or rails should also have "Space" parameters to allow us to make them stop short in these circumstances:
- Railings need instance parameters, so we can override Baluster placement. Sure we can make excessively long baluster placement rules that individually set out each baluster, but what a waste of time and we end up with potentially hundreds of Railing types in our project becoming a management nightmare! Why doesn't it work more like Curtain Wall Grids and Supports, where we can define a rule, but at the instance level unpin them and position them exactly where we want them, and even add extra ones if required.
- Why not have placement controls for Stair Posts such as "Centre on the first and last Tread of each run" with maximum spacings for intermediate Posts, that also default to centred on the Tread. WE DON'T PLACE POSTS ON THE NOSING!
- Corner Balusters, sometimes use base plates or brackets/supports. Because we have no control over their orientation we end up having to make 4 different versions for the different corner styles. We also have no connection to the angle of the corner.
- Give us access to the instance parameters! We have instance parameters available for Top Cut Angle, Slope Angle, Bottom Cut Angle & Height. However we can't drive other instance parameters from these as they don't get updated! For example, in a particular modular baluster, it has brackets to hold the rails. The bracket type varies depending on whether the Rail is flat or sloped. Now if instance parameters worked I could use an IF statement to ensure the appropriate bracket is visible.
- Visibility parameters seem to have weird glitches. EG: If you turn off parts of the balusters, some times they still display in section and elevation, but not in 3D.
- Corner Balusters should have their own special type with extra parameters to be able to use the angle of the corner in formulas.
- Instance based Width parameters for Panels! This way we can create proper Glass Patch fitting style Railings without workarounds...
- Landing Height Adjustment options are needed on Top Rails and Hand Rails. If you have a bottom Rail, you don't want its height to be adjusted as well!
- Why is it we can't have a Hand Rail on its own! Its the only rail type that allows us to have supports and adjust their positions per instance...
- Offsetting Rails from the edge of Stairs upsets transitions in slope.
AUTODESK WE ARE TIRED OF WORKAROUNDS! These issues have existed for many many years now... Please help us!