How we made a BIM model viewer: ups, downs, and lessons

Hello, tekkix! If you opened this article, you are probably interested in developing BIM applications, specifically 3D model viewers. Perhaps you already have your own BIM application and have encountered difficulties, or you are just planning to start development and are gathering information. In any case, you have come to the right place.

I will tell you the story of how we created our 3D Viewer, what pitfalls we encountered along the way, and what lessons we learned. Let's go!

Choosing technology: own development vs open libraries

When we started our project a little over a year ago, we had two paths:

  1. Write our own engine from scratch (very expensive and requires a large team)

  2. 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 with no usage restrictions, and an active developer community.

How IFC.js works

IFC is a text file format formed according to an international standard, describing information about a 3D model: walls, their color, coordinates.

The process works like this:

  1. We pass the IFC file to the library

  2. The library converts it into a 3D model

  3. We get the ability to interact with this model

Under the hood, the following happens:

  • IFCWorker.js (JavaScript code in a web worker) launches a WebAssembly module

  • The WebAssembly module reads the IFC file

  • Based on the obtained data, Three.js objects are created to render the model

  • IFC.js provides a high-level API for working with the model

Loading 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 by Three.js. IFC.js provides a GLTF manager for converting IFC to GLTF.

The results are impressive: a model that used to open in 4-5 seconds now loads instantly. However, as always, gaining speed we lose in memory. GLTF files are several times larger than the original IFC.

Practical application

There are two main approaches to using the conversion mechanism:

  1. Server-side conversion (for ECM systems with a focus on data consistency)

  2. Client-side conversion with saving to IndexedDB (for offline viewers)

We chose the second option, as we were developing a viewer for foremen working on a construction site without the Internet.

Unexpected twist: project closure

And then the unexpected happened - the developers of IFC.js decided to completely close the project and release a new one. All support channels in Discord were deleted, the documentation disappeared.

It was a shock. I often saw libraries stop being supported, but to burn all bridges so abruptly - I encountered this for the first time.

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 BIM application development 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. So a new project under the new brand That Open Company was born.

Fortunately, we already knew the API of the old version well and continued to work according to the planned schedule. By the time we thought about switching to the new version, two major versions of the new project had already been released.

New version: @thatopen/components

The new library @thatopen/components (version 2.1.0 at the time of writing) has a number of advantages:

  1. Separation into two packages: @thatopen/components and @thatopen/components-front

  2. Ability to execute code both in the browser and on the server

  3. New data format - frag, allowing fast loading of models

  4. Kuller - optimization of rendering by removing invisible elements

  5. Model post-processing to improve visual quality

However, there are also disadvantages:

  1. Optimizations work unstably on complex models

  2. Serious backend refinement is required to support new optimizations

  3. Problems with element highlighting

  4. Post-processing can cause performance issues

Compromise solution: version 1.5.1

After careful analysis, we settled on version 1.5.1. It does not provide all the new optimizations, but:

  1. Supports working with fragments

  2. Element highlighting works correctly

  3. Post-processing works stably (30 FPS)

  4. Partially compatible with the latest versions of the library

This means that it will be easier to move to the latest version later when it becomes stable.


The image demonstrates the process of developing a BIM model viewer, including key moments of successes, failures, and lessons learned.

Architectural solutions

We use the MVVM pattern and strictly limit interaction with the library through interfaces. This allows us to be ready for future API updates.

The most important thing is to adhere to one simple principle: do not import library types anywhere except for the layer specifically designated for it.

This can guarantee you low coupling.

Community State

Unfortunately, community activity has significantly decreased after the closure of Discord chats. There is now an official forum, but responses to questions can take several days. At the time of writing, the library had only two technical specialists.

Developing a 3D Viewer for BIM is an exciting but challenging journey. We encountered unexpected twists, technical difficulties, and organizational changes. But we managed and gained valuable experience.

I hope our story helps you avoid some pitfalls in your project. Good luck with your development!

Author: Viktor Trumple, Lead Developer at LIIS.Formica

Comments