thatopen / engine_fragment Goto Github PK

Description 📝

I suggest moving three js dependency out of dependencies, to peerDependencies and devDependencies, this way i believe we can reduce total size of a library.

Suggested solution 💡

"dependencies": {
"flatbuffers": "^23.3.3",
"three": "0.152.2",
"three-mesh-bvh": "0.6.0"
}
->
"dependencies": {
"flatbuffers": "^23.3.3",
"three-mesh-bvh": "0.6.0"
}
"devDependencies": {
...
"three": "0.152.2",
}
"peerDependencies": {
"three": "0.152.2",
}

Alternative ⛕

No response

Additional context ☝️

I beleive this direct dependency to be primary suspect of really heavy size of the bundle.

Validations ✅

• Read the docs.
• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

Describe the bug 📝

FragmentGroup.getFragmentMap returns "FragmentMap", but APIs such as OBC.Highlighter.highlightByID requests "FragmentIdMap". Therefore, I need to write the following conversion code myself. I think this is a bug because "FragmentMap" and "FragmentIdMap" are the same concept.

const item: any = OBC.IfcPropertiesUtils.findItemByGuid(this.groups[0].properties!, guid);
const expressID = item.expressID as number;
const found = this.groups[0].getFragmentMap([expressID]);
const result: OBC.FragmentIdMap = {};
for (const fragmentId in found) {
    const expressIds = new Set<string>();
    const expressIdsInNumber = found[fragmentId];
    for (const expressIdInNumber of expressIdsInNumber) {
        expressIds.add(expressIdInNumber.toString());
    }
    result[fragmentId] = expressIds;
}

this.highlighter.highlightByID('default', result);

Reproduction ▶️

No response

Steps to reproduce 🔢

No response

System Info 💻

System:
    OS: Windows 10 10.0.19045
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
    Memory: 5.58 GB / 15.75 GB
  Binaries:
    Node: 16.20.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 9.7.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (117.0.2045.43)
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    openbim-components: ^1.1.0 => 1.1.0

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 IFC.js components 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.

Describe the bug 📝

asdfa

Reproduction ▶️

No response

Steps to reproduce 🔢

afsdfa

System Info 💻

asdfa

Used Package Manager 📦

npm

Error Trace/Logs 📃

afasdfa

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 IFC.js fragment 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 Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

Description 📝

As an engineer, I'd like to be able to send incremental updates to a FragmentsGroup over a network.

I'm using this set of libraries to make a server-client BIM detailing application for steel wall framing. The basic flow of the application is as follows:

1. User uploads an IFC file
2. User specifies walls to frame and loading conditions for those walls
3. Server parses IFC file into fragments, generates new fragments for framing members
4. Frontend renders fragments with openbim-components
5. If model contains unbuildable conditions (e.g. clashes), GOTO 2

Unfortunately, it is quite wasteful to send the entire BIM down again every time a user has made a tiny little tweak to their project settings. Usually, I am only changing a very small percentage of all serialized data on each request. So I am wasting user bandwidth and CPU cycles by making them fetch the entire BIM once more and then parse it and stuff it into a THREE scene.

Suggested solution 💡

• A FragmentsGroupDiff class representing mutation of FragmentsGroup
• Methods to serialize/deserialize FragmentsGroupDiff
• Method to apply a FragmentsGroupDiff to a FragmentsGroup

Alternative ⛕

I considered hacking this on my own by just computing a diff on the serialized bytes of FragmentsGroup. The binary diff would go over the network and the client would combine that diff and the previous FragmentsGroup serialization to get the new serialized bytes, which it would then parse to get the new FragmentsGroup.

It would save some bandwidth, but I don't think it's a good alternative:

• I'm having trouble finding a good binary patch library for nodejs.
• Computing the entire serialization on the backend just to diff it is wasteful since you need to walk the entire BIM again.
• The client still has to build a whole new FragmentsGroup and swap it into the running THREE scene. This seems somewhat wasteful if all I need to do (for example) is change some instance matrices in a fragment.

Additional context ☝️

No response

Validations ✅

• Read the docs.
• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

Describe the bug 📝

I'm having trouble upgrading openbim-components, because there's a conflict.
Perhaps the issue is that package-lock.json of fragment still has "three": "0.152.2".

Reproduction ▶️

No response

Steps to reproduce 🔢

Download this package.json.

{
  "name": "demo-web",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "dependencies": {
    "openbim-components": "^1.3.2",
    "three": "^0.160.1",
    "web-ifc": "^0.0.50"
  }
}

Run npm i in the same directory

Get a conflict error

System Info 💻

System:
    OS: Linux 6.6 Pop!_OS 22.04 LTS
    CPU: (20) x64 13th Gen Intel(R) Core(TM) i5-13600KF
    Memory: 20.21 GB / 31.19 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 20.11.0 - /usr/bin/node
    npm: 10.2.4 - /usr/bin/npm
  Browsers:
    Chromium: 121.0.6167.85

Used Package Manager 📦

npm

Error Trace/Logs 📃

 npm i
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/three
npm ERR!   three@"^0.160.1" from the root project
npm ERR!   peer three@">=0.126.1" from [email protected]
npm ERR!   node_modules/camera-controls
npm ERR!     camera-controls@"^1.36.0" from [email protected]
npm ERR!     node_modules/openbim-components
npm ERR!       openbim-components@"^1.3.1" from the root project
npm ERR!   3 more (n8ao, postprocessing, three-mesh-bvh)
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer three@"0.152.2" from [email protected]
npm ERR! node_modules/bim-fragment
npm ERR!   peer bim-fragment@"1.3.1" from [email protected]
npm ERR!   node_modules/openbim-components
npm ERR!     openbim-components@"^1.3.1" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: [email protected]
npm ERR! node_modules/three
npm ERR!   peer three@"0.152.2" from [email protected]
npm ERR!   node_modules/bim-fragment
npm ERR!     peer bim-fragment@"1.3.1" from [email protected]
npm ERR!     node_modules/openbim-components
npm ERR!       openbim-components@"^1.3.1" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

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.

Describe the bug 📝

I'm using bim-fragment in Nodejs, it throw error

Reproduction ▶️

https://github.com/RyugaRyuzaki/bim-fragment-server.git

Steps to reproduce 🔢

1. Run "npm install"
2. Run "npm run dev"

System Info 💻

Nodejs 20.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 IFC.js fragment 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 Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

Description 📝

The viewer becomes data-intensive due to the repeated requests for property files, which are not cached and must be retrieved anew each time properties need to be accessed.

Suggested solution 💡

In the FragmentsGroup class, which contains the getProperties method that appears to be the primary function for retrieving properties, we could implement a caching system same as the one used for geometries.

Alternative ⛕

import Dexie from "dexie";

interface IStreamedFile {
  id: string;
  file: JSON;
}

export class StreamFileDatabase extends Dexie {
  // Declare implicit table properties.
  // (just to inform Typescript. Instantiated by Dexie in stores() method)
  files!: Dexie.Table<IStreamedFile, string>; // number = type of the primkey

  constructor() {
    super("MyAppDatabase");
    this.version(1).stores({
      files: "id, file",
    });
  }
}

export class FragmentsGroup extends THREE.Group {

private _fileCache = new StreamFileDatabase();

private async getPropertiesData(url: string) {
    const found = await this._fileCache.files.get(url);
    if (found) {
      return found.file;
    } else {
      const fetched = await fetch(url);
      const fileData = await fetched.json();
      this._fileCache.files.add({ id: url, file: fileData.data });
      return fileData && fileData.data ? fileData.data : null;
    }
  }

Additional context ☝️

No response

Validations ✅

• Read the docs.
• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

Description 📝

It would be cool if, just as the FragmentsGroup is able to create FragmentIdMaps, that it also provides a method to combine them.

Suggested solution 💡

Create something like FragmentsGroup.combineFragmentIdMaps.

Alternative ⛕

No response

Additional context ☝️

No response

Validations ✅

• Read the docs.
• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

Describe the bug 📝

I am upgrading from 2.0.4 to the latest version (2.1.6) and all my old fragment files have stopped working. The geometryIDs have changed. I've pinpointed that this commit introduced the regression.
c53ac59

I'm getting the error malformatted fragment because the fragment groups don't seem to contain geometryIDs that are stored in the streamedGeometries https://github.com/ThatOpen/engine_components/blob/23c99ee54aa30046e84bda902d45b171ceb504bf/packages/core/src/fragments/IfcGeometryTiler/src/base-types.ts#L4

My understanding was that fragment files should be persisted and should therefore be backwards compatible. Or will I have to regenerate all my fragment files?

Reproduction ▶️

No response

Steps to reproduce 🔢

• generate fragment files with 2.0.5
• upgrade lib on frontend to 2.0.7
• all the geometryIDs have changed and are no longer working.

System Info 💻

System:
    OS: macOS 14.4.1
    CPU: (12) arm64 Apple M2 Max
    Memory: 72.89 MB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.19.1 - ~/.nvm/versions/node/v18.19.1/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v18.19.1/bin/yarn
    npm: 10.2.4 - ~/.nvm/versions/node/v18.19.1/bin/npm
  Browsers:
    Chrome: 127.0.6533.89
    Safari: 17.4.1

Used Package Manager 📦

yarn

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.

Describe the bug 📝

I'm trying to clone a FragmentsGroup. I assumed this would be possible, because FragmentsGroup extends Group. However, it fails with Cannot read properties of undefined.

The root of the problem seems to be that FragmentMesh (or maybe FragmentsGroup) doesn't defined a clone-method which results in the default clone being called. The default implementation is the following:

  clone(recursive) {
    return new this.constructor().copy(this, recursive);
  }

This calls the constructor of FragmentMesh. Unfortunately, FragmentMesh doesn't define default arguments which leads to problems, such as geometry being undefined.

To fix the issue, either a clone that calls the constructor with proper arguments should be implemented, or a constructor with defaults arguments should be implemented. I feel that the latter would be the Three.js way, but I haven't read enough fragment code to make a judgement.

Reproduction ▶️

No response

Steps to reproduce 🔢

1. Create a FragmentsGroup anyway you want. In my case:

    const file = await selectFile();
    if (!file) {
        console.warn('File not loaded');
        return;
    }
    const data = await file.arrayBuffer();
    const buffer = new Uint8Array(data);
    const model = await fragmentIfcLoader.load(buffer, "example");
    components.scene.get().add(model);

2. Try cloning a FragmentsGroup. For example, after loading the model call:

// fragments is a FragmentsManager
const group = fragments.groups[0];
group.clone(true);

Result:

Cannot read properties of undefined

System Info 💻

System:
    OS: Linux 6.6 Pop!_OS 22.04 LTS
    CPU: (20) x64 13th Gen Intel(R) Core(TM) i5-13600KF
    Memory: 13.53 GB / 31.19 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 20.10.0 - /usr/bin/node
    npm: 10.2.3 - /usr/bin/npm
  Browsers:
    Chromium: 120.0.6099.71
  npmPackages:
    openbim-components: ^1.2.0 => 1.2.0

Used Package Manager 📦

npm

Error Trace/Logs 📃

openbim-components.js?v=4bd4a061:45990 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'index')
    at _FragmentMesh.newFragmentGeometry (openbim-components.js?v=4bd4a061:45990:19)
    at new _FragmentMesh (openbim-components.js?v=4bd4a061:45942:26)
    at _FragmentMesh.clone (chunk-ADNH2OTW.js?v=4bd4a061:5238:12)
    at FragmentsGroup2.copy (chunk-ADNH2OTW.js?v=4bd4a061:5263:24)
    at FragmentsGroup2.clone (chunk-ADNH2OTW.js?v=4bd4a061:5238:35)
    at cloneAndUnravel (ifcmain.ts:107:23)
    at produceGlb (ifcmain.ts:102:17)
    at exportGlb (ifcmain.ts:137:21)
    at Object.exportGlb (ifcmain.ts:163:20)
    at HTMLButtonElement.<anonymous> (three_examples_jsm_libs_lil-gui__module__min.js?v=4bd4a061:145:44)

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.

Description 📝

Test issue description!

Suggested solution 💡

asdfa dffadfa

Alternative ⛕

fadsfaasdfa

Additional context ☝️

afadfaaafdsa aada

Validations ✅

• Read the docs.
• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.