Repository navigation
Viewpoint: clipping planes and the position setter ignore the base coordination matrix #862
Description
Describe the bug 📝
The viewpoint camera is stored relative to FragmentsManager.baseCoordinationMatrix (B, the first model's coordination matrix), but the clipping planes are not: set() creates them at the stored location without B, and toJSON() writes their world origin without B⁻¹. For a translated first model (any IFC with a site offset, here Architectural.ifc with B = translation (−12.96, −6.20, −16.07)) a BCF clipping plane lands in the wrong place. The position setter drops B as well.
The same BCF clipping plane at IFC Z = 7.5 m. Left: where BCF puts it, through the windows. Right: That Open's plane, above the building. Then clipping off on both.
Expected: clipping plane locations go through B like the camera position (B on set(), B⁻¹ on toJSON()), and the position setter stores the B⁻¹ value it computes.
Where in the code
- Clipping planes:
set()(viewpoint.ts#L313-L336) andtoJSON()(#L719-L724). The camera position, by contrast, goes through B in the getter (#L128-L135) and B⁻¹ inupdateCamera()(#L461). - The
positionsetter computesvalue.clone().applyMatrix4(B⁻¹), drops the result and stores the world value (#L141-L154); the getter then applies B again. - Related, found by reading the code only: directions are never rotated by B (not in
updateCamera(), thedirectiongetter (#L160-L165) orserialize()(#L773-L774)). Web-ifc gives a translation-only B, so this only matters for a fragments file with a rotated one;transformDirection(B)would cover it (applyBaseCoordinateSystemcan't be used, it adds the translation).
Reproduction ▶️
https://github.com/BiroBotond0/thatopen-bcf-bug-reproduction/tree/main/issue-2
Steps to reproduce 🔢
- In the repro:
npm install,npm run dev, openissue-2/example.html. Both worlds load buildingSMART'sArchitectural.ifc. - The left world creates the BCF plane where BCF puts it. The right one passes it to
Viewpoint.set({ clipping_planes })on a viewpoint that has a world. (Its direction is reversed by hand, see Viewpoint / BCFTopics: BCF clipping planes are dropped by create(data) and load(), and clip the wrong half when they are made #863 , so only the position differs.) - Clipping on / off compares with the uncut building.
- The panel's Results (the plane's origin, and a
positionset and read back):
BUG set() plane origin in the world: got [6,7.5,6], expected [-6.955,1.3,-10.075]
BUG position after position = (5, 5, 5): got [-7.955,-1.2,-11.075], expected [5,5,5]
System Info 💻
System:
OS: Windows 11 10.0.26200
CPU: (16) x64 Intel(R) Core(TM) i9-10885H CPU @ 2.40GHz
Memory: 33.34 GB / 63.76 GB
Binaries:
Node: 22.22.1 - C:\nvm4w\nodejs\node.EXE
npm: 11.12.0 - C:\nvm4w\nodejs\npm.CMD
Browsers:
Chrome: 156.0.8078.48
Edge: Chromium (152.0.4191.53)
npmPackages:
@thatopen/components: 3.6.0 => 3.6.0
@thatopen/components-front: 3.6.0 => 3.6.0
@thatopen/fragments: 3.6.0 => 3.6.0
@thatopen/ui: 3.4.17 => 3.4.17
camera-controls: 3.1.2 => 3.1.2
three: 0.184.0 => 0.184.0
web-ifc: 0.0.77 => 0.0.77Used 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.
Activity