Towards the end of December, I had the opportunity to attend a webinar on two open source tools I knew almost nothing about: Speckle and IFC.js. The webinar was put together by a community called Agile BIM, which I also knew nothing about. However, what I do know for a fact is the importance of open source software development in any field, in which developers come together as a team to create software that is made freely available for possible modification and redistribution, allowing it to be developed even further. The technology that is developed with open source is often something that commercial software companies, whose business it is to develop proprietary software, cannot offer.
For the AEC industry, we do have organizations such as the Open Design Alliance and buildingSMART International working to promote openness and interoperability. (See the recent articles, “ODA Summit 2021,” and “An Overview of buildingSMART Standards.”) The IFC format has been well established for OpenBIM and is almost unanimously supported by all the leading AEC technology developers to allow their applications to exchange data with each other. So, what then are Speckle and IFC.js, what do they do, and why are they needed? The Agile BIM webinar on these two open source tools, which was held on Dec 15, 2021, gave me the opportunity to find out more about them.
Up first was IFC.js.
The idea behind IFC.js is to enable this by providing the source code and the documentation for IFC development for free, so that developers can at least have this starting point all set and ready to go. Of course, this presupposes that the IFC format is critical to any kind of BIM software development; and given how well-established it is — not to mention being the only open BIM standard that is available — this is a safe bet. However, it is very hard to implement. With a ready implementation that is entirely available for free, IFC.js eliminates the barrier for entry, making it a lot easier for smaller developers to jumpstart their software development.
Another example, shown in Figure 2, that was demonstrated in the webinar was a BIM + GIS app that was developed in less than 48 hours using IFC.js and another open-source library called Harp.gl. Then there was the example of a BIM viewer shown in Figure 3, with element selection, ambient occlusion, shadows, clipping places, camera animation, etc., created with only 74 lines of code. The IFC.js library has been implemented in such a way that the complexities of the code are hidden, allowing the required functionality to be easily referenced as required for the application that is being developed.
The second open source tool that was presented in the webinar was Speckle. Unlike IFC.js, which is not only free and open-source but is also developed collaboratively by individuals working in different companies, Speckle is actually the product of a company called Speckle Systems that has a few full-time employees, many of whom have previously worked in computational design in AEC firms known for cutting-edge technology development and implementation such as Arup, Buro Happold, and Foster+Partners. In fact, I first heard of Speckle in Issue 1113 of upFront.eZine where Peter Debney, senior consultant at Arup Digital Technology, wrote about why Arup had helped to produce Speckle as an open-source offering to tackle the problem of data transfer in construction.
Speckle is a collaboration and interoperability solution with a different approach than having a common file format like the IFC to exchange data between applications. Instead, it works by providing connectors to the most popular AEC applications, allowing them to exchange data in real time with other connected applications. Once a connector is installed for an application, it allows selected elements from the model to be captured as “streams,” which can then be received by any other application that has a Speckle connector. An example is shown in Figure 5. Currently, there are about 18 connectors, and more are in development, often in collaboration with the developer of the application. So, for example, Speckle is working with Graphisoft on an Archicad connector; a connector for Tekla Structures is also in the works.
In addition to its ability to enable AEC data exchange in real-time, what is key to note is that Speckle is not working with files as such. Instead, the data is being captured from an application through its Speckle connector as a “stream.” Speckle is a web-based application, and all of these captured steams are hosted online, as shown in Figure 6. Any stream can be sent to a receiving application that has a connector simply through a URL. Speckle keeps track of any modifications made to the elements captured in a stream and sends a notification about the updates in real-time to all those using that stream in other application.
The long-term vision for the product is to go beyond being a platform for end users to also being deployed by developers. Since the AEC data can be pushed in and out of Speckle as needed, it can enable development of tools that need to work with the data in the model such as embedded carbon calculations, quantity reports, costing, scheduling, and so on. With the AEC data now being “liberated” from proprietary files, other developers can access it and unlock the potential of BIM models without being required to develop APIs (application programming interfaces) to work with individual AEC applications. They just need to work with the data streams in Speckle, and the fact that it is free and open source lowers the barrier for entry, just as it does with IFC.js.
It is terrific to see so many people come together to pool their skills, interests, and resources to develop open source software solutions that would be useful to the industry at large, providing a much-needed counterpoint to commercially available software solutions. And by making them free, both Speckle and IFC.js allow smaller developers to jumpstart the development of their own solutions, which significantly reduces the barrier to entry and can encourage more innovation in the AEC technology industry.
Many of the contributors to these open source efforts do this as volunteers, making time for it in addition to their paid jobs. They are strong proponents of open source software, and they want to share the code they write. I found it very inspiring.
I did not get a chance to explore the Agile BIM community for this article, but I am intrigued by the idea of “agility” in BIM and how it can be done. I hope to explore it in a future article.
Lachmi Khemlani is founder and editor of AECbytes. She has a Ph.D. in Architecture from UC Berkeley, specializing in intelligent building modeling, and consults and writes on AEC technology. She can be reached at email@example.com.
Have comments or feedback on this article? Visit its AECbytes blog posting to share them with other readers or see what others have to say.
AECbytes content should not be reproduced on any other website, blog, print publication, or newsletter without permission.
This article capture the highlights of the 2021 Summit of the Open Design Alliance, including updates on its technologies such as CAD and 3D modeling, visualization, Revit and Navisworks toolkits, IFC and OpenBIM interoperability, point cloud support, cloud-based project management, and others.
A look at the different open standards for the AEC technology industry developed by buildingSMART, including IFC (Industry Foundation Classes), BCF (BIM Collaboration Format), MVD (Model View Definition), IDM (Information Delivery Manual), and bsDD (buildingSMART Data Dictionary).
This article provides a broad overview of the IFC model without delving too deeply into its technicalities, intended to provide a better understanding of it to the AEC practitioner interested in interoperability.
Han Shi, Head of BIM & Design Systems at Foster + Partners, describes how technology forms an integral part of the firm’s workflow, with several interdisciplinary groups involved in computational design, building physics, performance analysis, optimisation, fabrication, and interaction design.