Wall not rendered

[mctomac]

Describe the bug 📝

When Im loading my IFC file some of the walls are not being rendered.
It appears when using OBC 2+. In older version (1.5.1) it's displayed properly.
See the screenshot attached and IFC file that i've used (zipped, as github doesnt allow attaching pure ifc).
arch.zip

In the place marked with arrow there should be a IFCWALLSTANDARDCASE element with global ID 1uwjPQk3DDwRinyWJDQS9r with window inside. You can see the window rendered, but not the wall.

Reproduction ▶️

No response

Steps to reproduce 🔢

Load the IFC attached in the bug description (zipped IFC file) like this:

async function loadIfc(viewer: PkIfcViewer) {
  viewer.updateLoadingProgress("viewer_loading");
  const fragmentIfcLoader = viewer.components.get(OBC.IfcLoader);
  await fragmentIfcLoader.setup();
  fragmentIfcLoader.settings.webIfc.COORDINATE_TO_ORIGIN = true;
  viewer.updateLoadingProgress("downloading");
  const file = await fetch(viewer.url);
  viewer.updateLoadingProgress("buffering");
  const data = await file.arrayBuffer();
  const buffer = new Uint8Array(data);
  viewer.updateLoadingProgress("proccessing");
  const model = await fragmentIfcLoader.load(buffer);
  viewer.updateLoadingProgress("completed");
  viewer.world.scene.three.add(model);
  viewer.models.push(model);
}

The wall IFCWALLSTANDARDCASE element with global ID 1uwjPQk3DDwRinyWJDQS9r is missing.
Also 0ss0V06rz5vwTm8SnLzNeO at level -1 is not displayed at all, even though the door is.

System Info 💻

libs versions:
"@thatopen/components": "^2.0.21",
"@thatopen/components-front": "^2.0.20",
"@thatopen/fragments": "^2.0.5",

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.

[agviegas]

This is due to a bug in the core booleans. Transferring this issue to the core repo!

[maidi29]

Probably related to #877. I also provided a minimal ifc that produces this error there

[maidi29]

@agviegas what did you mean with the "core booleans"? Do you have more information here or where the issue could be? Currently it's blocking us a little bit so we will maybe try to look deeper into the repo and try to find the issue ourselves 🕵️‍♀️

[agviegas]

Hey @maidi29 I mean that the problem comes from the part of the geometry engine of our library in charge of performing boolean operations. Booleans is perhaps the most complex problem in our library. Are you familiar with C++ and computational geometry? If so, @QuimMoya can maybe introduce you to the problem and see if you can help us solve it. Otherwise, we'll take a look asap!

[maidi29]

Hey @agviegas,
sadly I myself don't have any experience with C++ at all, so I think I wouldn't be any help... My colleague has some more experience but probably diving into these codebases would take him too much time that he doesn't have 😿 I wish we could do more here to support you!
As we experience this in many of our buildings, it would be super awesome if you could try to solve this. Probably it's not the case but if there is still anything we could do (e.g. send more example ifc files, testing,...) then just hit me up ☺️

[SimonSchneider]

Adding to this issue that I also have found models where certain walls fail to render.

I've tracked it to the web-ifc package from here:

linkToCode

export class IfcGeometryTiler extends Component implements Disposable {
  ....
  private getGeometry(webIfc: WEBIFC.IfcAPI, id: number) {
    const geometry = webIfc.GetGeometry(0, id);

    const index = webIfc.GetIndexArray(
      geometry.GetIndexData(),
      geometry.GetIndexDataSize(),
    ) as Uint32Array;
   ...

When getting certain geometries the IfcGeometry is empty and all the calculated values (position, boundingBox, etc.) are NaN or Inf. An example geometry from the attached IFC that fails is the geometry with id 7098 which is a IFCBUILDINGELEMENTPART.

The attached ifc file is a small example with very few elements of which half of them work and the other half doesn't.
example.ifc.gz

[agviegas]

@SimonSchneider probably the problem is not that elements "fail to render", but that they "fail to be geometrically generated". The process from an IFC file to your screen is:

IFC explicit geometry (extrusions, curves, etc) > web-ifc geometry engine converts it to triangles > we generate a three.js mesh > you see it on your screen

We are failing in step 2. If you want to help us investigate this issue, you'll need to dive into the C++ & WebAssembly part of the libraries.

If you want to see a "raw" output of our core, you can test it here. If something renders in that page but doesn't render in components, let me know and I'll take a look. Otherwise, we'll try to solve this problem on the core asap!

[SimonSchneider]

Thank you @agviegas, thanks for the explanation, that's good to know!
I'll test it in the linked page but I'm inclined to believe you as my findings also show that the geometry to be written to the fragment files is empty in my investigations.

It was a while since I sat with C++ and I've not worked with graphics programming before so I'm unsure how much help I'll be on that end though.

Thanks for getting back to me

[SimonSchneider]

Can confirm that raw output in the link you sent doesn't show the missing object in my example IFC either.

[QuimMoya]

The latest updates appear to have resolved this issue.

[QuimMoya]

Now this issue is solved

[MarcusAndreasSvensson]

While there are great improvements on most of the models I'm working with between web-ifc 0.0.57 and 0.0.59, I can say that this issue still might persist, but on a smaller scale. With that siad, please correct me if I'm just using the incorrect version.

I tried both my viewer (right) and the link @agviegas provided above (left), and also Forge viewer, to verify the model isn't the problem.

As you can see, left and right performs differently, but none of them are perfect. This is one of a few examples in this model.

[QuimMoya]

Oh, this is a new model?

Maybe you can share it?

[MarcusAndreasSvensson]

Unfortunately I am not allowed to.

The following is from a model that I am allowed to share, but this looks more like flipped normals and I'm not sure it's the same issue.

Do you want this model?

More than that I will be on the lookout for models that I am allowed to share with this issue.

[QuimMoya]

I think it’s better to look for models that have similar issues to the ones you're experiencing with the model you showed us.

Thank you for your effort. Trying to solve issues is difficult with the models, but impossible without them. :)

[agviegas]

@MarcusAndreasSvensson in case it helps, we are also happy to sign an NDA. We've done it in the past with other companies.

Otherwise, we might add a feature to the library that allow to "split down" IFCs, so that you could extract that specific element as a super small IFC and send it to us. Would that help?

[MarcusAndreasSvensson]

@agviegas Unfortunately there are too many parties involved in these files to feasibly sign an NDA.

However it would be sufficient for us if you guys provided a tool where we could decimate and isolate these files to the problem area.

[agviegas]

Got it @MarcusAndreasSvensson! If you create a feature request here, we'll do it asap