Coloring IFCSPACE Elements in the 2D Plan View

[phisch1503]

Describe the bug 📝

The 2D plan view is built on the Views system from @thatopen/components combined with the ClipStyler. The ClipStyler creates a clipping plane per storey and renders fills (colored fill polygons) and lines (edges/outlines) from the clipped geometry. This works well for solid building elements such as walls, slabs, and columns, whose geometry produces clean cross-sections.

The Problem with IFCSPACE
IFCSPACE elements (rooms) are not physical building components in IFC — they are geometric space volumes. Their 3D mesh geometry exists, but:

No meaningful clip fills: When the ClipStyler intersects a clipping plane through an IFCSPACE volume, a cross-section is technically produced, but it does not align with the visible footprint of the room in the plan drawing. The result is either no fill at all, or a fill that does not cover the intended area.

Independent geometry: IFCSPACE objects are conceptually "behind" the walls and are not treated correctly as standalone surfaces by the ClipStyler render pass — their outline overlaps with the wall geometry.

Coloring via setColor() instead of ClipStyler style: As a workaround, IFCSPACE elements are not colored through the ClipStyler but directly via model.fragments.setColor() (the highlight mechanism of the fragment renderer). This overrides the original room mesh material with the desired color.

Timing Problem with setColor() in the Plan View
This workaround introduces a further problem:

views.open(viewId) switches the camera and internally fires onCameraChanged.
onCameraChanged calls fragmentsManager.core.update(true).
This update processes tile requests from the LOD system. New tiles that become visible receive freshly created materials — which overwrite colors previously set via setColor().
If setColor() is called before this update, the color is already gone before it is ever rendered.
If setColor() is called after the update but fragmentsManager.core.update(true) is triggered again by the subsequent render loop (e.g. through camera controls), the colors are reset again.

Conclusion
The fundamental problem is that the ClipStyler and the FragmentsModel renderer operate two independent color systems. IFCSPACE elements cannot be reliably colored via ClipStyler styles because they do not provide suitable clip geometry. The direct setColor() approach is fragile against asynchronous LOD updates, which can reset the color state at any time.

Reproduction ▶️

No response

Steps to reproduce 🔢

Take the views tutorial example and try to color the IFCSPACE

System Info 💻

Chrome 145.0.7632.119

"@thatopen/components": "^3.3.2",
"@thatopen/components-front": "^3.3.1",
"@thatopen/fragments": "^3.3.4",
"@thatopen/ui": "^3.3.3",
"@thatopen/ui-obc": "^3.3.3",
"three": "^0.183.0",
"web-ifc": "^0.0.75"

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.