STEP Multipart Import with colours and names

Multi-part STEP import introduced in #71 However, names & colours are lost in the process.

Target Outcome: Issue aimed to be closed when the following statements are true & tested.

Imported objects keep their:

• object name
• object material properties (just colour, or more?)

Only import sub-parts:

• Importer can start at a child and ignore siblings (controlled import hierarchy)
• If a hierarchy is selected to be imported as a Part, all geometry is merged [#146]

Performance:

• Measurable (obviously it’s preferable to be faster, but this may not be possible)
• Faster to only import a nested hierarchy.

[Rayfoundry]

This would be a great addition.

[fragmuffin]

There may be another problem with the “smart solution”

1. Skim-read the .step and remember:
   • data: “sections” of importable geometry (save as start/end seek points in the .step file)

The .step format is a sort of link-list of indexed vertices, edges, splines, faces (and so on). Usually the indexed geometry for a single part is confined to a seekable range within the .step file, but this is a common byproduct of creating the file. From what I understand, a .step file’s content separated into lines, could (almost) be randomised and re-written, and still import the same shapes.

Alternative that may still be possible A Skim-read could cache:

• an index list: [(<step index>, <file seek>, {<referenced indexes>, ...}), ... ]
• map parts to a dict: {<part uid>: <step-index>, ...}

Then to import a single part, the .step file could be fragmented; separated by tracing all referenced lines relating to that part, then “import” the fragmented .step file as a single Part.

Tasks / Questions to answer

• Feasibility study:
  • is this plausible? can the .step be fragmented like this?
  • different .step version support - this will require a partial “parsing” of the .step file, how susceptible to change is the .step format?, has it’s indexing & core metadata structure always been the same?
• Performance test(s)
  • is this “smart” way going to be just as slow as a standard “import everything” approach?