Toward a USD schema for IFCX interoperability
Hi all, there's obviously been a fair amount of chatter in the industry about the relationship between these projects, so I thought we might create some space here for a little opportunity brainstorming.
My personal baseline for inquiry:
- Ingesting IFCX to USD stages is a given
- What we do with it once it gets there is a discussion
- Sending it back the other way is a question
Observations:
- USD was developed by technical artists trying to solve the problem of interdepartmental collaboration in 3D design and rendering, in a context where none of that content would likely need to be built
- IFC was developed through collaboration across industries for more effective collaboration, transparency, and management of the built environment, where 3D visualization can sometimes be useful
- Open standards are living systems — there will inevitably be cycles, where basins of attraction generate periods of stability and then divergent offshoots test new lines of flight
Proposed goals for a collaborative conversation:
- Develop a USD schema alongside IFCX, through industry input and live testing on commercial projects
- Develop lossless strategies for round-trip interoperability between IFCX and USD
- Design the schema to expect IFCX inputs to merge with a diverse range of other sources without interfering with that interoperability
I think USD is useful to AEC as a scalable stage that can reference and sublayer content from a myriad of files with admirable performance. It tolerates lots of people working together who don't always understand each other and often just want to keep doing things the way that makes sense to them. But there might be room for development on the USD side that supports what IFCX is for, so that the benefits of USD workflows can be a part of what IFCX feeds into — which might be useful for decision-makers in site design and for broader civic coordination and engagement, even if it's not as necessary when we're actually on-site, doing the construction. This all seems to align with what IFCX is all about, so I assume these will be familiar thoughts — but that's partly why I wonder if we have an opportunity here to support the thinking and tooling.
Thoughts?
Comments
I should add — I have searched for projects that aim in this general direction or that would be of service and have come up with relatively little, so if this strikes anyone as an echo, definitely feel free to link it in and we can do some cross-examination.
Forgive my being blunt
in my shallow point of view the USD/IFCx saga is a sizeable amount of resources spent to find a solution to an almost non-existing problem.
Yes the trend is changing, IFC is slowly but steadly becoming a format requested by administrations in some part of the world, but we are just at the beginning.
My personal view is that the majority of those directly operating in the AEC industry don't need to play sophisticated virtual reality flashy Minecraft app on site with giga-bloated models.
We need a way to design and build + maintain in a coherent way, where stakeholders can truly interact with each other, with a solid information base to avoid waste and improve interoperability, optimizing costs. 99% of the cases if properly implemented IFC4x3 can do the job, now it's for the users to fully understand and use it. One day.
End of my rant, sorry
Great stuff, Steve - thanks for jumping right in! We love a level head — let's put these issues right at the top!
I'm hearing ...
How might we design out waste and design interoperability in?
And I think implicitly,
How might those investments yield results of public benefit and not detriment?
How's that?
I've got my own answers but don't want to take up too much space before others contribute. For anyone curious, you can see a little more about my framing and interests here.
@Hans
interesting take
with one important detail in my opinion: USD does not use a schema comparable with IFC4x3 (reason why the effort to save part of it into a limited version aka IFC5), it seems to be great at handling complex heavy geometries, but doesn't have the strength of ontology/semantics of IFC up to 4x3, if at all.
Current attempts at "optimizing" the current schema with alternative ones, suspiciously pushed by major companies like Autodesk and their bots I would add, only address the 3D view handling aspect at the cost of losing integrity of data, wich ironically is the core business of BIM, go figure.
Hope I can educate myself better on this topic ;)
cheers
@Hans
sure, but it's not so easy, IFC 's ontology is not comparable not even remotely, but I think I am biased ;)
thanks for the exchange
@Hans
if you could, kindly indicate or explain how to traverse USD schema
at the same time the fact that I can open an IFC modeled in any country knowing that the integrity of class, attributes, properties and relations is sound makes a lot of difference, validation via IDS can be implemented too..
entirely supports my point, if your priority is to handle data of course (you know, the "I" in BIM)
cheers
Interesting exchange, thank you both for your contributions.
I'll put on my moderator hat for a moment and summarize as best I can for those that might scroll the conversation later, then I'll reply to some of these thoughts with my own perspective — and with any luck maybe that will give us some traction for forward motion on how we might want to make use of this space.
CONVERSATION SUMMARY TO DATE
Debate: @Hans points to extensibility as a primary argument in favor of USD's increasing capabilities as a data exchange format
Questions worth considering:
What are the actual needs and priorities around 3D representation among AEC practitioners?
END SUMMARY
And not that I see anything to flag yet but I feel like I have some responsibility to encourage us all to treat this space as a valuable professional engagement opportunity. My personal goal in this conversation would be to see it develop into a project with some invested team members working in the open, where colleagues can regularly comment on progress. That will inevitably require depth and detail, like some of what we are seeing above, but I would encourage us to value the exchange enough to be cautious how much space we each take up with matters of opinion. I come here with an open mind, hoping to learn from each of you and would invite you to do the same — it's a great thing, to have spaces like these — so thank you both for what you've brought to it so far.
Great questions and comments all around.
Without getting too into the weeds or presenting myself as any kind of expert, I’ll just weigh in on where I see the opportunities.
Author’s note: After writing the content below, an important preface occurred to me, which I would like to call out explicitly here. IFC and USD share a quality with other standards, like HTML. They are a data structure that underscores a way of working, which enables broad, comprehensive collaboration. In some way, perhaps every data structure is a kind of paradigm but practically speaking, some reflect this more than others and operate at different scales of impact. We should be cautious how much we embrace the comparison to HTML but some solutions do come along that unlock a whole field of other activity. I don’t exactly see USD as unlocking the 3D equivalent of a dot com boom because it’s a little more niche than the notion of a global communication network but for those us working in 3D, it is kind of revolutionary. So I wanted to name that because the content below is very much not written from the perspective of someone thinking of USD as a file format; rather something closer to an atlas on how to navigate the future of 3D, where before there were mostly just signposts and billboards to go on.
On Ontology
On @steverugi 's general questions about USD, I’ll start by clarifying for a less familiar audience my understanding of the notion of ontology in this context. That word has shifted uses a bit over the past generation or so, as the philosophical study of what it means to exist (how the mind comes to be, what it means to those who experience mind to reflect on that experience, and so on) got applied to data. My interpretation of @steverugi 's use of it here is that he is referring to the way in which an entity in the IFC data structure exists first and foremost by its being identified as a certain thing; a meaningful thing. (Do I have that right, Steve?) The human-readable side of that might be a name or title but there is also a machine-readable component that differentiates it from every other entity that exists. That human-readable name is one of many chunks of data that we choose to associate with this universally unique, machine-readable identifier.
This is an important quality in BIM and I would imagine that its presence is a non-negotiable component of any useful BIM schema. The ability to identify a thing regardless of its geometric representation on a screen is what makes BIM useful. I am not a BIM specialist actually so if anyone would like to correct my understanding here, please feel free to contribute. Now, I should also say that I don’t know any builders who have ever heard of ontology as it relates to data or care any more about how the lines on the drawings got there than they do about what I had for breakfast — but every one of them care about clarity of communication and accuracy of plan drawings. And without that ontological quality, those would be difficult to reliably extract from a BIM model in a way that allows us to meaningfully correlate it to the rest of what need to know about that entity.
So how is this matter handled in USD? Short answer: it’s not! The U in USD is a part of what makes it great but that, by necessity, means that it doesn’t come packaged with any domain specific schema — which is why the more interesting answer is to reframe the question: How might we handle that in USD when investing BIM models? The thrust of my interest here is that if the answer is not designed by professionals in an open context, we risk repeating some of the issues that probably brought us all to this forum in the first place — namely, it will be decided by people in large corporations in ways that prioritize their own interests.
And I should be clear here: I have no reason whatsoever to challenge the motives of the people involved in AOUSD or claim that our own interests are inherently more important than theirs. I just know that any room that costs money to get into is a room that most people won’t be in. And since USD is an open system now, we have as much right as anyone to decide on our use of it. Most importantly, the trades history that I am most familiar with indicates to me that the methods workers put to use on the job are the ones that get passed down. So regardless of what gets handed down, we’re still entitled to come up with something else if we prefer.
To the point of “ontology” specifically, I’m making the case here (if even for the sake of argument) that it’s mostly solved by IFCX already but that a clever ingestion method will allow us to make full use of the incredible resources that really do make USD special. To explain that, I’ll end up touching on some of the points above, and I’ll do so by pointing out what we can do with USD that we can’t do with IFC. If you’ve missed any of my earlier assertions on this, I am explicitly arguing for the inevitable ingestion of IFCX into USD and am in no way arguing for or against the idea that USD will ever become a suitable replacement for IFC in any dimension of its current practice. I simply do not have the requisite experience to contribute to that conversation either way.
On USD Affordances
Metadata
Tagging entities in USD is a matter of applying custom data. A method of doing so might be called a schema. That’s the shortest possible definition I can think of to explain what we’re talking about here.
Tagging entities with a universally unique identifier is a one-line-of-code problem. Deciding what to tag and why, how it relates to the rest of what gets tagged and why, what it means about the relationship of those things as they move through USD workflow practices — this should be the topic of a months-to-years-long collaborative discussion and incremental improvement process. And like most efforts, we should expect to Get about 80% of the way there in the first 20% of that time. I haven’t found any open resources discussing this explicitly so I would like to think that we are somewhere in that 80% part now (and maybe the rest is happening in a AOUSD working group or side channel somewhere).
Not to push it as the only answer but I’ll post again the working draft schema that I’ve been developing to date:
This handles UUID while creating what I think of as ‘page breaks’ in the IFC hierarchy to provide better interoperability with the unique affordances created by USD.
Collaboration
Slices of relevant data will be a familiar topic to IFC users. Example models in well-studied repositories always seem to showcase this ability to separate and merge IFC content without losing track of where everything ought to be.
What might be less familiar to IFC users is the idea that we could all be working on the same file from workstations around the world, responsible for our own slice of the updates, without any concern over whether we might accidentally overwrite someone else's work. I'll spare the details here but this is one of many useful workflow elements that USD has created solutions for. Now as I'm sure we all know, everything can be done badly if you try hard enough, so there's no guarantee out of the box that this all happens on its own. It takes a bit of familiarity but that's where shared mental models come in handy and I'm making the case the data structure is a key part of that mental model here.
Variants
What I was always used to in the days before USD was having folders of numbered versions of everything and loading them up separately in the appropriate software, one at a time, and maybe eventually I had a computer strong enough where I could open TWO version side by side, which was very exciting indeed. USD has baked the importance of design variants right into the cake of the whole concept; not extra frosting either — a core concept, right along with layers (which is also a thing but I'll leave it for later). So we can toggle between model variants without changing software or opening files. And that works at all levels of the hierarchy. Chew on the potential of that a moment — that gets rather close to something like version control right in the logic of the format. In Blender, we might do different containers for design variants and toggle between them but Blender doesn't have any way to understand that only one of those two things can be true at a time.
What does that do for us if we're ingesting IFC as a matter of course into the USD stage?
If means that we can expect from day one that we're building out a hierarchical template of variants for consideration transparently communicate the intent to bundle it all as a part of the design service offering that we are presenting to our clients, for one thing. That strikes me as an improvement over current documentation practices. And I'm coming from the assumption that radically transparent practices improve living conditions broadly over time, so I'm operating from the assumption that, even if leaving your clients with all the rejected designs is met with skepticism in the near term, those willing to help their clients learn about the process and value its artifacts will be the ones leading and benefitting in the long term.
Let's play it out a little more: I'm ingesting your IFC files, as is my role in coordinating the visual twin we're using in presentations and meetings. you're on master planning, someone else is on interior design, another person is responsible for climate/carbon impact auditing, and we have an engineering team consulting on structure and soil. In our meetings, from a single file, we are toggling live between 1) design concepts based on split climate scenarios (let's say 1.5 v 2 degree warming, localized to our site) and then 2) floor plan variations for each of those concepts, 3) interior materials from an example subset from one of those, 4) daylighting studies — toggling between the false color displays of a moment-in-time study against the total annual or seasonal light — and accompanying lighting options that those studies may suggest. And in principle, we all open that file in different software and navigate through the same data.
Layer on to that the fact that we have time-series data which, as far as I know, is not a native IFC concept, and you can imagine how animated assembly instruction, material weathering, maintenance cycles, and future renovation opportunities might all be compiled into one file. Now conventionally, I would say that's gonna be a problem — the file is too big. But that's the problem context that USD emerged out of — artists want to pile billions (yes, billions) of polygons into a scene without getting bogged down in the hassle of having to optimize anything; oh and maybe we want explosions and water splashing around in whole host of volumetrics to boot. The USD system is all about compiling massive amounts of data in one place and keeping it highly performant and traversable for a demanding audience.
Visual fidelity (lighting, context, detail, time)
From the designer's point of view, extra flourishes like raytraced illustrations and expensive flythroughs can seem like a bit of extra sauce or garnish on top of a dish that already has everything it needs. But as someone coming from the arts into AEC, I have been personally surprised by the impact realism can bring to the decision-making process. In 2024, I was involved in the design of a social services project in Tokyo and, while the small team that I was on all had the spatial reasoning and material culture background to work easily off of drawings and callouts with a clear, shared sense of what those decisions would mean, I was humbly reminded that our clients were not necessarily coming from that background. Some struggled to fully understand our initial proposal. After an hour or so of debating the prints and drawings that we had put together, nearly at the end of our allotted time, we decided to proceed with the presentation of a live walkthrough in Blender, running on a computer that could handle a relatively rapid refresh of the denoised Cycles render mode. I was nervous because it seemed like such an unpolished way to deliver content, as I was more accustomed to the rendering workflows of commercial practices where we queue shots up all week and re-run them repeatedly until they're just right. But it made all the sense in the world to me when the room suddenly lit up under the glow of that screen and an audible "Ahhh ..." and "Oh!" emerged from the table of decision-makers. Most of what was debated in the hour prior was dropped immediately. The model answered questions about access, headroom, and shared spaces in ways in ways that just weren't visible on paper.
Conclusion
We may not need billions of polygons for a single building design but the combination of these affordances means that we can do things that we couldn't before (or not very easily). Like what, you ask? What about ...
a) put a whole campus together and selectively pull apart sections and highlight relationships in a comprehensive exploration; or
b) support municipalities developing civic twins in asynchronous collaboration with otherwise unrelated firms (and then run CFD simulations in them based on predicted changes in weather patterns and feed that data back to the designers responsible for retrofitting those properties); or
c) build libraries of shared resources, like https://github.com/NVIDIA-Omniverse/PhysicalAI-SimReady-Materials; or
d) maybe a library of animations attached to detail drawings so that a worker can confirm the process on their phone — like a library of what OpeningDetail is doing, but with motion?
Would a domain-specific USD schema help?
It's true that a USD schema for AEC will not solve much right out of the gate. I think I'm hearing @hans say he doesn't even want all that data messing about in the visual representation model -- and it's true that there is some risk of bloating visual models with data they don't need. But if we're navigating a visual twin collaboratively and publicly, not just with design professionals, then having that data means that we can choose to tell the story of that data and I'm going to lean on the side of, "Yes, please" on that conversation until I see hard evidence that there's nothing I can do with it to help elucidate the proposed design or its potential ramifications.
It takes some extra work to put models like this together and that comes at a cost — or it ought to — but open standards mean broader collaboration and that almost always results in patterns of use that make certain distances shorter and easier to follow. And if the presence of that model has an effect early on in decision-making and then gets updated and used throughout, not only does it contribute to cost-savings in the design process but I would argue it also contributes to the biggest cost savings of any project — a community of stakeholders that are satisfied (thrilled? moved? transformed?) with what gets built. I know that's not always a line item on the list because it's beyond the client-designer relationship — but it's there — and it's the hidden driver behind the motivations of at least some people in that room of shot-callers. That value is the one that determines how the project gets treated throughout its life cycle — and I don't have any illusions about USD being any kind of magic spaceship to get us there, I just think it's almost as handy a resource as CAD but in a way that might not yet be obvious.
At any rate, I may know a little about what can be accomplished theoretically, but I don’t yet know what it means to try and accomplish these things practically. There are always pain points pressures and hidden burdens that emerge when we put such things into commercial use.
Thanks all — enjoyed catching up on the debate!
PS — for @Hans : great to see your enthusiasm but I'd be cautious about getting too attached any particular tech stack during times of transition; fluid times are these — maybe that's why I've responded the way that I have to the life raft of stability that can come from open standards like USD, it's like we just finally figured out how to work in 3D and the last 40 years were just R&D.
@Than
I think so, the layman approach of mine sees IFC schema through its basic components:
1. RDF triples (Subject - Predicate- Object, or "Wall123-IsContainedIn -Storey5") that people more qualified than me may call IfcOWL/RDF, where the "O" stands for Ontology.
2. the EXPRESS "playbook" (those interested can find it at the bottom of each IFC entity's page of buldingSMART website), where entities are expressed in a form to allow their interaction with others.
3. Everything that makes this what they are: Class, Attributes, Properties, Relationships, Inheritance, and their semantics
I should say it's not important: it's essential
Allow me:
there are two ways to read the world, or our projects:
If you narrow the second point's scope it's the same as limiting the level of details of the model/project, it's not an opinion or matter of taste
I am one of those builders, pleased to make your acquaintance ;) or at least I wore several hats within the industry interested in having structured data behind fancy drawings, so yes I confirm, I care about clarity and accuracy.
sorry to reiterate: it's not "difficult", it's literally impossible.
that is why QS or PM like myself have to painstakingly convert drawings into something meaningful for data management including cost and time, the importance of structured data is as good as the structural design of the project.
IMAO I don't see IFCx as an equally efficient replacement of IFC4+, my understanding is that it only keeps the core of its predecessors and allows modularity for the rest, it's a slippery slope because it will create a moltitude of dialects, resulting in a babele of interpretations. But I guess this topic is not particularly intersting to many?
cheers