Revit 64 bit? Don’t use IE8!

I’ve been experiencing crashing events with both Revit 2009 and 2010. I finally narrowed it down to Internet Explorer 8. The funny thing is that these problems started with the released version of IE8 and not the Beta! This was filed this with Autodesk Support and turns out to be a known issue. Their response perfectly describes the symptoms I was experiencing. You have now been served!

“Thank you for choosing Autodesk Support.

Internet Explorer 8 is not recommended to be installed when used with Revit 2009 64 bit. There is a known issue with the recent files screen. The Recent Files menu is an HTML based window and uses Internet Explorer and has not been designed to be used with IE8.

IE8 is also not recommended to be used with Revit 2010 as it has not been designed or tested with it. The same problem does not exist with the recent files screen in the same way but it is apparent that if you have the recent files window up and TAB+CTRL between your windows while using 64 bit and IE8, it will crash. You can use IE8 if you do not have the recent files window open.”

Revit 64 bit? Don’t use IE8!

Jumpy Text

This is one of the most annoying behaviors in Revit. I can’t believe that we’ll have to deal with it for at least another year. Pretty sad.

We need text, don’t we? Unfortunately creating project notes in Revit is a frustrating endeavor. Text re-formats itself depending on the zoom factor, which is totally insane if you ask me. Take a look at this animated gif.

So how do we deal with this issue? You could link in a dwg that contains your text, but this can potentially result in more headaches as mtext boxes are sometimes ignored by Revit. And honestly, I want to stop using DWG files altogether. Another huge limitation is the inability to indent text so you can number each paragraph and be able to adjust the column width of your text without resulting in a formatting do-over.

Back at AU2007, I learned a tip which I’ll be employing from now on. I feel really dirty using it, but there’s no other solution I can think of. I’m not sure where it originated but I learned about it through a hallway chat with the “Rock-n-Roll Architect”, aka Steven Shell. If you know who contributed it, please post a comment. Here it goes…

Create a Key Schedule for a category that you never use. No, the Roads category is not available ;) In this example I chose the Sprinklers category but you’re free to pick anything you want.

Notice the Name field. That’s the name of your key schedule in the project browser, and will also be your Title when you drag this onto a sheet. It’s not necessary to change it in this dialog since you can rename it later in the Project Browser. I named my example “GENERAL NOTES”. Next, type in a Key name and click OK, which leads us to the Fields tab.

Add a new parameter to house your text notes; I used “MyText”. In the Sorting/Grouping tab, sorting will be set by default to the Key Name, which is exactly what we want. This will contain the numbering of each paragraph. To finish up, set your appearance preferences. In my case, I wanted a wide outline and turned off the option to Show Headers as we don’t really need them. Once you click OK, you’ll be in schedule editing mode which will just show the title (If you choose to not have a title, you’ll get a blank page). The next step is to add rows to your key schedule. Let’s use Revit’s new interface to illustrate (click animated gif for larger view).

Now you just drag this onto a sheet and make final adjustments there. This should eliminate the problem of Jumpy Text. A couple of issues that you’ll face are the fact that you don’t have Project Browser sorting/grouping capabilities and that you cannot use the same schedule name twice, so you’ll have to get creative. One option is to have these key schedules named with a prefix so they’ll be grouped together in the Project Browser and separate from “real” key schedules (ex: txt_Roof General Notes). Then you would turn off the Title and just type in text directly on your sheet as seen below.

PS: Autodesk, PLEASE, this needs fixed. Seriously.

Jumpy Text

Detailing issues after Rotating Project North

A couple of very useful tools were officially introduced in the 2009 versions of Revit that users had been begging for for quite some time. One was the Mirror Project tool and the other was the Rotate Project North tool.

How many times have you started drawing/modeling a building only to find out it doesn't fit nicely on sheets? As a "standard", we always try to orient Project North as close as possible to True North. But at times we find out too late that it would have been better to orient Project North differently.

With this new tool, we can rotate our project, associated views, tags, etc. at the same time. This is a huge time saver but comes at a price. It's a tool that has problems, so don't expect to come out unscathed. You might have to do some touch-up work to correct some things that don't rotate properly. As we shall see, some issues are currently not correctable, but it helps to know what can happen and be aware of potential workarounds. Note also that the Mirror Project tool has similar issues, but once again, it can save a lot of time when designs change and we want to flip the building when we're already far into documentation!

I came across a problem recently and thought that some elevation views had gotten corrupted. When the user tried to draw a view-specific element, such as a detail line or a filled/masking region, Revit returned an error because "the Work Plane is at a very sharp angle". Now we know that these elements are not drawn on a typical work plane like other elements, such as model lines, so this error is a little bit out of place.

I sent the file to Support (pays to be a subscriber!) and it was pointed out that the Project North might have been changed on this project and could be causing the problem. We confirmed that the team did use the tool, and unfortunately there is currently no solution to correct this, except to re-create the elevations in this case. It was interesting to see that elevation callouts created from these "defective" views worked just fine.

Once I became aware of the repercussions, I took it a bit further and tested Section views. Turns out that these are affected in the same way as Elevation views. So make sure to rotate Project North early in the process and don't wait too long!

Workarounds

Short of deleting existing vertical views and re-creating them, there is something you could do. If you create a callout view in your "defective" elevations/sections, you can add the view-specific detail elements in the new callouts. Then copy them and paste-aligned to the original view. These will appear as expected but they cannot be edited easily (no grips). You can also create detail groups of these view specific elements, which will allow you to edit them in other views, even Drafting views. If you don't need the callouts, you can delete them and re-create as necessary when needing to edit your detail items perhaps.

As you can see, it can get a bit convoluted! If you're early in the process, I'd suggest re-creating the views. But if you're further along and have invested a lot of hours in those views already, you might consider these techniques until this known issue is resolved.

Detailing issues after Rotating Project North

3D View Orientation

What a slacker I've been! It takes a while after a good storm for things to return to normal. Anyway, here we go :)

So let me start by pointing out what I believe was an oversight in the 2009 Revit family of products. Before the advent of the View Cube/Steering Wheel, we used to click F8 or click on the "eye" icon to dynamically modify the view:

Do you remember the highlighted icon shown above? This was used to undo any 3D view orientation changes, thus setting it back to the original saved state. It was very useful in the following scenario: Let's say someone saves a 3D view and places it on a sheet. Someone gets in the 3D view and spins it around. So now the view is oriented incorrectly. If the view is not re-saved, it will return to its saved configuration once the file is re-opened. But if this person wanted to print the sheet/view as intended with the correct view orientation, all you had to do is click on this icon and the view would be restored to its original state. Just closing and re-opening the view doesn't do the job, so it's either closing and re-opening the project or using this tool.

In 2009, the Dynamic View dialog has been replaced by the Steering Wheel. Instead of using the save button on that dialog, now you simply right click on the Steering Wheel (you can also click the little arrow at the bottom right corner or right click on the View Cube) and select the Save View option:

But what happened to the Undo button? Oops! It vanished. And no, the "Go Home" option only restores one home orientation for the entire project and not for each view. You can easily try this out by creating a couple of 3D views, setting them at different orientations, right click on the View Cube and then select the option Set Current View as Home. In one of the 3D views then select the Go Home option and you'll see that only one project-wide orientation can be set.

We absolutely need the Undo function back. If you agree, please submit a Support Request through your Subscription Center. Yes, I already did ;)

NOTE: Revit's help topic titled Dynamic View Tools in ViewCube and SteeringWheels suggest that the Rewind tool has replaced the Undo View Orientation Changes button. However, this is true as long as the view stays open. Once the user closes the view, Rewind history is lost and the only way to restore the view's orientation is to close the project and re-open (or re-orient and save).

3D View Orientation

"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"