From cf77e51ddc6951e39ba042cd2dfe3a7ffc11f351 Mon Sep 17 00:00:00 2001 From: Jonathan Westhues Date: Thu, 25 Jun 2009 03:58:39 -0800 Subject: [PATCH] I think this fixes an issue importing STEP into Rhino. Something bad seems to happen when a trim curve's u or v coordinate goes even slightly outside [0, 1]. And since I considered the bbox of the pwl segments when merging coincident surfaces (and not the true curves), that happened. So add a bit of slop, which seems to make things happy. [git-p4: depot-paths = "//depot/solvespace/": change = 1999] --- srf/merge.cpp | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/srf/merge.cpp b/srf/merge.cpp index e581685..6d08560 100644 --- a/srf/merge.cpp +++ b/srf/merge.cpp @@ -70,6 +70,18 @@ void SShell::MergeCoincidentSurfaces(void) { vmin = min(vmin, vt); } + // An interesting problem here; the real curve could extend + // slightly beyond the bounding box of the piecewise linear + // bits. Not a problem for us, but some apps won't import STEP + // in that case. So give a bit of extra room; in theory just + // a chord tolerance, but more can't hurt. + double muv = max((umax - umin), (vmax - vmin)); + double tol = muv/50 + 3*SS.ChordTolMm(); + umax += tol; + vmax += tol; + umin -= tol; + vmin -= tol; + // We move in the +v direction as v goes from 0 to 1, and in the // +u direction as u goes from 0 to 1. So our normal ends up // pointed the same direction.