IFC4 loses element colors compared to IFC2x3

[hwrdyen]

Describe the bug 📝

*The IFC2x3 and IFC4 files used to reproduce this issue were shared directly with antonio@thatopen.com

What happened:
I have two IFC files generated from the same Revit model:

• One exported as IFC2x3
• One exported as IFC4

When loading the generated fragment binaries in a self-built viewer using @thatopen/fragments:

• ✅ The IFC2x3 → .frag file renders all element colors correctly
• ❌ The IFC4 → .frag file renders only some elements correctly (e.g. wood beams), while most other elements appear dark grey
• Both files are processed and loaded using the same fragment pipeline and viewer code.

What I expect:

• The IFC4 export should display the same element colors as the IFC2x3 export, since both originate from the same Revit file.

What actually happens:

• In the IFC4 version of .frag, many elements lose their colors and fall back to the default dark grey material, while a subset of elements (e.g. wood beams) still retain their colors.

Assumption:

• When converting IFC4 to .frag, the structure changes compared to IFC2x3. For example, IFC4 uses a different structure and does not have the IFCPRESENTATIONSTYLEASSIGNMENT entity to directly link IFCMATERIAL with the corresponding IFCCOLOURRGB. As a result, the “color–element” relationship may not be fully preserved in .frag, causing the colors to default to grey.

Test:

• Both IFC4 and IFC2×3 files show the same color output at https://thatopen.github.io/engine_web-ifc/demo/:

• To rule out its related to my setup or configuration issues on my side, I also tested running the same file through engine_fragments example IFC importer locally, and observed the same missing color behavior there as well:

Screenshot Demo:

• IFC2x3 → .frag (correct color):

• IFC4 → .frag conversion (some loses colors and becomes dark grey):

Reproduction ▶️

No response

Steps to reproduce 🔢

No response

System Info 💻

System:
    OS: Linux 5.15 Ubuntu 24.04.2 LTS 24.04.2 LTS (Noble Numbat)
    CPU: (16) x64 Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz
    Memory: 13.25 GB / 15.50 GB
    Container: Yes
    Shell: 5.2.21 - /bin/bash
  Binaries:
    Node: 22.14.0 - /home/hwrdpvt/.nvm/versions/node/v22.14.0/bin/node
    Yarn: 4.9.2 - /home/hwrdpvt/.nvm/versions/node/v22.14.0/bin/yarn
    npm: 10.9.2 - /home/hwrdpvt/.nvm/versions/node/v22.14.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.

[hwrdyen]

Hey @agviegas,
Just wondering if there’s a rough ETA for resolving this issue. I completely understand if it’s not scheduled yet, this is just to help with planning on my side. Thank you!

[MiguelG97]

@hwrdyen I can not reproduce your issue. When I load the IFC4 file, the colors are correctly displayed for the Cladding Walls.

which version of web-ifc are you using?
I also noticed that the current version of web-ifc in the repository is 0.0.75, while the latest version published on npm is 0.0.74.
@beachtom @QuimMoya @agviegas Could you please help us releasing the 0.0.75 to npm? That could fix your issue

[hwrdyen]

Hey @MiguelG97,
Thank you for looking into this issue.
Currently, I'm using web-ifc 0.0.74 along with

"@thatopen/components": "^3.2.7",
"@thatopen/fragments": "^3.2.13",
"@thatopen/ui": "^3.2.4",

If web-ifc 0.0.75 updated the IfcImporter to handle more complex IFC4 structures, that could potentially resolve the issue.
Would you mind testing with web-ifc 0.0.74 on your end, or sharing your current setup that displays the correct colors, so I can compare it with mine?

[MiguelG97]

@hwrdyen I've cloned the web-ifc repository so I can use the latest changes from the wasm file. Thus my wasm path points to my local repository. In my tsconfig.app.json I have set it up like this:
"web-ifc": ["file:../forked_engine_web-ifc/dist"]

In your case, your wasm path should point to https://app.unpkg.com/web-ifc@0.0.74, as per documentation. Switch to version 0.0.75 once it becomes available.

import wasmUrl from "web-ifc/web-ifc.wasm?url";

  const components = new OBC.Components();
  const worlds = components.get(OBC.Worlds);
  const world = worlds.create<
    OBC.SimpleScene,
    OBC.SimpleCamera,
    OBC.SimpleRenderer
  >();
  world.scene = new OBC.SimpleScene(components);
  world.scene.setup();
  world.scene.three.background = null;

  world.renderer = new OBC.SimpleRenderer(components, container);
  world.camera = new OBC.SimpleCamera(components);
  world.camera.controls.setLookAt(58, 22, -25, 13, 0, 4.2); // convenient position for the model we will load

  components.init();


/**IFCIMPORTER */
  const serializer = new FRAGS.IfcImporter();
  const wasmFolder = wasmUrl.substring(0, wasmUrl.lastIndexOf("/") + 1);
  serializer.wasm = {
    absolute: true,
    path: wasmFolder,
  };
const ifcFile = await fetch(filePath);
  const ifcBuffer = await ifcFile.arrayBuffer();
  const ifcBytes = new Uint8Array(ifcBuffer);

  const buffer = await serializer.process({
    bytes: ifcBytes,
    progressCallback: (progress, data) => console.log(progress, data),
  });

 /**FRAGMENTS */
  const workerUrl = "/assets/workers/worker.mjs";
  const fragments = new FRAGS.FragmentsModels(workerUrl);
  world.camera.controls.addEventListener("rest", () => fragments.update(true));

  fragments.models.list.onItemSet.add(({ value: model }) => {
    model.useCamera(world.camera.three);
    world.scene.three.add(model.object);
    // At the end, you tell fragments to update so the model can be seen given
    // the initial camera position
    fragments.update(true);
  });
const model = await fragments.load(buffer, { modelId: fragmentId });

[agviegas]

Yep, solved in the latest version. Don't forget to use the latest web-ifc. Let us know otherwise!

[hwrdyen]

Hey @agviegas @MiguelG97 ,
While testing, I noticed that web-ifc v0.0.75 resolves some of the material color issues, but there may still be certain material–color relationships that are not being correctly captured.

I was able to recreate Miguel’s setup and point the WASM path to a local build of web-ifc v0.0.75. After upgrading to v0.0.75, the missing color issue on the front side of the house appears to be resolved. However, on the other side of the house, there are still some material color issues.

For example:

• IFC2x3 (correct color):

• IFC4 (missing wood color, and the triangular cladding wall should be light grey):

I was able to reproduce the same incorrect behaviour when running web-ifc v0.0.75 locally using the same two files:

• IFC2x3 (correct colors):

• IFC4 (missing colors):

Please let me know if you'd like me to provide additional info, Thank you!

[agviegas]

File privately shared here

[MiguelG97]

@hwrdyen Heads up: Even OpenIfcViewer encounters the same issue when rendering the materials on the inner side of the house. It might be an issue with the schema not preserving color information for that direction, as you pointed out.