Broken rendering of IFC files, and poor performance and freezes

[thnee]

Describe the bug 📝

I'm evaluating the library for the first time.
Not sure exactly what should be expected in terms of rendering, but this looks quite weird.
Am I doing something wrong?

• There's a large block on top of the roof?
• Colors are missing on almost all surfaces?
• Glass is opaque.
• The building is rendered below the grid on the vertical axis?
• It's running at 67% GPU utilization constantly, even when not loading any file, and not doing anything in the app.
• The app freezes completely when switching to orthographic camera.

Screenshot of your template app.

For reference, here is the same file being shown in the program BIMcollab Zoom.

Reproduction ▶️

No response

Steps to reproduce 🔢

• Run the demo app from https://github.com/ThatOpen/engine_templates locally using Node 24.6.0 on Ubuntu 24.04.
• Loadtest IFC file downloaded from https://github.com/youshengCode/IfcSampleFiles/blob/main/Ifc4_SampleHouse.ifc.
  (I've also tried a few other files, with similar problems).
• I've tested on both Firefox and Chrome, and it's exactly the same on both.

System Info 💻

System:
    OS: Linux 6.6 Ubuntu 24.04.3 LTS 24.04.3 LTS (Noble Numbat)
    CPU: (16) x64 AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics
    Memory: 11.57 GB / 14.96 GB
    Container: Yes
    Shell: 5.9 - /usr/bin/zsh
  Binaries:
    Node: 24.6.0 - /home/mattias/.local/share/mise/installs/node/24.6.0/bin/node
    npm: 11.5.1 - /home/mattias/.local/share/mise/installs/node/24.6.0/bin/npm

Used Package Manager 📦

npm

Error Trace/Logs 📃

No response

Validations ✅

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a repository issue and not a framework-specific issue. For example, if it's a THREE.js related bug, it should likely be reported to mrdoob/threejs instead.
• Check that this is a concrete bug. For Q&A join our Community.
• The provided reproduction is a minimal reproducible example of the bug.

[thnee]

Maybe related: ThatOpen/engine_web-ifc#1665

[agviegas]

Hey @thnee! To provide a more accurate answer, I'd need to check the file. You can send it privately to antonio@thatopen.com.

1. I'm guessing that block is an IFCSPACE (some viewers make it invisible).
2. Yes that's a known issue from web-ifc
3. The glass is opaque either because of the color issue of 2., or because the IFCSPACE behind it.
4. As shown in this tutorial, you can adjust the grid height.
5. That's because you are using the postproduction renderer, which by default renders a frame 60 times per second. We are currently thinking of making a "manual mode" that only renders when you make world.renderer.needsUpdate = true. That would probably solve the GPU consumption on idle.
6. That's a bug from the template, I've solved it right now and published a new version, you can try it out.

Cheers!

[thnee]

Hi, thanks for your reply!

I have to ask, what is the overall status of this project?
Is there some document describing which things are tested and known to be working correctly?
What versions of IFC are supported currently?

To provide a more accurate answer, I'd need to check the file.

This is the test file: https://github.com/youshengCode/IfcSampleFiles/blob/main/Ifc4_SampleHouse.ifc

That's a bug from the template, I've solved it right now and published a new version, you can try it out.

Thank you very much for that effort! However, it's still not working well for me.
It seems a bit better than before, now I'm able to switch to Orthographic camera.
But when switching back and forth a couple of times between Orthographic and Perspective, it still freezes.
And sometimes it throws the camera to a position really far away.

I'm guessing that block is an IFCSPACE (some viewers make it invisible).

I think so too. When enabling View > Spaces in BIMcollab Zoom, it shows a box in this location too.
However: It is not shown by default, and when it is enabled it is shown as a transparent box as opposed to opaque.

The way this is rendered in the ThatOpen demo app is simply unusable for any normal user.

Yes that's a known issue from web-ifc

Is this a regression bug issue, or a feature request issue?
I mean, was this working at some point, or was this never implemented in the first place?

As shown in this tutorial, you can adjust the grid height.

Sorry but can you elaborate on this?
What is the intended default behavior of the app/library?
My expectation would be that the app renders the grid at the model origin.

I also tested with these two files:
https://github.com/buildingSMART/Sample-Test-Files/blob/main/IFC%204.0.2.1%20(IFC%204)/PCERT-Sample-Scene/Building-Architecture.ifc
https://github.com/buildingSMART/Sample-Test-Files/blob/main/IFC%204.3.2.0%20(IFC4X3_ADD2)/PCERT-Sample-Scene/Building-Architecture.ifc

These are two almost identical files, but with different IFC versions.
For the 4.3.2.0 version, the grid appears to be in the correct position.
For the 4.0.2.1 version, the grid appears to be in the wrong position, leaving a gap under the house.

In BIMcollab Zoom, it shows both of these files to have the model origin in the same location, at the bottom of the reference cube outside the building.

[agviegas]

No problem!

The status of this project is:

• very actively maintained (we work on this every day)
• we (that open company) are the creator and main maintainer
• we make quarterly releases, and issue checking is stational. These days we are trimming issues off.
• we support all current and future official versions of IFC STEP (we have a parser generator in web-ifc).
• we have an official documentation here with api refs an tutorials.
• this project has a big exploration part. We are not solving known problems. We don't know how this should look like. Geometry is hard, and BIM is a hell of edge cases. We try and fix things as we go. So only time and use can prove feature robustness. Everything that belongs to the library should work. Otherwise, you can open an issue, and we'll take a look as soon as we can.

Regarding the issues: you can create separate topics for the camera topic belongs to another issue, the IFC SPACE default visibility in the template.

Regarding the web-ifc color issue: not sure if the color issue is a regression. We'll check it out these days.

Regarding the grid: the grid always is in the origin by default. What changes is the absolute position of both models. By default, we bring the BIM models to the origin and store that transformation as a matrix to coordinate them with other models. We do this to avoid stumbling upon nummerical stability issues in federated models. You can configure that in the settings of the ifc loader / ifc importer by setting COORDINATE_TO_ORIGIN = false.

The general phylosophy of this library is finding a middle point between being opinionated and flexibility. We make defaults of what we see work for most use cases and leave the rest open to configure (e.g. the grid position).

You could tell us that you are not willing to write some extra lines of code on your end (e.g. to align the grid with the AABB.min of your BIM model) because the library should do this automatically, and we could indeed do it. The problem is that your use case doesn't necessarily match with others, so when we give things in a certain way, other users will suffer. I've seen happen this many times. That said, you are free to propose changes and we will happily make them if they make sense.

I would recommend you to organize all these things into separated issues so that we can address them individually. Cheers!

[thnee]

Thank you kindly for your thorough response!
And thank you for pointing out the COORDINATE_TO_ORIGIN setting! I hadn't seen that one yet.
When setting it to false, it seems to render the grid at the model origin.

As for the surface colors/materials, I'm not entirely sure what's happening there.
I am getting different results, sometimes they are rendered, sometimes they are not.
Maybe it has to do with using OBC.SimpleRenderer vs OBF.PostproductionRenderer.

Apologies for compounding too many things in one issue.

Let's limit the scope of this issue to the following:
IFC spaces are (sometimes?) rendered as an opaque white block.

The problem occurs with this test file: https://github.com/youshengCode/IfcSampleFiles/blob/main/Ifc4_SampleHouse.ifc

When I test in this demo app: https://thatopen.github.io/engine_web-ifc/demo/
The result looks pretty good. Nothing looks broken.

When I test in this demo app: https://github.com/ThatOpen/engine_templates
There is a white opaque block as shown in the screenshot.

[agviegas]

Thanks for the reply, no worries!
Yes, we hide the spaces in the web-ifc demo, while we don't in the template. Most apps override the appearance of IFC spaces because users don't want to see them opaque, although that's the way the are defined in the IFC files.

I've created a new setting: ifcSerializer.geometryProcessSettings.forceTransparentSpaces, which is true by default. So if you update the version of fragments to @thatopen/fragments@3.2.6 or later, the space should be transparent by default. I think this is better than hiding it, as the user might think there are no spaces in the model:

I'm closing this, as this should solve the ifc default space opacity issue. Feel free to ping me if I missed anything.

PD: As for the performance issue: postproduction is indeed expensive, but I've just published a manual mode. You can check out this issue. It might require a bit of work to make it work in the template as a setting. Feel free to open an issue there if you think we should do it and I'll take care. Cheers!