IFC With Revit For Dummies

IFC with Autodesk® Revit® for Dummies
Martijn de Riet – MdR Advies
AB2988
IFC is a lot like ghosts: some believe it is real, and some believe it is against basic laws of nature. This
class will make you believe in ghosts. IFC is real, it’s there and, if you’re a non-US Autodesk Revit
software user, chances are that sooner or later you will be forced to work with it. More and more
countries are mandating the use of IFC as a deliverable in government projects. And from there, more
and more commercial parties will do the same. For those of us working on such projects, IFC is very
real. This class focuses on a practical understanding of IFC and how to work with it in Revit: (1) creating
mapping tables for import and export of IFC files, (2) using the available options to override these
settings on an instance basis, (3) using and modifying the Open Source Sourceforge IFC Exporter,
including how to map parameters to IFC properties and how to create and organize custom data in your
IFC file, and (5) modeling tips and tricks for a proper export
Learning Objectives
At the end of this class, you will be able to:
• Describe the basics of the IFC file format
• Create and modify import and export mapping tables and use the built-in possibilities to override
these settings
• Create a Revit model suitable for export to IFC
• Work with the Open Source IFC Exporter from Autodesk and understand the possibilities to
change this to your needs
About the Speaker

Martijn de Riet is a self-employed BIM Consultant from the Netherlands, working with Revit
since version 5.1.
Martijn has a bachelor degree in Building Science. After his study he started his own
engineering firm working for contractors, architects and private clients.
Starting 2007 his company transformed into a full-time BIM consultancy service. At the moment
Martijn's clients vary from mid-sized architectural firms to the largest Dutch General Contractor
and MEP Engineering firms, with a focus on specific corporate solutions, design and
implementations of Revit and BIM workflows.
Martijn is a member of the Dutch Revit User Group, co-author of the Dutch RUG "Best
Practices" for Revit and author / creator of the national Dutch RUG Revit Standards.
He provides lectures for companies, technical universities, seminars and such on a regular
basis.
Describe the basics of the IFC file format

So what is IFC anyway? Short and simple? IFC is a database format. Just as the .rvt format is
for Revit. Or the .pln format for Archicad. Or the gbXML format for that matter.
It’s just a way to store and retrieve data. And in this particular case, building data.
Now let’s look at the long and complicated way to explain this. In the next image, the official IFC
scheme is shown (also to be found at: buildingsmart.org, which is probably better for your eyes).
Image 1 Basic principles of IFC
Now let’s try to explain this.
2
Kernel
Most important part of the IFC format is the “Kernel”. This is the IFC Core, which basically
defines all major components. Not the actual building components, but it defines the master
structure of an IFC:
• An element in IFC is an Actor, Control, Process, Product or a Project.
• An element in IFC has relationships with other elements. Definitions for those
relationships are found in the Kernel.
• An element has dynamic properties defined in the Property Sets. The concept of
Property Sets is also part of the Kernel.
At this level of abstraction, the Kernel is really not something useful to you as a user. You might
page through it, but it would probably cost you a severe headache with limited results. However,
it is the part that makes IFC “smart”.
Resources
Below the Kernel are the Resources. Resources are just that: possible data items that can be
part of an object in IFC. There’s some that are quite obvious such as IfcCalenderDate. Others
are a complete riddle to me. To be honest, most of them are actuallyB
Important thing to remember: this is not stuff that you want to manually toy with.
Extensions
Above the Kernel you will find the Extensions. Extensions define the highest level of
components for Products, Processes or Controls.
Some of these you will use (such as IfcSite or IfcSpace. But most are broken down into more
specified Classes in the levels above: the Elements and the Domains.
Elements
Elements are somewhat of a go-in-between. Not Extensions (abstract level), and not Domains
(highly specified). Extensions are the smaller branches in a tree. For the larger, more obvious
building components they are the end of the line (Shared Building Elements, which contains
Columns, Roofs, Walls, Doors, Windows and such). For parts of a building that have a more
subtle definition, Extensions form a collective level. For instance:
In the Shared Building Services Extension you will find the IfcFlowTerminal, which in turn is the
supertype for the IfcAirTerminal and IfcGasTerminal that both reside in the HVAC Domain.
Domain
These are the most important part of the IFC definition for you as a user. These define the major
“editable” parts of IFC: the Classes (e.g. IfcWall).
3
How does it all work together

When you take the time to study the Architectural diagram as shown in Image 1, you will notice
that IFC has a hierarchical tree-like structure.
Image 2: Basic principles in a less schematic manner
• If the Kernel is considered to be the tree trunk, the resources are its roots. These are the
elements that feed the trunk and branches with information.
• The tree trunk contains the highest level of definitions, e.g. IfcProject and defines the
way branches are connected to each other.
• The major support branches are defined in the Extensions. These contain some dead
ends (IfcSpace) that are not further refined in the Domains. But most are. For instance
the IfcBuildingElement which is the supertype for all major Building Components.
4
The Origin of IFC
Acronym
So where did this all come from? IFC is the acronym for Industry Foundation Class. Frankly, I
have no idea what this means. But it has to mean something, so let’s try this:
Industry will probably mean the AEC industry.
Foundation could be a non-profit organization (not likely), or could mean that this is the
fundamental language to describe a building.
Class could be short for classification.
This would add up to IFC being a common language for the AEC industry to describe a building
in a database. That does sound somewhat right to me.
History
The IFC-initiative was started by the IAI (International Alliance for Interoperability). The driving
force behind the establishment of the IAI in 1995 was, believe it or not, Autodesk. They needed
a common language to facilitate the data exchange between different software packages (in
their portfolio).
The IFC database structure is derived from the STEP-format which is described in ISO 10303.
The STEP format is recognized to be the worldwide standard on “computer-interpretable
representation and exchange of product manufacturing information”. In common English: STEP
is a vendor-independent language to describe 3D geometry and associated data needed to
manufacture it (which is a broader description then build).
Intended use
The IFC format was originally intended to hand over data to downstream applications. In other
words, IFC is specifically meant for data exchange between different project phases, from
design to construction to Facility Management. That’s why, if you look at Image 1, a huge part of
the IFC structure is reserved for processes during construction and facility management.
So, here’s the first bombshell:
IFC is not meant to act as a round-tripping format between project partners on the same “design
level”.
Now before you (virtually) tear this handout to shreds, please allow me to make an argument:
IFC is based on the assumption that the exchange model needs to contain objects. You simply
cannot exchange sole properties. They need to be tied to a geometric shape.
This means that if you exchange IFC’s you will by definition exchange objects. Whilst most of
the time, what you want to exchange are object definitions.
How does it work?

Note: if you’re not interested in the technicalities behind it all, skip this part. We're going to look
at the inner workings of IFC. So put your pillow in place, this might get somewhat dull and
geeky. (If it wasn’t already)
5
In the dataset you will find a few IFC files. Open up ifc exporter test 2.ifc in Notepad (right click >
open with) and an IFC viewer (I use Solibri Viewer). You will see the following picture for Solibri.
Image 3: ifc exporter test 2.ifc in Solibri
Looks normal right? It’s the Legend View of the current version of the Dutch Revit Standards
template file. It basically has some System Families and a few MEP component families,
nothing fancy.
Now check the Notepad.
Image 7 ifc exporter test 2 in Notepad

Ok, this might give you a headache. But no worries, I’m not about to explain everything, just a
few basics.
On the top you’ll find the file header with all project specs. Then, up until line #100, there are
some basic settings: units, project base point, and such. Nothing to worry about.
Now let’s try if we can find a component. For the purpose of this exercise I did some spinning
and zooming and selected a Wall. Double clicking it will bring up the properties screen.
Image 8 Selecting a Wall brings up the properties
Image 9 and just the properties
6
This Wall has a Name, which ends with an Identifier “30521”. Switch to Notepad and use Ctrl+F
to find that particular Wall. You will find it at line #170. Check this by referencing the underlined
text with the Name and Guid as shown in the above image.
#170= IFCWALLSTANDARDCASE('1AfqIWC893jutJiP0Oylds',#41,'Basic Wall:20_WA_wand_generiek_100:30521'

,$,'Basic Wall:20_WA_wand_generiek_100:1384',#139,#166,'30521');
What does this line of code tell us? A few things:
1. It references line #41:

#41= IFCOWNERHISTORY(#38,#5,$,.NOCHANGE.,$,$,$,1378149109);
Which I’m guessing means that there hasn’t been any update (intriguing piece of information, is
it not?)
2. It references lines #139 to #166.

I won’t bother to copy-paste them here, but these lines of code basically give the placement
coordinates and define the way the solid representing this Wall is constructed.
3. The code for this Wall goes on with defining its properties and the property sets they belong
in from line #170 onwards. It ends with line #298:
#298= IFCRELDEFINESBYPROPERTIES('3yFzT6fBf5yBXemS0KPVgE',#41,$,$,(#170),#296);
This tells us that the properties defining this Wall can be found between lines #170 en #296.
After that, line #301 starts defining a new Wall.
Cool, so what?
Assuming that an IFC is generated by Solibri in numerical order this is the order in which objects
are created:
1. Object representation and placement
2. Properties belonging to the object.
In other words: you cannot simply export the properties, you need to define the object first.
However, there is hope. Open up ifc exporter test 3.ifc. Find Wall number 30521 as shown:
#173= IFCWALLSTANDARDCASE('1AfqIWC893jutJiP0Oylds',#41,'Basic Wall:20_WA_wand_generiek_100:
30521',$,'Basic Wall:20_WA_wand_generiek_100:1384',#142,#169,'30521');
Notice that the Guid and Identifier are similar even though this is a separate export. This means
that it is theoretically possible to match all objects in an IFC and compare properties. And
update themB
7
Create and modify import and export mapping tables and use the built-in
possibilities to override these settings
Enough with the theoretic stuff. Let’s talk some practical stuff. How does this whole IFC-thing
work in Revit?
First: IFC is a kind of Classification standard. Which means that it tells the computer a certain
Solid defines a Wall, and another represents a Window. And they both have properties to define
what kind of a Wall, how big the Window is, and so on.
Revit does the same with Object Styles and Parameters. Using those two classification systems
enables a user to define what a component is, and how it should act.
Basically, both IFC and Revit have their own language.
The logical step to take when working with IFC in Revit is to map the two. Regard it as a form of
Google Translate. If you were to look at the backend of GT, there probably is a huge database
with translation tables. Starting with A, all the way to Z, there is a string of similar words:
Cupcake in English = gebakje in Dutch =杯形餅 in traditional Chinese.

Height in English = Hoogte in Dutch =高度in traditional Chinese
In order to work with IFC, you’ll need to map definitions. This is done with the Import and Export
Settings. So how does one define the translation from Revit Categories to IFC Classes? The
geeky way off course: with simple txt-files. No flashy User Interface, just plain old notepad.
Export mapping tables

Let’s start with the export. Go to R > Export > All the way down to Options > IFC Options.
8
Image 3: Find the Export mapping table
This will open up a popup window where you will see three columns:
• Revit (Sub) Category

• IFC Class Name
• Type (IFC “sub”Categories, hardcoded in the IFC scheme).
9
Image 4: Export mapping table
Basically what you need to do is fill these out. Afterwards, use Save As to store it externally for
later re-use. For your reference, I added a modified file to the dataset.
However:
Take into account the implications! This means you NEED a well-defined set of subcategories in
Revit. And you need to assign your solids to these subcategories when creating families.
Why?
Because IFC and Revit do not perfectly align. Some classes in Revit are very Generic (e.g.:
Mechanical Equipment, Specialty Equipment) which have very specific IFC Counterparts
(IfcChiller, IfcCooler).
Import Mapping Tables

Import Mapping Tables are found in the IFC Import Settings. Everything else works about the
same as the Export Mapping tables.
10
Image 5: Find the import mapping table here.
11
There’s a tiny problem with the standard import file shipped with Revit. 86% of the IFC Classes
is mapped to Generic Models. That’s like taking a 3D DWG, put 86% of all Layers to layer 0 and
import that into Revit. Then wonder about why it works so poorlyB
Image 6: Ehm-. Okay?
12
Image 7: Import table included in the dataset
Compare image 6 and 7. Off course there are some classes that could be mapped better
(IfcCableCarrierFitting is a Cable Tray Fitting however you put it), but it also shows the need of
using Sub Object Styles. Without them, a proper mapping isn’t possible.
By the way: the Sub Object Styles defined here should already be present in your model upon
import!
Overriding general settings

There will be times that a certain Object needs to be mapped to another IFC Class then the
general export mapping table tells it to. Think situations like where you have a unique type of
family modeled as a Generic Model.
Besides the general mapping table you have the ability to use 2 Shared Parameters provided by
Autodesk:
IfcExportAs: Overrides or sets an object specific IFC Class to which the object will be mapped.
IfcExportType: Assigns a specific Type (Subcategory) within the specified IFC Class.
13
For instance:
You modeled an Air Cooled Chiller. Add the two parameters to the family and set them
accordingly:
Image 8: Setting up a specific a manual override
However, there are some noticeable limitations to this workflow:
1. System Families will generally default to the export settings in the mapping table or,
even worse, to hardcoded settings that you cannot touch at all. Doesn’t matter if you use
a “normal” or “In Place” family.
This means that creating an In Place Ceiling and having it export to something else
(even to the CEILING type will not work unless you do this in the mapping table).
2. In Place Families must have an IfcExportAs parameter assigned or they will default to
BuildingElementProxy.
3. To define a certain type you can either use the IfcExportType parameter OR add the
type to the IfcExportAs parameter with the following syntax: IfcClass.IfcType.
4. The IfcExportAs parameter can be assigned to either the project file (or template) or to
the family. You’d probably want a mix of these two. Generic Models in general have it
prepopulated in the family, for other categories that only marginally need to be adjusted,
having it in the project template will do.
14
In the dataset you will find a test file with resulting IFC to examine. The results of the different
settings applied are shown in the image below.
Image 9: Different settings for IfcExportAs
15
Create a Revit model suitable for export to IFC

So what are Best Practices, tips and tricks to work with IFC? How does one create a model
that’s worth exporting without turning everything into a gigantic mess?
This part will show you the most important tips and tricks to do this.
Do’s
Stuff missing?
Stuff missing from your export/import? Check the mapping tables. Very often it turns out to be
on a category that is turned off for export/import.
Are you sure it’s filled out in the tables: check the syntax. Is it written EXACTLY as in the Sub
Object Style inside Revit? And it should be there prior to the import.
IFC Layer naming setup

The IFC File format has a dwg-like layer structure, see the image below. This will probably
make sense to US residents, but not to me. I would like this layer definition to match our
national (or even company) standards.
Image 10: Standard IFC Layer naming
Luckily, this is fairly simple to manage. That is, once you found the trick:
16
1. Find the Revit.ini file. Default location is %APPDATA%\Autodesk\Revit\Autodesk Revit

2014\.
2. Open the file with Notepad, and add the following lines:
Under [Directories] add:
ExportLayersNameDGN=xxx.txt (with xxx being the full path and filename of your
desired dwg mapping table)
Under [Export] add:
UseVersion2012DGN=1
3. Export model to IFC to find it mimics the dgn export settings. (If you were running Revit
while making these changes you should restart it for the changes take effect).
17
Image 11: IFC Layer naming override to match company standards in Revit.ini file
18
Image 12: Customized Layer naming
Not exporting specific components

To not export a single object type, use the IfcExportAs and type in “DontExport” (without the “ “).
The object type will be ignored when exporting.
Don’ts
Edit Profile
When working with IFC, don’t ever use Edit Profile. This may or may not screw up your export.
Sometimes the changes mess up the Wall definition in translation and the entire Wall is gone.
Or worse: it will show up in one viewer, but not in another (which happens when the definition is
not fully translated into IFC. Some viewers are pickier then others)B
Attach to …
Try to avoid these when modeling. Walls attached to Roofs and Floors get an override in Revit
that is not always accepted upon export to IFC. Specifically attachments to (non-horizontal)
reference planes will lose their shape and default back to their original form (or don’t get
exported at all).
Btw: If you do have to choose, attaching is better than Edit Profile, but at least try to attach to a
dummy object and not export that one.
Linked Files
Linked Files won’t be exported. You can export the separate Links by opening the projects and
export, but you will need to aggregate them after export. Not all viewers can do that. And none
19
of them can merge them. In fact, the only software that I know off currently capable to merge
IFC’s is the Open Source BIM Server (www.bimserver.org).
You’re toast on all accounts when you copied and moved the links aroundB Exporting from
their separate projects will screw up the coordinates. Therefor rendering them useless. In this
case you have two choices:
1. Write your own custom version of the Open Source IFC Exporter that exports all Links taking
their offset, rotation and such into account.
2. Bind the links and then export.
Stuff to remember
Nested components
I often use nested components for quick creation of different types of complex families (for
instance windows and doors with nested panels). An important thing to remember is this:
Shared components will be exported as separate objects in the IFC-file.

Non-shared components will be part of the overall family; you won’t be able to distinguish them.
This behavior is shown in the following image, and in the IFC-file “test_export_window.ifc”. In
this file, both panels are Shared Nested Components. To demonstrate the difference more
clearly, I also made some of the Lining Shared Nested Components, and others Non-Shared.
20
Image 13: The behavioral difference between Shared and non-Shared Nested Components
When I decide to make a component shared, it all depends on the question “will this component
be swapped out independently during the building’s lifecycle?” In other words: a Door Panel is
Shared (since it can be swapped out), a Door Frame isn’t.
So, for me, the non-shared components behave as expected: they’re a non-distinguishable part
of the overall family. I basically only use nested components because it’s faster to model large
amounts of families/types once the components are in place.
The shared components however should be recognizable as such. But they should also be part
of the overall family (as sort of a container). When writing this handout, I reported this as a bug
to the Autodesk IFC development team and they’re currently working on a solution.
IfcExportAs and IfcExportType quirks

Add the IfcExportAs and IfcExportType parameters to your project template and if necessary in
your families. Make sure it’s classified as a Type Parameter and put in the Ifc Parameter group.
Otherwise it won’t work.
Documentation
In general: IFC documentation sucks. It’s not there. However, there is a website that has a
listing of all the technical stuff:
Use the IFC2x3 technical site to find listings of available IFC Classes and Types. Find it here:
http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/index.htm. If you don’t know what to
choose, go to the Architectural Diagram and start from the top.
21
Work with the Open Source IFC Exporter from Autodesk and understand the
possibilities to change this to your needs
What is the Open Source IFC Exporter?
It’s basically the same thing as what’s inside Revit. Only betterB You can find it here:
http://sourceforge.net/projects/ifcexporter/
The idea of the Open Source Exporter is simple: Revit updates once a year. The OS Exporter
on the other hand gets updated once a month. Which means there’s a lot more development.
And to be honest, there’s a lot of catching up to do.
For your convenience, I added the latest exporter to the dataset. A heads up though: there’s two
installers. One for the actual exporter, one for an alternate User Interface. You’ll need to install
both for full benefit.
In this part, I’ll be looking into the OS Exporter, what it does and how to properly configure it.
User Interface
Let’s start with the most obvious differences between the regular interface and the OS version.
Image 14 Regular export window
22
As shown the vanilla User Interface has a very limited amount of options and settings. Besides
that, there’s no way to keep your settings.
All is different when using the Open Source Exporter in combination with the Alternate UI. Most
settings won’t mean anything to you, but we’ll go through them one by one. A major thing to
remember is that it’s possible to save your settings in a custom selection set.
Image 15: Main window Alternate UI
23
Image 16: “Assignments” window Alternate UI
24
Image 17: “Modify Setup” window Alternate UI
In the next few paragraphs, we’ll be going through these entire settings one by one.
Export options vanilla Exporter

The regular exporter has a few basic options. These are also all present at the OS Exporter
Alternate UI.
Current View Only

This option defines whether the entire model is exported, or only objects visible in the current
view.
Split walls and columns by level:

Cut walls and columns that have a height of multiple levels into pieces by level.
Export Base Quantities

Export an IFC property set for certain categories (floors, walls) that contain quantity parameters
such as Gross Area, based on measurements of the actual objects (and not parameter values
inside Revit).
25
Image 18: Base Quantities
As you can see there’s some weird stuff going on here (the wall I selected is 2x2m and 0.1m
wide. This does NOT add up to 13.123m2 of GrossSideArea. Probably a conversion issue
between metric and imperial that is filed as a bug and will be fixed soon.
Export Space Boundaries

This includes the relationships between Spaces and their Boundaries (e.g. surrounding Walls,
Floors, Doors, Windows, and so on) in the export. There are 3 options:
None: Rooms/Spaces are exported as static components without any relation to their
boundaries.
1st Level: Room/Spaces are exported with basic reference of their boundaries.
2nd Level: Rooms/Spaces are exported with full relationships to their boundaries, including their
properties for materials, energy transmissions and such.
IMPORTANT NOTICE: 2nd Level Room Boundaries only works when you have a model suitable
for energy analysis. In other words: you need bounding objects that have this information
present AND the proper project settings applied!!!
26
Image 19: No Space Boundaries
st
Image 20 1 Level Space Boundaries
27
Additional Export settings Alternate UI

After installing the Open Source Exporter and Alternate User Interface a lot of extra
customization will be available, divided in two “extra” screens, the Assignments and Export
Setup.
Let’s look at the “Assignments” window first. This contains 3 tabs where you can define global
properties for the exported IFC.
File Header
This will add a bunch of administrative properties to the IFC.
Image 21: Properties to add to the File Header.
28
Image 22: Parameters and values added to the IFC
Image 23: And present in the Viewer
29
Address
In this tab you can enter the necessary Project Information. The checkbox “Update Project
Information” copies this data into the Project Information.
Image 24: Project Information in the Address tab-
30
Image 25: Gets copied into the Project Address-
31
Image 26: - And into Energy Settings-
32
Image 27: -Last but not least, the IFC itself
Classification
The Classification tab is a nice one. It allows you to specify the classification system used in the
project.
33
Image 28: Classification tab
Let’s say you want to name and define your Rooms through a certain classification system. And
you want to export this data with the Rooms. Here’s how you do this:
1. Create Key Schedule. Name it whatever you like.

2. Add a parameter called <ClassificationCode>
3. Add rows as desired and fill in the data.
a. In the Key Name you add the description you want to use to select the parameter
value in the project (left this example to the default value <Key Name> but you can
rename it).
b. The parameter <ClassificationCode> should have the following syntax:
[ClassificationCode]classification_description. <ClassificationCode> is the name of the
Classification Code you want to be added to the IFC (the local Building Code, Naming
34
system or whatever). The <Classification description> is the instance value you want a
certain Object to have (e.g. Living Room) in the IFC Export
4. Select Rooms, add the desired Key
5. Export and watch what happensB
Image 29: Setup in Revit
35
Image 30: Classification tab in Assignments setup
36
Image 31: Result in IFC Viewer-
As you can see I didn’t get the Source to Export, although upon examining the IFC file in
Notepad I noticed that the value does get exported from Revit. At this point I’m not sure whether
it’s a syntax error in the Export, or that this is expected behavior and the “Source” in the IFC
Viewer is not the same thing as in Revit.
37
Image 32: - And in the code itself
Additional Setup Alternate UI

The second screen that handles the Export setup is the “Modify Setup” screen. First and most
important option is that you can use that to specify (and save!) your desired Export settings.
38
Image 33: The “Modify Setup” screen.
Let’s look at all the checkboxes one by oneB I’ll leave out the ones that also exist in the vanilla
exporter.
File Type
If I may suggest something: use IFCZip when you’re not obliged to a preset Definition. This
does exactly as suggested and zips the IFC which cuts down file size drastically. Most viewers
don’t need you to unzip it anywayB
Export internal Revit Property Sets

This exports all Revit Parameter Groups as separate IFC Property Sets, and the parameters
inside with it. Use this if you want to handover data that does not get mapped to a Common IFC
parameter.
Export IFC Common property sets

All IFC Classes have common property sets (IFC version of a hardcoded set of parameters).
Use this checkbox to export that and map certain hardcoded Revit parameters to them.
Export Schedules as Property Sets

Cool feature: export your schedules as Property Sets. This is sort of an in-between for the
“Export Revit Internal Property Sets”-option. While that is a package deal (all or nothing) this
option lets you define parameters you want to export based on schedules available. Few things:
- It will export ALL schedules present in the project.
39
- It will work on every parameter in the schedule, Shared or project, even Calculated Values.
Export parts as building elements

If you have Parts in your model, this checkbox will export those instead of the original object.
However, you’ll need to have Parts turned on in the view you’re exporting from (and it only
works with “Export only elements visible in view).
Export 2D plan view elements

This is an obvious one; it exports 2D components from Plan View. Keep in mind though: you’ll
need to set the Mapping Tables accordingly! (They default to not export 2D elements)
Export Bounding Box

Think about the Course vs Medium vs Fine detail level in Revit. Lots of people use Coarse
representation to model and show a simple box instead of a complicated window lining profile.
This is somewhat the same: the ability to export a simple geometric shape instead of more
profiles.
Not quite sure how these are created and if this works for everything though. That would require
some testing. And to be honest, my opinion on this is about the same as on the Coarse-
Medium-Fine debate: don’t really careB So it’s not that high on my to-do list.
Export Solid Models when possible

This requires some background (read: boring) stuff. Basically Revit can export any given
geometry in two ways:
1. Extruded solids. Same thing as in Revit. Simply draw the base and extrude to a certain
height.
2. Boundary Representation. I’m going to quote Angel Velez, IFC developer for Autodesk, on
this one, because he has a great way of explaining this:
For an arbitrary, nicely defined Boundary Representation, you would start with defining 8
vertices (one for each point of the cube). Next, you’d define 12 edges, which would be curves
of some sort (in the case above, lines) that would refer to the vertices (so any given vertex
would be referenced by 3 edges for the cube). Then, you’d define 6 faces, which would be
defined by a series of the 12 edges above, connected nicely. This is called the topological
representation of the cube. It isn’t bad, in that you have some shared information, but it isn’t as
nice as an extrusion or a revolved solid, that has extra parametric information associated with it.
That’s not what’s in IFC2x3 J What is in IFC 2x3 is a dumbed down version of that called a
faceted BRep. In this case, all edges are lines, faces are polygons, and while edges can share
vertices, they don’t have to, and edges aren’t shared either. You could make the nice thing I
said above, but you have to reconstruct all of the topology. The issues with IFC come from the
“faceted” part. A nice sphere can be very easily parametrically defined, but there is no way to
exactly create a sphere out of facets. So depending on how hard you try, you might get a cube,
40
or you 100m radius sphere might be approximated by 1mm x 1mm x 1mm triangles. As you
can imagine, the range of possibilities to get this right – or wrong – are staggering.
Now, to put it in terms anyone can understand, below is an image of a faceted Brep.
Image 34: Faceted BRep
See all those tiny triangles?
Those are faceted BRepsB The default exporter uses either one: Solids OR BReps. If the
entire entity cannot be exported as a Solid, it’s exported as a BRep. Which, as you can imagine,
is often the case (especially with curved forms).
Checking this option means the OS Exporter will always use Solids for those parts that can be
defined as such. Only the parts that cannot be defined as a Solid will be exported as a BRep.
Use family and type name for reference

All IFC objects have a “Reference” parameter (sort of a Type Mark and Mark in one). This lets
you combine Family and Type Name into that Reference parameter.
Use 2D room boundaries for room volume

Checking this box means Revit will treat a Room Separation Line as a spatial element with a
height and area when calculation the Room boundary area.
Include IFCSITE elevation in the site local placement origin

Again, Angel Velez from Autodesk:
41
A site has a Z offset. By IFC CV 2.0 specification, the Z offset should be included in the
specification of the IFCSITE, NOT in its local placement origin. Doing both is “double counting”
and will result in the site being 2x as high as it should be. However, most existing applications
don’t follow the CV2.0 standard, and so doing the right thing generates the wrong picture. So
check this if you want bad IFC files that behave correctly.
Use coarse tessellation for some BReps

The example image on the previous page has a rather coarse tessellation. But creating IFC’s
with any IFC Exporter using BReps can come with some seriously heavy results.
Image 35: Faceted BRep Cistern
The above Cistern in IFC format from the NBL-website is 2640 lines of code. Which actually
isn’t that bad because the Revit file exported to IFC is a 1000 more lines.
There’s two problems here:
42
1. IFC is different than Revit. Every instance is defined separately. Which means that two of
these mean twice the amount of code and twice the filesize.
2. The frustrating thing about this is that it can be different. Jon Mirtschin from GeometryGym
wrote a blog about IFC manufacturer content (find it here:
http://geometrygym.blogspot.nl/2013/10/parametric-ifc.html) where he proved that with a little
smarter implementation, the filesize can be brought down with 80% and the amount of code to
360 lines.
I put the testfiles in the dataset.
Store IFC GUID in file after export

Just like all Revit components, their IFC counterparts have a unique identification code, the IFC
GUID. Checking this option results in the creation of an instance parameter in all exported
objects called <IfcGuid> and writing the value to it.
43

IFC With Revit For Dummies

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IFC With Revit For Dummies

Hochgeladen von

Copyright:

Verfügbare Formate

IFC with Autodesk® Revit® for Dummies

Martijn de Riet – MdR Advies

About the Speaker

Describe the basics of the IFC file format

Image 1 Basic principles of IFC

Now let’s try to explain this.

How does it all work together

Image 2: Basic principles in a less schematic manner

The Origin of IFC

So, here’s the first bombshell:

How does it work?

Image 3: ifc exporter test 2.ifc in Solibri

Now check the Notepad.

Image 7 ifc exporter test 2 in Notepad

Image 8 Selecting a Wall brings up the properties

Image 9 and just the properties

#170= IFCWALLSTANDARDCASE('1AfqIWC893jutJiP0Oylds',#41,'Basic Wall:20_WA_wand_generiek_100:30521'

What does this line of code tell us? A few things:

1. It references line #41:

2. It references lines #139 to #166.

Cupcake in English = gebakje in Dutch =杯形餅 in traditional Chinese.

Export mapping tables

Image 3: Find the Export mapping table

• Revit (Sub) Category

Image 4: Export mapping table

Import Mapping Tables

Image 5: Find the import mapping table here.

Image 6: Ehm-. Okay?

Image 7: Import table included in the dataset

Overriding general settings

Image 8: Setting up a specific a manual override

However, there are some noticeable limitations to this workflow:

Image 9: Different settings for IfcExportAs

Create a Revit model suitable for export to IFC

IFC Layer naming setup

Image 10: Standard IFC Layer naming

1. Find the Revit.ini file. Default location is %APPDATA%\Autodesk\Revit\Autodesk Revit

Image 12: Customized Layer naming

Not exporting specific components

Shared components will be exported as separate objects in the IFC-file.

IfcExportAs and IfcExportType quirks

Image 14 Regular export window

Image 15: Main window Alternate UI

Image 16: “Assignments” window Alternate UI

Image 17: “Modify Setup” window Alternate UI

Export options vanilla Exporter

Current View Only

Split walls and columns by level:

Export Base Quantities

Image 18: Base Quantities

Export Space Boundaries

Image 19: No Space Boundaries

Additional Export settings Alternate UI

Image 21: Properties to add to the File Header.

Image 22: Parameters and values added to the IFC

Image 23: And present in the Viewer

Image 24: Project Information in the Address tab-

Image 25: Gets copied into the Project Address-

Image 26: - And into Energy Settings-

Image 27: -Last but not least, the IFC itself

Image 28: Classification tab

1. Create Key Schedule. Name it whatever you like.

Image 29: Setup in Revit