Myth Buster: Revit & IFC, Part 2 - The Saga Continues
Where Are We Now?
After my first article on Autodesk® Revit® and IFC (AUGIWORLD, September 2012), I got a lot of responses and feedback—from all sorts of different people and companies. I'm currently collaborating with IFC programmers from Autodesk® (yes, they actually have those), a technical consultant from Tekla, and several architectural firms using ArchiCAD such as BondBryant Architects and Zeep Architecten to document and investigate IFC handling with Revit. As it most surprisingly turns out, we all just want to do our jobs as well as possible and IFC is a part of it. This article is an update of that collaboration.
Roads
Let's start with a challenge: How do you create an element in Revit of the category Roads? Yes, the main category Roads, not a Site or Topography subcategory. Check it—it’s there... now use it.
Figure 1
Okay, spoiler alert—you can’t. There is no way to natively create a road element within Revit. Basically the category is a leftover from an attempt to bring proper site tools to Revit back in the days. Development was an epic failure so it all got cancelled. After the smoke cleared, all that remained was the obsolete category Roads. That, and Site Tools.
But you can create roads using IFC with the mapping functionality. Model Road elements as masses, (in-place) walls/floors, generic components… heck, use railings based upon adaptive components. Just make sure they're identifiable as roads.
There are a few things you need to remember when choosing the Category as you create these elements.
System Families cannot be overridden by the export mapping table. In other words, a floor will always be mapped to IfcSlab. There are currently two exceptions of which I am aware:
a. In-Place components categorized as System Families. These too will respond to the settings for the appropriate category in the mapping table.
b. Setting the Revit (sub)category to “Not Exported” will not visibly export the element. The element will be exported, but not visible in an IFC viewer, nor will it be re-imported when opening the file in Revit.
In the import mapping table, some hard-coded IFC counterparts for the Revit System Families are simply not there, which means you cannot use these to override IFC classes upon import. Examples are IfcRamp, IfcSite, IfcSlab, IfcSpace.
System Families you can remap are IfcCurtainWall, IfcWall, IfcRoof, IfcStair (which makes no sense since it’s basically the same as a Ramp in Revit).
1. Create a 3D view with only the components visible you need as roads. I used the following Revit categories to create roads (see Figure 2):
- In Place Floor
- Floor
- Topography
Figure 2
Option A will let me put them in any given IFC class based upon the settings in the mapping table.
Options B and C will always be exported as an IfcSlab and IfcSite. Upon import I will not be able to remap this to roads because the IFC class IfcSlab and IfcSite are not supported in the import mapping table.
2. Create a custom export mapping table. How to do this? Open the standard AIA export mapping file you get upon import. Don’t know where it is? Go to R > Export > Options > IFC Options (see Figure 3).
Figure 3
In the menu, choose Save As and save the txt-file somewhere. Rename it “IFC_Not_exported.txt” or something similar. Exit the command then open the txt-file in Notepad and place everything beginning with “Ifc” with Not Exported. Save it again. You now have an “empty” IFC Exporter file to use as desired.
You’ll get something like Figure 4. Keep in mind that the syntax is:
<Revit Category> <Tab> <Revit Subcategory> <Tab> <IfcClass>.
If you don’t need to specify a Revit Subcategory, leave this one blank, just put in two <Tabs>. Currently IFC subclasses are not supported.
Figure 4
Now for the final step. In Notepad, find the categories you DO want to convert, and rename “Not Exported” into “IfcBuildingElementProxy.” In this example we need to map the following Revit categories:
- Floors (for the In Place Floor component and to export the Floor to the IFC file.)
- Topography (to export the Topography to IfcSite). It doesn’t matter which class you put in here, just as long as it’s not the “Not Exported” value.
3. Go back to Revit, IFC Export options and hit Load. Now find the file you just created and apply it. Then Export your file to IFC. Use the standard 2x3 settings upon export.
4. Upon import, create a mapping table which converts all elements in IfcBuildingElementProxy to the category Roads and presto, you're done (see Figure 5). Notice that you cannot apply an override for the IFC classes associated with Revit System Families (see Figure 6).
Figure 5
Figure 6
Why would you want to do that? I don’t really know… But it doesn’t just end here. When thinking about practical uses, it occurred to me there are several:
Use masses to model sites and convert them to a topography.
Model complex windows as curtain walls and re-import them as a native window.
Ever have a mass that wouldn’t let you create a Wall/Floor/Roof from Surface? Select the surface, extrude it to the desired thickness, export to the proper IFC class, and re-import.
Use Generic Model Adaptive Components to create all sorts of shapes you cannot manage in the “regular” family editor and then export and re-import in the desired category.
And so on…
Granted, there are limitations. Imported IFC objects usually are dumb, non-parametric objects, which limits the usability. And I’ve not had the time to test performance hits, stability, and that sort of thing. So use at your own risk. But still, this is an intriguing workflow.
IFC By Layer
Have you ever had to use an IFC file from other software such as ArchiCAD? Notice how they could sort IFCs according to layers with a custom naming convention?
That can also be done and customized in Revit. By default it will use some American format. To customize it, you need to add a setting in your Revit.ini file. Add these lines:
In [Directories], add: ExportLayersNameDGN=xxx.txt (with “xxx” being the full file- and pathname of your layer mapping file. In this article I basically used my dwg mapping file.
In [Export] add: UseVersion2012DGN=1
You will now have the custom layer settings in the IFC file (see Figure 7).
Figure 7
Exporting Custom IFC Parameters
Have you ever tried to create and export IFC parameters that were not in the Autodesk IFC Shared Parameters file? Did it work? I'm guessing it didn't and that’s probably because you tried to do it the logical way and put your custom parameters in the IFC Parameter group. That's not possible—you can basically use any group but this one.
Known Limitation: Family Instances
One of the most frustrating issues pertaining to IFC imports in Revit is the fact that Family Types and Instances are not recognized. In other words, import 20 similar Windows or Doors and there will be 20 different families in Revit.
This, however, is a limitation within the IFC file format and not a Revit-related problem. IFC knows only individual objects and does not have the intelligence to group similar objects into Families and/or Family Types.
Both Autodesk and other software developers such as Tekla are working on ways around that. In fact, the latest importer/exporter for Revit in Tekla 19 should be able to identify different instances of beams and group them in Families. The Revit importer explores these possibilities for columns.
However, there are some difficulties. How does one define which elements should belong to one family? For structural elements, which are for the most limited in variation, it is relatively easy to base it on geometry. For doors or windows that's virtually impossible. Maybe somewhere in the future there will be a smart way to do this, but I highly doubt it. And to be frank, there are bigger problems.
User Input: Varying Results upon Import
If you work with IFC regularly you might experience varying results upon importing them in Revit. Usually this is not your (or Revit's) fault.
Take for instance a roof in ArchiCAD. This can be modeled in various ways: With the Roof tool, Shell tool, Morph tool, and Slab tool, after which it is "told" to be a roof.
The last one creates an error in the IFC output. Yes, it’s really a bug—verified and all. You can check this by creating a slab in ArchiCAD, tell it to act like a roof. In the properties it will remain in the IfcSlabType class, which creates an error when importing in Revit (it is ported to the Generic Model Category).
This example is a bug. But there are others where the way things are modeled in one software affects the way it’s exported and imported in another.
Conclusion
To be honest, I would have stopped this quest after the first article if it wasn’t for all the feedback I received from people also working on this. Some just provided me with tips and tricks; with others I am collaborating on a daily basis to get this entire IFC thing properly documented.
I am not a particularly big fan of the format. It has its place, but use is limited to a carrier of the most basic information (at least, in my humble opinion). However, getting through this and gaining more knowledge, I am beginning to see that 99 percent of the opinions “out there” are expressed by people who have absolutely no clue of what they are talking about.
And to figure it out is a bigger challenge then anything I’ve faced with Revit in the past year. And I do like my challenges every now and then…
So, this is a shout out to all of you who have tricks and tips on IFC not included in this article or the previous one; for those who are trying to figure this out too and want to help and/or collaborate on this; or anybody who just wants to pick my brain. Contact me on Twitter (at mdradvies) or by email (martijnderiet@mdr-advies.nl) and hopefully we can get this thing sorted once and for all.
And maybe there’s a Part 3 in this, too.
