Can .xml connect to .glTF?

[HWAZWD]

I've got two files,one is .xml and the other is .glTF.Now I load the .gltf file with Three.js,I was wondering when clicking a part of the model,how can I get the corresponding information stored in the .xml file?If not,any suggestions? Thanks a lot!

[aothms]

The IDs are the same. Just IFC uses a base64 encoding mechanism. In python you have ifcopenshell.guid.compress() / expand(). There is also a Javascript implementation here https://github.com/AECgeeks/BIMsurfer2/blob/master/bimsurfer/src/Utils.js#L54

In general you might want to consider switching to https://github.com/AECgeeks/BIMsurfer2. It also uses threejs. But solves the issue of integrating with XML (and 2D SVG). You might also want to consider https://github.com/AECgeeks/ifc-pipeline which includes BIMsurfer2 and a Python based processing queue for the model conversion.

[HWAZWD]

@aothms Thanks a lot,that's working!

[theRealSuperMario]

Is there any way you can toggle if you want base64 encoding or not in the output file when running IfcConvert?

Me personally, I just want all the ids to be the same, regardless of the implementation details and output file formats.

Maybe that's just my personally taste, but I don't see a point in allowing this inconsistency in the first place, even if IFC is the format that does the weird thing. If the pipeline starts with IFC, the ids should just be kept in the same format throughout the pipeline.

What do you think?

[aothms]

@theRealSuperMario you can use the --use-element-guids option to retain the same IFC base64 encoding. Issue is that these are not valid XML identifiers due to character set and starting with a number. Hence the default naming.

[theRealSuperMario]

@aothms Thanks for the hint.

Just to recab:

• the starting point is IFC, which has base64 encoding.

• converting to XML retains this base64 encoding (which is because XML needs base64, fine for me).

• But why do we CHANGE the encoding if the output format is .glb? It's not XML after all (I wrote a tiny script which just converts the guids back to base64, and it works fine).

• I still suggest to change this default behaviour to keep the base64 for the .glb output format. I can do it if you agree with me here.

[aothms]

The reasoning is that the glTF serializer is quite new. The previous approach to get glTF was through collada serializer and then collada2gltf. So I prefer these flows to be compatible.

I wrote a tiny script which just converts the guids back to base64, and it works fine

But isn't that the point? It doesn't matter much. It's just a preference of whether you choose consistency within the geometric output formats, or choose resemblance with IFC.

[theRealSuperMario]

I understand. That makes sense. I am just a hardcore consistency lover I suppose. Sorry for bothering.

[aothms]

No worries, if you see things to make consistent feel free to send PRs. Especially now that we just started the 0.7.0 branch there is definitely room for some backwards incompatible clean up :)