The openBIM bootcamp: TOP 10 IFC tips for Revit users

LEJLA SECERBEGOVIC: Hi, and welcome to the first official openBIM Bootcamp at AU. My name is Lejla Secerbegovic. I live in Germany. And I was trained as an architect and worked as one for almost 10 years, but I was always fascinated by the computers and technology, so I ended up becoming a BIM and Revit specialist at Autodesk. I also like finding ways to explain complex topics in an easy and understandable way. And I hope I will also manage to do so today.

Before we start, I need to remind you of our Safe Harbor Statement and that all forward-looking statements about future developments are not a guarantee for their implementation. Your purchasing decisions should always be made upon the currently, already available features and nothing we might promise or indicate today.

As you might have noticed from the title, today's session is about the top 10 IFC tips for Revit users. And I can tell you it was a tough job selecting these 10 because there are so many things to be said when it comes to IFC. The goal of the session is to give you practical tips from a user perspective and not to talk too much about the theory or the concepts behind IFC, at least not more than absolutely necessary.

If you are also interested in the basics, I invite you to watch the recording of my last year's AU session, where I talk about the concept and the structure of IFC. In addition, we have a great session on the Autodesk strategy and our plans when it comes to the future developments of IFC, which is held by my colleagues. Make sure to check out the recording of this talk as well, as it will give you a great overview of the newest possibilities and features in the IFC 4.3.

I hope you are also already aware of our official Revit IFC manual, which is available in nine different languages. You will find the download links in the presentation slides and the handout, of course. The latest version has been issued about a year ago and is available as a PDF download. Despite some new developments and changes which happened throughout the last year, this document is still valid, and we will discuss the most important improvements and new features in this session anyway.

If you prefer video tutorials, I have created a small series of YouTube videos where I try to explain IFC in a simple and fun way. I will also make sure to add some in-depth videos based on the topics of this session. So make sure to check it out if you are looking for a more hands-on experience.

Now, let's start with our number one. This might seem a bit basic, but I can assure you that an outdated Revit IFC plugin is the most common issue among the Revit users. The IFC plugin is updated separately from Revit because we have our own team working on the IFC integration, and they are publishing the updates more frequently than the Revit service packs are issued.

Therefore, a the Revit IFC is distributed separately in order to give you access to the latest developments as soon as possible, since, recently, you are also able to download the plugins via the desktop app or through the Autodesk account, like all the other updates and plugins. You can always see which version you are currently using if you launch the Export dialog inside of Revit. The version number used to be located at the top in the past versions, and, in recent versions, it's moved to-- at the bottom, but it's still quite easy to spot.

Now, what's important to remember is that, despite this plugin is called the IFC Exporter, it is actually a lot more. The installation will not update only your IFC export, including all the functionality and the dialogues, but also the link IFC feature. And last but not least, the same IFC engine is also used inside of Navisworks, where you can view and coordinate your IFC files, no matter if you have Revit installed on the machine or not. Therefore, please make sure that you are using the latest development whenever working with IFC.

The Revit IFC-- a plugin for the older versions can be found on the GitHub, including the latest source code and the developer resources. The Revit IFC is an open source project and enables developers to use our code in order to adapt it to very specific requirements. The out-of-the-box exporter, however, covers all the common use cases and provides a wide range of options which make it easy to export what you need and the way you need it. You can also subscribe on GitHub to receive the email notifications whenever a new release is published.

Talking about that, let's move to the tip number two. Please don't just hit Export, but take the time to configure what is exported. Why is this so important? BIM is all about data. And the more data we have, the more we need to be careful with how we use it.

Let's say you wanted to build a LEGO spaceship and you go into the store. Would you just buy a bag full of all kinds of bricks and hope the ones you need are among them? Or would you prefer a set with the exact instructions and containing only the bricks you need?

Your IFC file is nothing else but a database, so please don't overload it with unnecessary information. And make sure it is structured in a meaningful way so that it can also be interpreted easily by the recipient.

The first aspect you need to be aware of is which elements need to be exported, and there are several ways in Revit to control this. First of all, there is the IFC export mapping table where you can not only define the assignments of IFC classes to Revit categories, but you can also exclude certain Revit categories from the export by entering Not Exported. This mapping table is stored outside of Revit as a text file and can also be easily shared between the projects.

The second, and my preferred way, is to use a dedicated view for export which contains only the elements that need to be exported. You can use the filters, phases, or the general visibility overrides to control this. The IFC exporter has an option to export only the visible elements but still also include the rooms, areas, and spaces for the 3D views, as these are never visible in Revit 3D view. Obviously, you can also create several of such views for different use cases-- for example, for an export for the structural engineer showing only the load-bearing structure and an export for the map engineer containing more details and rooms.

Last but not least, you can also exclude specific elements using the newly introduced Export-to-IFC option. In the older versions, this property is called IFC Export As, and you don't have a dropdown but need to enter Don't Export manually.

Now that we know what we are exporting, what else is important? Just like in Revit, where the category of an element also defines its function with the properties and so on, we have classes in IFC which serve the same purpose. Unfortunately, we cannot always do a direct mapping because there are more IFC classes than the Revit categories in many cases. And the final assignment often depends on the actual use of the element.

We already mentioned the export mapping table before. This is where we assign the Revit categories to IFC classes directly, and it is already populated with default values. However, as mentioned, there will be, also, cases where you need to specify this mapping on the element itself, especially when it comes to the MEP equipment, wall and floor coverings, and so on.

This is done using the Export IFC as property, which launches a dialog so that you just need to pick the IFC class and type. If you are using an older version of Revit, you might need to enter these values manually. This option is available either on the instance or the type level and can also be used inside of loadable families to predefine their behavior.

A question I get asked very often is, can I export the Revit wall or, actually, any other category as something else in IFC? And the answer is not that simple. In the past, this used to be very restricted, and, indeed, you could only export a wall as an IFC wall. But in the last years, this has been made possible because we know there are certain use cases where this still might be needed. But still, you should keep in mind a Revit wall exported as an IFC column will always be a wall disguised as a column, and you should really try to use the right Revit categories, wherever possible, from the beginning.

Now let's have a look at levels. Why are these important? When we have a look at the visible structure of an IFC file in an IFC viewer, you will find that the first three levels are always the same. IFC seen project contains the IFC site, which contains the IFC building, which, again, contains the IFC levels. Just like in Revit, most elements are assigned to the levels, and this provides a good basic structure and makes it easy to browse the model.

But now, when we think about a typical Revit project, we might have many more reference levels which have no relevance for IFC. Therefore, it is important to define which levels will actually be visible in IFC. This is done through the building story option in the level properties. Only the levels which are marked as the building story will also be exported to IFC.

In order to keep a good overview, I would recommend you to create a level schedule containing this property and the filter which highlights your building stories. This way, you can easily control the levels before the export.

You might wonder, now, what happens to the elements whose assigned level is not exported, like, in this case, the base level of the wall? The IFC exporter will always pick the next building story below. And if there is none, it will be assigned to the next one above. If you still need to keep this information about the original assigned level-- in this case, the wall base-- you can, of course, export this information as a separate wall-- as a separate wall property.

OK, let's move to the next point. Shared parameters play a big role in Revit, and not only for IFC. To be sure we are all on the same page, let me briefly explain why the shared parameters are so important. Creating a regular project parameter is a lot faster, after all, right?

However, a project parameter lives only in the project. And if I have the same project parameter in another project, they will have different global unique IDs or GUIDs, which can lead to issues in the coordination or in the other systems. In addition, there are limitations when it comes to scheduling and tagging of Revit families.

A shared parameter, on the other side, is defined in an external text file and has a unique ID, which means it remains the same throughout all of the projects. The Revit IFC plugin comes with two shared parameter files, which carry all the parameters relevant for IFC.

Before you ask, why is this information not already built in in Revit, I recommend you to have a closer look at these files. The IFC schema carries way to many properties which are seldomly used and would overload the Revit project. Therefore, we have only the most commonly used properties built in inside of Revit, and you can always add the additional ones as needed.

If you are wondering why there are two files, let me explain you the following difference between Revit and IFC. In IFC, we have the entities, which describe the actual object, similar to the instance inside of Revit. And obviously, there can be also different instances of the same object, and they all might have different properties.

Just like in Revit, these instances or entities belong to a type, and here comes the difference. The IFC entity can have the same property as the instances with the same name but another value, which lies on the type level. In order to achieve this in Revit, you can use the shared parameters file with the type in its name to add the same properties, which already exist on the instance level.

This is how this looks like. I used the regular shared parameters file to add the IFC a description on the instance level and the type I for the type property. Notice that this one also shows a type in the brackets. During the export, however, these are mapped correctly to the corresponding IFC property.

The most important aspects of IFC are the common IFC properties. You can think of these properties as of the fields on your ID, which contain your personal data. And the properties are defined in the IFC schema and are designed to always be the same, no matter which software an IFC comes from.

Revit makes it very easy to export the common property sets. Just tick the box, and you are ready to go. OK, maybe it's not that easy. Let's have a brief look at the IFC documentation.

Here, I search for the keyword, common, to identify the common property sets in the list. Each set carries a certain amount of the properties, which are documented here. However, when I export a wall from Revit and include the common property sets, using the setting we just saw. I might not get all of the properties I see in the schema.

Now, why is that? There are two possible reasons. Either the properties have no value assigned and are, therefore, empty or the property simply doesn't exist in Revit yet. As we mentioned before, we only have the most commonly used IFC properties built in. Others need to be added as needed.

We have two options to solve this now. The first one, as you surely already assumed-- using the shared parameters file to add the missing properties to your Revit project. The shared parameters file already contains all the supported Psets and the properties and makes it very easy to find the right values. By adding these to the project, I can see that the new values have been added to my Pset after the export.

There is one downside, however. These parameters are always in English and are not automatically translated when you switch the Revit language, which is not so great for everyone. For this reason, you can use the Export Parameter Mapping Table, which allows you to map any Revit property to an IFC property using a simple text file.

It is very easy to create this file. Simply open your text editor and write IFC property set name. Enter a tab. Write the property name. And after another tab, write the name of your actual Revit property.

For example, in this case, I want to map the German Brandabschmitt to the compartmentation property in the Pset wall command. In order to achieve this, I will first write, Pset wall command, press Tab, then write the compartmentation. And after another tab, I'll type, Brandabschmitt.

Obviously, you need to take care that the data type of your Revit property is the same as it is defined in the schema. Otherwise, the export will fail. Despite many common properties defining the schema, the building projects can require many other properties, which are defined by the user.

The good thing is every property you have inside of Revit can be exported to IFC. For this, you will be creating user-defined property sets containing your own unique properties. This can be accomplished in two ways-- using schedules or, again, a mapping file.

The schedules are great for testing because they are very easy to use. However, they are not the best way to implement the BIM standards, as they cannot be easily shared between the projects. The mapping file, on the other side, is a bit more complex to set up. However, it can be stored on a cloud or a network drive where it is accessible from all of the projects.

Now, let's have a closer look at both of these options. As mentioned, the schedules are fairly simple. You simply create a schedule containing the properties you want to include in the Pset, and the name of the schedule will also be the name of the Pset.

Now, let's have a look at the mapping file. This is, again, a text file. And you can find the template installed with the Revit IFC plugin.

In this template, you can find the schema definition, which looks like this. After the keyword property set followed by a tab, you enter the name of the Pset, then another tab, then, I, for the instance or, T, for the type property, another tab, and then the element list, which is nothing else but the IFC classes this Pset should be assigned to.

Now we have defined the Pset and we need to fill in the properties. A Pset can have as many properties as you need, and you can also create several Psets in the same file.

The properties are defined by entering the property name you wish to create an IFC and, after a tab, the data type of this property. You will find all the data types listed in the Template file for the reference.

Finally, after your last tab, you can enter the name of the Revit property for the case. It is not the same as the name of you-- which you assign to the IFC property at the beginning of this line. The next property can be added the same way in the next line.

I know this sounds a little bit complicated, but let's create a simple example to make it more understandable. We start with creating the property set called the Autodesk Parameter on the instance level and assign it to the IFC element type, which will basically include this Pset on all the elements in IFC. I could also enter IFC wall here to assign it just to walls or IFC wall-- IFC wall, IFC column to assign it to walls and the columns.

In the next line, I'll start adding my properties. Let's say I want to export the phase from Revit, which is a text parameter. In Revit, this one is called Phase Created, which might be a bit confusing in IFC, so I decided to rename it to Phase. The next one is the space boundary. This is a Boolean and has the same name in Revit, so I don't need to enter anything after the data type. Same goes for structural.

After the export, my Pset that will look like this in an IFC viewer. This is really a lot easier than it looks at the beginning, and it takes just a little bit of practice to master it. Believe me.

Another very important aspect when it comes to BIM and the databases are classifications. Let's think again of our LEGO bricks. If we had to classify these, we could do it according to the color, size, maybe function, or we could also add weight thickness, and so on.

In the building industry, we also have several widely used classification systems, like the master format, uniformat and so on, and even more specified classification systems for very special use cases like the regional cost estimation standards and so on.

We have a great white paper on the classification systems, which you can find on our interoperability website, along with the standardized data tool for Revit, which is a free plugin that makes it very easy to assign the classifications inside of Revit. In fact, this tool was formerly called the Classification Manager for Revit.

Revit has one built-in classification system which can be used out of the box for the IFC export. This is the uniformat assigned to the assembly code type property. Like every classification, the definition includes a code and a description. This specification is also automatically exported to IFC without any further settings needed.

Some IFC viewers, like BIM version, in this case, show the classification in a tree structure, which makes it very easy to browse the content. As you might notice, the classification file is, once again, a text file, which you could, of course, also adapt and use it for another classification system.

However, in most of the building projects, we need to be able to use several classifications for the different use cases throughout the project. Luckily, we can easily create the multiple classifications in IFC using, once again, our shared parameters where you can find 10 parameters starting with the classification code. These need to be populated in such a way that you add the name of the classification in the brackets, followed by the code and the description.

After the export, your IFC file will display the different classifications, as you can see here on the right. Of course, you can also configure the standardized data tool for Revit we mentioned before, which lets you pick the values from the list so that you don't need to enter them manually.

The coordinates are a topic we all struggle with regularly at some point. So let's have a closer look at the current state and the situation we have inside of Revit. I'm sure you are all aware of the most important requirement for a successful project coordination-- a coordinated project base. This is typically a point near the building known to everyone. Usually, it's also marked by a geometry like this inverted pyramid, which sits on the top of the point.

Revit, on the other side, has several reference points to consider. Firstly, it has an internal origin, which is fixed and cannot be moved. All the geometry must sit within 10 miles or 16 kilometers within this point, and anything beyond this range will cause the issues in Revit. Then we have the project-based point, which is usually placed at the corner of the building and which can be used to define the angle to the true North.

We also have the survey point, which is an additional reference point typically used for a reference on site and the coordination with the surveyor, for example. When you start the project from scratch, these three points are on the top of each other, but they can also be placed elsewhere. I would always recommend, though, to leave the project base aligned with the internal origin, if possible, in your project.

And now it's about to get a little bit complicated. We can also have a fourth base point in Revit, which is the Shared Coordinate Base-- typically used to reference the real world coordinates, and its base point will, of course, be very far from the project. This is not an issue yet because the base point is just a virtual reference, and there is no geometry outside our 20-mile circle.

If your model is set up correctly, you will see your real-world coordinates reflected in the project-based point and the survey point, which is correct. But these should still be placed close to the building. You will find more details on how to set this up correctly in the handout.

Now, let's have a look at what happens when you export IFC. When we select the survey point, obviously, all the geometry will be exported in reference to this base point. Similar things happens when you use the project-based point. And same goes for the internal origin. The project base and the internal origin can also be combined with the true North, as most projects are also rotated inside of Revit.

Now, you'll notice, maybe, that I skipped the first option-- the shared coordinates, and this is not without reason. Let's have a look at what happens when we pick them. In this case, all the geometry is referenced to this point, which is very far away, and this can create issues in building projects because we get very large numbers with many decimal places. IFC viewers which are usually a very simple software, as they don't have the editing capabilities, or most CAD software will usually still display such IFCs correctly.

But what happens if we link such an IFC back in Revit? Due to the complex setup we just saw, Revit can only link IFC files with the origin to origin at the moment, and this means that the Revit internal origin will be linked to whatever you selected as the base during the export. This can lead to several issues, and currently, the best practice is not to use the shared coordinates when generating IFC files but one of the local reference points to avoid issues.

Of course, this doesn't mean that you cannot have the real-world coordinates in your IFC file. When using the IFC 4, for example, we have new definitions which enable us to select one of the local points and still include its real-world coordinate system at the same time, using the projected coordinate system reference. I believe and hope that this will simplify the handling of the real-world coordinates in the future developments, and we'll definitely keep you posted on this topic on my YouTube channel.

Now, last but not least, I wanted to also to mention the link functionality. Not everyone is fully aware of the fact that the open IFC options also apply for linking IFCs, and that you should indeed set up a Revit template here. If you have no template selected, Revit will take the first template which is set in your Revit options, which is usually also the standard project template, and it's typically packed with families, sheets, and other stuff, which you don't need when linking an IFC file, and which will only increase the file size without providing any value. It is recommended to use a minimal template at this place, and I will show you how you can create one from scratch in a minute.

First, let's remind ourselves of what happens when we link an IFC. Revit generates an ifc.RVT using the template we set before and also a Shared Parameters text file for each IFC file which we link. This Shared Parameters file can be used to add the IFC properties to your main project in order to be able to schedule or filter the linked IFC based on these properties. This is very straightforward and will work as a charm as long as you have just one IFC.

Since Revit is generating a new Shared Parameter file for each IFC you link, the parameters get different GUIDs, which means you would need to add the parameter again and again for every IFC file, even if the parameters have the same name. This is where the IFC template becomes important. You can use the IFC template to add the common IFC properties from the beginning and avoid them being recreated with different GUIDs.

First of all, create a blank template by starting a new project in Revit, selecting a template file, and clicking the Project template. Then add the common IFC properties to the file. Please note that this only works for the common property sets at the moment, and other IFC properties cannot be handled by this workflow, unfortunately.

You will obviously need to repeat the same in your main project, where you will be linking the IFC files and add those same properties there. Once finished, save the Template file and set it to be used in the IFC Import options.

When you now link the multiple IFCs in your main project, you will notice that your filters and schedules work as intended, as the parameters in both of the linked files have the same grid. If something is not working, please check whether you have added the same shared parameters to your current project file. And keep in mind that you can use this workflow only for the common property at the moment.

That's it. I hope you learned something new today and found my top 10 tips useful. Feel free to share feedback or any questions you might have through the AU platform or the LinkedIn.