Mesh Placement Behavior in ifcLoader and Manual Mesh Creation

onderilkesever commented 4 days ago

Describe the bug 📝

Hello,

I wanted to ask about a behavior I’ve observed when working with meshes using the library. So far, I have been creating my meshes via ifcLoader.load, and everything has been working as expected. However, today, I conducted an experiment and manually created a mesh using a method from a sibling repository, as demonstrated in this example: web-ifc-three.ts#L26.

The issue I noticed is that the meshes generated through these two approaches do not appear in the same positions within my scene. To ensure consistency, I’ve set COORDINATE_TO_ORIGIN to true in both scenarios. Additionally, for ifcLoader.load, I pass the coordinate parameter as false. Despite these settings, the placement discrepancy persists.

_Note that when COORDINATE_TO_ORIGIN set the false on both, they appear exactly same on same location as expected._

Since the precise positioning of the models is critical for my use case, I would like to understand what might be causing this difference. Are there additional factors or settings I might be overlooking that could impact mesh placement?

I greatly appreciate your support and insights on this matter.

Thank you in advance!

Best regards,

Reproduction ▶️

No response

Steps to reproduce 🔢

No response

System Info 💻

System:
    OS: macOS 14.7.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 175.95 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.19.0 - ~/.nvm/versions/node/v18.19.0/bin/node
    npm: 10.2.3 - ~/.nvm/versions/node/v18.19.0/bin/npm
  Browsers:
    Chrome: 131.0.6778.86
    Edge: 131.0.2903.70
    Firefox: 132.0.2
    Safari: 17.6

Used Package Manager 📦

npm

Error Trace/Logs 📃

No response

Validations ✅

[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] 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.
[X] Check that this is a concrete bug. For Q&A join our Community.
[X] The provided reproduction is a minimal reproducible example of the bug.

onderilkesever commented 3 days ago

I wanted to share some further observations to aid in the investigation. I noticed that the coordination matrices obtained from fragmentsGroup and directly from web-ifc are not matching. However, when these matrices are applied to the corresponding 3D objects (meshes), the objects are brought to the exact same location in the scene.

This suggests that there might be a discrepancy in the mesh creation process, which is somehow compensated for in the coordinationMatrix. I couldn’t identify any code in the repository that explicitly handles this adjustment, which leaves me at a bit of a loss in terms of where to focus my investigation.

From web-ifc >

1 0 0 0 0 1 0 0 0 0 1 0 48.8318280384837 0.1524 19.4187064561144 1

From fragmentsGroup.coordinationMatrix >

1 0 0 0 0 1 0 0 0 0 1 0 -2.215953884857178 -2.076200008392334 27.88630140649414 1

Here is my ifc file if you would like to try out yourself. https://drive.google.com/file/d/1kXqb-5_7z05Trn655KQG7WmQBNoAH94E/view?usp=sharing

I’d really appreciate any insights or guidance on this topic.

Thank you!

onderilkesever commented 3 hours ago

I might have an idea about what’s happening here. Could it be that the coordination matrix depends on how the IFC model is traversed? For example, using StreamAllMeshes vs. StreamAllMeshesWithTypes might result in different coordination matrices. However, applying the matrix to the object still places it in the correct location. Could you please confirm if this is the case?

Also, perhaps I should tag @beachtom, as I believe he might be able to provide valuable input on this matter.

beachtom commented 3 hours ago

So _coordinationMatrix is only used when coordinating to Origin - and yes it could depend on the order of the objects - the matrix is generated based on the first object that is found that needs coordinating - then all others are done related to that object - so you if you change the order of the objects then yes the matrix will change

ThatOpen / engine_components