ups, downs and lessons
Choice of technology: own development vs open libraries
When we started our project a little over a year ago, we had two options:
Write your own engine from scratch (very expensive and requires a large team)
Use open source libraries
We chose the second option, and our favorite was the IFC.js library. At that time, it was (and remains) the most productive, had an MIT license without restrictions on use and an active developer community.
How IFC.js works
IFC are text files generated according to the international standard that describe information about the 3D model: walls, their color, coordinates.
The work process looks like this:
We give the library an IFC file
The library converts it into a 3D model
We get the opportunity to interact with this model
The following happens under the hood:
IFCWorker.js (JavaScript code in the web worker) runs the WebAssembly module
WebAssembly module reads IFC file
Based on the received data, Three.js objects are created to render the model
IFC.js provides a high-level API for working with the model
Load optimization: IFC vs GLTF
Loading large IFC files can take a long time. But there is a way to speed it up – converting to GLTF format.
GLTF is a kind of JPEG in the 3D world. It is widely supported, including Three.js. IFC.js provides a GLTF manager for converting IFC to GLTF.
The results are impressive: a model that took 4-5 seconds to open now loads instantly. However, as always, what we gain in speed we lose in memory. GLTF files are several times larger in size than the original IFC.
Practical Application
There are two main approaches to using the conversion mechanism:
Server conversion (for ODS systems with an emphasis on data consistency)
Client-side conversion with saving to IndexedDB (for offline viewers)
We chose the second option because we were developing a viewer for foremen working on a construction site without the Internet.
Unexpected turn: project closure
And then the unexpected happened – the IFC.js developers decided to completely close the project and release a new one. All support channels on Discord have been deleted and documentation has disappeared.
It was a shock. I have often seen libraries cease to be supported, but to burn all bridges so abruptly – this is the first time I have encountered such a thing.
The main ideologist of the library, Antonio Gonzalez Viegas, an architect with 10 years of experience who independently mastered programming, pursued the goal of making the development of BIM applications accessible to everyone. The goal was achieved, but the existing code base did not allow for scaling. And he decided to rewrite everything from scratch. Thus a new project was released under the new brand That Open Company.
Fortunately, we already knew the old version's API well and continued working as planned. By the time we started thinking about switching to a new version, two major versions of the new project had already been released.
New version: @thatopen/components
The new @thatopen/components library (version 2.1.0 at the time of writing) has a number of advantages:
Split into two packages: @thatopen/components and @thatopen/components-front
Ability to execute code both in the browser and on the server
New data format – frag, allowing quick loading of models
Cooler – optimize rendering by removing invisible elements
Post-processing of the model to improve visual quality
However, there are also disadvantages:
Optimizations are unstable on complex models
The backend needs major improvements to support new optimizations
Problems with highlighting elements
Post-processing can cause performance issues
Compromise solution: version 1.5.1
After careful analysis, we settled on version 1.5.1. It doesn't provide all the new optimizations, but:
Supports working with fragments
Illumination of elements works correctly
Post-processing works stably (30 FPS)
Partially compatible with the latest versions of the library
This means that later it will be easier to move to the latest version when it becomes stable.
Architectural solutions
We use the MVVM pattern and strictly limit interaction with the library through interfaces. This allows us to be prepared for future API updates.
The most important thing is to adhere to one simple principle: do not import library types anywhere other than the layer specifically designated for it.
This can guarantee you low grip.
State of the Community
Unfortunately, community activity has decreased significantly since Discord chats were closed. There is now an official forum, but responses to questions may take several days. At the time of writing, the library only had two technical staff.
Developing a 3D Viewer for BIM is an exciting but challenging journey. We faced unexpected turns, technical difficulties and organizational changes. But we managed it and gained valuable experience.
I hope our story will help you avoid some pitfalls in your project. Good luck with your development!
Author: Victor Trumpel, leading developer of LIIS.Formica
