Unexpected selection grouping when loading an IFC in the your official BIM App template

[cubalibre]

Describe the bug 📝

Hi everyone,
I first encountered this selection issue while working on my own BIM viewer based on That Open Components.

To make sure the behavior was not caused by my own implementation, I reproduced the same test using the official That Open BIM App, loading the original IFC directly.

The same unexpected selection behavior occurs there as well.

When I click one specific glazed panel of the curtain wall, several other glazed panels are highlighted together, even though they are separate elements in the original IFC.

I'm testing the official That Open BIM App with an IFC model and I've noticed an unexpected selection behavior.

When I click one specific glazed panel of the curtain wall, several other glazed panels are highlighted together, even though they are separate elements in the original IFC.

I initially thought this could simply be related to the curtain wall hierarchy/grouping. However, the selection also appears to include a separate window belonging to the same "Living room" environment.

An interesting detail is that the behavior is not symmetric:

clicking the curtain-wall panel highlights multiple glazed elements, including the separate window;

clicking that separate window by itself does not highlight the curtain wall.

I tested the same original IFC in BIMvision. There, the curtain-wall panels can be selected individually (for example, the selected element shown in the attached screenshot is reported as an IfcPlate).

I can also reproduce the grouped-selection behavior using the official That Open Highlighter example with a .frag generated from this IFC using the That Open importer.

So at the moment I can reproduce the behavior in both:

the official BIM App when loading the IFC;

the official Highlighter example when loading the generated FRAG.

while BIMvision allows individual selection on the original IFC.

Is this expected behavior due to how the IFC elements are mapped/grouped during the fragments conversion, or could this be an issue in the IFC → fragments pipeline / selection mapping?

If useful, I can provide the IFC file and a minimal reproduction.

Thanks!

http://www.acleweb.it/small2.ifc

Reproduction ▶️

No response

Steps to reproduce 🔢

http://www.acleweb.it/small2.ifc

System Info 💻

.

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.

[agviegas]

Update with findings: we loaded small2.ifc and inspected the converted data. The conversion is clean: the six IfcPlates come out as six independent items, each with its own selectable sample. Three of them share one geometry representation, which is normal instancing for identical panels, and sharing a representation does not merge selection at the data level. So the grouping you see is not baked into the conversion; the suspect moves to the selection path in the viewer and template, which we're auditing next. We'll follow up here with what we find. Thanks again for the file, it made this quick to pin down.

[cubalibre]

Thanks Antonio, this is very helpful. We noticed one additional behavior that might be relevant to your investigation. In our viewer, when we make the *IfcSpace elements invisible*, the selection behavior changes: we are then able to pick the individual glass *IfcPlates separately*, rather than getting the grouped selection we were seeing before. I don't know whether this is directly related to the root cause, but since you've confirmed that the six IfcPlates are independent at the converted-data level, I thought this might be a useful clue for the selection/picking path you're auditing. Thanks again for looking into it! Il giorno ven 11 set 2026 alle ore 14:26 Antonio González Viegas < ***@***.***> ha scritto:

…

*agviegas* left a comment (ThatOpen/engine_fragment#274) <#274 (comment)> Update with findings: we loaded small2.ifc and inspected the converted data. The conversion is clean: the six IfcPlates come out as six independent items, each with its own selectable sample. Three of them share one geometry representation, which is normal instancing for identical panels, and sharing a representation does not merge selection at the data level. So the grouping you see is not baked into the conversion; the suspect moves to the selection path in the viewer and template, which we're auditing next. We'll follow up here with what we find. Thanks again for the file, it made this quick to pin down. — Reply to this email directly, view it on GitHub <#274?email_source=notifications&email_token=AAG42PFHWFENKADL2G2V7ZT5OPVP7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRTGQ2DCMRZGIZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5634412922>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG42PEIVLS6AINC2MTRNPL5OPVP7AVCNFSNUABFKJSXA33TNF2G64TZHM2DSNRSGAYTMOJYHNEXG43VMU5TKMZQHAZDONBZGI32C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAG42PHFHHBAK5JPGPEFLM35OPVP7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRTGQ2DCMRZGIZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AAG42PCYXHSSTS7G5KAU4OD5OPVP7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRTGQ2DCMRZGIZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: <ThatOpen/engine_fragment/issues/274/5634412922 ***@***.*** com>