Refine pc2cad strategy: end-to-end ply → editable CAD pipeline review #15

New issue

Closed

opened 2026-06-17 18:24:23 +00:00 by Mark · 0 comments

Mark commented

2026-06-17 18:24:23 +00:00

Owner

Context

During a working session on 2026-06-17 we discovered that pc2cad's current point-cloud → CAD pipeline has several strategy gaps that interact poorly with real mechanical-part scans:

Mesh vs CAD output confusion — STL/OBJ output was removed entirely as 'out of scope' (#9 was the aborted attempt), but users legitimately want a fast STL preview of the analytic reconstruction alongside the STEP. The session that removed it then created #10 to add it back as a first-class export option.
Plane fitting is brittle — single global RANSAC threshold + no per-segment confidence + no coverage reporting (#11 tracks hardening).
No hole detection — the user's primary use case (mechanical parts) requires detecting and boolean-cutting holes from cylinder fits, not just listing cylinders (#14).
No detection of pockets, slots, bosses, ribs, fillets, chamfers — the rest of feature detection from Milestone 2 in PLAN.md.
Adjacency-driven fusing can over-fuse — coplanar faces get merged, destroying features (#13).
Noisy real-world scans not handled robustly — density variation, outliers, missing regions, unit confusion (#12).
Profile operations extracted but not exported — extrude/revolve profiles from planar sections are computed but never reach STEP/FCStd (#6, reopened today).
No topology graph / adjacency-driven editing — once features are detected, there's no way to navigate the CAD tree, edit a single feature, and re-derive downstream features (Milestone 3 in PLAN.md).

This issue is for the strategic review of the END-TO-END pipeline — not any single feature. The goal is to define the right order, scope, and dependencies between #10, #11, #12, #13, #14, plus the remaining Milestone 2 features, before more tickets get created in isolation.

Goals

Document the end-to-end workflow as it should work for a real mechanical-part scan:
- Input: PLY scan of a part with holes, ribs, a counterbore, fillets
- Stages: load → preprocess (outliers, density, units) → plane fit → cylinder/cone/sphere fit → feature detection (holes, pockets, etc.) → topology graph → CAD solid assembly → export STEP + optional STL preview
- For each stage: what goes in, what comes out, success criteria, failure modes
Define the MVP slice — the smallest end-to-end pipeline that produces a usable editable CAD solid for a real part. Candidate: a part with one base, one counterbored hole, one rib. Should pass through all stages.
Order the existing issues — what's the dependency graph between #10, #11, #12, #13, #14, #6, and the yet-to-be-created pockets/slots/bosses/fillets tickets? Which unblock which?
Define test corpus — what synthetic + real scans do we need to verify each stage? Real scans should be captured under controlled conditions and stored in samples/ (or a separate fixtures repo).
Identify the riskiest single piece — based on current state, what is most likely to derail the whole pipeline? (My read: feature detection — distinguishing holes from bosses from bores, with correct boolean cut direction, is where every prior scan-to-CAD tool has failed.)

Scope

This is a STRATEGY issue, not an implementation issue. The deliverable is a written design document at docs/STRATEGY.md (new file) that:

Defines the end-to-end pipeline with stages, I/O, success criteria
Orders the existing feature tickets by dependency
Defines the MVP test corpus
Identifies the riskiest single piece and proposes a de-risking spike

It is NOT:

Writing any production code
Closing any of the existing feature tickets
Re-architecting the existing code

Acceptance

docs/STRATEGY.md exists, reviewed, and committed to main on a docs branch
The MVP slice is defined with a specific test scan and pass/fail criteria
The existing feature tickets (#10–#14, #6, plus future ones) are referenced by the strategy and the strategy defines which order they should land in
The riskiest-piece section names a specific risk and proposes a time-boxed spike

Why this matters

Without a strategy, we keep creating feature tickets in isolation and ending up with a collection of half-integrated capabilities. The user's session on 2026-06-17 demonstrated exactly this: 5+ feature tickets were created mid-debugging, with no shared understanding of the end-to-end pipeline or which dependencies matter. The next debugging session will hit the same wall unless the strategy is written down first.

## Context During a working session on 2026-06-17 we discovered that pc2cad's current point-cloud → CAD pipeline has several strategy gaps that interact poorly with real mechanical-part scans: 1. **Mesh vs CAD output confusion** — STL/OBJ output was removed entirely as 'out of scope' (#9 was the aborted attempt), but users legitimately want a fast STL preview of the analytic reconstruction alongside the STEP. The session that removed it then created #10 to add it back as a first-class export option. 2. **Plane fitting is brittle** — single global RANSAC threshold + no per-segment confidence + no coverage reporting (#11 tracks hardening). 3. **No hole detection** — the user's primary use case (mechanical parts) requires detecting and boolean-cutting holes from cylinder fits, not just listing cylinders (#14). 4. **No detection of pockets, slots, bosses, ribs, fillets, chamfers** — the rest of feature detection from Milestone 2 in PLAN.md. 5. **Adjacency-driven fusing can over-fuse** — coplanar faces get merged, destroying features (#13). 6. **Noisy real-world scans not handled robustly** — density variation, outliers, missing regions, unit confusion (#12). 7. **Profile operations extracted but not exported** — extrude/revolve profiles from planar sections are computed but never reach STEP/FCStd (#6, reopened today). 8. **No topology graph / adjacency-driven editing** — once features are detected, there's no way to navigate the CAD tree, edit a single feature, and re-derive downstream features (Milestone 3 in PLAN.md). This issue is for the strategic review of the END-TO-END pipeline — not any single feature. The goal is to define the right order, scope, and dependencies between #10, #11, #12, #13, #14, plus the remaining Milestone 2 features, before more tickets get created in isolation. ## Goals 1. **Document the end-to-end workflow** as it should work for a real mechanical-part scan: - Input: PLY scan of a part with holes, ribs, a counterbore, fillets - Stages: load → preprocess (outliers, density, units) → plane fit → cylinder/cone/sphere fit → feature detection (holes, pockets, etc.) → topology graph → CAD solid assembly → export STEP + optional STL preview - For each stage: what goes in, what comes out, success criteria, failure modes 2. **Define the MVP slice** — the smallest end-to-end pipeline that produces a usable editable CAD solid for a real part. Candidate: a part with one base, one counterbored hole, one rib. Should pass through all stages. 3. **Order the existing issues** — what's the dependency graph between #10, #11, #12, #13, #14, #6, and the yet-to-be-created pockets/slots/bosses/fillets tickets? Which unblock which? 4. **Define test corpus** — what synthetic + real scans do we need to verify each stage? Real scans should be captured under controlled conditions and stored in `samples/` (or a separate fixtures repo). 5. **Identify the riskiest single piece** — based on current state, what is most likely to derail the whole pipeline? (My read: feature detection — distinguishing holes from bosses from bores, with correct boolean cut direction, is where every prior scan-to-CAD tool has failed.) ## Scope This is a STRATEGY issue, not an implementation issue. The deliverable is a written design document at `docs/STRATEGY.md` (new file) that: - Defines the end-to-end pipeline with stages, I/O, success criteria - Orders the existing feature tickets by dependency - Defines the MVP test corpus - Identifies the riskiest single piece and proposes a de-risking spike It is NOT: - Writing any production code - Closing any of the existing feature tickets - Re-architecting the existing code ## Acceptance - `docs/STRATEGY.md` exists, reviewed, and committed to `main` on a docs branch - The MVP slice is defined with a specific test scan and pass/fail criteria - The existing feature tickets (#10–#14, #6, plus future ones) are referenced by the strategy and the strategy defines which order they should land in - The riskiest-piece section names a specific risk and proposes a time-boxed spike ## Why this matters Without a strategy, we keep creating feature tickets in isolation and ending up with a collection of half-integrated capabilities. The user's session on 2026-06-17 demonstrated exactly this: 5+ feature tickets were created mid-debugging, with no shared understanding of the end-to-end pipeline or which dependencies matter. The next debugging session will hit the same wall unless the strategy is written down first.