Background
Templot is migrating from per-facet ASCII STL emission to parametric BRep construction via simpleOCCTVP, exporting as STEP. A typical layout has tens of thousands of placements (chairs, jaws, bolts, nails, timbers, rail runs) of ~50 unique component definitions. Component reuse via TopLoc_Location + a proper assembly STEP file is what makes this tractable.
For that to work end-to-end the export side needs a couple of additions, and we'd benefit from some inspection helpers when debugging the resulting BRep tree.
Asks
1. XCAF-aware STEP export
Today ot_export_step (in src/occt_templot_io.cpp) uses plain STEPControl_Writer. That collapses the input shape to a single solid and drops colour. For an assembly with hundreds of named components we want hierarchy and colour preserved.
Proposal: a new ot_export_step_assembly(OTShapeRef shape, const char* path) → bool that:
- Builds a
TDocStd_Document (or accepts one — see (3) below).
- Adds the shape with
XCAFDoc_DocumentTool::ShapeTool()->AddShape(...).
- Sets per-component colour via
XCAFDoc_DocumentTool::ColorTool().
- Writes via
STEPCAFControl_Writer.Transfer(doc, STEPControl_AsIs) then Write(path).
ot_export_step stays as the plain/flat path for backward compatibility.
2. Colour-per-component on the builder side
Pair with the existing builder roadmap: a way to attach a colour to a TopoDS_Shape (or to whatever opaque component handle the eventual builder API uses) such that ot_export_step_assembly picks it up. RGB tuple is fine for v1.
3. BRep graph inspection / dump helper
OCCT 8.0 ships internal BRep graph machinery; we'd like at least one of the following to surface from the C ABI for debugging:
Minimum: an ot_dump_shape_tree(OTShapeRef shape, FILE* out) that walks the shape and prints TopAbs_* type, hash, and any XCAF label/colour attached, indented by depth. Lets us sanity-check the structure of what we're sending to STEP without firing up FreeCAD every time.
Nice-to-have: a small CLI tool tools/dump_brep_graph foo.step doing the same on a STEP file (round-trip validation).
Stretch: ancestor/descendant queries (shape ↔ shape) for navigating the assembly tree from the C API. Not needed for Templot day-1, but useful longer term.
Why this matters
Templot's catalogue of parts is ~30 distinct block kinds (nails, bolts, hex nuts, jaws, seats, keys, washers) plus rails (swept BS profiles) plus timbers. Without component reuse the STEP file for a real layout would be in the gigabytes; with proper XCAF assembly references it's a few MB. So XCAF isn't optional for this use case.
Priority
Research-but-non-blocking. Templot's day-1 spike will run against the existing flat ot_export_step to prove the loop end-to-end with a single primitive (cone). Items (1) and (2) become blocking once the part inventory grows in days 4–5. Item (3) is debugging aid, helpful but not blocking.
Happy to PR any of these — let me know if you'd prefer the work happen here or upstream.
Background
Templot is migrating from per-facet ASCII STL emission to parametric BRep construction via simpleOCCTVP, exporting as STEP. A typical layout has tens of thousands of placements (chairs, jaws, bolts, nails, timbers, rail runs) of ~50 unique component definitions. Component reuse via
TopLoc_Location+ a proper assembly STEP file is what makes this tractable.For that to work end-to-end the export side needs a couple of additions, and we'd benefit from some inspection helpers when debugging the resulting BRep tree.
Asks
1. XCAF-aware STEP export
Today
ot_export_step(insrc/occt_templot_io.cpp) uses plainSTEPControl_Writer. That collapses the input shape to a single solid and drops colour. For an assembly with hundreds of named components we want hierarchy and colour preserved.Proposal: a new
ot_export_step_assembly(OTShapeRef shape, const char* path) → boolthat:TDocStd_Document(or accepts one — see (3) below).XCAFDoc_DocumentTool::ShapeTool()->AddShape(...).XCAFDoc_DocumentTool::ColorTool().STEPCAFControl_Writer.Transfer(doc, STEPControl_AsIs)thenWrite(path).ot_export_stepstays as the plain/flat path for backward compatibility.2. Colour-per-component on the builder side
Pair with the existing builder roadmap: a way to attach a colour to a
TopoDS_Shape(or to whatever opaque component handle the eventual builder API uses) such thatot_export_step_assemblypicks it up. RGB tuple is fine for v1.3. BRep graph inspection / dump helper
OCCT 8.0 ships internal BRep graph machinery; we'd like at least one of the following to surface from the C ABI for debugging:
Minimum: an
ot_dump_shape_tree(OTShapeRef shape, FILE* out)that walks the shape and printsTopAbs_*type, hash, and any XCAF label/colour attached, indented by depth. Lets us sanity-check the structure of what we're sending to STEP without firing up FreeCAD every time.Nice-to-have: a small CLI tool
tools/dump_brep_graph foo.stepdoing the same on a STEP file (round-trip validation).Stretch: ancestor/descendant queries (shape ↔ shape) for navigating the assembly tree from the C API. Not needed for Templot day-1, but useful longer term.
Why this matters
Templot's catalogue of parts is ~30 distinct block kinds (nails, bolts, hex nuts, jaws, seats, keys, washers) plus rails (swept BS profiles) plus timbers. Without component reuse the STEP file for a real layout would be in the gigabytes; with proper XCAF assembly references it's a few MB. So XCAF isn't optional for this use case.
Priority
Research-but-non-blocking. Templot's day-1 spike will run against the existing flat
ot_export_stepto prove the loop end-to-end with a single primitive (cone). Items (1) and (2) become blocking once the part inventory grows in days 4–5. Item (3) is debugging aid, helpful but not blocking.Happy to PR any of these — let me know if you'd prefer the work happen here or upstream.