Skip to content

kernel: union is operand-order dependent — ring ∪ post exact, post ∪ ring double-covers the overlap caps #892

Description

@ecto

Repro: ring() (r 24..28.75) and post() (8×5×6 cube reaching 0.5 mm into the ring wall), same z range so both caps are coplanar.

volume net-open edges over-used
closed form 4946.55
ring ∪ post 4946.55 ✓ 0 0
post ∪ ring 4951.99 (+5.44) 30 24

+5.44 mm³ is exactly 2 × the overlap cap area (2.717 mm²): the caps over post∩ring (x ∈ [23.87, 24.5], |y| ≤ 2.5, at both z planes) are present twice.

Established (--features debug-boolean, VCAD_SPLIT_DEBUG=1): with the ring as operand B, its annular cap faces are offered the lines y = −2.5, y = +2.5, x = 16.5 and x = 24.5; every split returns "1 sub-faces" silently except x = 24.5. The overlap patch is never cut out of the ring's cap, the whole annulus is kept, and the post's own cap patch (kept as the A-side coplanar face) doubles it. Likely the same root as the many-shell issue: find_line_polygon_crossings only looks at the outer loop, so a chord entering and leaving the outer circle passes through the bore's inner loop and split_face_by_curve cannot partition the face.

Done when: both orders give 4946.55 ± 0.1%, closed.

Found while getting the rana-60-cnc stator to solve (#890). Helpers ring(), post(), fillet_block(side) live in crates/vcad-kernel-booleans/tests/coplanar_cap_union.rs; assert volume against a closed form in any new test — every failure in this family was a plausible mesh of the wrong solid.

🤖 Filed by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingkernelRust kernel cratesrobustnessEdge cases / numerical robustness

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions