Jonathan Westhues a74f85e0d1 I had been using LENGTH_EPS as the tolerance on both xyz points and ... uv points. This is inconsistent, unless the surface happens to be a plane square with side length one. So modify the SBspUv tests to take a surface, and measure distance linearized in that surface. That fixes at least one mis-classification bug, and doesn't seem to break anything. [git-p4: depot-paths = "//depot/solvespace/": change = 2005]		2009-07-01 19:32:17 -08:00
..
boolean.cpp	I had been using LENGTH_EPS as the tolerance on both xyz points and	2009-07-01 19:32:17 -08:00
curve.cpp	Add beginnings of marching surface intersection; I can find all the	2009-06-18 23:56:33 -08:00
merge.cpp	Don't merge two coincident surfaces unless they share an edge.	2009-06-29 20:38:40 -08:00
ratpoly.cpp	Now we are actually marching. There seems to be either a numerical	2009-06-21 01:02:36 -08:00
raycast.cpp	I had been using LENGTH_EPS as the tolerance on both xyz points and	2009-07-01 19:32:17 -08:00
surface.cpp	Clean up the marching step size / chord tol stuff, and add code to	2009-06-21 18:54:09 -08:00
surface.h	I had been using LENGTH_EPS as the tolerance on both xyz points and	2009-07-01 19:32:17 -08:00
surfinter.cpp	I had been using LENGTH_EPS as the tolerance on both xyz points and	2009-07-01 19:32:17 -08:00
triangulate.cpp	When exporting STEP, identify the outer contours, and group them	2009-06-08 08:21:33 -08:00