A Stinkin' Simple Railing - Part 1

When long-time users pour so much passion and energy trying to make Revit better through constant feedback, they eventually get burned out and exhausted when they do not see significant change, version after version. Sadly, I find myself in that situation and it is getting harder to stay positive about Revit, even though it is still my preferred software of choice (how about that for leverage?). The way Autodesk have been treating its development these last couple of years is nothing short of appalling. They seem to have forgotten the “works like an Architect thinks” mantra and sadly too often Revit seems to work like a clunker and thinks like a delusional Architect instead. The API keeps improving, which is great, but I expect a heck of a lot more from the exposed part of a platform that is briskly coming up to its 14th birthday since becoming commercially viable. If software age is more like dog years, one can safely say that Revit is no teenager.

In the spirit of (desperately) trying to stay positive, I’d like to write about all the problems with the “new” railing tools. Nowadays for Autodesk, “new” means less than 20% completion. I wish I had that luxury myself, so I’ll just roll around in envy for the time being.

I documented these while trying to build a simple, wall-mounted handrail commonly found in fire escape stairs. Since there are too many issues to list and document in one post, I’ll do it in multiple parts so I can be of service to my loyal readers. Some might not see this as being positive but in my book, the first task on the path to improvement, is to acknowledge your problems. I will suggest workarounds and best-practices where possible.

Some bugs have been resolved in Revit 2014, but not all projects I deal with are in that version (actually as of now, very few are). Template versioning has become a real headache where things work differently depending on what template version a project was started from: the upgrading process alone is unlikely to guarantee nirvana. Note that everything I’ll be posting about has been confirmed through Autodesk Support.

BUG #1	Occurs up to
Posts in “old” railing on “new” stair	Revit 2013 SP3*

STATUS: Resolved in Revit 2014 SP1 *only if you start a project from a 2014 template.

If you had a previously working old railing definition that used posts to define extensions and you used it on the “new” assembled stair, the posts do not display in plan. Your existing projects are not going to get fixed through an upgrade to Revit 2014. In this case you’re going to have to re-build them with a different railing definition. As you can see below on the left, the railing works on old sketched stair definitions but not on the assembled stair. If you start a project from a new 2014 template and copy & paste the faulty railing definition shown on the right, it works. Why not when upgraded? I have no clue.

 

BUG #2	Occurs up to
Terminations not visible in plan	Revit 2014 SP2

STATUS: Unresolved

Termination families do not represent themselves in plan views but when you hover over the railing, you see the invisible outline of the termination family. Visibility should be controlled through the family subcategory and detail levels, but this is not happening. So if you were thinking creatively of using a termination as a railing extension to get around other buggy behavior, forget it.

 

BUG #3	Occurs up to
Align tool on supports doesn’t work right	Revit 2014 SP2

 

STATUS: Unresolved

The align tool does not work correctly on supports when handrails are sloped. When they are flat everything is fine, but if it slopes (which is the most common), the support is moved by the incorrect distance and it takes several subsequent alignments to get it close to where you want it - it never properly aligns, just keeps getting closer and closer. Workaround: Use the move tool in lieu of Align.

Stay tuned for more bugs and “as designed” issues. Happy New Year!

A Stinkin' Simple Railing - Part 1

Stairs and railings

I'm really excited to see the upcoming stairs and railing tools in Revit 2012. I have no idea why they were not covered by other bloggers in the past weeks. I'll do my best to work up some examples and post back. Stay tuned!

Stairs and railings

Seuss Railings

One very interesting session I attended this year at AU was Inside the Factory: How Revit is designed. We were exposed to the rigorous approach that the team takes when assessing all the feedback they get from various sources and how they "storyboard" potential tools and prepare mockups. It helps to know what the tool should be capable of achieving so you don't push yourself into a corner.

One particular example that was used during this session was the infamous Edit Baluster Placement dialog box.

Attendees made lots of points about what could be improved, but I believe the governing question of all in this case should be"Why a dialog?". Dialogs are great at organizing a set of rules, but how will I model and document the following railing? I rest my case :)

Seuss Railings

Railings from hell - 1

Railings have steadily been climbing to the top of my "most hated tools" list and are now...you guessed it...at the very top. Building railings in Revit is one of the most designer-unfriendly processes. At least when it comes to commercial-type railings.

One of the most important things for Architects to define when it comes to guardrails and handrails is the height, which is measured from the top of the element and NOT from the centerline. Another important dimension is the clear distance between the railing and the wall (again, NOT to the centerline). So with this in mind, I created a circular handrail profile and made the top reference and one side reference to define the origin.

As you can see now I just type in the actual height of the handrail in this example and the offset represents the clear width from the sketch line. So if you sketch on one face of a wall, the inside face of the railing will be offset by that amount and leaves that clear gap. Great! Another advantage (which is probably my top reason for this) is that if one needs to change the railing diameter, you don't need to mess with offsets as the railing will shrink/grow downwards and outwards, leaving the top of rail (height) and clear distance (offset) the same at all times.

But enthusiasm is short lived. Once the railing needs to step because of your stair configuration and a vertical segment is added, you end up with this horrendous joint.

Making the origin lie at the centerline of the railing profile solves the issue, but now I'm back to square one, having to factor in the railing radius, and subtract it from the height and add it to the offset. Why, oh why?!

This is just one of the many quirks that have been driving me insane about this tool. I can make it work (and sing in some cases), but it's harder than it ought to be. Designers and Architects working on projects are not going to even bother and will (are) going to use Sketchup to DESIGN a railing solution for their stairs instead. Revit is in dire need for a designer-friendly tool for this purpose. Think curtain walls: very designer friendly. You cannot drive everything with rules! That is a very limiting approach and causes you to create a multitude of railing definitions just to get ONE stair railing to work. It's nuts. Now I'm even having to separate the guardrails from the handrails just so I can "efficiently" model these railings and make them less complicated. This has got to be made easier. Something in line with Revit's sketching philosophy perhaps where you sketch the skeleton of the railing on a plane in elevation/3D (not just a footprint line!) and assign different profiles or sketch them on the fly, with joins that work properly. Anything's got to be better than this. We can make it work but it feels like pulling teeth and it shouldn't be.

I plan on posting other segments on this topic as you might have deduced from the title ;) Instead of just stomping my feet and throwing a tantrum, I'll try to post some solutions and techniques I've been using to make it easier for typical users to attempt using the tool. Ahhhh, I feel better now.

Railings from hell - 1

"Balustration" continued

Today I'm going to pick up where I left off in the other post on this topic.

Previously, we discussed how the left-over space in the Railing system family can be filled with a baluster at a user-defined spacing. The problem is that we do not have the same level of control we have with the main baluster pattern and the posts, so we cannot define where the top and bottom of this left-over is through the Edit Baluster Placement dialog. So we have to resort to modifying our post and/or baluster families.

Before we begin, here are some interesting facts about balusters:

• Baluster families (whether posts, panels or neither) cannot be generated through a Generic Model family by selecting the appropriate category, so if creating something from scratch, you need to make sure to start with the appropriate template. The category does not show in the list and in fact, you cannot even do an in-place baluster family. When you open such a family or create one from a template, you'll notice that no category is highlighted in the Family Category and Parameters dialog.

• The Top Cut Angle and Bottom Cut Angle Instance parameters are used for baluster families. These parameters give you the ability to trim the top and base of a baluster according to the slope of the top and base hosts. The Yes/No parameter "Post"works in conjunction with these parameters. If checked, these angles are set to zero and the top and base of the baluster are cut horizontally against the host and/or the railing's profile origin. Notice that these parameters are also available in the Baluster - Post family template, but the angles and sloping reference planes are not drawn. I personally prefer to use the Baluster template in lieu of the Post template, so I don't have to maintain two separate families. I can simply check the Post parameter to have it trim horizontally.

• Even though you can un/check the baluster family parameters "Always Vertical" and "Shared", the OK button stays greyed out. So basically these cannot be changed.

• Baluster templates have a fixed origin. Reference plane's "Defines Origin" parameter has no effect on changing the origin location. Make sure to locate your geometry relative to the original ref. planes set to define the origin. Avoid moving these as you'll get frustrated when the usual logic for geometry location in your project doesn't seem to hold anymore ;) If you lose the origin location, simply import a dwg into your family with some lines located at the WCS Origin, using the Origin to Origin option with Orient to View checked and you'll easily find where it is.

Now that you have some great cocktail-party facts that will make you look smart at your next User meeting or Mixer, we'll move on to see how to give an offset to the base of the baluster family.

Above you can see what's necessary to create control for the base offset. The baluster family has a void at the base and top. For the base void, we need to control the top of the void sketch. So I added a horizontal ref. plane and assigned a label parameter. I called it Base Offset. Then I moved the sloped ref. plane to the intersection of this new horizontal ref. plane and the vertical, center plane. The angular parameter will rotate the sloped plane around the intersection of the sloped plane and the horizontal plane (the two planes that the angular parameter references). In this case, even if you turn on automatic sketch dimensions, you will not see these relationships. Since the horizontal plane can move vertically based on the value of the Base Offset parameter, Revit will also move the sloped plane to maintain the intersection point in the same place. Also note that there's another parameter called "Baluster Height" that is not shown in the image (from ref. level to second ref. plane from top).

When you load this family in your project and assign a positive value, the base of the baluster will move vertically. The same can be done to control the top of the baluster. The top will trim at the angle of the railing slope, but the bottom will be horizontal since the host for the base is flat (the floor or the thread). If you want to make the bottom of the baluster be cut at the same angle as the top, replace the parameter "Bottom Cut Angle" with "Top Cut Angle".

"Balustration" continued

"Balustration"

I was in a state of baluster frustration last week as I came across a couple of things that flustered me for some time until I realised that I wasn't losing my mind!

Railings can be quite complex and I see users struggle with them quite often. You can pretty much achieve any design you want, but it takes some serious muscle to master this tool and a lot of trial and error.

The railing tool is a System Family made up of a series of horizontal Rails and vertical Balusters. Rails are defined through Profile families - imagine them as beeing sweeps. You define a vertical height, a horizontal offset, a profile & a material and you're done. Balusters are a little more complex and we need to assign the main pattern and then define the posts by selecting a Baluster family and defining the spacing rules, offsets and materials. Balusters could be a simple round or square post or a complex panel, depending on your design.


To master this tool, you have to spend some time experimenting and trying out what each parameter does. The most challenging part is building a complex baluster panel family that flexes correctly with the angle of the stairs/ramp in your project. But here, I'll highlight just a few problematic baluster issues so you can steer around them and not get stumped.

In the Railing Type Properties dialog, the parameter Baluster Offset offsets the baluster in the same direction as the Offset value in the Edit Rails Dialog. However, the Offset value in the Edit Baluster Placement dialog moves the baluster in the OPPOSITE direction of the other two parameters. This was reported and confirmed as a known "defect".

The main problem with this is that for example, if I use an offset of 3" for my rail and then I type in an offset of 3" inside the Edit Baluster Placement dialog, I end up with a 6" gap between the centerlines of the rail and baluster, whereas you would expect their centerlines to coincide! If I then type an offset of -3" in the Edit Baluster Placement dialog instead, the rail and baluster centerlines coincide, but the baluster top will not stop at the underside of the rail and will instead go to the top of the rail.

For the post top to properly clean up, the two baluster offset settings have to be either the same value, or the offset in the Edit Baluster Placement dialog has to be zero. This means that one should avoid the use of that offset value and instead use the type parameter "Baluster Offset". If you have multiple baluster patterns with different offsets, that might not be possible.

Another issue is that the Baluster family origin seems to be fixed. If you move the reference planes that have the option "Defines origin" checked together with the 3D geometry and then you reload the family back into the project, the baluster geometry will move. This shouldn't happen because these reference planes are supposed to define the origin. Since the relative distance between them didn't change, the geometry shouldn't move when the family is reloaded in the project. This seems to be an issue with the baluster family templates.

One last thing...in the stair image above, notice that the leftover spaces are filled with vertical baluster posts that go all the way down to the host surface. If we look in the Baluster Placement dialog, you'll notice that there is no control over the Top and Base (plus offsets) of the "Excess Length Fill" optional balusters.

If you want the vertical fillers to be located off the host surface, you might have to create a custom baluster with the correct offsets and number of balusters built into the family. I'll go into more detail about this in a future post.

"Balustration"