Make ShapeElement::contains() always accept an endpoint - #46
Merged
Conversation
A point equal (within tolerance) to an element's own start or end point could still be rejected: for a LineSegment, the betweenness check's distance-sum excess grows about twice as fast as the endpoint distance itself near an endpoint; for a CircularArc, the stored endpoint isn't always perfectly consistent with its own center and radius. Both let contains() reject an element's own endpoint, which made compute_start_element_pos() pick a wrong starting element and produce a degenerate (negative-area) outline during boolean union. Also updates the expected output of InflateShapeTest.InflateShape/2. Fixing contains() lets the union pipeline detect a genuine (if sub-tolerance, ~9e-7) line/arc intersection it previously missed near one joint, which changes which of two near-duplicate offset arcs (both independently derived from adjacent pieces in offset.cpp's per-edge decomposition) the graph trace follows. The new arc is a valid, self-consistent circular arc, but its center/radius are off from the mathematically exact concentric offset by ~1e-6, versus ~1e-14 before (both well under the 1e-4 scale a user would ever notice). This is a known, small precision side effect of a pre-existing redundancy in how offset.cpp derives shared joints, not something this change attempts to fix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A point equal (within tolerance) to an element's own start or end point could still be rejected: for a LineSegment, the betweenness check's distance-sum excess grows about twice as fast as the endpoint distance itself near an endpoint; for a CircularArc, the stored endpoint isn't always perfectly consistent with its own center and radius. Both let contains() reject an element's own endpoint, which made compute_start_element_pos() pick a wrong starting element and produce a degenerate (negative-area) outline during boolean union.
Also updates the expected output of InflateShapeTest.InflateShape/2. Fixing contains() lets the union pipeline detect a genuine (if sub-tolerance, ~9e-7) line/arc intersection it previously missed near one joint, which changes which of two near-duplicate offset arcs (both independently derived from adjacent pieces in offset.cpp's per-edge decomposition) the graph trace follows. The new arc is a valid, self-consistent circular arc, but its center/radius are off from the mathematically exact concentric offset by ~1e-6, versus ~1e-14 before (both well under the 1e-4 scale a user would ever notice). This is a known, small precision side effect of a pre-existing redundancy in how offset.cpp derives shared joints, not something this change attempts to fix.