zcy
/
solvespace
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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]
solver
Jonathan Westhues 2009-06-25 03:58:39 -08:00
parent 3da334028e
commit cf77e51ddc
1 changed files with 12 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
srf/merge.cpp
View File

@ -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.