Thursday, 23 July 2015

Propagate Extents for Grids

An update to an older post...

PROBLEM: The Propagate Extents command in Revit for grids does not seem to work. Is it broken?
SOLUTION: Don’t waste your time changing grid bubble locations view-by-view!. The Propagate Extents enable to apply a consistent override of grid bubble placement across multiple views in the project.

But for this command to work, both the "source" view with the bubble override and the "destination" views should be parallel (i.e., horizontal level views, parallel elevations or sections), AND the cropping properties of the views should be disabled. The process is as follows:
  1. Prepare a single view with the grid bubble location as desired.
  2. Switch off the Crop View, Crop Region Visible, and Annotation Crop of the source view and all the parallel views you would like to apply the same grid bubble graphics:
  3. Select the grids in the "source" view, and in the contextual tab click Propagate Extents
  4. At the prompt of the dialog box, select the views to propagate the grid extents and click Apply.
  5. Return to the views and switch on the Crop View and Annotation Crop boxes.

Friday, 20 March 2015

Ensuring your families 'make the Cut'!

We all know family creation can be a tedious art, especially when you need an element (i.s. an under-mount sink) to cut into another object (i.e. a counter top), so here's a friendly reminder about how to set this up correctly:

In your family:

1. Ensure "Cut with voids when loaded"
2. Model the void extrusion(s) you need to cut the adjacent elements in the project
3. Load the family into your project

In the project:

4. select the element
5. Use the Cut tool (under Modify tab) and then
1st select the element to be cut
2nd select your cutting element (the family you just loaded)

And the result:

Tuesday, 20 January 2015

Troubleshooting Underlays in Revit

If you're experiencing problems displaying elements using the Underlay property of a Revit view, the feature just might be behaving as designed.

We recently had a team working on a high-rise project and they wanted to use the Level 8 plan as an underlay for the Level 5 design. In other words, using a level above as a reference for a lower level.

PROBLEM: The walls didn't show, but plumbing fixtures did. As a matter of fact, it seemed like anything that was supposed to be cut in plan view was not showing. We tried just about everything to fix the problem...changed the view discipline, checked the phase filters, and so on.

It turns out that the View Range settings are crucial to the behavior of underlays. If EITHER the host view or the underlay have the View Depth set so that the views 'cross' each other - cut object styles will not be displayed. This usually happens when View Depth is set to Unlimited.

While this seems to make sense for an upper level that uses a lower level as an underlay, it behaves the same way in the opposite. If the View Depth of the upper level includes the lower level within the view range, Revit thinks the elements are already being displayed and does not show them in the underlay.

Tuesday, 13 January 2015

Problem with Standardized Shared Parameters

It seems like a wonderful idea to develop an industry standard shared parameters file for Revit - but it all depends on how you develop the parameters and implement them. Should you set the standard without any special naming convention or identify parameters developed specifically for such a standard?

Antony McPhee provides some constructive commentary on the standardized shared parameters provided by the NBS (National Building Specification) in the United Kingdom over on the Practical BIM blog.

(Thanks to Cesar E. for the contribution)

Monday, 27 October 2014

Underlay Visibility Issue in Linked Models

It appears that this problem has been around since Revit 2011 but I have not personally come across it until a few weeks ago. We frequently separate Furniture and Furniture Systems into their own models on certain projects to improve on model performance and general working efficiency. Recently one team member noticed that underlay behavior differed when these element categories were in a linked model vs. in the host. This issue could potentially affect other categories but we have not attempted to confirm.

When laying out lighting in a Reflected Ceiling Plan view, designers need to reference Furniture and Furniture Systems by overlaying them. When this geometry is in the host model (in the same model as the ceiling), the user simply sets the Underlay option in the view’s property and carries on with their work as shown below:

Elements in HostIf furniture and furniture systems are brought into a view through a linked model, things get unnecessarily complicated and the Underlay option no longer works:

Elements in Link1If link visibility is set to By Linked view and the source view has the Underlay option enabled, the underlay elements still do not show. The current workaround is to:

a) lower the cut plane temporarily so it crosses the geometry in the linked model;By Linked View

b) set up a source Reflected Ceiling Plan view in the host model with a low cut plane (ex: at the floor level and only enable Furniture and Furniture Systems). Now set the visibility of the linked model to By Linked view and use this source view.

I think we can all agree that this is something that needs to be addressed sooner rather than later (confirmed to still be a problem in Revit 2015 Update 3).

Elements in Link2

Wednesday, 24 September 2014

Dialog Box, Dialog Box: Where art thou Dialog Box?

In the world of having 2 monitors, sometimes Windows likes to think we have more than 2 monitors connected. When that occurs dialog boxes can open and not be visible on the either of the current monitors.

For Example, you open Revit, click to open a file and the open dialog box "Pops Up". Only, Revit seems to hang and you never get the dialog box to display.

Try this quick little Windows Trick to get the dialog box to become "Sticky" to your mouse and then move it back onto your viewable screen.

1. With Revit as your active program.

2. Perform the following Keystrokes:
A. ALT+Space Key
B. M (This is for Move)
C. Push one of your Arrow Keys (Doesn't matter which direction)
D. Move your mouse and the active dialog box will be attached to your mouse cursor and you can now place it where it can be visible.

Keep in mind this is a Windows function and will work for more than just Revit, the solution works on anything that has a standard dialog box or window that can be Minimized, Maximized or Closed.

I hope this helps alleviate some frustrations in finding where dialog boxes go and seem to make your application hang, but really it's waiting for a response from you!

Tuesday, 20 May 2014

Phantom Keynotes 2.0

I posted about this topic in the past (see Phantom Keynotes) and it seems that we keep finding issues with Keynote Legends reporting keynotes that don’t seem to exist in the view. I have also written a follow-up post (see More on Keynotes) to discuss other visibility issues and other problems related to this functionality and the current User Interaction shortfalls. Recently some Electrical users pointed me to additional instances of misreporting by Keynote Legends, so this post will summarize those findings. These can be reproduced in Revit 2015.

  1. If the Annotation Crop Region is not enabled, keynotes attached to objects that lie outside the model crop region are still reported, which is completely unexpected. The result is the same whether you use Element Keynotes or User Keynotes. The expected behavior should be that if keynoted objects lie outside of the model crop region, those keynotes should not appear in the legend, regardless of whether the annotation crop region is enabled or disabled.
  2. Another instance of Phantom Keynotes occurs with keynoted elements in close proximity to the view’s model crop region. This issue is exacerbated even more when the tags are far from the objects they are attached to. With the Annotation Crop Region enabled, the keynote still appears in the legend unless the boundary of the Annotation Crop region touches the edge of the keynote annotation. This is completely unexpected and the following series of images illustrate the problem:


If the Model and Annotation Crop Regions are adjusted such that both the model element and the keynote tag lie outside these boundaries, the legend will rightly not report that keynote:


However the Keynote Legend will still incorrectly report the keynote if only the model element is outside of the Model Crop Region, but the Keynote Tag is within the Annotation Crop Region (the legend is actually only concerned about the tag, not the model element):



Please be very careful when using this functionality and double check your work (don’t assume that the Keynote Legend will hide unrelated keynotes for you!). The only workaround at the moment is to pick the keynote tags that shouldn’t be listed in the legend and manually hide them in the view, which is a very ugly workaround. The following process needs to be followed for each view:

  1. Select all instances of the keynote tag in the project;
  2. Remove all keynote tags visible in the view from the selection;
  3. Right-Click and Hide all instances in the view.

The desired and expected Keynote Legend filtering is as follows:

  • If the keynoted model element is not visible in the view and as a consequence the tag is also not visible, do not report it;
  • If the Keynote Tag is not visible because it is manually hidden in the view or because it touches or is outside the Annotation Crop Region, do not report it

Monday, 14 April 2014

To/From Room Door Parameters

Prior to Revit 2014, these parameters were very unreliable and prone to error. With Revit 2014, we saw the introduction of a new family parameter called Room Calculation Point, which can help with reporting consistency. However be mindful of the fact that this setting has to be manually activated, otherwise the information will remain as unreliable as before. You can read more about the topic in this RFO thread.

Here are some facts about how these parameters work without the Room Calculation Point enabled:

  1. If rooms already exist on either side of a wall when a door is inserted, the room on the swing-side of the door will be set as the To Room;
  2. If the door is then flipped, the To/From Room parameters do not update. The user has to make manual adjustments if desired;
  3. If no rooms existed when a door was inserted, the first room added to either side of the door will be set as the To Room;
  4. Both doors and rooms have to be in the same model for these parameters to report. The schedule can reside elsewhere, however manual changes between the two reported rooms have to be made in the host model.

As you can see, the reported information is prone to error and highly unreliable. Another big issue is the fact that door swing direction does not imply “ownership”: a door could be swinging out of a room and technically belong to that space. It is also usually not possible to infer hardware functionality from swing direction and door “ownership” alone.

By enabling the Room Calculation Point, we can at least address data errors. The To/From Room parameters will then update consistently regardless of whether the door is placed before/after the rooms, or whether the swing direction is altered after placement.

As with a lot of things in our industry, there is no standard way of documenting doors: some include information for the room that the door “belongs” to, some include both To/From Room information, while others completely exclude these columns of data. I happen to be of the opinion that the latter is the most prudent choice, although the Room Calculation Point parameter makes me less concerned about data inaccuracy. However be very careful: changing the To/From Room parameter when the Room Calculation Point is enabled, will actually flip the swing direction! This is a behavior change that you really need to be aware of.

If you happen to use the To/From Room parameter to report “ownership” only, you can do so with even greater reliability by employing the following trick. The little leaders are hardwired in the family template to prevent them from crossing the Internal X-Axis:


By shifting family geometry, you can then consistently report “ownership”. In the example below, both the To Room and From Room parameters will always report the room on the swing side of the door. Note that you can flip the To/From direction if you need to, although that would not change how these values are reported in the example below:


The other very positive side-effect of doing this is that now you cannot accidentally flip the door direction from the schedule, since both To/From Room parameters will report the same data. If you want to report ownership based on the outswing-side, simply shift the geometry in the opposite direction. Please note that “ownership” rules cannot be changed at the instance level (ex: you have to commit ownership of a door to always be on the swing side at the family level), so if you need to change this and still use the Room Calculation Point, you will have to double up on your family definitions in a project, or employ some of the workarounds described in this RFO thread.

Friday, 11 April 2014

Sync with Central Best Practices

Here’s a list of best practices David Ivey shared for synchronizing with central (SWC) in Revit:

Never leave for extended periods of time (i.e. Lunch, Meeting, Home) after hitting the Sync button. 
Revit will often ask for something before the process is complete, and if this happens while you’re out, your team can be stuck with a central file that is ‘in use’, and be kept from saving/working.

Always use the Worksharing Monitor (WSM), and consult it before hitting the Sync button. 
This will save you and your team time by not making Revit slowly wade through two or more concurrent SWC attempts. Wait for an opening in the WSM, and then sync. And yes, WSM will work in a Citrix Revit session.

Always use the Sync and Modify Settings command, so that you are presented with the dialogue to release borrowed and owned elements. 


Check all available boxes when syncing (with the exception of the Compact box), so that all objects and elements are returned to the central file.


Add comments in the field provided. These comments are helpful in tracking down problems that may occur from time-to-time in the model. Short, concise descriptions of work are all that is required. This is a problem solving tool, and not a means for assigning blame (as some believe).

Always save locally when prompted.  SWC when prompted when working alone, or after consulting the WSM on small team projects (2-5).  For larger projects, consult with your project’s BIM Coordinator.  On larger projects, there may be a SWC schedule to follow, usually set in 30-120 minute increments depending on project, team, and model size, or during deadlines.

Over-communication with your team is far better than poor communication. Utilize Jabber (or other instant messaging application), email, your phone, or your voice, and make sure you and your team are all on the same page.

Monday, 24 March 2014

Filled Regions and DWG Exports

This sounds like an odd paring for a blog post subject, but they are unpleasantly related.

When a view contains the following items and you export to a CAD format, you will likely experience loss of data:

  • Families with nested Generic Annotation such as Security Devices, Fire Alarm Devices, Electrical Fixtures, etc.
  • A large filled region covering a big portion of the view, usually to identify areas of work and areas outside of work.

This issue was filed with Autodesk Support and it has been known for at least 3 to 4 years. It seems that regeneration of the nested families fails, which results in the absence of these devices in the export. They are actually still in the view, but since in most cases there is no geometry visible in plan except the nested annotation itself, you end up with no object representation. The following are some workarounds, some more acceptable than others, depending on your situation:

  1. Delete/hide the filled regions before exporting;
  2. Change the filled regions to Solid Fill and everything will export as expected. You will then need to open each exported file and change the hatch to something other than solid within the CAD editing software;
  3. Do not use component families with nested annotation. This is obviously not an acceptable solution for MEP (#2 or #1 seem to be the only viable solutions), but might be acceptable for Interiors, where they can simply show these devices through the use of Generic Annotation families placed directly in the view. These can be scheduled within Note Blocks if required, however this workaround means you cannot make these objects visible in other views to properly coordinate your work, or see them in elevations, sections and 3D views.

There is no good workaround for this issue and the best is probably #2. Let’s hope the Factory can get this fixed sooner rather than later.