missing properties in model about xeokit-sdk

[xeolabs]

Hi, which converter tools are you using :

1. Ifc2GLTFCXConverter and converter2xkt (IFC->glTF->XKT, with property sets)
2. IfcConvert and convert2xkt, (IFC->glTF->XKT)
3. convert2xkt by itself (IFC -> XKT)

Note that 2 & 3 do not support property sets currently.

Also, if you represent one of our enterprise users (and you're using 1), please raise this issue with our Jira, and we can prioritize support on this issue.

Thanks

[perssam42]

I'm using convert2xkt and I can almost see all Property Sets so i don't understand what you mean when you say that converter 2 & 3 do not support it. As you can see in screenshot2 I have sections and properties inside every objects. I also have most of propertySets in the metaModel Object in my code.

Regards

[xeolabs]

We have three different techniques ("pipelines") to convert IFC into XKT, each using a different combination of CLI tools (see 1, 2 and 3 in my previous message).

Which one are you using?

Only pipeline (1) supports property sets.

Do you represent one of out enterprise users? If so then perhaps you could log a support request with our Jira issue tracker, and we could possible also have a meeting to help you out.

[perssam42]

I'm pretty sure i'm using pipeline 3 which, if i understood, should not be able to extract propertySets from the IFC file. However i can see them in my Inspector panel so i don't understand why you say that it's not supported.

[xeolabs]

My mistake - (3) does support some properties, but not completely.

We recommend using (1), which does have complete property set support. (1) is the pipeline that our enterprise users are using - see here for how we recommend using it: https://xeokit.github.io/xeokit-model-conversion-tests/ifc-tests.html#testMethod

(3) is a "low-power" conversion pipeline that's really there for community experimentation (it uses web-ifc internally, a 3rd-party library, for parsing IFC). We keep it for educational purposes and don't recommend that for enterprise users. Recommend using (1), since it's fully maintained by us.

[perssam42]

In case I choose ifc2gltfcxconverter instead of convert2xkt, what would be the amount of changes for my actual app ? Does it change much things, like objects informations, tree structure, etc... ?
Currently my IFC files take sometimes few minutes to be converted into xkt, i saw in the link you shared that it takes less than 1 sec for ifc2gltfcxconverter : is it related to your server specs or the overall conversion time has been improved ?

[xeolabs]

You would use ifc2gltfcxconverter to convert IFC into glb and JSON files. The glb holds the geometry and materials, and the JSON holds the IFC metadata. If you are using the option to split the models into multiple glb and JSON files, it will also output a JSON manifest file that lists all those files.

Then you would use convert2xkt to convert the glb and JSON files into XKT files. if you are using the splitting option, convert2xkt would take as input the manifest output by ifc2gltfcxconverter, and would output its own JSON manifest file that lists the XKT and JSON metadata files.

So, you still use ifc2gltfconvert AND convert2xkt together, as two stages of the same pipeline.

The usega is describe in the documentation:

Without splitting: https://xeokit.notion.site/Converting-IFC-to-XKT-using-ifc2gltfcxconverter-a2e0005d00dc4f22b648f1237bc3245d

With spiltting: https://xeokit.notion.site/Automatically-Splitting-Large-Models-for-Better-Performance-165fc022e94742cf966ee50003572259

[perssam42]

Okay, so if I understand correctly, this won't change the way the data is stored in the final xkt file. Currently, I extract my data from the xkt, so I won't need to change my current implementation (whether I use splitting or not), is that correct?

Could you confirm whether the conversion time is significantly reduced compared to my current method ?

[xeolabs]

Yes, (1) is much faster than (3). In addition to full property set support, it also handles the geometry conversion a lot better.

The objects in the XKT will be the same, and the geometry for those objects will in some cases be better and more correct.

The metadata will be the same as well, except that it will also have property sets.

The difference will be that the geometry for the objects will be more correct, eg. ifccxconverter handles more edge cases for boolean geometry correctly.

Splitting is also worthwhile, because it allows convert2xkt to handle larger models, and allows xeokit Viewer to load larger models also.