IFC vs Speckle: From Vendor Control to Community Control
How Speckle, as opposed to IFC, brings interoperability from vendor control into community control and opens up a new page in the built environment’s 3D digital transformation.
Given the frequent questions that pop up on the Speckle community forum around Speckle’s relationship with IFC (Industry Foundation Classes), Matteo heckled me (@dimitrie) to write a blogpost that clarifies our stance.
The IFC vs Speckle Fallacy
First of all, any comparison between Speckle and IFC is fallacious. IFC is a standard, whereas Speckle is a platform for 3D data that happens to come with a standard. This means is that, within Speckle, the object model (the definitions of objects, e.g. how a wall is defined) is not an integral part of the platform - it’s actually “hot swappable”. If the default object model is not fit for purpose, it can be replaced entirely by another better-suited one.
As such, the legitimate comparison is between Speckle’s Objects (the default object model) and IFC. There are multiple ways of comparing two standards. The most important one, though, relates to a standard’s primary stated function: how does it deal with the interoperability between systems for which it’s designed?
Dealing with Interoperability: Vendor Control vs. Community Control
Conversions to and from IFC are essentially controlled by each individual authoring application vendor - Autodesk, Trimble, Bentley, etc. - and their respective teams. Given each vendor’s business needs - to attract and lock in their users - the incentives for properly and honestly implementing the IFC standard are, at best, confused. As a direct consequence, the implementations’ actual quality vary and break in numerous ways - within a vendor’s ecosystem, as well as between ecosystems.
As an example, here’s a sample of the feedback we usually get:
“We see IFC as a quasi-standard: good AEC collaboration is unfortunately prevented by the slow implementation of IFC by almost all CAD software providers (perhaps intentionally).”- Anonymous Speckler
At Speckle, our approach is to own an implementation of the standard we use as a default. This is a crucial difference: rather than relying on competing vendors to correctly implement a standard, Speckle is directly responsible for its implementation. As such, incentives are fully aligned with those of users - architects, designers and engineers that want better interoperability. This is ingrained in the very fabric of Speckle - if things break, it’s our fault, and we are directly responsible.
Nevertheless, Speckle is not a black box run by exclusive committee meetings. Being 100% open source, our responsibility is shared with users and contributors. As a company, we listen, we act and we accept contributions - from code that better structures classes to bug reports and ideas. Speckle is fundamentally shifting the paradigm from vendor control to community control.
Speckle is fundamentally shifting the interoperability paradigm from vendor control to community control.
Want to be part of our community? Join our forum! Curious how you can contribute? Read below more
Why Doesn’t Speckle Use IFC As Its Object Model?
The question “Why Speckle doesn’t use IFC as an object model and develop conversions based off it?” has been asked quite a few times on our community forum. So why?
IFC Evolves Slow, Speckle Moves Fast
To start, a pragmatic reason is the fact that the surface area and abstraction levels of the IFC standard are huge. This, coupled with a very bad developer experience, means that developing anything that relies on IFC takes years of effort from a dedicated team. The Hypar team has articulated even more reasons in the same vein.
Beyond pragmatism, one of Speckle’s stronger principle stances is that it does not assume to know what is the best way to represent data in AEC - architects, engineers and designers know best. This principle manifests itself even in the deepest part of our code foundations: every Speckle object, regardless of the object model it comes from, is strongly typed and dynamically extensible, making it very easy to prototype new data structures. Speckle puts language evolution at the heart of interoperability; its aim is not to offer a complete standard but a framework within which the very ontology of the built environment can evolve in a meaningful, logical and useful way.
Speckle puts language evolution at the heart of interoperability.
On the other hand, IFC excludes competition: despite being committee driven, its claims of universality and the financial gatekeeping required to have a voice in said comities exclude most competitive divergence from happening. Speckle’s aim is to be as inclusive as possible: as mentioned at the beginning of this article, the default object model that Speckle comes with is swappable: any entity can either improve the existing one or extend and create a complete new standard. In other words, Speckle welcomes change and provides a framework for managing it.
Contrary to IFC, Speckle does not aim to offer a complete standard but a framework within which the very ontology of the built environment can evolve in a meaningful, logical and useful way.
Reference: Enabling Ontological Diversity - Stefanescu, D., 2020. Alternate Means of Digital Design Communication (PhD Thesis). UCL, London
Data, Not Files™️
IFC, currently, is heavily biased towards being a file format. Files are heavy and opaque blobs that do not lend themselves easily to automation - and as a way of transferring 3D data around, provide terrible performance. For example, it is very difficult to properly diff an IFC file and ensure that you only send the changes over the wire. If you have modified just one column out of 1000, you will need to re-upload the whole file again.
Speckle operates on a whole new principle: it’s an object-oriented data platform. During serialisation, Speckle decomposes each 3D model into its constituent atoms - walls, windows, doors, floors, etc. - and each of these atoms is sent over the wire if they haven’t been sent before. Take the previous example: if a designer modifies just one column out of 1000, the data being transferred is just that one column that changed. Beyond the gains in actual storage performance, this enables a curatorial approach to sharing 3D data: an architect can send a structural engineer just the parts of the model that are relevant for the other’s work.
Moreover, objects are stored as individual entries in a database, thus enabling a whole new level of flexibility when it comes to collaboration as well as automation. For example, one can query for just specific parts of a building and create zero-overhead overlays of multiple models, or sub-sections of models, on the fly.
If you want to give it a try, load the partial model below and click on the 
comment.
Speckle is an object based 3D data platform, not a file based one. This allows us to enable truly communicative exchanges of data between design stakeholders.
Reference: From Sharing Files to Curating Data - Stefanescu, D., 2020. Alternate Means of Digital Design Communication (PhD Thesis). UCL, London
Key Takeaways
Speckle is a platform for 3D data collaboration, whereas IFC is a standard: that’s why it’s difficult to compare the two directly. Where IFC’s goal is to define all the elements of the AEC industry, Speckle’s ambition is to bring along a new paradigm of real-time collaboration with 3D data: a truly cooperative multiplayer mode for designing and building the real (and virtual!) world.
Here are a few things Speckle has to offer beyond just interoperability:
And much more.
So, what can you do with IFC that you can’t do with Speckle? In the long term, Speckle’s aim is to change the industry in such a manner that the answer would be “nothing”. At present, IFC has a large legitimate inertia as an archival format that is well supported for viewing operations. Speckle, on the other hand, is a place where 3D data is alive: not as an archival format but as a multiplayer experience in which anyone can dial into the design process from the comfort of their own apps.
Addendum: Exciting Things Around IFC
It’s not all bleak. In the last couple of years, a number of exciting open source initiatives emerged that aim to level the playing field around IFC and, through their efforts, try and effect change. Here are some that stand out:
IFC.JS
IFC.JS is a modern, fast web-ready parser and viewer. Speckle is using its parser (web-ifc) as our processing backend for converting IFC files!
Blender BIM
Blender BIM brings IFC into Blender - an amazingly versatile and powerful open source modelling, VFX, animation and more software widely used in the film industry.
IFCOpenShell
The OG IFC toolkit and parser out there. 6500+ commits and going strong!
Hypar Elements
https://hypar-io.github.io/Elements/index.html
Not IFC related at all - but extremely exciting for exactly that reason: our friends at Hypar are developing Elements, which “is a cross-platform library for creating building elements. It’s meant to be used by architects, engineers, and other building professionals who want to write code that generates buildings.”
Thanks to Matteo, Jonathon, Iain and Bilal for the patience, spell checking and pertinent remarks on this article!