Strategy gap: feature detection (holes, gouges, counterbores, slots) is not constrained by the point cloud #34
Labels
No labels
blocked:needs-decision
blocked:preflight
bug
in-progress
in-progress
lint-cleanup
needs-decompose
quickfix
triage-approved
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Mark/pc2cad#34
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Feature detection (holes, gouges, counterbores, slots) not driven by pointcloud constraints
What
pc2cad.pyhas feature detectors for planar pockets(
detect_planar_pockets, line 1207), chamfers (detect_chamfers,line 1292), fillets (
detect_fillets, line 1385), and slots (theslot-pairing block in
derive_profile_operationsaround line1571). Each detector looks for a specific geometric pattern in the
primitive list — pairs of parallel planes, adjacent planes with
matching normals, co-axial cylinder groups.
What they don't do: take the point cloud into account. The
detectors are run on the abstract primitive list, with thresholds
that come from
FitConfig(e.g.chamfer_min_angle_deg,fillet_radius_ratio_max) but no direct check against the inputpoints. A pocket is "detected" if two parallel planes have the
right area ratio — even if the actual point cloud has no pocket
geometry in that region (a false positive from primitive-fit
noise). Conversely, a real pocket in the point cloud can be
missed if the surrounding primitives don't fit the expected
geometric pattern.
The user-facing impact: feature detection is fragile. On real
scans, the fitter produces a primitive list that's noisy enough
that the geometric-pattern tests pass on spurious patterns and
fail on real ones. The
Merge_01_pc.plyRevopoint scan produced3 detected intersections and 3 features in the report, but a
visual comparison shows the analytic fit is mostly wrong about
which surfaces are features vs. body.
Reproduction
Expected
Each detected feature should be verified against the point cloud
in the region the feature claims to be in. A "detected pocket"
should produce a fitted pocket in the point cloud (a region of
points on the inner plane, not just two planes with the right
area ratio in the primitive list).
Actual
Feature detection runs on the primitive list only. No
point-cloud-constrained verification. False positives from
spurious primitive fits pass straight through.
Suggested fix (not for me to implement)
Add a pointcloud-constrained verification step to each feature
detector. After the geometric-pattern test passes, sample the
input points in the candidate feature's region and check whether
they actually fit the feature's geometric model (pocket depth,
hole radius, slot profile). Reject features whose pointcloud
support is below a confidence threshold.
Related
feature verification can't be done visually either)
2026-06-20 review)