Support weakly-visible hull facets with threshold-based orientation tests

[acgetchell]

Problem

The current hull extension algorithm uses strictly visible facets, treating coplanar cases (orientation == 0) as non-visible to avoid numerical instability. While this is conservative and safe, it can reject valid insertions when points are very close to the hull surface, triggering "No visible boundary facets" errors.

Current Behavior

From src/core/algorithms/incremental_insertion.rs:1030-1031:

let is_visible = (orientation_with_opposite > 0 && orientation_with_point < 0)
    || (orientation_with_opposite < 0 && orientation_with_point > 0);

This requires strictly opposite orientation signs, rejecting coplanar cases entirely.

Mitigation in Place

The progressive perturbation retry system (Triangulation::insert_transactional) currently handles this by perturbing nearly-coplanar points away from the hull surface with escalating scales (1e-4 → 5e-2 over 5 attempts). This works well in practice but adds retry overhead.

Proposed Enhancement

Implement weakly visible facet detection with epsilon-based threshold:

// Weakly visible: opposite sides OR nearly coplanar
let is_weakly_visible = orientation_with_opposite * orientation_with_point < 0;

This would treat nearly-coplanar facets as visible, reducing reliance on perturbation retries.

Implementation Considerations

From TODO comment (lines 1024-1029):

1. Configurable epsilon threshold based on coordinate type (f32 vs f64) and input scale
2. Careful edge case handling to avoid creating degenerate cells
3. Testing with various numerical precision scenarios
4. Kernel integration - should this be FastKernel vs RobustKernel behavior?

Open Questions

• Should weakly-visible behavior be:
  • Default for all kernels?
  • RobustKernel-only feature?
  • User-configurable option?
• What epsilon values work well across f32/f64 and different coordinate scales?
• How does this interact with the existing perturbation retry system?

Priority

Low-Medium - Current perturbation retry system handles this adequately, but a direct solution would be cleaner and more efficient.

References

• src/core/algorithms/incremental_insertion.rs:1024-1029 (TODO comment)
• src/core/triangulation.rs:562-638 (progressive perturbation implementation)

[acgetchell]

Blocked on public topology traversal API (planned for v0.7.0). Will re-evaluate after merge.