cam_blend: seam_matches debug-assert panics on near-degenerate hosts from acute-corner ring offsets #98
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?
Found while wiring blend visualization (PR #97) into the STEP wedge showcase scene (PR #96).
Repro:
blend_passon any ring pass of thefilleted_wedge_platescene (cam_viz::scene::build_scene("d")with a nonzeroblend_corridor) panics at theseam_matchesdebug assertion (CAM/blend/src/junctions.rs:706).Key observation: corridor-magnitude-independent — reproduces at 4 µm, 1 µm, and 1 nm, so it is not a tolerance-tuning issue.
Analysis: the wedge plate has an acute ~56° corner;
plan_ringsinward offsets drive that corner toward a near-medial-axis collapse.min_blend_chordanticipates near-degenerate hosts but theforce_skippre-filter does not account for post-halving trim shrinkage, so near-degenerate hosts slip into theBlendoutcome ofresolve_junction, where the seam invariant then fails.Current workaround: scene d plans with
blend_corridor = ZEROandcam_viz::scene::build_scenehas askip_blendsguard (doc comment there cross-references this limitation). NoteBlendParams::validate()also rejectsmax_deviation == 0, so zero-corridor cannot be expressed throughblend_passitself — worth deciding whether zero should mean "no blending" at the API level.Suggested fix direction: extend
force_skipto account for post-halving trim shrinkage, or degrade to a Host passthrough when the seam invariant cannot be met, rather than debug-asserting.