Wednesday, January 4, 2012

Clash Report and Incorrect Revit ID Numbers

This problem sucks, there just isn’t any good way to put it….

If you’ve been using Navisworks with Revit files, you may or may not have run across this depending on how you use the Clash Reports (exported reports).  When you look at the Clash Report, there is a separate column for the Item ID, which for Revit is the Element ID.  You can use that ID number to search for the Element that is being called out in the Clash. (similar to what I discussed in this post about Revit Interferences)  At first glance, it looks great.  I can grab that ID number, go to Revit and quickly find the item in the Clash, especially if you don’t have the Navisworks model (versus possibly using Switchback if you had the Navisworks model). 

But, there is a problem when it comes to some objects.  Some objects, like Columns, Beams, Diffusers (to name a few) don’t actually report the proper Revit Element ID!!  Yeah, not so good!  From what I can tell, it’s actually calling out the Element Type ID Number and not the Element Instance ID Number.  (See this post about the props of a Revit element and what is considered Instance vs Type)  Some of you may be thinking, well can’t I just use the ID number to find the object in Revit….sorry, no you can’t.  Revit wants the Instance ID number so it can actually find and select the corresponding Instance Element.

Oh, I should mention a way to get the proper number.  Well, there actually is a couple. One being to use DWF’s from Revit instead of NWC’s.  The DWF will put the Element ID number as a suffix to the Name of the object in Navisworks.  But for many, that would require a complete change in process of getting files.  The other way, would be to have the Navisworks model open with the corresponding Clash Test and Results.  When you select a clash, the bottom pane in the Clash window will show you what objects are clashing.  If you select the Element Name, use the Select button, you can then look at the Properties to get the proper Element ID number.

I’ve reported the issue to Autodesk Support, which was escalated to the Development Team.  Hopefully (keep anything and everything you can crossed) that they can solve this issue in the next release of Navisworks!

Tuesday, January 3, 2012

Selection Tree and Revit Objects

This is something that I get asked quite a bit…when I load in a Revit file into Navisworks, why do things like Columns or Doors (as examples) always show the Type Name twice?

If you’re not sure what I’m talking about, here’s a little screen shot…


As you can see, the W10x49 has a “sub component” also called W10x49.  What you are really seeing here is the Element and the Type (respectively).  To help explain this a little further, here’s each one selected and the associated “Element” properties…

image  image

As you can see in the image on the left, the Properties for the first item selected displays the Instance Properties of the Revit object.  On the right image, you can see the next item in the list is selected, which is now displaying the Type Properties.

So when you see Revit objects with what seem to be duplicate names, you are actually seeing the Instance and the Type.  One thing to note, this isn’t the same for all Revit objects.  Take Walls for instance, Navisworks only lists out the Instance and the actual geometry (as shown in the top image).

From what I can tell, this helps separate out the Properties and the number of tabs that are displayed.  But, there is an issue with having all of these properties broken out like this, specifically the Element ID!  This ties back to the Switchback post…if you try and use Switchback with the Type selected, it won’t find the object.  And, that’s not all…it also affects your Clash Detection reports!  More to come on that subject soon….