solvespace/srf
Jonathan Westhues d3dcd8fb23 Now we are actually marching. There seems to be either a numerical
problem or a tendency to generate backwards edges or both, need to
debug that. But it generates the curve, and begins to work.

And change the edge classification. Now instead of testing for
point-on-surface using the results of the raycasting, test for
point-on-surface as a separate step. That stops us from picking up
the additional numerical error from the surface-line intersection,
which may be significant if the ray is parallel or almost parallel
to the surface.

[git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 01:02:36 -08:00
..
boolean.cpp Add beginnings of marching surface intersection; I can find all the 2009-06-18 23:56:33 -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 Oops, don't let the coincident surface merging stuff try to merge 2009-06-10 00:26:09 -08:00
ratpoly.cpp Now we are actually marching. There seems to be either a numerical 2009-06-21 01:02:36 -08:00
surface.cpp Add beginnings of STEP export, which weren't as horrible as I had 2009-06-07 22:50:16 -08:00
surface.h Add beginnings of marching surface intersection; I can find all the 2009-06-18 23:56:33 -08:00
surfinter.cpp Now we are actually marching. There seems to be either a numerical 2009-06-21 01:02:36 -08:00
triangulate.cpp When exporting STEP, identify the outer contours, and group them 2009-06-08 08:21:33 -08:00