Zero length geometry

[andersskeiefocus]

Describe the bug 📝

At conversion from IFC to frag (version 3.3.6) I am sometimes getting these console messages

Fragments: Zero length geometry: 92351

So going into the file to examine I see that my file at this point is:

#92351=IFCPOLYLINE((#4,#92350));

and

#92350=IFCCARTESIANPOINT((3030.,0.));

#4=IFCCARTESIANPOINT((0.,0.));

As I understand my data there I have one point at 3030, 0 and the other at 0,0. Hence the geometry length of that 2D line should be 3030. Is this actually a bug in the ifc to frag conversion or have I misunderstood something?

Looking into the frag engine code I see that this occurs at

const buffers = this.getGeometryBuffers(modelID, geometryRef);
if (buffers === null) {
  console.log(`Fragments: Zero length geometry: ${geometryData.id}`);
  element.geometries.pop();
  this._problematicGeometries.add(geometryData.id);
  return;
}

File lies at https://people.thatopen.com/c/help-us-do-better/zero-length-geometry.

Reproduction ▶️

No response

Steps to reproduce 🔢

No response

System Info 💻

Windows
    "@angular/animations": "^19.2.18",
    "@angular/cdk": "^19.2.18",
    "@angular/common": "^19.2.18",
    "@angular/compiler": "^19.2.18",
    "@angular/core": "^19.2.18",
    "@angular/elements": "^19.2.18",
    "@angular/forms": "^19.2.18",
    "@angular/material": "^19.2.18",
    "@angular/platform-browser": "^19.2.18",
    "@angular/platform-browser-dynamic": "^19.2.18",
    "@angular/router": "^19.2.18",
    "@azure/storage-blob": "^12.17.0",
    "@microsoft/signalr": "^8.0.0",
    "@ngx-translate/core": "^15.0.0",
    "@ngx-translate/http-loader": "^8.0.0",
    "@thatopen/components": "^3.3.0",
    "@thatopen/components-front": "^3.3.0",
    "@thatopen/fragments": "^3.3.0",
    "@thatopen/ui": "^3.3.0",
    "@thatopen/ui-obc": "^3.3.0",
    "angular-resizable-element": "^7.0.2",
    "bootstrap": "^5.3.3",
    "camera-controls": "^1.37.3",
    "concat": "^1.0.3",
    "earcut": "^2.2.4",
    "fast-xml-parser": "^4.3.6",
    "forma-embedded-view-sdk": "^0.87.0",
    "jszip": "^3.10.1",
    "ngx-colors": "^3.5.3",
    "rxjs": "~7.8.0",
    "three": "^0.178.0",
    "tslib": "^2.3.0",
    "uuid": "^9.0.0",
    "zone.js": "~0.15.0"

browser: Chrome

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.

[TrabacchinLuigi]

We recently updated from 3.1.4 to 3.3.3 and we started getting a lot of those accompanied by visual bugs.
I'm guessing the cause to be some sort of boolean operation the converter is doing on compenetrated meshes that where not being done before. I'm working on reproducing this with a file i can share with little success.