Child of #15: mechanical reconstruction path (feature-based, the core path) #17

New issue

Closed

opened 2026-06-17 18:25:49 +00:00 by Mark · 0 comments

Mark commented

2026-06-17 18:25:49 +00:00

Owner

Parent

Part of #15 — refine pc2cad strategy. The end-to-end pipeline forks into three reconstruction paths. This is the mechanical / feature-based path — the core path and the one the user cares about most.

What "mechanical" means here

Inputs that are manufactured parts:

Milled/turned/cast parts with planes, cylinders, holes, pockets, slots, ribs, bosses, fillets, chamfers
The user's primary use case: scan a bracket, housing, or fixture and get an editable CAD solid back
Characterized by: dominant planar regions, regular feature patterns, axis-aligned features (drilling/milling axis)

Pipeline characteristics

Input class: point cloud with strong planar + cylindrical structure
Primary primitives: analytic (plane, cylinder, cone, sphere) plus extracted features (holes, pockets, slots, ribs, fillets, chamfers)
Output format: editable STEP with named features as far as possible (a hole is a boolean cut with parameters, not just a missing cylinder in the BREP)
Feature detection: aggressive — every primitive must be classified as a feature
Topology: watertight solids required (mechanical parts have closed geometry)

What to design

Feature detection — extend the existing cylinder fit into a feature classifier. For each fitted cylinder: is it a hole, a boss, a bore, a fillet? For each fitted plane: is it a base, a step, a pocket floor? For each fitted cone: countersink or cone?
Boolean assembly — features combine via boolean ops. Document the rule order: subtract holes first, then add/subtract bosses, then fillets, then chamfers. Each feature has a parameter set that survives in the STEP.
Parameter preservation — when exporting STEP, ensure each feature has identifying metadata so a downstream CAD user can edit the radius of a hole without losing the feature history. This means: name features, store parameters as USER properties on the STEP entities where possible.
MVP — the smallest mechanical part that exercises every feature type. Candidate: a flat plate with one counterbored hole, one through hole, one slot, one rib, two fillets, one chamfer. If this works, the pipeline handles real parts.
Test corpus — at minimum: 5 synthetic mechanical parts covering the feature mix, 2 real scans (the user has one). All scans stored under samples/.

Scope

In scope: design doc for the mechanical path. Defines feature detection rules, boolean assembly order, parameter preservation strategy, MVP scope, test corpus.
Out of scope: implementing the feature classifier (separate tickets #11, #12, #13, #14 already cover pieces). This is the STRATEGY for the path, not the implementation.

Acceptance

Document at docs/STRATEGY-MECHANICAL.md covering: feature classification rules, boolean assembly order, parameter preservation strategy, MVP scope with specific test part, test corpus list
Cross-references to existing tickets (#6 profile operations, #11 plane fitting, #12 input constraints, #13 adjacency fusing, #14 hole detection) showing how each contributes to the path
Decision recorded in #15 as a link back to this child

Why this matters

The mechanical path IS the product. Without a unifying design, the existing tickets (#6, #11, #12, #13, #14) are islands. The user will need a single document that says "here is how all the pieces fit together" before any of them can land without breaking the others.

## Parent Part of #15 — refine pc2cad strategy. The end-to-end pipeline forks into three reconstruction paths. This is the **mechanical / feature-based path** — the core path and the one the user cares about most. ## What "mechanical" means here Inputs that are manufactured parts: - Milled/turned/cast parts with planes, cylinders, holes, pockets, slots, ribs, bosses, fillets, chamfers - The user's primary use case: scan a bracket, housing, or fixture and get an editable CAD solid back - Characterized by: dominant planar regions, regular feature patterns, axis-aligned features (drilling/milling axis) ## Pipeline characteristics - **Input class:** point cloud with strong planar + cylindrical structure - **Primary primitives:** analytic (plane, cylinder, cone, sphere) plus extracted features (holes, pockets, slots, ribs, fillets, chamfers) - **Output format:** editable STEP with named features as far as possible (a hole is a boolean cut with parameters, not just a missing cylinder in the BREP) - **Feature detection:** aggressive — every primitive must be classified as a feature - **Topology:** watertight solids required (mechanical parts have closed geometry) ## What to design 1. **Feature detection** — extend the existing cylinder fit into a feature classifier. For each fitted cylinder: is it a hole, a boss, a bore, a fillet? For each fitted plane: is it a base, a step, a pocket floor? For each fitted cone: countersink or cone? 2. **Boolean assembly** — features combine via boolean ops. Document the rule order: subtract holes first, then add/subtract bosses, then fillets, then chamfers. Each feature has a parameter set that survives in the STEP. 3. **Parameter preservation** — when exporting STEP, ensure each feature has identifying metadata so a downstream CAD user can edit the radius of a hole without losing the feature history. This means: name features, store parameters as USER properties on the STEP entities where possible. 4. **MVP** — the smallest mechanical part that exercises every feature type. Candidate: a flat plate with one counterbored hole, one through hole, one slot, one rib, two fillets, one chamfer. If this works, the pipeline handles real parts. 5. **Test corpus** — at minimum: 5 synthetic mechanical parts covering the feature mix, 2 real scans (the user has one). All scans stored under `samples/`. ## Scope - **In scope:** design doc for the mechanical path. Defines feature detection rules, boolean assembly order, parameter preservation strategy, MVP scope, test corpus. - **Out of scope:** implementing the feature classifier (separate tickets #11, #12, #13, #14 already cover pieces). This is the STRATEGY for the path, not the implementation. ## Acceptance - Document at `docs/STRATEGY-MECHANICAL.md` covering: feature classification rules, boolean assembly order, parameter preservation strategy, MVP scope with specific test part, test corpus list - Cross-references to existing tickets (#6 profile operations, #11 plane fitting, #12 input constraints, #13 adjacency fusing, #14 hole detection) showing how each contributes to the path - Decision recorded in #15 as a link back to this child ## Why this matters The mechanical path IS the product. Without a unifying design, the existing tickets (#6, #11, #12, #13, #14) are islands. The user will need a single document that says "here is how all the pieces fit together" before any of them can land without breaking the others.