OpenBIM Workflows at Autodesk

ANGEL VELEZ: Welcome, everyone, and thanks for joining us for this presentation. We'll be talking about openBIM workflows at Autodesk. I will start this presentation. I'm Angel Velez, and joining me are Lejla and Nigel, and I'll let them introduce themselves.

So I said I'm Angel Velez. I'm a Distinguished Engineer at Autodesk. I have been working primarily on Revit for, oh, 25 years or so. And I have just gotten my 20 year anniversary of working on IFC. So I've been working on this for a long time. Lejla?

LEJLA SECERBEGOVIC: Hi, I'm Lejla a former architect and a solutions engineer based out of Munich, Germany and with Autodesk since nine years. My focus is around Revit, BIM, and interoperability. And my mission is basically to make IFC more accessible to everyone, especially the designers and the engineers among you who don't have any experience with software development and data schemas. And during the live session at AU, we will also be joined by Nigel Peters, the product manager for Civil 3D and the driving force behind the latest IFC 4.3 integration for the infrastructure.

ANGEL VELEZ: All right, thank you. OK. And hopefully you have your bingo cards ready. We do need to have the safe harbor statement. so obviously, we're going to make some statements here about what we think we're going to be doing coming up. Please don't buy any software based on that. Thank you.

All right, so what are we going to be talking about? So we've got four main sections. So we kind of want to talk about first around what is openBIM at Autodesk, how does it manifest itself in our products today. After we go through that-- so kind of showing where we are today-- we'll show also what's new in the latest releases, the 2025 releases. In case those are new to you, you can get an idea of what we're working on right now or what we just worked on.

Then we'll look into what's coming up next. And that will be a combination of both roadmaps, meaning literally what are the next things we plan to be working on, and also a little bit of where do we see openBIM going and Autodesk in conjunction with that.

And lastly, I know a lot of people here might be here for this part. Lejla will wrap up with some tips and tricks. And Nigel in the live session also will have some to contribute to this section also.

OK, so let's start with where we are today. So as we mentioned before, we've been working on IFC for a long time. So IFC itself has been around for 30 years. This is the 30 year anniversary of IFC. And Autodesk was there right from the beginning. So Autodesk set up the International Alliance for Interoperability, which is the organization that eventually became buildingSMART.

And my own kind of addition to this timeline is around 2004 when I started implementing Revit. That's IFC 2 implementation for use in Singapore, and we've really come a long way since then. So we'll look and see later on which formats we're supporting and go into a little bit more detail there.

So again, so IFC 2x3 is still really the most popular IFC format, and you can see it's kind of supported throughout a significant part of our AC products, including, by the way, in Venture, and we'll get to that in a little bit too. But we see more and more IFC 4 implementations. So not only kind of vanilla IFC4 but also IFC4.1, which is really just around alignment, which is why only Civil 3D supports it.

But more recently, IFC4.3. So IFC4.3 just became an ISO standard this year. So we were kind of right there ready to have IFC4.3 support as soon as it was officially an ISO standard in Revit and Civil 3D and in some of our other products.

So how do we decide what to work on at Autodesk when it comes to these open standards and openBIM? And really, we kind of have three guiding principles that we align ourselves around.

So completely going out of order-- because you can read slides as well as I can-- the first one for me that's the most important is actually the Consistent one. So it's all well and good for IFC to be easy to use and fast, but first the data has to be right. And so that's kind of our first principle is we want to provide data that you can trust and actually matches what you expect to either write out from our products or read in.

Then, of course, again, it's great that you can trust the data, but it has to be able to get the data in or out in a reasonable time frame. So that's the Performant aspect. And again, we want to be able to make sure that we make improvements around how quickly you can access your data.

And lastly, we understand that there isn't a one-size-fits-all for how you want to use the data. And so we need to have flexibility in letting you decide how you want to write the data out or how you want the data to come in. You'll see these little icons in some of the future slides as we go over the features that we're either supporting now or plan to support. And hopefully they'll give you clues as to why we decided to focus on these.

So you could take our word for it that our implementation is pretty good, but it's better to have independent certification about that. So buildingSMART has had a certification program for some time. And certainly on the Revit side, we've been very active in getting certifications as soon as they're available.

So we were one of the first applications to have IFC2x3 certification, and we are the only application to have all IFC2x3 certifications. There are three expert certifications for architecture, structure, and MEP, and one kind of joint import certification.

And then we didn't stop at IFC2x3. And when the IFC 4 certification came out, we got that one, too. Again, while we see one icon for it, that is also four separate certifications, three for export and one for import.

In addition, we don't only look at buildingSMART international certifications. We also look at regional certifications. So I mentioned earlier that kind of when I first started working on IFC, that was because of requirements from the Singaporean government. And the CoreNet certification that we got at the time was our first and was around being able to do model checking using an open standard for buildings in Singapore.

That's come a long way, and we since then have gotten new certifications based on more updated versions of that. Japan also has a certification process undergoing, and we've been able to get our product certified for the Japanese requirements.

So I mentioned the Singapore requirements. So many of the requirements are things that we did to make sure that everyone in the world would benefit from the work we did. But some of it is very specific or country-specific that wouldn't make sense for it to just be generically in the product.

So we have our Autodesk Interoperability Tools that allows you to download specific content that might be useful for you. So again, if you're in Singapore and you have shared parameters that are specific there, you can go get the shared parameters file specific for that region.

But there's other stuff here, too. So I do highly encourage you to check out the Autodesk Interoperability Tools to see what's there and see if there's something that's right for you on top of our standard implementation.

So those are the certifications we have gotten, but we're still working on current ones. So for Revit, as I said, we worked on a Japanese certification, but that is an ongoing certification. So buildingSMART, Japan, and MLIT have an idea that this is not going to be a one-time but it's going to be a yearly event. And so we will continue to improve our products as necessary based on the yearly increments of the certification process.

And kind of excitingly for Civil 3D, right now buildingSMART has created an IFC4.3 pilot certification program. Autodesk is only one of four vendors invited by buildingSMART to participate in the pilot. So it's obviously kind of a private program at the moment, but we're helping influence what does it mean to have proper IFC4.3 representation of civil objects inside of an IFC file. So we're very excited to be part of that program and look forward to it being opened up to everyone in the future, including Revit.

So speaking of IFC4.3, while we are waiting for the certification to happen, that does not mean that we do not already have IFC4.3 support. So here is a workflow where you can see we're getting Civil 3D data from Civil 3D into Revit using IFC4.3. And you can see that this isn't just a blob. This is individual objects that have geometry and parameter information, as you would have had in Civil 3D.

One of the other things that you might notice, by the way, is that we're showing Civil 3D 2022 and Revit 2023. So this is part of our commitment to not just have the latest releases have support for IFC4.3, but we're actually going back and making sure that older releases also have IFC4.3 support as makes sense and is possible to do.

And you can see also, of course, the point of this is that some of your workflows are going to involve multiple products. So we created the base site and the bridge, the rail bridge, in Civil 3D. And then we were able to build buildings in Revit based on referencing the Civil 3D data.

So certainly on the Revit side, one of the ways that we're able to get these changes up and running faster and be able to get them into previous versions is that our IFC support is based on open source. While it does ship with the product-- so you don't need to go out and look for it-- it is available if you are a developer or you know a developer, you want to look at the code, you want to make your own changes, it's free for you to do so.

And again, it lets us make changes to previous versions more quickly and easily. But right now, if you just go to ADA, you will see we have asynchronous updates for IFC. You can also just wait for the latest version. We will include all IFC updates every time we update a point release in Revit for a previous version.

Now, this is not an IFC presentation, this is an openBIM presentation. And openBIM is more than just IFC. While IFC is the core of it, there are other buildingSMART standards. One of them is the buildingSMART Data Dictionary. And so here you see how we are working in conjunction with a partner, Onestruction, to use the buildingSMART Data Dictionary to get external parameters into Revit based on the ones that are already defined in the buildingSMART Data Dictionary.

In addition to the bSDD, also now a very new standard for buildingSMART is called IDS, which is the Information Delivery System. And this basically allows you to have rule-based checking on IFC files. And again, Onestruction has created an add-in to Revit that allows you to create these IDS files to be able to check, and, in fact, put this information inside of the Autodesk Construction Cloud.

Another important concept inside of buildingSMART is that of BCF, which is the Building Collaboration Format. This is one that allows you to exchange information about issues. And here we see not Revit but ACC loading in a Revit model-- this is the Snowdon model, which is one of our sample models of the Revit 2025-- and be able to create issues, export them, and read them back in. And not only can you read them back in to ACC, but because of the add-in, you can also bring them back into Revit.

So hopefully that gives you an overview of how we're integrating not just IFC but kind of a variety of openBIM standards and formats across our products. And so now I'd like to spend some time going over what we've added in the 2025 series of products.

So when you see some of the things that we've done, one of the background things that we've done has really gotten away from the bespoke solutions for IFC specifically that we've had in our products for a long time. So we had some reuse, but Revit was used for Navisworks and BIM 360, and that was a rather heavy tool to be using for these lightweight products.

So instead we've used something internally we call ATF, the Autodesk Translation Framework-- no alcohol involved, unfortunately-- to be able to have a unified approach for being able to bring in data. And this gives us improved fidelity, improved performance, and, again, kind of consistent output across Autodesk products.

And one of the ways that you see that right away is not even in AC but in Inventor, where they were able to use this approach to add import IFC capabilities into the Inventor product. And by the way, again, you'll see later on, this is being used in our other products also. So here you see a workflow, where you can see all the IFC data brought in. Again, this is the old Revit model. And you can go in and get them as individual objects.

So again, so Navisworks 2025 is using this approach, too. So they've added their V4 method, and this is the one that uses the ATF solution. It's a lot faster, 50% faster than before, has improved geometric fidelity over the previous version.

And one of the nice issues that it solved is both Revit and Navisworks had issues around bringing in data that was far from the origin. And so you can see at the bottom, that data is correct, except it's all jaggedy. And once you try to move it around, it does weird things on the screen. And instead now you get the pretty picture that is what you'd expected from your bridge model, not the weird thing at the bottom.

And we're not just looking at Link IFC on the Revit side. We've also made improvements on the export side. The biggest improvement we made is, again, around performance. So we're able to cut the export time for our average models by half, 54%, and also use 18% less memory while we're doing it. So again, while we did do changes to make Link IFC based on ATF in Revit 2025, we didn't forget about export, either.

In addition, one of the big pain points people have had throughout time is trying to figure out how to export their Revit model into IFC in terms of what IFC entities were to be used on the export. And basically the interface we've had since time immemorial was a text file and a very kind of error-prone text-based UI in Revit.

So we've gotten rid of that and instead created a new Weave-based UI around export mapping. So first of all, it lets you have multiple mappings inside of your Revit project. You can import and export them. You can decide which ones you want to export more easily. And you can pick from a list for the class and predefined types.

Here you can see a little simple model. We're going to go export this to IFC. And now you see that the category mapping goes to this section. And now we're going to say, hey, let's see what walls we have.

And we're going to decide to not export or export some of them. And we can also decide that we don't want to export them as walls. We can pick from whatever schema we want, look at the options, go through the list. And in this case, we'll pick a different setting. So we'll do wall standard case of possible.

In addition to that, again, one of the advantages of-- this was not in Revit 2025 when it first shipped, but again, one of the advantages of the approach we take is we can make changes in previous versions. So we've added the ability to export ceiling grids to IFC. Again, this has been a very, very big request for a long time.

So the ceiling grids are not a separate entity. They are exported as part of the ceiling, as the footprint representation. And so we take the pattern in Revit and make it a bunch of lines that we export to IFC.

And again, in case you think you're going crazy, here we are looking up. So tilt your head appropriately so you see the model inside that. And it's not automatic, though. When you go to the expert settings, you can go to IFC, and you can choose to export the ceiling grids or not. Maybe you do, though, be in the file. It's that simple. And here you go see them in the viewer. And you can see that they're all there and oriented properly and everything else.

So again, this is not just Revit. So we have made some significant changes for Civil 3D in 2025 also. So kind of going into little more detail than what's here. So we made some changes to improve how we export metadata. So these are all export-based changes here. So there are mapping enhancements around what metadata can be exported.

Also, the metadata can be put into any kind of level of the spatial structure during export. So it can be, again, kind of every level. I think for Civil, there's still some decisions to be made around how the spatial structure looks. But you have some choices as to where your parameters go.

Secondly, we've added more support for more types of solids, usually lesser-used ones and multi-view blocks when exporting the data. So this is something before where some data could be missing because we didn't support those solids or multiviews, and now we can.

And lastly, for alignments, in addition to exporting the alignment itself, we'll also export the fallback geometry. So the fallback geometry is the 3D sketch of the alignment. And we can also export labels and sample lines.

So what's coming up next for these products? So the IFC roadmap is public. The link is on this slide, so you can go there and look at it yourself. It is not just for IFC. It's for all of Revit, but in particular, kind of, what are we working on now?

One of the biggest pain points for Link IFC has always been around position selection. So there are a lot of different ways to specify where a project is in IFC. And you can't necessarily always trust that they're even right. So we intend to give you more options for how to place your IFC.

To start, we probably are going to concentrate on based on site survey point and project basepoint or just internal origin, with or without True North orientation. But we also look forward to getting feedback from people as to whether these are the options that they want and if they're working the way that they expected.

The second big project that we're working on currently is around property set mapping. So we basically we want to take the work that we did for category mapping and extend it to properties. And this is obviously a pretty big set of things. So again, we plan to have multiple mappings available in one file.

And it takes a bunch of checkboxes and text files. I know Lejla loves text files in Revit, but unfortunately you're going to have to get rid of them and replace them with a UI that lets you choose, am I exporting IFC common properties? If I am, which ones am I exporting? Do I want to export Revit properties? Again, similarly, do I want to export all of them? Do I want to export some of them? And UI around I want to create custom mappings. How can I do that without having to figure out text files? So that's just some progress now.

And then kind of next, again for flexibility, we want to be able to let you open an IFC file from Revit Home. Right now, if you want to open an IFC file, you have to go to the old interface to do so. Ideally, we can let you do that from Revit Home itself.

And lastly, we want to be able to support georeferencing for IFC. So not just kind of simple link position selection, but more generally, how do we georeference projects that might come from Civil 3D or other places?

For Civil 3D, the roadmap includes, again, customer-focused workflow enhancements. So that's more kind of generic issues that we've heard from and that we want to try to get into the next releases.

Civil 3D is also looking to use some of the UX that the Revit team has created already around the category mapping and a future parameter mapping. So we're going to work together to figure out how we can reuse that. I also have direct IDS support inside of Civil 3D.

And lastly, and this goes back, again, to the previous statement, IFC4.3 certification. So hopefully once the pilot program is done, that will lead to a path certification. And Civil 3D is very eager to get that as soon as it's available.

Now, I mentioned earlier that, of course we don't want to be telling you that our IFC files are valid and we want to have a certification process. And so future certification processes are intended to be built on top of the validation service for buildingSMART. So we do recommend that you check out the validate.buildingsmart.org website.

And we want to say that we are explicitly using it, especially for Civil 3D but also for Revit, to check that our export does meet the requirements of the validation service. Now, the validation service that shows on the screen is in beta, and so it's being actively worked on. So it's a moving target at the moment.

If you got all green check marks in version 0.6, that doesn't mean you'll get all the green check marks in version 0.61 because they might have added something. But we're actively working with buildingSMART to keep up to date with them. And as we said before, as part of the pilot certification program, kind of helping to figure out what rules should be in the validation to allow this to be the foundation of an IFC4.3 certification.

So in addition, I do want to spend a little bit of time just talking about where we see IFC as going and how that matches our own vision within Autodesk as far as sharing data in the future. So some of you may have heard about the AEC data model and the vision around it. So we want to get away from you needing to have our desktop products to be able to get our data. So we want to have an open extensible data platform connecting AEC+O teams to the tool of your choice.

So what does it actually mean? That means granular access across all users' experiences, which is exactly what the vision is for IFC5. So IFC5 is something that's being actively worked on by buildingSMART, and it is something that we want to make sure that our own data model is aligned with the views of IFC5.

I also want to make a point that USB is also something that's looking at the AEC industry. And we are involved with the AOUSB, which is the Alliance for Open USB. And there's even a interest group for AEC that I'm chair of.

So again, we're really looking forward to driving these different approaches so that they're as similar as possible so that you can conceptually have the same experience or similar experiences trying to get your granular data in the cloud from Autodesk and from everyone else that has IFC5 concepts.

And before I scare you off, as far as the future, we still intend to continue supporting existing versions. So this is a list of the bug fixes and improvements that we've made in recent versions.

And the idea is this is not just IFC4.3. This is not just thinking about IFC5. This is IFC2x3 and IFC4 in addition. And as long as people are using them, we intend to continue to support them.

With that, I'm going to pass it over to Lejla, although I will continue to move the slides.

LEJLA SECERBEGOVIC: Thanks, Angel, for this great overview. And now I'm looking forward to show you some tips and tricks. It was really hard to find some tips and tricks which we have not shared in the past. So we have tried to find some workflows and tips which you have not seen so far.

And just to kick it off with one tip, which we hope is also obsolete because we do hope that you are all aware of our IFC manual, which has been published in 2018 as a PDF and then updated in 2021. And considering the pace of the IFC development in our products, we realized that we need to release updates more frequently, which is why we published a live version of the IFC manual this year. And you can access this version through the address shown here.

And this enables us to update the documentation more frequently and cover all the new features as they are released. Here you can also find a lot of information and links included previously shared tips and tricks. So if you struggle to follow along in this section, you can always read more about the details in the manual.

And one fact that you might be familiar as well is the IFC structure, which is reflected in a similar way in all IFC viewers and includes several spatial containers, starting with the IfcProject, IfcSite, IfcBuilding, and last but not least, the IfcBuildingStorey, which, again, contains the IFC element like walls, doors, and so on.

The structure itself is a part of the IFC schema and cannot be changed, but you can influence the information that is attached to these elements. So let's have a look how these are defined and populated when exporting from Revit. But keep in mind that these concepts also apply to the Civil workflows and can also be implemented in the Civil 3D exports.

So starting with the top container, the IfcProject, this one carries the general information about the project, like the name and the coordinate system. This information is usually populated by default, and you can see here which information from Revit is also automatically mapped.

If you want to populate the additional properties like the description here, for example, you can go ahead and add the IFC description from the Revit IFC export shared parameter file. Or of course, also specify a user-defined pset to be attached on this level. And please remember to check the IFC manual if you are not sure how to achieve this.

Moving to the next level, the next spatial container is the IfcSite. And similarly, it is also populated with values from the Revit project information. There are also several additional parameters which you can add from our shared parameter file and also psets defined in the IFC schema. If added to the project information category in Revit and populated, these will be, again, automatically assigned to the IfcSite upon export.

The third entity that pulls its information from the Revit project information is the IfcBuilding. And again, you can add the additional assets and assign them to the project information if needed. Additionally, the project address set in the location inside of the Revit project will be exported as the building address.

With IFC4.3. buildingSMART has introduced a new infrastructure facility types which can be used instead of the IfcBuilding, which are all also already supported by the Autodesk solutions like Civil 3D and private. When exporting IFC 4.3 from Revit, for example, you can select the facility type to be used instead of the default IfcBuilding.

The support for IfcTunnel, by the way, is expected to be introduced with the IFC4.4 schema. And Autodesk will make sure to add the support as soon as this standard has been officially released.

The final container in our IFC structure is the IfcBuildingStorey, or the level. Most of the Revit projects have many reference levels, which is why you can define which levels are your actual building stories through the built-in level property inside of Revit. This way, you can also easily manage which levels will be visible later in your IFC structure. And only the Revit levels, which have the building story checked inside of Revit will also be exported to IFC.

Now, you might wonder what happens to your wall, which is assigned to a non-building story inside of Revit. This one will be assigned then to the next lower level, which is exported to IFC. Of course, this default behavior might not always be what you want to achieve, which is why there is also another way to manually change the level assignment of the elements in IFC through using the new improved support for the IfcSpatialContainer, where you can add your-- which you can add to your Revit project as a project parameter and then populate per element.

The values in this case can either be the IfcBuilding, IfcSite, or the actual levels according to their Revit names. As you can see on the screenshot on the right where we see the result in the IFC, my walls, which I have also assigned to the different containers in IFC, are indeed displayed in the different containers inside of the IFC viewer tree structure. As mentioned, all these concepts also apply to the Civil workflows and can also be implemented in the Civil 3D exports.

Another thing you may not be aware of is the fact that we can use formulas to calculate or to combine values in Revit during the IFC export. Why would you want to do this? In Revit, we can create the calculated values inside of the schedules.

However, these values cannot be exported to IFC as the IFC properties. This is why you can use simple formulas to either combine the values, like, for example, the room name and the department or also to calculate the values like the maximum room occupancy in this case.

In order to achieve this, you will need to create a custom parameter with the data type text and export it to a user-defined property set using the data type label, which will include your combined values in the IFC file. And we can see the workflow mentioned, if you click on the next two images, Angel, please.

And you can also find the exact instructions on the syntax in the handout. And on the next click, we will see the result in the IFC file, where you can see that we have created a new pset which contains the combined and the calculated values as specified in Revit.

When working with IFC, please make sure to always have the latest updates installed for Revit. We ship the updates with the regular Revit updates, but minor updates can also be downloaded from the manage.autodesk.com. In order to use the latest 4.3 Civil 3D, you will need to install the extension also found in manage.autodesk.com.

And the most essential tip when it comes to working with IFC is to define as early as possible what exactly needs to be included in your IFC file. And this is usually done by creating a dedicated information delivery specification, or IDS. For the various use cases.

Also, keep in mind that IFC today is always just a subset of your actual native format file and cannot replace it. If you need to edit your design, you will want to use your native file format. Last but not least, remember that you can always test your IFC files using the independent buildingSMART validation service to make sure that they are valid.

The official documentation can often be challenging to navigate, but it can be very helpful to know how you can double-check yourself, what is actually included in the schema, and what not. The easiest way to navigate to the documentation is to go through the technical.buildingsmart.org. Navigate to Standards, and select the latest official version of the schema you're using.

And then if you go through the alphabetical listing, you can easily search for a class-- like a wall in this case, for example-- and review its definition, including the IFC types, for example, or also the psets which have been defined in the IFC schema. And this will help you create an IDS that makes sense for every single use case you might have in the project.

There is, of course, a lot more to be said about IFC, and here are a couple of links where you can find other valuable information. Our Autodesk University website offers recordings of all the sessions throughout the years. And you can use the search to filter the IFC related sessions, of course.

The AEC Tech Drop blog offers the latest news around all kinds of the AEC topics, including IFC and interoperability and openBIM. I also run a personal blog called Bim Me Up, where you can find some more nerdy tips and workflows related to working with data and IFC.

I hope this session provided you some valuable insights about the Autodesk data strategy and the openBIM workflows. And yeah, we wish you a great day and hope to see you soon again in another session on openBIM. Thank you.

ANGEL VELEZ: Thank you.