Related Posts with Thumbnails

« New Revit Certification Program | Main | Railings High Level »

April 02, 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.

1. handrail: offset
2. handrail: return
3. handrail: support
4. handrail
5. handrail: extension
6. railing: panel
7. railing: panel infill
8. rail: bottom
9. railing panel layout grid: division
10. railing panel layout grid: border
11. railing: end post
12. railing: length
13. handrail: transition

The Black Thing on the half landing is a CAT!

1. Handrail (is this a corner transition?)
2. Handrail: Termination Return
3. Handrail: Wall Connection
4. Handrail: Handrail
5. Handrail: Termination Extension

6. Railing: Panel
7. Railing: Panel: Subelement/Form
8. Railing: Panel: Subelement/Form

9.Railing: Panel: Grid Line
10. Railing: Panel: Grid

11. Baluster
12. Balustrade (or Guard)
13. Handrail: Decorative Transition

I think naming all these elements perhaps complicates the issue. I often just give up on the railing tool and make an in-place family. Nine times out of ten, I want something custom anyway (architects like their stairs and railings) and the built-in tool is woefully inadequate. Once you get into naming 7&8, you've gone too far because there's an infinite number of configurations, or they might not exist at all.

For large projects, it makes sense to perhaps have a railing defined as a toolkit of basic elements that are combined as needed to accommodate the railing path. To determine what the pieces in the toolkit are, you might think about how someone might draw/detail/dimension the typical set. And then deploy the elements along a curtain-wall-like tool for railings, where you can define gridline placement, control visibility of elements along those grids, adjust overall height/width/extents, manually override poor automatic transitions, and edit the railing profile (like editing a wall profile).

Thanks.  Certainly the railing tool has many issues around the model produced and the complexity of the UI, far more than naming alone can address.  Your thoughts on how you would approach it are appreciated.
A UI that allows you to define patterns and then interact with it directly is clearly preferable.

Not really what you are asking, but I would like to have control over what is drawn in Coarse, Medium and Fine for System Families like railings and stairs and even walls. This would allow the possibility to do some of these fine details as simply 2D symbolic lines shown only in fine for example...

Hi Erik, thanks for finally showing some signs of work on this tool. The sad part is that if we're trying to define what these conditions are called, I'm afraid we are either starting on the wrong foot or we're a couple of years away from seeing anything concrete to test :{

I'm going to try and reply by not answering your questions directly and instead break down what I see as key components of railings:

a) Handrail (height measured to top face is what's important for documentation; clear distance from mounting surface is what's important for documentation). Handrails in commercial applications usually follow a different path than the "guardrail" portion, including unique terminations, mounting surfaces, etc. For example they might start as being mounted to the guard rails and then continue on to a wall when the guardrail stops. In plan view, the handrail is quite important to show correctly. The guardrail is too, but I think the handrail is even more important. Inside/outside corner radii in plan should be defined by the sketch itself. It would be great to pick from a collection of termination options (extensions) that clean up nicely in plan, elevation and 3D. Defining the size of the extension from where you stop sketching the railing in plan is preferable (ex: with a 12" tread, you usually extend the handrail at the bottom of stairs by another tread depth (12") so you would sketch that and stop. Then you would apply an end extension of another 12").

b) Guard rail: Consists of repeating panels of equal sizes or custom sizes. Could consist of completely different sizes and multiple configurations (ex: A-B-A-B-A instead of A-A-A-A-A). Height to top railing is most important for documentation. Sometimes start and end panels need to be defined separately from the rest of the "pattern". In most cases, we try to make panels be a multiple of stair tread depth, but in other cases we use start and end panels (could be either equal or not) to "pick up the slack" and make the panels between the start and end panels be equal. Sometimes the interior panels are not a multiple of the tread depth.

c) Supports: They can be wall mounts to support the handrails or posts mounted to the top or side of the stringer. These posts could support the handrail itself or the guard rail panels. The top of the posts might be trimmed horizontally or they could follow the slope of the stair stringers (came applies to the bottom of post, independently of the top). Typically we would like to have control over placement of these posts, and the panels would then flex to fit in between (kinda like curtain panels or adaptive components) rather than trying to rigidly define unique panel sizes and insert them in some dialog box, in the hope of defining some pattern which is so tedious to adjust during design iterations.

Guard rails are sometimes not necessarily higher than the handrail. The handrail can sometimes be the top of the guard rail (ex: small accessible ramp that does not rise more than 30"). So as you can see, all this is next to impossible to control through a set of rules. Also keep in mind that codes change between states, counties, cities and countries. And over time. So I don't think any of that data should be part of the tool (ex: openings below certain height not permitting 4" sphere to pass through etc....). Let us be architects and let us apply rules and regulations that apply to our unique projects ourselves. This will also help to simplify the tool.

There are soooo many permuations and combinations of parts that designers will dream up (which is what makes architecture exciting) that I think it is foolhardy to try and think of all bends, nooks and crannies that we'll ever need, name them and insert them in some UI. I seriously think that the framework of a railing is what's most important. Then build in the modeling flexibilities to make adjustments on the fly, in canvas, and let us skin and detail that framework any way we want to. And be able to change it quickly. And not have to draft 2D drawings to document the same railings we modeled in 3D (help us justify 3D modeling by also being able to document from that model!). Think massing tools. They give us the flexibility to dream up any form (almost) and build it. Railings should do the same.

I tried not to look at other comments before I replied hoping to keep my responses from being suggested... but being a Revit user still is somewhat suggestive. 6-8 we don't do in this office and 9-10 answers probably reflect that fact as well. (so 6-8 answers are probably "Revit" suggested),

1. Handrail
2. Top Handrail Return
3. Handrail Support Bracket
4. Handrail
5. Top Handrail Return
6. Railing Section (Panel)
7. Railing Section Fill
8. Railing Section Bottom Rail
9. Dashed Horizontal Line
10. Dashed Vertical Line
11. End Newel Post
12. Railing
12. Fence
12. Any other name someones used the railing tool for.
13. Termination Gooseneck

Here is a link to terminology as it relates to stairs.

Dave, Awesome response, thank you.  Sigh...  This happens often that in soliciting any information perceptions vary and speculation and assumptions reign - I guess based on past evidence/experience.   Ill follow up with some future posts but your last paragraph sums up my thoughts on the matter and I will try to respond in kind    As you note permutations are vast.  Ive seen everything from curving iron scrollwork to curved glass panels.  Glass without handrails and curvy Dr. Seuss handrails.  A general framework or skeleton is surely a good approach.

Perhaps I should have started with this but here are some of the top issues I see with the current tool:

-Indirect UI - Designers do not want to work in a spreadsheet.  Choosing a rail and clicking edit to then see all the geometry reduced to a single pink line is almost funny but I will refrain from laughing.  The baluster and rail dialogs need to go and be replaced by direct editing and simple properties.  Making a railing from scratch is the most difficult thing in Revit to do.  I think I am comfortable saying this.
-Missing objects - While generalized can be good the current tool is too general.  Handrails may take many forms but most railing have 0-2 and they have a relationship to the railing or host plane.  Panels have been described as a nightmare or sometimes a living nightmare mainly because there is no concept of panel!.  Rails end with hardware such as a rosette or even a simple cap.
-Too rigid - 13 types are often required to model a rail where one or two should do.  Making small tweaks needs to be supported once a general pattern is established
-bad geometry - rails are usually continuous so there is a need to get it right or provide a means to shape the rail path.
-bad inputs - railings have codes and we need to ensure all the proper distances can be referenced and dimensioned and critical spacing can be input without too much math.
-hosts - not enough of them.  Rails can not just go on stairs but tops of walls, topo surface, roofs, between columns ect...

There is more but hopefully I can appear to be standing on the right foot.  BTW I am about to go into a meeting with two well known Reviteers to talk about this very subject so trust them if not me to ensure the proper research is going on.

Thanks again for the response

I wonder if trying to name these parts so specifically is locking you into a rigid way of working and thinking about the tool. We regularly use Revit railings to create all sorts of repetitive elements like canopies, awnings etc. In which case no 3 might be an awning support flange, and no 7 might be a light shelf or a sun screen for example.

You can name them generically.  The idea of a generic system placement tool is a good one and there are different ways to achieve this.  Its certainly possible that a generic system object can place specifically named content or two tools can work the same yet be extended to meet specific object needs.  Its not lost on many here that curtain wall, beam system, trusses all have some similar needs and could be better aligned as they are now.

You missed one that always stumps people.

What is a Lambs Tongue?

Ornamental railings eh.  I have some interesting examples.  Not sure we would ever hard code something with that name but it could be a component that is incorporated on a railing.  Examples like this reinforce that naming should be left to the user as much as possible.  Revit can provide the frame that specially named content lives on.

1 handrail
2 handrail:return
3 handrail:support
4 handrail:top rail
5 handrail:extension
6 balustrade:panel module
7 balustrade:infill panel
8 balustrade:bottom rail
9 balustrade:mid rail
10 balustrade:baluster
11 balustrade:newell post
12 balustrade:run
13 handrail: step transition or gooseneck

it would be great if we could see a balustrade dialogue box graphically, eg diagram with named parts, click on part, then fill out an editing popup dialogue box and see the item update on the fly, before placing in model.

Brilliant! What a great read. That was a good post - informative but not too heavy. Thanks for taking the time out to write it! I think spirituality is really important too, we certainly agree on that point. A leader without spirituality is missing a key element.

The comments to this entry are closed.


  • Subscribe