Phantom Keynotes

NOTE: This is a re-post from the HOK BIM Solutions blog

We have had several users report that some items in Keynote Legends could not be tracked down in any sheet view, even after verifying that keynoting default settings are correct. This issue had me scratching my head for a while until I figured out what was going on.

Here’s a typical scenario where this could occur: You have a core & shell project that was documented and under construction and the model gets copied as a new project for the Tenant build-out phase. As the model cleanup process commences, users start reporting that they cannot find some keynotes that are being reported on the legend.

While troubleshooting, I noticed that when enabling the view's underlay, the phantom keynotes showed up together with the tagged elements, which then led me to tweak the view range and ultimately discover how these project files were started and what the root of the problem was: when the view range was adjusted, keynoted elements were no longer visible, but still reported in the Keynote Legend. As you can see in the image below, a plumbing fixture was keynoted and properly listed in the legend:

In another view, the cut plane and top plane were lowered until the element and keynote were no longer visible in the view::

In the above image, you can also observe that right-clicking the family type also reveals that the object is not visible in the view, yet it reports in the legend. Note that hiding the element and/or tag in the view makes the legend update accordingly, but in the above example the legend is misreporting.

This has been confirmed as a bug and slated for a future fix. In the meantime, please be careful and use this example to help in your troubleshooting efforts.

Phantom Keynotes

What You See is NOT What You Get

You’re probably familiar with the acronym WYSIWYG. It’s one of the beauties of Revit, where what you see on screen is what you get in your prints. For the most part, that has been true prior to Revit 2013.

I’m surely late to the game in writing about this and it probably makes this post totally useless, but I suppose if I struggled so much to figure out how to fix the following problem in Revit 2013 and Autodesk Support themselves were unable to point me to the correct Hotfix (being told the usual canned response that the development team is aware of the problem but we cannot tell you when it’ll be fixed yada yada yada, even after pushing back to try get more detail), then I assume some soul out there might benefit from these ramblings too. This has been known for a while as you can see here.

Revit 2013 was no longer acting WYSIWYG when specific conditions were present. If certain elements were behind others that were set to 100% transparent and were totally “blocked” by said elements, then you see them on screen but you don’t get them in print. Bad, very bad, especially for Healthcare documentation and Interiors in general.

As you can see above, I said “on some machines”, but this problem actually affected all machines which were just updated to Update 2 but not with the hotfix.

It turns out in my random testing that my machine and another user’s worked fine and you guessed it…I had updated these manually a looong time ago in an effort to cure other problems with 2013, but forgot all about it (you know, the drawing area jumping into the ribbon? Yeah that one, but this hotfix isn’t so hot for that problem). I finally put 1 + 0.5 + 0.1 + 0.35 + 0.05 = 2 together and figured this hotfix actually worked to resolve the above symptom.

Anyway, I also checked that the recent Update 3 (for OneBox)incorporates this hotfix as well, so just skip it altogether and install Update 3 as fast as you can. There are separate downloads for the stand-alone packages.

I sincerely do appreciate the effort that most give at Autodesk Support when you file a Support Request, but sometimes I just cannot figure out how something like this wasn’t documented properly in their internal system and a conclusive resolution offered right away instead of having to deduce it myself. Oh well, that’s enough from grumpy Dave!

What You See is NOT What You Get

Subcategories in project files: What for?

As a Revit beginner, I wondered what was the reason we could add subcategories in a project file. Once I got more familiar with families and started playing around with in-place families, I realized why we could add them. Yet, I never ceased to wonder if there was another use for them and I finally found one recently.

Let’s say you link in an MEP model and it contains custom families with elements assigned to custom subcategories. If you look at your Object Styles in the host project, you’ll realize that those custom sub-categories do not show up (I believe they should, don’t you think?). So if your link is set to By host view, you cannot change the visual characteristics of certain family parts. This forces most users to change the link to Custom and make edits to the link. Personally, I prefer to do this as a last resort. So how do you control a TV that you don’t have a remote control for? (assume it has no buttons either!)

Adding a subcategory in the host project with the exact same name, actually establishes the missing connection to subcategories in linked projects. It’s like finding the remote for that TV. So there you have it, another use for adding subcategories to projects.

In summary, I think Revit should:

1. Display custom subcategories from linked files in your host project;
2. If objects of a discipline-specific category exist (whether in the host or linked projects), it should display that category even if it is of a different discipline than the Revit flavor you are in. I’m not a big fan of having Revit automatically hide all categories from other disciplines even if they have elements on them. Most users can’t figure out why they cannot turn something on/off (Analytical Model subcategories for Structural Framing and Structural Columns anyone?). I’d be ok with Revit hiding unused categories & subcategories from other disciplines or all unused, but if an element of a particular category exists in the project, that category and all subcategories should be listed in the V/G dialog.

Subcategories in project files: What for?

Filters, View Overrides and Halftones

Here’s an example of something that seems to be broken. I created 2 floor types and 2 wall types, and called each one Object1 and Object2. Then I created a filter for the floor and wall categories, and filtered By Type = Object1. This way I could verify that the issue is not isolated to a single category. I assigned this filter to the Visibility/Graphics dialog, set an override for projection lines to Red, and the result is shown below:

 

Then I set a view override in addition to the above filter and made Floor projection lines as Blue:

 

Thus we can deduce that overrides are applied in this order

1. Filters
2. View Overrides

So far so good. Based on this order, one would assume that if I set an additional view override to Floors and Walls to Halftone, Object2 should halftone but Object1 should not, right?

 

Wrong! As you can see above, the halftone setting in the View Overrides is taking precedence over the filter. I’d say this is an inconsistency that needs fixed. Agree?

Filters, View Overrides and Halftones

Pesky beams

So you have a plan view with the following View Range:

which should only show elements in the shaded area:

Notice that the beams are above our view range. However in a plan view, you get this:

Why on earth are those beams showing up in that plan view? After taking a look at the properties, one might not see any issues. Upon inspecting a 3D view, the Analytical Lines don’t seem to be set correctly, however the Vertical Projection in the Properties is set to “Auto-detect”. So what gives?

The answer is at the top of the properties dialog. Notice that the beam’s Reference Level is grayed out and so is the Workplane. Now try and enter a value for the Start or End Level Offset and notice how the Workplane parameter disappears and the Reference Level is now editable. Just re-set the Start/End Level Offset to zero and alas, the analytical model will come to its senses and will start detecting the correct location. Bug? I dare say so but I’ll seek an official confirmation and post an update.

The interesting thing is that Structural Framing visibility is defined by where the analytical model is. I personally do not agree with this at all. Plan representation (in my opinion) should not be dictated by where an engineer decides he/she wants the analytical model to reside, but it should be purely based upon geometrical location. So make sure to either “touch” the Start/End Level Offset as described above if you’re only using the z-Direction Offset value, or use the other offsets instead!

Pesky beams

Visibility mystery

Picture this…you have a Site project linked into an Architectural project. You go to a 3D view and nothing from the site file shows up. The treasure hunt begins.

It could be as easy as the workset assigned to the Site link being turned off. Or the link being turned off in the view. Or all the object categories that exist in the Site project file being turned off in the host view. Or having the link visibility being set to “custom” and all categories being turned off. Or the link being overridden in the view and turned off (yikes!). Or a filter’s visibility being unchecked. Or a particular workset in the Site project was closed when initially linking it in. Or a hidden section box was clipping the site project elements out of the view. Phew, I’m out of breath!
However, there is a condition where none of the above are the cause of the problem and could leave you scratching your head for some time. It’s a condition that exposes another little Revit shortfall which makes us beg for even more visibility control.
The problem is a workset in the Site project file that is set to not be visible by default in all views. In this particular case, the users were able to see the information in a plan view set to “By Linked View”, but in 3D views the Site project was invisible. It turns out that all site elements were on one workset set to not be visible by default. We don’t have control over the visibility of worksets in linked files and I think we really need to. The fix was to create a new workset that is visible by default in all views, delete the offending workset and move all objects to the new workset, and then rename it back to what the original one was. Mystery solved!

EDIT:  As of Revit 2011, we now have control over the visibility of worksets in linked files. Thanks Factory!

Visibility mystery

Display Model parameter

A view property that is often overlooked is Display Model, under the Graphics section. This is useful when you want to quickly turn off the visibility of model elements or set them as halftone/grey scale. This leaves view-specific elements such as detail lines and text visible or easily distinguishable from model elements.

To turn off model visibility in a view, go to the view properties and under Graphics, set the "Display Model" parameter to Do not display. This will turn off visibility of model elements. Keep in mind that tags will disappear since the model elements they belong to are no longer visible. If you use the option As Underlay, model elements will display similar to half toned elements and tags will also stay visible.


I have run into multiple occasions where not all model elements turn off. I filed a Support Request about this a year ago, and it was confirmed to be a bug. If you come across a case like this, please report it and quote SR# 1-2045600292 as a reference. Visibility of elements with overridden line work seems to be respected, but if you hover over their location, they can still be selected, which I don't think is right either.

What I like about this view property is that you can isolate detail lines. If you turn off the visibility of the lines category in V/G, detail lines turn off also, as the line category contains both model and detail lines. So if you have both model or detail lines in a view, you can use this parameter in combination with some other tools to isolate and convert those lines to your liking. See Steve Stafford's post for how to do the conversion.

Some teams like to "draft" their wall sections from scratch rather than using Revit's live wall sections and then embellish them as necessary. There are cases where this might indeed be faster, but I think it all boils down to technique. I don't advocate the former approach, but if you absolutely have to, use a live section view and set the "Display Model" parameter to As Underlay. This way you can at least have some visual reference to see if you're matching up with the model or not. Due to schedule, sometimes this approach might get your drawings done faster as you don't have to wait for all model components to be accurately placed (such as structure, etc.), but please understand that by doing so, you're giving up the true benefits of the BIM approach and will require manual coordination of systems. To make sure it's closer to a BIM work flow as possible, leaving the model as an underlay ensures that the big skeleton and skin of your building conforms with your detailed wall sections.

Display Model parameter

Line weight visibility in linked files

This was inspired by a thread on the AUGI forums and I didn't realize that visibility in Linked Files behaved this way.

When you link a Revit Project into your main host project, the visibility is by default set to By Host View. You can change this option to By Linked View or Custom. So far so good.

If your host and linked projects were started from the same template, you might not notice this issue, which is probably why I never came across this head-scratcher. When getting a project file from some other source outside your office, you stand a good chance that the line weights in each file are not the same as yours and/or other linked files.

When your link visibility is set to By Host View, Revit will use your host project's visibility settings to display the geometry in the linked file/s, together with other settings as shown below.

Notice that Object Styles will also be represented based on the Host file. But here lies the problem: what if the line thickness mapped to the line weights are not the same in each file? That's exactly when you notice the problem. For example in your host project, you might end up with walls showing with different line thicknesses, because Revit will use the line weight per the host file, yet it will still map the line thickness of the parent project file to it's geometry. So while your walls might rightly be using line weight 5 for their cut representation, your host project's geometry will display at 0.018" thick lines per the host's line weight settings, but if the linked project has line weight 5 mapped to a thickness of 0.2", then Revit will use that thickness for geometry residing in that linked (parent) file.

The solution is easy: Use Transfer Project Standards to copy the line weight settings from your host project to the links. I personally don't think Revit should behave this way. If I say I want settings to be By Host View, I would expect the line weight to line thickness mapping to also be honored. Maybe we need a new line item to the above list: Line Weights. You agree? Great, go file a wishlist item on AUGI!

Line weight visibility in linked files

DWG visibility in Revit projects

When you link or import a DWG file into your project (with the option "Current view only" unchecked), Revit sees this information as part of the building model and will use standard model visibility rules to display it. If you check the above mentioned option, Revit will see it as view-specific "annotation" and that DWG will be visible only in the view where it was imported/linked.

The use of DWG files in Revit projects varies. The most typical applications are to pull from one firm's detail library and for use as background drawings, such as site surveys, casework backgrounds, etc. I know, not a great use, but when transitioning, you need to somehow eat that elephant in small bites, especially when project size is large and Revit knowledge is not substantial!

When used as backgrounds, DWG visibility could get a bit confusing. For example last week I was helping someone with their project. This user linked a DWG on the first level and another on the second level. Typically, if you open the second floor plan, you would not expect the first floor DWG to show up. The team wanted to quickly bail out and turn it off manually on the second floor plan by unchecking the subcategory visibility in the Imported Categories tab, but that's just bad practice in my opinion. If you go this route, you'll have to manage visibility in every second floor plan view! Not very efficient, isn't it? The key is to understand why it was showing up and prescribe a cure.

We checked the View Range and it was set correctly. We opened the linked file in ADT/ACA and looked at it in side elevation and saw a number of lines going up in the Z direction. Once your View Range can see any geometry in the DWG file, the entire link/import shows up. The DWG link/import doesn't act as a cuttable object; instead, once the View Range overlaps a part of the DWG, it acts as a switch and turns the light on over the entire link.

So next time your "2D" DWG seems to misbehave, just check for those maverick elements that turn it into a 3D object and zero out their Z coordinate values or lower them so your View Range doesn't overlap these elements. You'll be pleased with the results ;)

DWG visibility in Revit projects

A tale of a ghost

So I'm sitting here kicking myself for not thinking of this earlier, but now I'm a better man for it!

Bill comes to me in desperation..."I have an image that is printing in every single section and elevation view, but it doesn't show up in the actual view!". I looked at him in awe....I thought he had a sip too many. "Bill, that can't possibly be true! Don't you know that what's not in your view, cannot print?! That's a Revit basic behavior!". So I reluctantly stroll to his desk and we open up the project file. Sure enough, the darn raster image shows up in the Print Preview. So I start troubleshooting....turning visibility of links, raster images with absolutely no positive results. Then Bill pointed out that if the crop region doesn't include the first level, the image goes away. I immediately start blaming some project corruption on the level and thought that we're going to have to send it to Autodesk Support.

And then it hit me.....I turned off all Imported Catergories (those awful DWG files) and the raster images vanished from the print preview! Hurray! Problem solved. Don't ask me how that raster image got there in elevation in all section/elevation view of all orientations, as the dwg files were used as backgrounds for casework and other things that we didn't do in Revit in plan, but that's what was wreaking havoc. Pretty simple issue to resolve....DON'T USE DWGS!!

Well, use with caution :)

A tale of a ghost