Given the frequent questions that pop up around Speckle’s relationship with IFC (Industry Foundation Classes), Dimitrie (co-founder of Speckle) wrote an article explaining why Speckle doesn’t use IFC as its object model.
⚠ This is not necessarily an IFC rant but rather an article written to explain the rationale behind the decisions taken.
What do you think?
https://speckle.systems/blog/ifc-speckle-can-you-compare-them/
[deleted]
The TLDR version is that they are two object models with very different objectives. One is concrete, platform specific data transfer designed to be easily extended. The other is abstract, platform agnostic data designed to standardize semantics. Choose the best tool for the job :) the industry needs both.
My $0.02.
It's a great article. It's getting people asking the right questions.
The article begins with talking about how IFC should not be compared to Speckle, but rather to Speckle's object model. This is a really important piece for people to understand. If IFC is HTML/CSS/JS, Speckle is akin to the HTTP protocol. Speckle Objects itself would then be akin to a lightweight JSON schema.
The slow vs fast thing is correct. IFC is slow. It's an ISO standard by a consortium, government groups, and non-profits. Speckle is fast, it's super lightweight by a single company. IFC is highly abstracted, because it targets a huge scope of the industry. There are portions of IFC which are definitely almost definitely overengineered, but such is the conservatism of such an ambitious international project. IFC4 improved significantly on IFC2X3, IFC4.3 has been a good evolution, but I expect IFC5 to be another leap. For wiring together two apps, this is clearly a con. For long-term real estate data mangement for large enterprises and governments, this is a pro.
But the main reason Speckle Objects are fast are because they are lightweight, or in their words: "its aim is not to offer a complete standard but a framework" - this is a great solution for short-term middleware dealing with live data streaming, but probably not a great idea for internationally standardised long-term data interoperability. For example, where is my "FireRating" property stored and how is fire rating measured for walls? IFC gives you an answer. How are construction tasks connected to cost items and object types? IFC has an answer. How are manufacturers and supplier contact information stored? IFC has an answer. Speckle doesn't. But Speckle doesn't intend to, either. The pro or con depends on your audience.
The point made about "Speckle is not a black box run by exclusive committee meetings. Being 100% open source, our responsibility is shared with users and contributors" was true, but no longer. I was a vocal critic of this in the past. IFC has significantly opened up their development process. On the dev side, projects like FreeCAD, the BlenderBIM Add-on, Homemaker, IFCJS, show that it does not take teams of developers. The monopolies are probably just apathetic.
Data, not files, deals with how the proprietary vendors deal with IFC. Native IFC disproves this, and chunks IFC into editable (and thus streamable) portions. For those that only deal with proprietary IFC exports / imports, the article makes perfect sense. For those who have seen the potential of native IFC, it doesn't apply. With modern toolkits like IFCJS and IfcOpenShell, it's becoming easier for anybody to build lightweight IFC editors. It would be significantly harder to build the BlenderBIM Add-on without IFC, and it would be "Yet Another Object Model".
Let's talk about what Speckle does well, and where IFC truly sucks. IFC streaming is completely unproven. In theory, we're moving to it, but it's not at the core of how things work like how Speckle has data streaming at its core. Speckle is very friendly, with modern documentation and a clear direction for devs on how to get started and which libraries to use. For those in the Windows bubble, C# is great. IFC docs are back from the 1990s and early 2000s. IFC4.3 looks more modern, but the content still has a long, long way to go. IFC geometry is an overengineered beast. It urgently needs simplification. There are only a handful of heavily used geometry types, and Speckle clearly knows what they are.
I think it's only a matter of time before Speckle offers IFC as one of its data models (or as a native platform endpoint?), because IFC has answers to many of the questions that Speckle is avoiding (i.e. how exactly should I describe X across all disciplines?). Similarly, it's also only a matter of time before IFC solves its data streaming problem and can flow through systems like Speckle easily. Maybe this day can come sooner if we put our heads together and bring the best of both worlds. Ping @dimitrie :)
Agree with the above. I think they both are intended for different purposes. Rather, I think Speckle to be more in competition with other solutions for interoperabilty like Unreal's datasmith or Rhino.Inside.Revit. I haven't seen detached properties before in OO programming. (I'm not a professional programmer by any means!) Is this something unique to Speckle?
@wrongbutfaster said:
Agree with the above. I think they both are intended for different purposes. Rather, I think Speckle to be more in competition with other solutions for interoperabilty like Unreal's datasmith or Rhino.Inside.Revit. I haven't seen detached properties before in OO programming. (I'm not a professional programmer by any means!) Is this something unique to Speckle?
Rhino.Inside is more of a tool for a one person process, you use tools of Rhino and therefore Grasshopper live in other softwares.
Speckle is more of a collaboration platform between several people who would not work on the same software, it acts with commits like a git for coders. Sure you can also use it alone.
Would be awsome to collaborate on a same IFC from different softwares sending commits with Speckle.
Sorry to be extremely late to the party. Dion's remarks make for a wonderful extra commentary and clarifications/corrections where I'm wrong. I agree that in recent times, building smart is much more open and accepting - which is very encouraging, especially to Dion's point on the future merger of agendas and directions.
I think it's only a matter of time before Speckle offers IFC as one of its data models (or as a native platform endpoint?), because IFC has answers to many of the questions that Speckle is avoiding (i.e. how exactly should I describe X across all disciplines?). Similarly, it's also only a matter of time before IFC solves its data streaming problem and can flow through systems like Speckle easily. Maybe this day can come sooner if we put our heads together and bring the best of both worlds.
I would love to see, encourage, sponsor or all of the above a hackaton on this - to essentially see where we could go! Not sure this is a good idea, but it's the only thing that would give me the time to actually do it in a focused manner.
I haven't seen detached properties before in OO programming. (I'm not a professional programmer by any means!) Is this something unique to Speckle?
That's basically the spiel. I think our approach here is somewhat unique, but not necessarily original. From my previous research when setting up Speckle 2.0's core architecture, I couldn't find anything that fits our use case; happy to be proven wrong. Cunningham's Law etc., etc.
I'm bringing this because this is essentially our solution to "streaming" - decomposing and recomposing an object tree so it can be diffed, chunked, etc. and passed around efficiently. Applying this to an IFC model would be as simple as ensuring that the IFC class definitions are annotated with Speckle's conventions around detachability and chunkability [0], and basically that's it [1] - the sdk would take care of the rest (object hashing, diffing, streaming, etc.).
[0] http://speckle.guide/dev/decomposition.html
[1] After writing it that I realised there's another 'gotcha' around circular references that would need to be untangled. I might be projecting too far ahead in my head :)
I think one of the biggest advantages of streaming IFC is that it makes the streaming significantly less lossy for any IFC-aware application. So for example if I stream Blender to Revit, right now Revit only gets geometry, whereas if I stream IFC (potentially made using BlenderBIM Add-on, or FreeCAD, or WebIFC, etc) then I could get parametric Revit objects, smart cost-schedule or sequencing connected elements in Bexel or Synchro, a ggIFC graph in Rhino, smart 2D drawings in IFCJS, or even a BOM with parametric formulas in Excel.
For any Native IFC aware application, it goes even further and it would also allow for lossless round-trip streaming I suspect. Right now, that's only a handful, but it'll likely grow. For example, you could be using both FreeCAD and Blender and IFCJS to be all editing different portions of the IFC database.
@dimitrie what type of schedule are you thinking of? Who might help as the Speckle (or even better Speckle + Blender) expert? :)
Login or Register to reply.