Modeling Algorithms - Fix edge extended beyond both vertices by fille…

[angelobartolome]

Pre-Submission Checks

• I checked existing issues, pull requests, discussions, and forum topics for related work.
• I followed the contribution guidance in .github/CONTRIBUTING.md.
• I used a PR title in the Group - Summary format.

Problem / Motivation

Two concave fillets that each build a valid solid on their own give an open shell when built together, if both fillet ends cross the same edge outside it: one beyond each of its vertices. BRepCheck reports four wires and the shell BRepCheck_NotClosed and four faces BRepCheck_UnorientableShape. The volume drops by 1567.31 instead of growing by 396.12.

Reduced case: a plate standing on a cylinder, with the end caps unified with the plate's coplanar sides up to z = 40, where the plate's outline leans outwards. Fillets of radius > 5/3 on the two lines where the plate meets the cylinder are trimmed by the leaning face, and each crosses the z = 40 edge of the end face beyond one of its vertices, at parameters −0.6282 and 20.6282 on a [0, 20] edge. ChFi3d's data structure holds both points correctly. The rebuilt edge runs from −0.6282 to the edge's own vertex at 20, so the wires around the other end don't close. The same failure shows up on a real part (fillet R50 between a clamp's plate and its bore).

Proposed Solution

TopOpeBRepBuild_PaveSet::Prepare adds the edge's own vertices to the interference points before the paves are grouped into edges. On this edge the sorted paves are FORWARD (−0.6282), FORWARD (vertex, 0), REVERSED (vertex, 20), REVERSED (20.6282). In TopOpeBRepBuild_Area1dBuilder, the pave at −0.6282 opens an area. Both vertices join it, because a boundary loop is only tested against the area's block loops. The pave at 20.6282 is then OUT of the REVERSED vertex at 20, so it starts an area of its own. MakeEdges drops that area because it holds a single pave.

With one fillet the vertices are processed before any area exists. They then go through the mutual IN test that keeps the vertex at 0 and rejects the one at 20, so the edge comes out right only because of the processing order.

The fix is in Prepare: a bounding vertex of an open edge is no longer added when an interference point with the same orientation lies beyond it (by more than Precision::PConfusion()). The edge is extended past that vertex, so the vertex lies inside the new edge and shouldn't bound an area. Closed edges (FUN_islook) and degenerated edges keep the previous behaviour.

Validation

Checks performed:

• Relevant tests were added or updated when applicable.
• Relevant local tests were run.

Local macOS arm64 Debug (OpenCascadeGTest):

• New: BRepFilletAPI_MakeFilletTest.FilletEndsCrossingSharedEdgeBeyondBothVertices. It builds the reduced shape through the API and checks that each fillet alone and both together are valid, and that the volume changes add up (547193.04; 545229.61 before the fix).
• All suites in TKFillet/GTests and TKBool/GTests (fillet, chamfer, ChFi3d, BRepAlgo, BRepAlgoAPI, TopOpeBRepBuild, TopOpeBRepDS, TopOpeBRepTool): 66/66 pass; before the fix the new test was the only failure.
• Full OpenCascadeGTest: 9157 passed, 3 skipped (missing reference data, unrelated to this fix), 0 failed.
• DRAW: the reduced script and the original part (fillet R50 on two edges) give valid shapes, and each fillet adds the volume it adds alone. Radii 1, 1.5, 2, 5 and 10 on the reduced shape are all valid and additive.

CLA Confirmation

• I confirm that I have read the contribution requirements, and that I have signed and submitted the CLA or I am covered by an approved company CLA.

CLA ID / submission reference: 1144

[angelobartolome]