The PMI on parts is lost when using Shattered mode

HOOPS Communicator
1

Command used to create xml:

..\bin\win64\converter --input "_data\catia\Product1.CATProduct" --prepare_shattered_parts "output\Product1_shattered" --prepare_shattered_xml "output\Product1.xml" --read_wireframes 0 --import_pmi 1 --sc_export_pmi 1 --read_attributes 1 --sc_export_attributes 1 --sc_logging 1

Command used to create master sc:

..\bin\win64\converter --input_xml_shattered "output\Product1.xml" --sc_shattered_parts_directory "output\Product1_shattered" --output_sc_master "output\Product1" --read_wireframes 0 --import_pmi 1 --sc_export_pmi 1 --read_attributes 1 --sc_export_attributes 1 --sc_logging 1

When I convert a single part, the PMI shows correctly:

..\bin\win64\converter --input "_data\catia\P1.CATPart" --output_sc "output\P1.CATPart" --read_wireframes 0 --import_pmi 1 --sc_export_pmi 1 --read_attributes 1 --sc_export_attributes 1 --sc_logging 1

Tested attached Catia files on HOOPS_Communicator_2024.8 and HOOPS_Communicator_2025.5, same result.

Shattered
Shattered2910×885 125 KB

catia.zip (647.6 KB)

2

Hello @drawmindmap,

I can confirm that, currently, this is a known limitation when using the shattered approach for assemblies with PMI.

Thanks,
Tino

3

Thank you tino.

Are there workaround solutions?

4

Unfortunately, there are no workarounds at this time.

5

I mean the parts contain PMIs, not the assembly.

Can I replace the files generated by --prepare_shattered_parts(which has no PMI) with the files generated by --output_sc(which contain PMI) of every individual part?

6

Loading Stream Cache files generated in monolithic (--output_sc) from models with PMI can potentially be problematic when reassembled back in shattered mode. The reason being is that PMIs can be associated with certain views and when activated, can result in incorrect positioning (and/or visibility) of the PMI.