Picking individual geometry representation items

[NepomukWolf]

Hi! First of all, I really love the project. I have been experimenting with using ifc-lite as a faster alternative to web-ifc and the ThatOpen ecosystem for the 3D preview in my VS Code IFC extension.

The general approach works very well and loading, hiding/isolating and picking elements is extremely fast. There is one feature, however, from my existing web-ifc viewer that I have not been able to reproduce with ifc-lite: drilling down into the individual geometry parts of a building element.

For example, when looking at a wall context, I want picking any part of a window to resolve to the owning IfcWindow. After focusing the window itself, however, I would like to be able to pick its individual representation items (for example a pane, frame part, IfcFacetedBrep, IfcExtrudedAreaSolid, or another source-backed geometry item) and navigate to that entity in the IFC source.

As far as I can tell, ifc-lite picking currently returns the express ID of the owning product for all of these parts. I could not find a public mapping from the rendered triangles or submeshes back to their originating representation-item IDs.

Is exposing this level of picking granularity something that is already planned or would fit the direction of the project? For my use case, either of these would probably be sufficient.

I found #2443, which discusses multiple MeshData entries per product, but as far as I understand it still treats those entries as parts of the same product-level identity. My question is specifically about retaining or exposing the originating IFC representation-item ID for each part.

I understand that this may not always be straightforward, but was wondering if that is something you already thought about or think would be possible to implement.

Thanks again for an awesome project!

[louistrue]

Thanks, and this is exactly the kind of request I want landing here.

The mapping you are looking for already exists inside the pipeline. It is one field short of reaching you. That is a value we compute and throw away at the wasm boundary, not something that has to be derived back out of triangles.

Where the id already is

The router walks IfcProductDefinitionShape to IfcShapeRepresentation to .Items and tessellates each representation item on its own. Each result is a SubMesh carrying geometry_id, which is the item's STEP id:

// rust/geometry/src/router/processing.rs
sub_meshes.add(item.id, mesh);

That survives into the per-element MeshData as geometry_item_id, and it survives opening and void cutting too. If you use the server REST path you can already see it in the payload today.

Then MeshDataJs::from_mesh_data in the wasm bindings does not copy the field. So the TS MeshData in @ifc-lite/geometry has no equivalent, picking has nothing finer than the product to return, and your read of the situation is correct from where you are standing.

What I am building

MeshData.geometryItemId, with the same meaning as web-ifc's PlacedGeometry.geometryExpressID. An element stays one expressId with N pieces, and each piece names the representation item it came from. You already get the pieces, since an element can emit several MeshData entries that you group by expressId. This adds the missing half of that pair.

If you render the meshes yourself, that alone is enough: one mesh per piece, indexed however you like.

On top of that, opt-in item resolution on pick() plus a focus mode, which gives you the two-level interaction directly. Default click resolves to the IfcWindow, and once an element is focused a click on the same pixel resolves to the pane or the frame. The pick pass already hydrates one mesh per piece and hit-tests them individually, so the part you hit is already known. Only the answer is currently collapsed to the owning product:

// packages/renderer/src/picker.ts
const mesh = meshes[decoded.meshIndexPlusOne - 1];
return { expressId: mesh.expressId, ... };   // the piece is right there

For the jump to source you need nothing new from me. The item id is the STEP id, so CompactEntityIndex.getByteRange(id) from @ifc-lite/parser gives you the byte range in the original file and store.entities.getTypeName(id) gives you the type.

Limitations, so you know what a null means

A null will mean "merged away", not "no such item":

• Elements that fall back to the single merged mesh path.
• IfcMappedItem on the cached path, where all items in the IfcRepresentationMap are merged into one mesh shared across occurrences. On the submesh path you do get an id, but it is the innermost solid inside the map rather than the IfcMappedItem itself.
• GPU-instanced occurrences. That wire format has no slot for an item id, so those stay product-level for now. Say so if it matters and I will look at a format bump.
• Booleans give you the IfcBooleanResult or IfcBooleanClippingResult id, which is a real entity you can navigate to. The operands are folded inside the CSG kernel and are not recoverable.

One thing your question turned up that is a bug, not a gap. For material-layered walls and slabs the pipeline reuses the same field to carry the layer's IfcMaterial id, and 0 when the layer has no material:

// rust/geometry/src/router/layers.rs
out.sub_meshes.push(SubMesh::new(layer.material_id, slab));

So geometry_item_id on the REST path is not always a representation item today, and following it to source lands on a material or on #0. I am splitting that into a separate field so the item id is never anything else, and following it always lands on the right entity. Thanks for the prompt to look.

On #2443: your read is right. That one was about a viewer-side registry keeping only the last submesh per element and it was closed by #2452. It did not touch per-item identity.

One question back

Does per-piece granularity cover you, or do you need per-triangle? IfcOpenShell exposes item_ids per triangle face, but it needs that because it merges an element into one buffer. ifc-lite is already split per item, so per-piece carries the same information without a parallel array on every mesh. If you have a case where a single representation item has to be subdivided further, that changes the design and I would rather know before I build it.

[NepomukWolf]

Thank you so much for the detailed reply! That's amazing and essentially the exact feature I would need. Being able to retrieve the representation item's STEP ID would cover my use case entirely. Per-piece granularity is sufficient for me, I currently do not need per-triangle IDs or picking.

GPU-instanced occurrences do matter for me, though. Repeated windows, doors, frames, and similar products are likely to benefit most from instancing, while also being the elements where drilling into individual parts is especially useful (please correct me if I have the wrong mental model of instancing here). If carrying the item ID through the instanced wire format is feasible, that would complete the feature for my use case. If not, I can always disable GPU instancing.

Apart from that limitation, what you are building would completely address my request!

I do have one related question out of curiosity: could the current design also expose entities referenced by a representation item? For example, an IfcExtrudedAreaSolid references a swept-area profile that has its own STEP ID. Could a picked part of the generated geometry be associated with that profile, or is this connection lost or no longer unambiguous after tessellation? I do not need this for my current use case, so representation-item-level picking would still cover my requirements entirely. However, it could be a nice future improvement for my extension, connecting the source and 3D representation at an even deeper level for exploration and debugging.

Thank you again!