Is IFC5 Autodesk's Trojan horse? a chat with AI on the upcoming shift
If you are familiar with the subject I pasted in a PDF file (attached) my exchange with ChatGPT of this morning on the IFC4+ > IFC5 transition, which raised some concerns I'd like to share with this platform.
It's a bit long but the final part might be interesting:
any comment? ;)
Comments
I've read about half way through, and I've got this mental image of an IFC5 architect telling a builder, "It's not a wall, it's just acting like one."
Some weird stuff in that chat, the genetic analogies are a bit far fetched.
It does feel that IFC5 is very much about exporting to read-only reference data - formalising the current openbim best practice.
The existing proprietary tools have trouble mapping to the IFC schema, so the solution is to allow custom schema. None of the vendors want a Native IFC workflow, so this hasn't been a consideration in the design.
I don't really see how Bonsai can become an IFC5 editor, this would need to be a new tool with a very different interface.
Can you guys please provide some links describing the new schema (modular, flexible, based on behaviour) more in detail? All I find is comparison with USD and talk about meshes - both concerning the geometry only and not the schema.
I don't yet see why building a native editor for ifc 5 should be a problem. Yes, if it's all meshes with no properties, then converting back to parametric elements requires a lot of guessing (but I've seen some tools that do even that) but has that been decided?
Or do you mean there's actually no definition on how to describe a layered wall anymore and each authoring software can do it their own way?
this looks promising (I don't have an actual knowledge of the matter, I use AI to summarise concepts that are difficult for me to grasp, often subject to its hallucinating pitfalls, but I don't have other choice)
source1 from chatgpt.com
Hi @brunopostle
thanks a lot for your comment, truly appreciated
yep, it is but maybe(?) the analogy could somehow offer a hint to non specialised people like myself
The reason why I see IfcBuiltElement entities as siblings is because they seemingly are, in the IFC schema, sharing most of their attributes.
Please correct me if I'm wrong, to me it looks like they only differ in their PredefinedType number 9 section, or 1 out of 4+7+5+5+13+1 = 35 total attributes.
Similarly an
IfcDistributionFlowElementshares 4+7+5+5+13 = 34 of the common attributes and has 1+1 =2 specific ones, in my naive understanding they totally look like close cousins :)I know in biology the example doesn't actually hold, it was just to highlight the strong inheritance root entities carry in themselves. I visualize them as a stack of Lego blocks with part of the top being the specialised ones.
I also know that the schema is far more complex given the multitude of relations and properties, but I need to start from somewhere..
the dormient aspect of unused inverse attributes was also an analogy I found useful, hopefully it doesn't lead me too far from the correct understanding of the schema.
I have no idea about the implementation of IFC5 in Bonsai, looks like it won't be an imminent issue to address anyway
My concern I tried to detail in my AI exchange was the fact that IFC5 appears to me as a big deal that goes beyond the hyped USD/json change, I am more interested in the data structure and new ways to parse a model to extract its information, or validate its integrity compared to an ISO standard.
Cheers and thanks again for looking into my post
@JanF as far as I'm aware the parametric stuff like CSG and layered walls is still going to be supported. IFC5 is much more flexible with multi-user workflows involving an overlay system - the assumption is that everybody else's work is read-only, so you will be able to reference and override their data non-destructively.
However moving from an indexed list (currently every entity is addressable with the step id), to an anonymous list of entities, solidifies the existing openbim practice of exporting a dump of data in whatever order. These data dumps are not intended to be round-trippable, they won't play nicely in git, and we won't be able to diff/merge them.
This isn't all bad, but it is a vision of how the industry should operate encoded into the file format. Openbim workflows are currently spectacularly unwieldy, but still better than 'everybody must use revit', IFC5 should make openbim more practical.
@steverugi yes the inheritance tree is intended to resemble a 'tree of life' this is a concept from object oriented programming that got incorporated into the IFC standard. LLMs latch onto any idea you give them and then run with it, generating a soup of plausible nonsense if you are not careful. There is a genotype/phenotype split in IFC, but the phenotype is the physical building (or maybe the 3D geometry after all transforms).
One of the problems with the existing IFC inheritance system is that each time you create a subclass, eg. Ifcwall is a subclass of ifcbuildingelement, you can only do this by stuffing new attributes to the end of the entity. The structure of an IFC entity is not very flexible if you want to do real object oriented stuff. Though whether we need this is another question: do we need to be able to define a wall that is also a floor? Maybe a wall is fundamental and a wall is just a wall.
@brunopostle
I noticed that! :D Even after switching to "engineer mode" it still sugar-coats part of the output
PS in the same soup I found the concept of
RDF-triples(subject-predicate-object) where the predicate is apparently defined at a local level, it doesn't make use of a standard dictionary (yet?), if remotely true it might lead to countless IFC dialects, what do you think of it?Thanks
I think that is how IFC was always meant to be.
Reference/underlay other participating parties IFC stuff in your "proprietary" App and design your stuff. Which you will finally export as IFC, to reference together with all other parties stuff to coordinate with a complete ICF BIM Model.
But I think that's not how it is used in reality and that it's hard to really strictly separate each party. You often want to use IFC also as a File Converter between different Apps, as it often works better than classic file export/import options.
An architect may start designing a building. Then an engineer may want to grab the structural parts to calculate and do some changes. Does it mean in IFC 5 that the engineer should build all structural parts from scratch and tell the architect that he now should eliminate Slabs 1+7+8, Columns 12-27, Walls 4+5+7-9 from his Arch model, as these are structural parts ?
I may have to do a visualization from that (hard to handle for that purpose) IFC Model, want to have access to the geometry to cleanup and simplify things. With IFC 5, should I better recreate an optimized model from scratch instead of?
Sounds a bit like Navisworks. If I got that correct, which is something like a proprietary Model Coordination Platform for Autodesk Products only. At that time maybe released to counteract open BIM and IFC. And meanwhile Autodesk does like they invented IFC and Open BIM.
Does IFC 5 really mean a trend to lock other parties geometry and data from others ?
How fo these two paragraphs go together? If you want to reference other people's data, the system has to make sure the original data can be updated without losing the reference - meaning there still has to be an unique identification for each element.
The main change seems to be going towards a more structured system - right now as you said new data relating to existing elements are added at the end, meaning you have to go through the whole file to make sure you have all the relevant information, whereas the new system wants to group the information together to allow to just load a part of the file.
This has always been the main point of ifc for me: to write down the definition of what is what, so that we people and computers all speak the same language. The whole point of organising things is that it's clear what the structure is and not flexible.
I think the idea is that the engineer can override/delete any columns in the architect's model, but the architect won't see these changes unless they use the engineer's model as an overlay. Everyone will see a different building depending on which order they load overlays, so it could get complicated.
There will still be global IDs (the long random string), so each building element will be traceable, but it is losing the step IDs (the number with a #), so individual entities are anonymous and it won't be possible to track them - it is only Native IFC applications like Bonsai that care about this stuff, everyone else treats the step IDs as an inconvenience.
So I've looked through the example at https://github.com/buildingSMART/IFC5-development/blob/main/examples/Hello Wall/hello-wall.ifcx
To me it looks like ifc 5 is basically very flat xml, similar to for example svg. There are many native editors for many kinds of xml, why do you say it's a problem? To be honest I've never understood the benefit of step ids from programming point of view.
Looking at the example I honestly don't see much difference at all - yes, the step IDs are gone and the entities reference each other by guid. But you still have to traverse the whole file to make sure you find all relevant info and there's no chunk structure as promised?
@JanF
The problem I see (but I could be wrong) is that you don't have the ifc4+ schema anymore, anything can become anything from the naming standpoint and beyond.
Flexible but weak when you need to know what you are dealing with. I just completed most of the videos of IFC5 today and that's what I gathered so far.
Unless we have a standard dictionary I wonder how can we run IDS the way we do now, or querying models for QTO.
You need to know how "things" are named prior to do it, no Pset anymore..
Don't get me wrong, I like the "layers" or "modules" approach but whereas now you could technically open any good IFC4+ from any source, with IFC5 there are some steps in between that could be tricky.
Maybe the vendor can handle it, I'm not an expert..
Cheers
@steverugi
Ok strange. As I see from the example, the classes are there, as well as standardized properties (so the schema is still there). It seems you're right about the property setes. That would be ok for me in theory, but from my experience it's hard to define properties in a way that it's clear what they mean for any kind of element.
@JanF
If you have time I'd recommend the videos, they are well explained
The step IDs allow a fork and merge workflow, without them you rely on fuzzy matching which isn't good enough. Multi-user collaboration with IFC5 might work very well, but it will be the openbim collaboration model, and not a fork and merge collaboration model.
I searched a bit about what's all about IFC 5.
I think I found an interesting article. AFAIR the author is already known and possibly controversial. And it's in German, but if you have a translator :
https://bau-rockstars.de/das-zeitalter-des-wandels-ifc-gehoert-der-vergangenheit-an-oder-warum-ads-und-andere-cad-anbieter-bereit-sind-ifc-fuer-usd-aufzugeben-14-wichtige-fakten/
thank @zoomer
USD vs IFC saga, there was a guy some months ago with lots of posts on this platform and LinkedIn promoting USD as the new IFC
If you need to show a model or zipping around it you like USD, if you need to professionally handle amount of information in the BIM model traversing it in a stable way you need a relational database with a coherent standardized structure, ontology, semantics.
But maybe I am wrong, or?
Those terms are far above my pay grade :)
For me USD was finally just a hope for 3D what IFC started for AEC. An open "standard", that seems to work in 3D Studios to collaborate in a pipeline with people with lots of different Apps. I see that one of my CAD Apps totally ignores USD export, the other has support but internally so far is not able to offer a comfortable way to interact with USD's deep nested hierarchies.
Which seems like a relatively normal deep structure in Blender's Outliner, if I look at my Lidar Scans with Apps with Apple's Room Plan API. Is it semantic (?) when meshes are grouped by e.g. Scan/Room/Furniture/Chair. For me that looked pretty much like my BIM Structure Tree in Bricscad. That's where I can still follow.
But lots of things like the (recursive?) complex graphics of IFC relationships you all show here on Bonsai forum, that's already too abstract for me.
Maybe I am wrong, but USD in Blender, for me seems like, in future enabling finally lossless exchange between 3D Apps and likely also with CAD/BIM Apps, if even Autodesk jumped on that train (for whatever ethical or not reasons). And, if USD could be a file format for IFC data too, for me that looks like that could bring Blender and Bonsai together.
But I did not expect any IFC 5 in the foreseeable future nor that IFC may have something to do with IFC. So everything quite new to me. But not much fear of USD for IFC, more about the way how ODA and IFC is managed and works. Now under control of all parties that with their behavior once created that need for IFC and ODA.
Yeah that's him, it's the same article he was spamming all around, also here. It's mostly (probably ai generated) plausibly sounding nonsense.
You're absolutely correct. I think speckle is what everyone wants, when they think about quick design collaboration. And in that case yes, we don't need another one.
Ifc has three main parts:
The USD/ifc discussion was mainly about #1, while people thought it's about #2, while #3 is what matters for most purposes, which made the discussions largely absurd.
@zoomer
it makes two of us ;)
the 'ontology' concept is not easy to digest, if you like try this page
this from Stack Overflow is not bad either:
understanding the difference between a dataset (table), relational database (tables with relations using common keys), ontology to regulate the interaction among the data entities is crucial, in my opinion, to appreciate why BIM needs IFC or similar.
If the ontology is not robust (like having a high level of customization of such rules and terminology) it might result in something that serves only a portion of the audience (best case scenario) or in a semi-chaotic slew of dialects.
Perhaps IFC5 will be the silver bullet to sort out all the issues, at the moment I have some doubts, hopefully someone here can help me clarify them.
Happy modeling (In IFC4+)
That isn't at all what I want.
(For BIM in general - it could help for ArchViz though)
What about USD getting support for things Solids and BREPS ? Still USD not useful for BIM ?
Not sure why that should not be possible in USD (?)
https://openusd.org/release/intro.html#what-can-usd-do (I see Solids and Cureves)
https://openusd.org/release/intro.html#what-can-t-usd-do
This is an Example of how expanded USDZ looks and structures my Lidar "Room Plan" Scans. At the end is a Wall with its Window.
If that doesn't look like IFC or my BIM Structure Tree in Bricscad .....
BTW,
if you select one of the USDA geometry (and data ?) files in Finder, you can rotate the Model in Finder Preview
This is exactly what I said last time in the discussion, about USD - of course you can do all that, you can take pretty much any format and add the rules for different kinds of geometry and the schema and use it instead of ifc, but in the end what you have is just a slightly different ifc, so why bother?
I don't care if the file uses .ifc or .bim, if it's sql database or a file, if it's step or xml, as long as it's open so that you cen reliably read it and we all use the same schema, so that you can reliably understand it.
I am attaching a link with information about if5, and from there you can access an ifc5 viewer that is in test mode, allowing you to convert ifc 2x3, 4, and 4x3 formats to ifc5. I recommend watching the video tutorial.
https://biblus.accasoftware.com/en/what-is-ifc-5/
@BimETS
thanks, it was a good read (I am a big fan of ACCA software btw)
I'm still perplexed about how IFC5 will evolve to handle schema consistency, or its 'ontology' for that matter, but hopefully it's going to be clear soon.
cheers
I do not quite get the examples .....
Doesn't already do that any BIM/IFC authoring software with e.g. IFC 2x3 ?
Just overwriting or adding data/info ?
I have been going down an AI rabbit hole with this, and it seems like IFC 5 could change the game for open source BIM if it is managed properly. I agree with the OP that community members must be involved to ensure submodules of IFC 5 are community driven instead of being profit driven. But it would allow for more manageable modular IFC standards, such as architectural schemas, structural schemas, HVAC schemas, etc.
I am also very excited for the possibility to move from STEP to a graph database with IFC 5, which will solve many of the problems IFC 4 faces with memory management and collaboration once tools are built to properly manage it. A graph-based database will also allow storing constraints and relationships between elements directly in the data itself, removing the loss of constraint data when moving between different software.
This post and discussion is great, and we need to spread awareness of the importance of architects and engineers getting involved with the creation of these element relationship and discipline specific ISO standards, as it has the potential to bring open source BIM into the AEC industry as a real competitor to Autodesk.
Some examples of what might be possible were IFC to occupy a graph database instead of local text file (STEP):
1. Loading geometry from objects only inside the current view/camera, helping with memory management issues.
2. Only loading discipline specific/spatially specific assets in the view, making multi-discipline collaboration seamless and also helping with memory management.
3. Allowing one user to modify a node/relationship/property and lock it, so other users cannot touch it until user 1 syncs it back to the database.
4. Other software integration - a structural design software could directly read and write to the graph database while other users are modeling the geometry in the different software, with full node locking to prevent merge conflicts.
5. Seamless linking and model federation - a simplified version of models could be used for federation, and only the exact content of what you want to link to a sheet would be possible with flexible graph queries.
Lots of research and tools are needed before these items above could become a reality, but well-managed IFC 5 opens up the foundation for all of this.
I went down an AI rabbit hole with this, and I believe the potential from IFC 5 and a graph database for storing this data could be a game changer for open source BIM. Here is a summary of that conversation:
Summary of Key Points
IFC as an Implicit Graph: The IFC schema is fundamentally a graph-like structure, with entities (e.g., IfcWall) as nodes and relationships (e.g., IfcRelAggregates) as edges. This makes graph databases a natural fit for storing and querying IFC data, a concept explored in projects like IFC-Graph.
Limitations of Traditional IFC Formats: The most common .ifc format (STEP Physical File) is not a true graph data structure. It's a sequential, text-based file that is difficult to parse for relationships, lacks parametric intelligence (loses the design logic from native applications like Revit), and is not optimized for collaborative, real-time workflows.
IFC 5 as a Solution: IFC 5 is a paradigm shift away from a monolithic, file-based standard. It is being developed as a modular, language-independent core with optional, domain-specific modules. This modularity is a critical enabler for solving the parametric problem.
Graph Databases as a Foundational Technology: Graph databases are the ideal technology for storing the missing "design intent" and parametric relationships. They can explicitly represent the rules and dependencies that define a model's behavior, allowing for powerful, relationship-based queries that are impossible with traditional databases.
The "Structural Engineer" Analogy: The conversation highlighted that the modular approach of IFC 5 means that a new "Structural Module" will be developed by structural engineers themselves. This shifts the responsibility of defining the standard from a centralized body to domain experts, ensuring the standard is more relevant and useful.
Implications of IFC 5 and Graph Databases
The combination of IFC 5's new architecture and a graph database backend has profound implications for the AEC industry:
True Round-Trip Interoperability: This approach paves the way for storing not just the static geometry of a model, but also the parametric rules and relationships that define its design. This would enable true round-trip interoperability, where a model can be exchanged between different software programs without losing its design intelligence.
Real-Time Collaborative Workflows: By using a graph database as a central repository, a file-based workflow could be replaced with a live, transactional system. This would allow multiple users to work on the same model simultaneously, with the database handling concurrency and conflict resolution.
On-Demand Data Management: A graph database could serve as a backend for a rendering engine, allowing applications to query and load only the data that is needed at any given moment (e.g., within a camera's view). This would be a game-changer for working with massive, complex models.
Potential Areas of Development with Open-Source BIM
The synergy between IFC 5 and graph databases creates several exciting areas for open-source BIM development:
A "BlenderBIM" Graph Database Add-on: The development of a Blender add-on that acts as a client for a graph database (like Apache AGE on PostgreSQL or Neo4j) is a significant opportunity. This add-on would be able to load, edit, and save BIM data directly from the database, eliminating the need to manage large .ifc files.
Specialized IFC 5 Modules: Open-source projects could be developed to define and implement the specific domain modules for IFC 5. A project could focus on creating a robust "Structural Engineering" module that includes parametric constraints and alignment logic, which could then be contributed back to the buildingSMART community.
Advanced Query and Analytics Tools: The combination of IFC data in a graph database opens the door to a new generation of open-source tools for building analysis. These tools could use the graph structure to perform complex queries for things like structural integrity analysis, fire egress pathfinding, or sustainability reporting.
Hybrid Database Solutions: The development of tools that leverage multi-model databases like Apache AGE on PostgreSQL is a promising area. This would allow developers to use the same database for both traditional relational data and the complex graph relationships of a BIM model, simplifying infrastructure and enabling powerful "hybrid queries."
A New "IFC-to-Graph" Exporter/Converter: As IFC 5 is developed, an open-source tool will be needed to convert existing IFC models to the new, graph-friendly structure. Projects could focus on creating a robust and standardized exporter that can extract not just the geometry but also the implicit relationships and prepare them for a graph database.
Basically, as the OP mentioned it is critical that engineers and architects are directly involved in the development of IFC 5 sub-modules for discipline specific applications. This could open up the potential for fragmentation, but properly managed could shift IFC from being a rigid "one-size-fits-all" approach that leads to memory management and collaboration limitations to a flexible single-source-of-truth graph database that can widely adapt to fit the various needs of projects, while still having the useful structure of various industry specific needs.