Strategy gap: feature detection (holes, gouges, counterbores, slots) is not constrained by the point cloud #34

Closed
opened 2026-06-20 20:07:25 +00:00 by Mark · 0 comments
Owner

Feature detection (holes, gouges, counterbores, slots) not driven by pointcloud constraints

What

pc2cad.py has feature detectors for planar pockets
(detect_planar_pockets, line 1207), chamfers (detect_chamfers,
line 1292), fillets (detect_fillets, line 1385), and slots (the
slot-pairing block in derive_profile_operations around line
1571). 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 input
points. 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.ply Revopoint scan produced
3 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

cd ~/Projects/pc2cad
./.venv/bin/python pc2cad_cli.py tests/fixtures/Merge_01_pc.ply \
  --out /tmp/test.brep --report /tmp/test_report.json
python -c "
import json
r = json.load(open('/tmp/test_report.json'))
print('features:', r.get('features', []))
print('pockets:', r.get('pockets', []))
print('holes:', r.get('holes', []))
print('chamfers:', r.get('chamfers', []))
print('fillets:', r.get('fillets', []))
print('slots:', r.get('slots', []))
"

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.

  • pc2cad#29 (pipeline doesn't persist the freeform mesh, so
    feature verification can't be done visually either)
  • pc2cad#32-34 (the other "missing strategy" bugs from the
    2026-06-20 review)
# Feature detection (holes, gouges, counterbores, slots) not driven by pointcloud constraints ## What `pc2cad.py` has feature detectors for planar pockets (`detect_planar_pockets`, line 1207), chamfers (`detect_chamfers`, line 1292), fillets (`detect_fillets`, line 1385), and slots (the slot-pairing block in `derive_profile_operations` around line 1571). 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 input points. 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.ply` Revopoint scan produced 3 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 ```bash cd ~/Projects/pc2cad ./.venv/bin/python pc2cad_cli.py tests/fixtures/Merge_01_pc.ply \ --out /tmp/test.brep --report /tmp/test_report.json python -c " import json r = json.load(open('/tmp/test_report.json')) print('features:', r.get('features', [])) print('pockets:', r.get('pockets', [])) print('holes:', r.get('holes', [])) print('chamfers:', r.get('chamfers', [])) print('fillets:', r.get('fillets', [])) print('slots:', r.get('slots', [])) " ``` ## 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 - pc2cad#29 (pipeline doesn't persist the freeform mesh, so feature verification can't be done visually either) - pc2cad#32-34 (the other "missing strategy" bugs from the 2026-06-20 review)
Mark 2026-06-21 18:50:12 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/pc2cad#34
No description provided.