Insight
Murray:
I got you to join me and you are basically the chief evangelist for Open BIM and open source. Can you tell me a bit about that?
Dion:
I've been involved with open source for a very long time. It's been well over a decade and many different fields of open source. Looking at open source and desktop computing, things like Linux desktop environments, looking at open source from the creative applications like Blender (https://www.blender.org/) and Gimp (https://www.gimp.org/) and so on.
I was trained as an architect and naturally when you try to combine open source and the AEC industry there's only a few things which intersect, one of those things is an open data standard known as open bim where we say, “Okay, let's, let's go and standardize the way data is structured.”
Because of that standardization, you gain interoperability, you gain the ability to build systems independently of one another. You get standardization. You get the freedom of being able to own your own data rather than kind of renting the data based on the whims of somebody else who structures your data. That's very conducive to open source software.
Murray:
You mentioned an open data standard and open bim. How is that different from IFC?
Dion:
It's the same. It's good to distinguish between open source and open BIM. If you talk about data, that's what open is, it's about the data.
It's not about the tools used to interact with the data. It's about the data itself. And Open BIM is an open data standard applied to BIM, the way you digitally describe our buildings. IFC is one out of many open data standards that apply to BIM. It's not the only one. There's others out there like bomb. There's the speckle object model. There's hyper elements, there's brick schema, there's the haystack and so on. There's a lot out there. But IFC stands out because the Le re are a few things which make it unique compared to the others. That's why I tend to interact with IFC quite a bit more than the alternatives.
Murray:
What are those things that are unique? Why is IFC better than the alternatives? There seem to be an awful lot of alternatives over the last year or two. Whereas IFC, although it has had its problems for many years, it's got age on its side. Maybe it's ironed out, a few of its creases?
Dion:
I don’t think you can say that it's better or worse but you can say whether it's more appropriate for a certain task. One of the big differences in IFC is that it's an ISO standard and that immediately makes IFC a very good contender for certain things like when governments want to require BIM data in their contracts. For example, here in Australia, it's a legal requirement that you cannot specify proprietary data. So they go, “Hey, it's ISO standard. Tick.” And that's why the Australian government tends to request a lot of IFC information. So, it makes it more appropriate for that use case. Being an ISO standard also means there's a certain rigor in the process. For example, the process required to make sure that it doesn't overlap with other standards or it integrates with other standards. IFC has integration with things like gbXML (https://www.gbxml.org/) or X 3D and now with Gltf. There's a lot of places where IFC doesn't recreate the wheel and plays nice with existing standards. That's one of the main differences is that it's ISO.
Another huge difference is that IFC is, I think, the only one which had the bravery to tackle the entire industry. Most of these open data schemas only tackle a portion of our industry like gbXML. It focuses on energy modeling, for example. A bricks schema focuses on building sensors during BMS operations phase. Outside that it just stops.
Murray:
Thinking about IFC, it's actually worthwhile to think of its limits as well. While I completely agree with you that there's energy data standards, as I have slowly researched IFC, one thing to realize is that it's specifically about buildings. IFC is huge, you can describe almost anything in a building in IFC, but these days I get the people asking about building models or 3D models, which are metaverse type things, or which are completely digital and never gonna be physical. That's not actually what IFC is for. It is quite interesting to say that while IFC encompasses the AEC industry fantastically, it only encompasses the AEC industry. With digital standards these days, like Nvidia, they’re incorporating IFC into their USD standard.That's where I would say USD is much broader than IFC. But IFC is obviously broader than the energy modeling standards you mentioned.
Murray:
IFC is designed for the physical built environment, and that's more than buildings. That includes infrastructure as well, for example. But you're right that it seems to be focusing on the physical world and the semantics that the physical world requires.
Now, I'm not an expert on metaverse, so, if there are certain semantics that the Metaverse requires I'm pretty sure that's not the top priority list for the IFC schema. I wouldn't be surprised if it was less than appropriate. USD, however, is definitely not designed to describe the physical world from an AEC perspective. It has a significantly smaller scope. It’s designed more for the CG world. For example, geometry. IFC has parametric definitions for most of the common profile definitions in our industry. Things like I-beams, angles, and RHS and so on. Whereas USD, it doesn't have any of that.
Immediately that makes it completely inappropriate for things like structural analysis or just any sort of structural modeling or most buildings. IFC is definitely catered for the physical world. I can't speak much about metaverse.
Murray:
It's nice for us to be able to focus on that. We're focusing on real, physical buildings and not push it around too far. You spoke a bit about Open BIM and what that means and the fact that by getting ourselves out of proprietary data, what we're actually trying to do is communicate better.
I was speaking to Patrick Chopson from Cove.tool. For Cove.tool who are energy modeling kind of softwares, it's transferring that building data between a growing number of startup companies which provide various niches, whether it's energy modeling or reality capture. There's this web based ecosystem of more and more little companies, which aren't Autodesk, and who needs to speak to each other. We need to speak across apps more and more often. This is where IFC suddenly becomes way better than anything that Autodesk could offer. Is that so?
Dion:
I'd say so. If you are a web developer, the analogy I'd like to use, is that you want to deliver your application across everybody's web browsers. So, you need two things. You'll need a language, and that could be html, css, JavaScript. And you'll need a protocol to transfer that language to them like http. That means, if you comply with those two open data standards for html JavaScript, and the open protocol standard for http, then, anybody with a web browser will be able to consume your content in a standardized way.
That's the beauty of the web. It took a long time for the web to get to where it is. If you remember the early days of the web when you had things that worked best in Internet Explorer. It's kind of where our industry is at right now for AEC. Any developer coming to AEC they say, “Okay, what's the language of digital buildings?”
It's very hard. The answers which people give are typically things like IFC or gbxml or brick schema. These open data standards that say, “Here are the languages of digital buildings which language you choose depends on your use case.” The one which encompasses most disciplines is definitely IFC.
Then, you just look at the suite of tools out there. The majority of BIM tools, at the very minimum, have an import/export IFC feature. The quality varies but, at the very least, they have that. You can't say the same for something project haystack, for example.
After they give you that advice, you'll go pick whichever digital language you prefer. The next question is “What's the protocol?” That's another really interesting debate, which our industry is not yet at. There's some really interesting solutions like Speckle, which offers essentially a protocol with a very lightweight schema.
I like to think of them as solving the problem of interoperability from the other end. Protocol first rather than schema first. Once you have both of those, you're right. It does let people speak to each other a lot better.
Murray:
I've never thought of how we communicate in terms of both schema and what speckle’s doing. Every time I've looked inside an IFC, I can read IFC badly, as it takes documents or inside something like BlenderBIM. But that protocol, that's where either Speckle or IFC.js or IFC Open Shell comes in. Is that correct?
Dion:
I guess the protocol is, “How do you transfer that?” In an efficient manner, you don't wanna grab, everything out of a digital building. Think of how the GIS industry works. In theory you could have a data set of the entire world. But you wouldn't need the entire world. Open Street Maps has a data set of the entire world, but, you'd only extract portions of it that you're interested in. Similarly, you'd have a digital building and you'd only extract portions of it that you're interested in and you'd make little edits of those things that you're interested in with whatever tools you like. Then change that back in this underlying dataset. That's where the protocol comes in. How do you extract just what you're interested in, change just what you're interested in, using whatever tool you like, and then stream it back? Speckle has done an incredible work of engineering in solving that. Not with the IFC schema, in fact, with any generic schema.
IFC hasn't solved it, but IFC has put in place a strategy to enable it to be solved in the future. Don't forget, IFC was back in the 1990s. What IFC has done is that it has separated the IFC schema, which says, “Here's how we describe objects in our built environment with the serialization method.” That serialization method is the magic sauce of how to record it in a way that computers can understand and transfer it. For example, that dot IFC file is just one possible way of storing and reading IFC. Json if you want to go server to server or xml server to server is also possible.
But serialization is also just one part of the story. Sure you can, you can store it in a language which is easier to stream or something like that but how do you determine how best to divide up the schema? For example, and this is a very difficult question, if you download a wall, let's say you just wanna edit some walls. You're an architect. You edit that wall, how do you ensure that that wall has the appropriate downstream impacts on whatever that relies on it? That wall would have an impact on a space boundary for energy simulation. It would have an impact on a plane for a structural surface member for a structural analysis.It would have an impact on a calculative quantity, which would have an impact on a cost. Which would have an impact on a construction schedule. Which would have an impact on your LCA analysis. All these things are interrelated. And IFC has developed, over decades, the way of describing these relationships.
The next problem is “how do you chop it up?”
Murray:
So, how do you chop it up? But first of all, how do you ensure that all of those downstream impacts are gonna be recorded? There are so many complications or so many things that a wall will affect. A wall will affect the area of your room. The energy modeling inside that room to get all of them to work together. It's not a simple parent/child relationship. I saw somebody describe our industry as spatial computing. When we are talking about digital versions of our building, we're not necessarily talking about a parent/child relationship of all of the elements anymore. Rather, we're talking about three dimensional relationships where a wall relates to a floor or a room by proximity or by geometry.
Dion:
Not actually. It's not geometric primarily, I would say. So IFC for example, is a little bit more complex than parent/children. Most relationships do have a suggested hierarchy. Like, “This is the parent, this is the child” but in some places, some relationships don't have that hierarchy.
This is just the relationship. It's two way or there is no directionality. You can think of an IFC database and most of those databases as a graph. It's a network of many nodes which have edges to one another. The question is, how do you split it up into meaningful subgraphs and how do you ensure that you have these well-defined entry points into these subgraphs and the ability to mark other sub graphs as potentially stale so that somebody can say, “Hey, something has changed here, which could have triggered my domain. Maybe I should update it.” For example, when that wall moves or changes, it triggers another sub graph, let's say, the energy modeling sub graph that says, “Hey, maybe these space boundaries need to be refreshed and recalculated and re-simulated and so on.”
That's a big part of what the Blender BIM add-on is doing. A lot of this goes unnoticed. That's actually a huge challenge that we're solving into how to chunk these subgraphs into meaningful disciplines. It's not an insurmountable goal. It's difficult and that's why IFC has taken so long and it's significantly harder than a home brew solution of a wall of the box. It's not insurmountable because you can actually count these relationships. IFC has refined them over many years. It's not perfect but there's a lot of really smart thinking behind of it and you can chunk it.
The BlenderBIM add-on has chunked IFC, so far, into 40 modules. We said there are 40 distinct subgraphs here. Some are more related, some are less related, and this has got nothing to do with geometry. You can do an entire building without geometry and hese relationships are agnostic geometry. Some of them will tell you if they're related to geometry but the geometry aspect is completely optional.
Murray:
I've always really liked that optional geometry kind of mentality of thinking about buildings, which you get with IFC. Let’s talk about BlenderBIM (https://blenderbim.org/) for a minute. Blender Bim, your amazing product. You were just saying that you've chunked IFC into 40 different modules, subgraphs, if you will. Can you explain that?
Dion:
One example might be classification systems. The ability for an element or a task or something to be classified into one of these classification hierarchies like Omniclass, Uniclass and so on.
That's one clearly contained set of concepts in IFC and you can quite easily make a call. If you change something, will it impact classification or not? There's a pretty easy delineation there. Nothing's perfect, of course, but there's a good delineation there.
You could in theory, and we have, cuz we have chunked it up that way, you could build an IFC editor that all it does is deal with classifications. It's an app that all it does is filter my classifications, color code by classifications, bulk classifications with AI or catch anomalies. It can just be your IFC model classifier tool. It doesn't need to understand any other aspect of IFC. It doesn't need to care about geometry and all the complexities of that doesn't need to care about energy analysis, costing, scheduling. It can just deal with classification by itself and not have any data loss or downstream impacts elsewhere in the graph.
Murray:
With Blender BIM, the one example that I know of where you can create IFC natively without creating IFC in something, without creating building information in something and then exporting it to IFC. Blender BIM is the only place that I've seen creating IFC natively. It's not just about geometry, right? The thing is that BIM quickly moves on from a wall plus whatever the properties of the wall are and quickly moves to the high level relationships. Before walls, making a room or the volume of that room for energy modeling. What does Blender BIM do, aside from let me create a wall and add a material and a property to it. Aside from creating geometry with a few parameters?
Dion:
I think it does everything. In short, we do nearly everything. In fact, we were able to do non geometric relationships earlier than we could draw a wall and that comes as a surprise to many people.
We were able to say that a wall belongs somewhere, had a classification system, included as part of a cost schedule and, parametric sort of formulas calculating its costs. We were able to do that far before we had a real a nice wall drawing tool and, in some ways, that's the right way to go about it. You have to first, truly appreciate how your wall is to be consumed by others before you can build a wall drawing tool.
Nowadays, what I've learned during that process, I could probably do it the other way around but for my first foray into it, that would be the way I go. You can definitely do a lot more than just draw some geometry and assign some metadata. This is a common way people understand BIM. They say BIM is geometry plus metadata, some keys and some values. The more you dig into IFC you realize it's far more than that.
For example, a wall has a type and. It'd have an architectural construction made out of various layers. Those layers would have certain thicknesses of it. Immediately, it's not just a key value pair because you now have a wall related to a type and it's the type which has all of the data, not the wall itself. The wall inherits data through the type. If the type has X layers and the wall itself must inherit from the type, you've got two objects now. The type would then have layers, but the layers need to be made out of materials. Again, it's no longer just key values. It's related to material objects. You can see how it starts building up quite a set of relationships.
Murray:
We've been hearing it for years, it's a common kind of phrase to say that BIM is not Revit or Revit is not bim, whichever way around you want. I was in architecture for a good 15 years or so but recently I've been only doing scan BIM. What scan to BIM tends to be, traditionally, is we laser scan something. We import it into whichever software (and it's always Revit). Then we trace over the Revit model or we trace over the point cloud in Revit and give those walls whatever parametric data you want. It’s just a material and a thickness, probably and some kind of geometry. I would love to skip the Revit step and go, “Well, what do I need to know? I'm starting with a point cloud.” There are some people out there who would take the point cloud, just select the number of points which encompass that wall, add the metadata and be done with it.
You have a point cloud, and that's close enough to geometry. All actually want is a point on the two points on the floor, you can draw the corners of the wall and you don't need an extruded rectangle. Maybe that's how we are all going to escape from Revit, if that’s what we’re trying to communicate then the geometry seems to fall away a little bit.
Dion:
Absolutely. You made a comment there about how point cloud is almost geometry. I mean, a point cloud is geometry. There's nothing saying that your wall needs to be an extruded rectangle. Your wall could be a mesh or your wall could just be points. Your wall could be a photograph. There's nothing, at all, that says that it needs to follow a particular geometric paradigm. Depending on which discipline you're in, you will need different paradigms. Scan to BIM is an excellent one of telling people, “Actually, no, the extruded model doesn't work. It's actually worse. You're actually getting worse quality information.”
Murray:
You're definitely losing information by trying to make the wall kind of offset settable basically. We're constantly dumbing it down, which we shouldn't be doing.
Dion:
There's really good research done by Thomas Krijnen on assigning IFC classifications and data to point cloud geometry, segmentation of it, how to store that efficiently, and how to extract that efficiently.
There's a lot of good research done on that and I think there was also some BuildingSmart award winners in the past which focused on Scan to BIM and how to do that. It's not my area of expertise but I know it's definitely being looked at.
Murray:
Actually, it becomes quite interesting with the work of Florent Poux in France. He's semantically segmenting the point clouds, which, when it works, is beautiful. You just run the point cloud through python and get the wall, or toilets, or a table automatically to you rather than having a human decide. If you can machine learn the point cloud, the segmentation of the point cloud, then you solve a whole lot of input problems as you're going along. That's not necessarily going anywhere.
Dion:
Definitely. There's some brainstorming happening on the OSArch forums (https://community.osarch.org/) recently about somebody doing what you're doing. They're talking about how to drop this very high resolution mesh into IFC, which IFC was not designed for. We were talking about various solutions. One possibility is that you could have the best of both worlds. You could have your extruded, kind of solid, but then you would have a texture map, for example, which would be an XYZ displacement, which would reflect the true point value so you get that, kind of, really lightweight, approximate model. Then if you really wanted the true detail, you could select an area and the textures can scale very, very well. Another example might be whether it's machine learning or really just fast, rapid modeling, a CG amateur could do it, of just modeling simple planes. Saying, “This is the rough plane of it, and therefore, at the very least, count the number of walls, number of objects.” Just put a box, run that object and you say, “done.” Anybody who wants more information about that box or single plane, a 2D plane, not even with thickness, it then does an offset search with a certain loci around those areas to pull in the point clouds from the point cloud scan.
If you think about dilapidation studies or existing buildings, it's actually very little work if you're not interested in this kind of pristine, parametric BIM model. It isn't, anyway. You could just scan it and then get somebody to just walk around, do simple plane modeling or even just an fm, you just list the objects in the room and a single point, a little xyz coordinate and that's it. It's super lightweight and you get a lot of information out of it. All these old buildings where the paper drawings are long gone, the Revit files don't exist anymore. Of course, you could very quickly get a super high quality IFC. Even more accurate than anything you could get modeling from scratch from.
Murray:
This is where I would love to be pushing things. I guess what you've gotta do then is sell yourself or sell your products to everybody who wants the Revit model which they can work off.
Even though creating the IFC, like you've been saying, is better. It becomes an education problem. It becomes a problem of, “I need to hand over information or I need to communicate information about the building and in my case it's reality captured.” but you could be anywhere in the process.
“I need to communicate that information about the building. And I need to do it in a way that's different to either the typical Revit way of doing it or the typical AutoCAD, PDF way of doing it. We're still using new processes, which requires education of people down the line, doesn't it?
Dion:
Absolutely. I completely agree.
