Belgian start up, Qonic, has ‘open sourced’ one of its key foundation technologies, to enable new ways of working with dynamic, ‘component-level’, BIM data sharing
Anyone who has used a computer understands that all data is typically stored in files. In the world of CAD and BIM, design data is stored in the proprietary file format of each software developer. These are typically DWG for AutoCAD, RVT for Revit, 3DM for Rhino, PLN for Archicad etc.
Drawings and models have been intrinsically linked with the files in which they are contained, needing management, protection, and archiving – locally or in the cloud. The new thinking around collaborative design is that we should be working in a centralised database instead, and have access to shared design information, at a more granular level. Qonic Atom IFC is a gift to the industry to accelerate that way of working.
Regular readers of AEC magazine, or attendees of our last two NXT BLD conferences in London will hopefully have seen the presentations from Greg Schleusner, HOK’s principal / director of design technology, on how BIM workflows don’t fit the way the industry works and how we need to build a data bridge to connect all the key data silos of information that we create in the design tools we use.
Watch Schleusner’s 2021 and 2022 presentations below.
To a large extent, this work has already been done in the Media and Entertainment industry with the USD format which connects all users and their tools. USD contains geometry, materials and lighting and means scenes can be easily shared amongst users of different applications. Schleusner envisages that, for now, something similar could be done with IFC which supports more BIMspecific data than USD.
To get over the ‘it’s just a bunch of files’ issues, the idea was to break down BIM models into their components and broadcast them to a central repository (this could be local or in the cloud). As each component (wall, door, window, etc.) is added to the design in Revit / Archicad / Vectorworks, Blender BIM (choose your poison), it is broadcast to the repository. This will create an IFC data lake for the BIM design data.
Here, it’s worth pointing out that other tools like Speckle Systems and IFC.JS are contributing open-based tools which operate in this Common Data Environment (CDE) ecosystem.
The benefits of this ‘data lake’ concept are manifold – the design is no longer only stored in a proprietary file format, IFC components can be selected and shared as work packages with other users and sent individually (vs sending the whole model), users who subscribe to IFC components can be notified when they have been updated and, when the data is out, it will be possible to run applications directly off this common data, as opposed to having to write them for individual design tools.
Using IFC as a core schema already opens up the potential to wire up the existing ecosystem. However, there is one small problem. How do developers ‘atomise’ their BIM data? It’s that issue which Belgian BIM software startup Qonic has addressed and is giving away to the industry as Atom IFC.
Qonic Atom IFC
Qonic Atom IFC is an open-source tool, available on github. It will ‘atomise’ (split) monolithic BIM data into bi-directional streams of BIM components. It can be used to split or recombine IFC and contains the ability to track and log changes to each component as a design evolves.
For his NXT BLD 2022 presentation Greg Schleusner used the early beta of the Atom IFC toolkit to write an integration for Revit. He demonstrated Revit dynamically sending atomised IFC data to another Revit user in real time. When he edited his model, the elements impacted in the other Revit session almost instantly, enabling new ways of working.
With Qonic Atom IFC available as open source code, all it would take is for vendors to write an integration to add this capability. But, as Schleusner demonstrated, it’s something that anyone with basic API knowledge could do themselves, so this doesn’t ultimately have to come from the software developers but can be retrofitted by knowledgeable individuals using tools already included.
Who does this help?
AEC Magazine asked Qonic why it decided to open source an important part of its forthcoming BIM solution (which we explore in this AEC Magazine article).
Co-founder, Erik de Keyser explained, “Our point of view is that we need this capability anyway. If we were the only one to do this, we would then have to convince the whole market, and that’s very difficult. We also think that if we didn’t do it, in six months to two years someone would push the same idea into the market. So, we preferred to deliver a technology that we know really works well.
The next revolution requires a ‘fit for purpose’ core data schema, on top of which both old and new BIM tools can co-exist, protecting investment in current tools, while enabling new, more open ecosystems to grow
“We are using the same technology in our own product, but Qonic will bring additional capability to the modelling and the management sides of BIM data. So there’s a lot of functionality that we will deliver on top of Atom IFC, but it is beneficial for us to give away something that everybody can use, because it immediately opens the market.”
Head of Product at Qonic, Tiemen Strobbe, added, “The initial idea of Qonic is that you bring in an IFC file, and you add further detail to the model and you will have an enhanced IFC file as an output. During the process of enhancing the IFC file, things will change in the model. Designers will send you new designs and, if each time you had to re-import the entire thing and send across 100 – 200 MB IFC files, that’s not really a collaborative workflow.
“For us, it’s in our benefit to have a system like Atom IFC, where you can send across small chunks of the model, just the objects that change and merge it into the rest of the model. We needed to support this kind of workflow, and we feel it needs to be open.”
By making Atom IFC open source, Qonic accepts that its development will be not just down to its team but will be driven in many new directions by the community. Strobbe explains, “Everybody can contribute changes and can merge these changes into the main code stream, or opt to keep them separate. Sometimes people branch off the code stream for their local use, and that’s fine, they don’t have to send their changes to us, or they can choose to contribute to the open Atom IFC code. These can be merged to the main code stream. If we make changes, if we make optimisations, we will push them to this open repository too. Basically, anybody who knows C Sharp can contribute to this to this library.”
Conclusion
Over the last few years, AEC Magazine has been examining what comes next for BIM. There are growing demands from users for a new generation of tools which are not primarily designed for the production of drawings, which all current BIM tools have been.
Mature BIM customers want tools more capable of meeting their modelling needs, together with built-in collaboration capabilities for a disconnected industry. While the concentration of this has been on demanding brand-new tools, we are rapidly coming to the conclusion that the next revolution requires a ‘fit for purpose’ core data schema, on top of which both old and new BIM tools can coexist, protecting investment in current tools, while enabling new, more open ecosystems to grow. Qonic’s generosity has potentially kick-started this journey and IFC looks set to be amongst the first BIM data formats to embrace entity-based file transactions.
Greg Schlusener has launched a website where his views and developments in this area can be seen, together with some explanation videos of the concepts he is working on.
Atom IFC features
- The Atom IFC library is open-source, available under an MIT licence, and will remain so forever. C# library with IFC classes and read/write support.
- Combine IFC objects from different files, while correctly handling all the corresponding relationships, attributes, and properties.
- Merge partial IFC files per building storey.
- Keep track of how many objects have been added, changed, and removed during merge.
