Why Autodesk and other CAD vendors are willing to give up IFC for USD in 14 key facts

A by ArtemBoiko on 26 Nov 2024, edited 18 Jan 2025 # +8 -2 votes

A new article on the topic of open data for construction projects has been published:

‘The Age of Change: IFC is a thing of the past or why Autodesk is ready to give up IFC for USD in 14 key facts’

I would welcome any of your comments, criticisms, recommendations. I would sincerely appreciate your comments and opinions! If any facts raise questions for you or you want to share your own view on the topics raised, let’s discuss them. Your point of view, every remark and observation is important for the discussion.

🔗 Read the full article on LinkedIn: https://www.linkedin.com/pulse/era-change-ifc-thing-past-why-autodesk-other-cad-vendors-artem-boiko-kwake/

🔗 Read the full article on Medium: https://boikoartem.medium.com/the-age-of-change-ifc-is-a-thing-of-the-past-or-why-autodesk-and-other-cad-vendors-are-willing-to-3f9a82ccd10a

The construction industry is undergoing an epochal change. Data formats like IFC are giving way to new approaches based on versatile and simple solutions like USD. 14 key facts about the transition from IFC to USD:

Creation of the AOUSD alliance: Autodesk, Nvidia, Apple and others are teaming up to promote USD, calling it an open standard but with an explicit focus on their ecosystems.
HOK and USD promotion: A company involved in the creation of IFC is now actively promoting the benefits of USD at the buildingSMART level.
Autodesk and IFC: In 20 years, Autodesk never implemented full native support for IFC in Revit using third party SDKs.
High cost of IFC support: IFC development and certification is expensive, making USD a more attractive option.
SVF as a predecessor to USD: Autodesk already uses a USD-like format (SVF) in Forge, making the transition easier.
Mass adoption of USD: USD support is being actively added to Autodesk products starting in 2023, providing universal export options.

7. IFC limitations for interoperability: CAD vendors avoid using IFC, preferring proprietary APIs or alternative formats.

GLTF as an alternative to IFC: Khronos Group proposed to use the USD-like GLTF as the basis for a new version of IFC.
Outdated IFC structure: The IFC format has roots in 1980s technology, making it less convenient for modern processes.
CPIXML as a European alternative: In German-speaking countries, large companies use CPIXML, a format similar to USD.
IFC in Central Europe: Although IFC was invented in Germany, large companies in the region favour simplified formats for 4D-7D processes.
Blender and Unreal Engine support USD: Design and visualisation tools are actively integrating USD support, making it easier to adapt.
ARUP and HOK promote USD: These companies are openly lobbying for the use of USD in the construction industry through buildingSMART.
IFC5 and USD: The new version of IFC plans to borrow ideas from USD, which could lead to a merger of formats

C by CadGiru on 26 Nov 2024 # +4 votes

Go Native, Freedom of Data is a fight worth fighting

Why is building data not maintained and updated during the lifecycle of a building?

Because of closed proprietary software needing to translate open (ifc) data to a closed proprietary format, and the back...

Data is always lost in Translation

(btw it took roughly 50 years to get an ISO standard for word processing)

Standards are imperative for the freedom of Data. Use the tools best suited for the task, without translation.

With the emergence of native IFC authoring and editing, we finally have freedom of DATA in the AEC industry

Asked my friend GPT: Industry Foundation Classes (IFC) and Universal Scene Description (USD) are both open standards designed to facilitate data interoperability, but they serve different industries and purposes.

Industry Foundation Classes (IFC):

Purpose: IFC is an open international standard for Building Information Modeling (BIM) data, enabling the exchange and sharing of information among software applications used in the construction and facility management sectors.
Scope: It encompasses data related to buildings and civil infrastructure, including geometry, materials, and spatial relationships. IFC supports various use cases across the building lifecycle, such as design, construction, and maintenance.
Standardization: IFC is maintained by buildingSMART International and is recognized as ISO 16739-1:2024.

Universal Scene Description (USD):

Purpose: USD is an open-source framework developed by Pixar for the interchange of 3D computer graphics data. It is designed to facilitate collaboration and efficient management of complex 3D scenes in industries like film, animation, and gaming.OpenUSD
Scope: USD supports the representation of geometry, shading, lighting, and other scene elements, enabling robust interchange between digital content creation tools.
Adoption: Autodesk has integrated USD workflows into its content creation tools, including Maya and 3ds Max, enhancing interoperability and collaboration in 3D content creation.

Key Differences:

Industry Focus: IFC is tailored for the architecture, engineering, and construction (AEC) industry, focusing on building and infrastructure data. In contrast, USD is aimed at the media and entertainment industry, facilitating the creation and exchange of complex 3D scenes.
Data Representation: IFC provides a comprehensive schema for representing building components and their relationships, supporting detailed BIM workflows. USD offers a flexible framework for composing, editing, and rendering 3D scenes, emphasizing performance and scalability in graphics applications.
Standardization and Maintenance: IFC is an ISO-standardized schema maintained by buildingSMART International, ensuring consistency and broad adoption in the AEC industry. USD, while open-source and widely adopted, is not an ISO standard but is actively developed and maintained by Pixar and the broader open-source community.

In summary, while both IFC and USD aim to enhance data interoperability, they are designed for different domains and address distinct requirements within their respective industries.

A by ArtemBoiko on 26 Nov 2024 # +1 votes

@CadGiru, many thanks. BuildingSMART has been managed by Autodesk since 1994. Autodesk's problem is that they can't export IFC format themselves, and SVF2 is a format close to USD, which is convenient to replace IFC by dropping ODA. They are two formats - IFC with BREP and USD with “dead geometry” MESH. The question of which format will be convenient for work outside CAD will probably be decided by users themselves.

Perhaps there will be no classical class hierarchy in working with data, only a set of elements with properties - this is the essence of the granular transition, which Autodesk has been talking about since last year. This is also the point of the Entity-component-system, which is sewn into USD. We can attach whatever parameters we want to USD elements. There's an element, and it has attributes, which can include the classic class and group attributes. Type and other categorical attributes can be written through any parameter or set of parameters, not necessarily the default ones in Revit. If we are waiting for an element in an external system, we first define the parameters that the elements must have through requirements. If these parameters are not present in the data obtained from the model, the element cannot be used.

If Autodesk declares about realization of work with USD, why the user will need IFC, unloaded through ODA IFC SDK, if it will be possible to unload the same data - geometry and attribute properties through USD. The similar identical USD format CPIXML is used in all stages of 4D-7D construction in central Europe and has already successfully replaced IFC in these matters.

N by Nigel on 26 Nov 2024 # +10 votes

The discussion around IFC and USD highlights my concern: are we witnessing a genuine push for innovation, or is this a carefully crafted campaign to undermine IFC? While the portrayal of USD as the inevitable successor to IFC may seem promising on the surface, it glosses over significant risks that could reshape the construction industry in troubling ways:

Potential loss of neutrality in data exchange, a cornerstone of open collaboration.
Increased dependence on corporate ecosystems, threatening diversity and choice.
Unclear long-term costs and governance, leaving smaller players vulnerable.

While USD has undeniable technical strengths, IFC remains the gold standard for neutrality and openness in BIM. Rather than abandoning it, the industry should focus on improving IFC, holding corporations accountable for poor implementations, and staying vigilant against vendor-driven monopolization disguised as progress.

Defending open standards is not just a technical debate—it’s about ensuring fairness, transparency, and accessibility in an industry that thrives on collaboration. Keep questioning the motives and framing behind such transitions. Skepticism and critical thinking are essential counterbalances to the marketing-driven narratives being pushed. Let's continue to advocate for an open, fair, and future-proof BIM ecosystem.

J by JanF on 26 Nov 2024 # +5 votes

@Nigel said:

The discussion around IFC and USD highlights my concern: are we witnessing a genuine push for ...

Well if you compare the two standards you'll quickly find the discussion makes little sense, as they have simply completely different goals. The only people driving this discussion are spammers like mr. Boiko here, who use any opportunity to gain some publicity for their private projects selling nonsense.

When exchanging AEC data you need a well defined information standard tailored to buildings. No matter where you start, you'll always get something similar to ifc, so it just makes no sense to replace it.

A by ArtemBoiko on 26 Nov 2024 #

@Nigel thanks. The industry needs open data. But CAD vendors will never give it to them on their own. Therefore, there is only one way out, as happened in its time with AutoCAD and the DWG format - the openDWG alliance appeared. A similar alliance still exists today - ODA, but the problem is that it is now controlled by CAD vendors.

@JanF thanks. Have you tried reading the article? Please write which of the 14 facts you doubt - or which points or conclusions lacked references and sources.

C by CadGiru on 26 Nov 2024, edited 26 Nov 2024 # +5 votes

@ArtemBoiko said:

Autodesk's problem is that they can't export IFC format themselves, and SVF2 is a format close to USD, which is convenient to replace IFC by dropping ODA.<

Autodesk's approach likely involves a mix of "can" but strategically "will not" prioritize IFC beyond meeting minimum compliance for BIM workflows. Instead, they might focus on modern, proprietary solutions like SVF2 and integrations with USD to align with long-term business goals. Go Native, fight for freedom of Data

J by John on 26 Nov 2024 #

IFC includes a taxonomy of built environment elements/objects that has been developed and agreed by many nations, thus enabling efficient trading of goods and materials with known parameters and attributes. USD doesn't have this natively.

IFC includes an ontology - the taxonomy with verbs linking items in the taxonomy e.g. plumber installs boiler on wall. I don't believe USD can do this.

IFC development and governance is not driven by a profit motive. USD is developed by profit driven commercial entities whose sole purpose is to maximise returns to shareholders, maximising profits for end-users is not their objective and is often contrary to the software vendors' objectives.

A by ArtemBoiko on 27 Nov 2024 #

@John thanks. A similar identical USD-format CPIXML is used for all stages of 4D-7D construction in central Europe, and it has already successfully replaced IFC in these matters. More about it and its history in the article. If you know any ERP used by large companies for full cycle 4D-7D processes using IFC format - please write

O by Owura_qu on 27 Nov 2024, edited 27 Nov 2024 # +7 votes

The discussion around IFC and USD highlights my concern: are we witnessing a genuine push for innovation, or is this a carefully crafted campaign to undermine IFC?

I will go for the latter. Why does USD suddenly get hyped by Autodesk just when IFC's popularity and adoption are taking off (or already in flight)? This is suspiciously coincidental. We know the challenges of IFC but undermining it would be like kicking against the pricks. We are not oblivious to the fact that Autodesk has an economic interest to protect, and the increasing adoption of IFC threatens its lion's share of the market.

Bonsai (FreeCAD, That Open Company etc.) has brought liberation for IFC use, and I believe it's too late for any campaign against IFC to survive the revolution!

I only hope that IFC5 tries as much as possible to solve most of the problems of the previous versions.

D by doia on 27 Nov 2024 # +3 votes

God, I just wasted 10 minutes of my life to read OPs convoluted and with buzzword overloaded article, which feels like rage bait (damn, it worked on me).

the 14 key facts are actually just 13, no. 2 and no. 13 are duplicates
OP does not understand the difference between IFC and USD, which serve different purposes in their respective domain

@JanF I agree to 110%.

A by ArtemBoiko on 27 Nov 2024 #

@doia thanks. With USD, you can cover the full cycle of data usage from 4D to 7D - an example of this is the flat CPIXML - a copy of USD.

In this format we get geometry of elements and in the same format we have all parameters and properties of elements. We lose only the parametrics of BREP geometry building, replacing it with simplified MESH.

A by AlBabr on 7 Dec 2024 # +1 votes

I can't agree with the "facts" provided. Shortly speaking:

- 1. - no
- to be precise we need information from Autodesk
- 1. - no

Full version ofthe fact-check is published on LinkedIn https://www.linkedin.com/pulse/thought-leadership-fact-checking-action-alexander-borovikov-kwiuc/?trackingId=3vcPBFqQQSuJpjTAY7uKFg%3D%3D

A by ArtemBoiko on 7 Dec 2024, edited 7 Dec 2024 #

@AlBabr many thanks. Please allow to add a little context. Alexander Borovikov (AlBabr) first contacted me after publishing my article 5 parts of lobbying games four years ago. Since then, for three years we have been working together with Alexander on the OpenDataBIM Ltd. project, which I wrote about on this forum 3 years ago. All this time Alexander supported my articles and social media posts, and was critical of the use of the IFC format.

The situation changed after I left the OpenDataBIM project due to disagreements on its development and launched my own project - DataDrivenConstruction - from scratch a year ago. Since then, Alexander may have changed his vision of working with data and started criticizing my actions on the platforms and social groups where I am present.

I appreciate constructive criticism and everyone is entitled to their own opinion. I also consider it important to have "black PR" among people who initially did not intend to open my articles or follow the links, but now are forced to familiarize themselves with the content and main theses thanks to the discussion.

G by Gorgious on 10 Dec 2024 # +2 votes

Have we reached peak humanity yet ? I just wasted 20 minutes looking at LLMs arguing with each other ><

A by ArtemBoiko on 10 Dec 2024, edited 10 Dec 2024 #

IFC advantage consists of semantics and parametric geometry. Few people talk about geometry as an advantage, because IFC geometry requires a geometry core, which CAD vendors buy for hundreds of thousands of euros. The main focus of buildingSMART now is on semantics.

Because of the fact that IAI (buildingSMART) once decided to follow the way of creating semantic web in constrution with RDF and OWL, which was then very popular in the mid-90s and very promising in the construction industry all large companies should now also think about how to use semantics, although in the same Internet, for which the concepts of RDF and OWL semantics are not developed and used at the moment. In other industries, corporations have actually ‘scrapped’ the original semantic web project, retaining only the favourable technological elements.

The issue is not the use of formats - USD, IFC, GLTF, RVT or whatever, it does not matter. The main observation that can be traced in the history of creation and development of IAI and buildingSMART with their initiatives is that it is an organisation working for CAD vendors and especially for Autodesk, and that the interests of the construction industry and even more so Open Source are secondary here

N by Nigel on 11 Dec 2024 # +3 votes

What is autodesk

A by ArtemBoiko on 11 Dec 2024 # -1 votes

Autodesk is only one of the major CAD vendor representatives. But in general all CAD (BIM) startups and programmes strive for one thing. The concept of IFC in classical BIM software only scratches the surface of what might be possible. The main problem is the complexity of converting data from one structure to another. Right now this process looks like ‘native -> IFC -> native’, but in the future it may change to ‘native -> USD -> native’.

The fundamental problem exists as long as the internal data structure of BIM programmes differs significantly from the open data structure, making export possible only through configurators (translators). On the other hand, a truly open data structure would not require translation back into the original software. It is also logical that CAD vendors have no interest in providing such open data access. After all, it would allow users to leave the ecosystems that vendors have been building for the past 20 years.

The root problem is the need for interoperability. If all software used the same data structure, there would be no need for interoperable formats. The construction industry needs to move away from relying on IFCs and start adopting true open source approaches. This means moving away from semantics and formats imposed by CAD vendors. Formats such as GLTF and USD can serve as a starting point, demonstrating that design data can and should be simpler than we previously thought.

S by steverugi on 11 Dec 2024, edited 11 Dec 2024 # +2 votes

Dear @ArtemBoiko

a bit of a rant from a final user, if you are willing to read it

due to my almost total ignorance on the topic I understand very little of your article and following posts, except you being very keen on promoting USD to replace IFC

my point is the following:

what I understood of this platform during the past two years is that there is a substantial number of professionals/users/hobbyists in the AEC world who want to get away from Autodesk's claws as soon as possible for numerous reasons.

Mainly, I suspect, due to the pricing policy and the proprietary format of their products to keep everybody in the same gated paddock lest people quickly start running away, this is a trend now affecting other companies like Adobe for instance

Everywhere people had enough, did you notice that? I guess they are now willing to somehow compromise on a steep learning curve, headaches and so on to find a suitable product to see if there is a way out

In fact there is, at least in my experience, it's called FOSS with its own products and formats where people can partecipate, contribute, discuss,exchange ideas, etc

I appreciate your effort man, nothing personal, but your USD supported and promoted by Autodesk with such verve sounds like a recurring nightmare for me, like an old greedy girlfriend coming back in my dreams with her insatiable demands

Don't dispair, if USD (nomen omen) has objective advantages with no hidden policies to replicate the current indecent fees while trying to hold the keys to format accessibility why not use it?

If it does a much better job than IFC I think most of the users here will gladly implement it, right? The "O" as in Open means, in my view, to be also flexible to be open to moving on with the best tool available, regardless of its origin

Until then if you don't mind I keep using FOSS and IFC on daily basis, it literally changed my workflow and can't be happier, like with a "brand new girlfriend" :))

thanks

A by ArtemBoiko on 11 Dec 2024 # +1 votes

@steverugi many thanks.

Completely agree with you. Just as companies ran away from proprietary and closed DWG AutoCAD in the late 1990s, users today are running away from closed RVT Revit (The struggle for open data in the construction industry. The history of AUTOLISP, SDKs, Autodesk, intelliCAD, openDWG, ODA and openCASCADE)

I've been promoting OpenSource as much as I can since 2010, I ran the BimOpenSourceChat(https://t.me/bimopensource) for 4 years, where we had a lot of interaction with CAD product developers, developers from OpenCascade, OpenDesignAliance and CADExchanger and many more from the openBIM community.

I won't use USD in my work unless asked. Why I'm writing about it is because I do consulting for some pretty big companies that deal with cross-platform topics. And unfortunately there are no other conclusions so far - except that Autodesk, having registered AOUSD in 2023, started to sharply push it into buildingSMART. For me, buildingSMART has always been an organisation that primarily works for the interests of CAD vendors. And while those ties have been obscured since 1994, since 2023 the new favourite Autodesk is again showing how much buildingSMART is manipulated.

Of course you can use IFC for your own purposes further. My subjective opinion was gathered from conversations with specialists who stood at the very origins of IFC and various specialists from Chapter and Rooms, who share their insights. I see that there is an alternative to the IFC format and want to show specialists in the construction industry that in addition to IFC, RVT, DWG formats we can use those formats that are convenient for us in our work, and not those that are promoted by CAD vendors.

A by ArtemBoiko on 12 Dec 2024 # -2 votes

I am currently writing an article on the main problems of BIM and IFC and if you have any comments or criticism please write.

Geometry in IFC cannot be a reliable basis for data exchange due to the following reasons:

Complexity of the standard — IFC supports several geometry types (BREP, CSG, Swept Solids, etc.). BREP is the main one but requires a geometry kernel, which standard tools lack.
Dependence on CAD vendors — Only large CAD developers can fully support IFC, as they have the resources to create geometry kernels and account for hidden features of the standard.
Specification ambiguity — IFC specifications allow multiple interpretations, leading to different results when the same data is processed by different programs, complicating standardization.
Closed knowledge — Critical IFC details are accessible only to key buildingSMART members or shared informally among vendors.
High implementation cost — Full IFC support requires significant development resources, making it unfeasible for small companies without their own geometric core.
Hidden monopolization — Large firms use IFC's complexity to create vendor lock-in, similar to Microsoft's "adopt, extend, destroy" strategy, limiting market competition.

Structure and semantics problems in IFC:

Excessive complexity - IFC tries to describe all building objects with one global ontology, which is too complex and cumbersome. Other industries (e.g., the CYC project) have abandoned this idea in favor of local ontologies.
Ambiguity of specifications - The description of IFC objects allows several interpretations, which leads to different results of export and import in CAD systems.
Difficulties with semantics - IFC semantics does not give “new knowledge”, but only fixes relations between objects. These relationships could be communicated through simple tables (SQL, CSV) without complex RDF graphs.
Low tool support - RDF and SPARQL used for semantics are not massively accepted, unlike SQL and CSV, making their use in the construction industry inefficient.
High implementation costs - Supporting semantic logic and ontologies requires large resources, which is advantageous for large market players but unaffordable for smaller companies.
Unsuccessful bet on global ontology - IFC repeated the mistake of semantic web, trying to create a single consistent description of all entities. Other industries (e.g. W3C) abandoned this idea and opted for local graphs.

A by avico on 12 Dec 2024, edited 12 Dec 2024 # +1 votes

Sorry, I rated it by mistake, but I'd like to point out that Coen got it right (@steverugi, I think you had a bad experience with an old girlfriend :-) )

A by ArtemBoiko on 12 Dec 2024 #

@Coen could have simply clarified exactly what he believes to be untrue in this list of concerns. Each fact can be easily explained using references and sources

J by JQL on 15 Dec 2024 #

Interesting read.

If IFC is not futureproof, if it is too complex, with too many dependencies and even if buildingSmart is an organization with deep ties to autodesk, why would USD, promoted by autodesk, created by pixar, and adapted to get closer to IFC or CPIXML would be the opensource solution for the problem?

A by ArtemBoiko on 15 Dec 2024 #

@JQL many thanks. No, I don't think USD is the best choice either. The question is whether we need parametric geometry and ontology to work with data in the construction industry.

The decision of buildingSMART to follow the concept of semantic web, which at one time seemed promising and popular in the late 90's, has affected the whole construction industry. However, the paradox is that the semantic web concept itself, originally proposed for the Internet (RDF - Resource Description Framework and OWL - Web Ontology Language), has not been widely used even in its native environment. On the Internet, for which RDF and OWL were developed, these concepts are hardly used today. History shows that the full-fledged semantic web in the original architecture never appeared, and its creation may not be expected.

And on geometry: to support IFC in any program it is actually necessary to create one more ideal IFC CAD inside an existing solution with its own geometry core and its own logic of working with geometry. Today, a full-fledged implementation of IFC ontology is possible only for large CAD vendors who can invest significant resources to support all entities and their mapping with their internal geometry core. Large vendors also have the ability to coordinate technical details among themselves that may not be available to even the most active buildingSMART participant.

Subjectively, I believe we need to focus on creating geometry engines that are open source and independent of proprietary SDKs and geometry kernels. Data formats should be human-readable and easy to correct. CSGs, voxels or open geometry kernels may start to play a key role.

Subjectively, I recommend not wasting the Open Source community's time on fruitless attempts to “revitalize” IFC, a format that exists in isolation like a horse in a vacuum. Instead, focus on creating new engines and online tools for geometry generation. Now begins a parabolic upswing similar to what happened in 2D design 20 years ago.

Today in image processing, no one thinks anymore about where to create vector or raster graphics - there are hundreds of thousands of tools generating open JPEG, PNG and GIF formats for this purpose. So in the construction industry in 10-20 years there will be no questions about where to create geometry of construction objects. The main thing is not to fixate on the solutions of large CAD vendors. It will be enough to get triangular geometry with parameters that describe the element itself, its connections and group relations.