ConformalRender: add preprocessing (split_pinches, split_t_junctions!)

[ybrightye]

Adds two geometry-preprocessing utilities to ConformalRender that
downstream users otherwise have to reimplement locally to feed clean
input to render_conformal!.

Motivation

After boolean operations (union2d_curved, difference2d_curved,
etc.) hand back a Vector{CurvilinearRegion}, two classes of topology
bug can still make OCC or the mesher reject the geometry:

1. Self-touching contours (pinches). Clipper's union can produce
   polygons where two non-adjacent vertices coincide — a zero-width
   neck or figure-8. OCC rejects these with "Curve loop is not
   closed".
2. T-junctions across group boundaries. When two adjacent groups
   share a boundary but Clipper doesn't put a vertex at the same
   location on both sides, TetGen rejects the input with "vertex lies
   in segment" PLC errors.

Neither is caught by the existing render_conformal! cache — that
cache assumes correct topology going in.

API

Three new symbols exported from DeviceLayout.SolidModels (also
available via DeviceLayout.SolidModels.ConformalRender):

• find_pinch_points(pts; atol_nm=2.0) — O(n) hash-grid detector for
  coincident non-adjacent contour vertices. Returns (i, j) index
  pairs.
• split_pinches(regions) — splits every self-touching region (on the
  exterior AND every hole) into simple sub-regions. Curves are
  preserved by remapping curve_start_idx. Sub-loops with < 3
  vertices are dropped as zero-area slivers.
• split_t_junctions!(target, sources...) — injects on-edge vertices
  from sources into edges of target, restoring 1:1 edge
  correspondence. Straight edges get the foreign Point verbatim
  (bit-exact — the cached point merge unifies the two copies at
  render). Paths.Turn curves get split via Paths.split at the
  appropriate arclength so sub-arcs remain native.

All three operate on native curve types (Paths.Turn,
Paths.BSpline, Paths.OffsetSegment) with no discretization.

Typical usage

using DeviceLayout.SolidModels: split_pinches, split_t_junctions!,
                                render_conformal!

groups = compute_groups(cs)                     # boolean output

# Restore 1:1 edge correspondence between adjacent groups.
split_t_junctions!(groups[:base_negative],
                   groups[:bp], groups[:l2_gnd])

# Clean self-touching pieces before render.
groups[:base_negative] = split_pinches(groups[:base_negative])

render_conformal!(sm, cs; context=ctx)

Tests

6 new testsets in test_conformal_render.jl:

• find_pinch_points detects self-touching contours
• find_pinch_points returns empty for a clean polygon
• split_pinches splits a figure-8 into two simple loops
• split_pinches leaves clean regions untouched
• split_t_junctions! injects a foreign midpoint on a straight edge
• split_t_junctions! is a no-op when no source vertex lies on target
• split_t_junctions! splits a Paths.Turn at a foreign point on the
  arc

Pkg.test locally: 55/55 pass. Formatter clean.

Not in this PR

• Curve-aware mutual noding (broader whole-groups pass) — depends on
  arc-recovery helpers; separate follow-up.
• Ramer-Douglas-Peucker polyline decimation — not exercised in the
  simple 2 nm-tolerance regime; separate follow-up if requested.

[codecov]

Codecov Report

❌ Patch coverage is 90.42146% with 25 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/solidmodels/conformal/preprocess.jl	90.42%	25 Missing ⚠️

📢 Thoughts on this report? Let us know!

[gpeairs]

Clipper's union can produce polygons where two non-adjacent vertices coincide

Do you have test cases coming out of Clipper? In simple examples it seems to separate contours that touch at a point.

[ybrightye]

You're right that direct Clipper on simple touching shapes doesn't produce pinches — it separates them into distinct polygons. I added a testset that documents this (Clipper does not produce pinches on simple touching shapes, in b1cad18) covering diagonal-touching rectangles and hourglass triangles.

The failure mode split_pinches is actually defending against is post-Clipper: when a downstream pipeline runs a symmetric shared-boundary vertex-injection pass to align adjacent physical groups' outlines (so their common boundary carries a bit-identical vertex sequence, which the conformal shared-edge cache needs), that injection can create pinches on Clipper-clean inputs.

Concretely (also as a testset in b1cad18, find_pinch_points catches noding-induced pinches):

• Region A is a top slab with a V-notch touching the shared edge y=0 at (150 µm, 0). A's outline visits (150, 0) once — as the notch tip.
• Region B is a bottom slab with an on-edge port anchor vertex at (150, 0). B's shared-edge traversal is broken at that anchor.
• A's shared-edge traversal in the Clipper output is one long segment (-300, 0) → (300, 0), no interior vertex at x=150.
• The noding step scans A's edges for donor vertices from B. B has (150, 0) strictly interior to that edge → inserts (150, 0) into A between (-300, 0) and (300, 0).
• Now A's outline visits (150, 0) at two non-adjacent positions: the injected one and the original notch tip. That's a figure-8 that OCC rejects with Curve loop is not closed.

I also added an end-to-end testset (76ab7f6, render_conformal! fails on pinched outline, split_pinches fixes it) that builds this pinched CurvilinearRegion, calls render_conformal! (@test_throws ErrorException), then runs split_pinches first and asserts the render completes.

If you'd rather scope this PR down to just split_t_junctions! and hold split_pinches until I upstream the noding pass itself (last big preprocessing chunk on my list), happy to do that — but the two are naturally paired since the T-junction split introduces the vertices that can pinch. Your call.

Also worth flagging: find_pinch_points uses atol_nm::Float64=2.0 in the docstring but its impl calls ustrip(getx(p)) without a target unit, so it strips whatever unit the point carries. Points in μm get compared with a numeric-2.0 tolerance interpreted as their raw unit's scale — I hit false-positive pinches with small-coord test inputs (<2 µm apart) before switching to ~100 µm coordinates. Might want to either doc that the caller is responsible for the input unit or ustrip(u"nm", ...) explicitly.

[gpeairs]

Yes, let's scope down to just splitting T junctions for now.

That's also a feature that's useful for avoiding 1nm gaps due to grid rounding for GDS output, so I'd request putting this in src/postrender.jl (can see it as either a 2D geometry postrendering operation or preprocessing for 3D) and including a method that takes Polygon vectors as input.

On the unit issue, we have the onenanometer(T) idiom that avoids ustrip everywhere entirely. Things like tol = 50.0, perp_tol = 3.0, len_sq < 1.0, bbox pad 5.0 can be mytol*onenanometer(T) etc where the methods take ::T rather than Float64. I don't think any of the conversions back and forth are necessary. Tests should verify output is the same regardless of input coordinate type.

Those tolerances (and the 0.01 radian angular tolerance) also have an unclear relationship to other default tolerances (in particular the default 1nm rendering tolerance, the GDS 1nm grid, or the vertex merge tolerance for render_conformal!). Right now it seems like you can get conflicts with supposed guarantees where the tolerance admits split points that don't get merged or skips vertices that wouldn't normally be mergeable. Ideally they would be configured by a small number of unit-correct keyword arguments (or derived from a small number of constants) with meaningful names.

[gpeairs]

I don't think the ustrips are necessary, and they're not idiomatic for lengths or for angles. Also ustrip without a unit is not correct for arbitrary unitful coordinate type T as you flagged elsewhere.

[gpeairs]

dθ = rem2pi(θ - θ_start, RoundNearest)?

[gpeairs]

You shouldn't need to ustrip any angles, but if you did, ustrip(NoUnits, turn.α0) would give you the angle in radians as Float64 without having to know the implementation detail that turn.α0 is typeof(1.0°).

[gpeairs]

This is not actually the on-arc point sub_turns[2](zero(l)) but the point from split_pts which may be up to 50nm away, which will break the CurvilinearPolygon (which has 1e-3 nm tolerance in the constructor for point deduplication and in to_polygons for agreement between the points field and curve endpoints). But if you do use the on-arc point then the split_pts version doesn't get merged because the merge tolerance is much smaller. I think you do want to use the actual on-arc point, and probably a tighter tolerance.

[gpeairs]

For CW arcs (e.g. from CurvilinearRegion holes), this means points will be processed starting from the end, which will give incorrect results if there are multiple on-arc points. Sorting by sign(turn.α) * dθ should work, along with a test covering multiple T junctions on a hole.

[gpeairs]

Avoid Any in a container, something like Point{coordinatetype(target_regions)} would be better

[gpeairs]

Why is this tolerance so large?

[gpeairs]

compute_groups isn't a function in this package and I'm not sure what "boolean output" means here. Maybe clearer to say something like

target_regions = union2d_curved(cs => :metal_negative) # Returns Vector{<:CurvilinearRegion}
source_regions = union2d_curved(cs => :metal_positive)
split_t_junctions!(target_regions, source_regions)

[gpeairs]

Docstring could be clearer that inputs are iterables over CurvilinearRegion