Otherwise, we might merge in ways that make things slower (because
the bboxes aren't as tight) or less robust (because the
intersection needs to be split in more places, and that might fail).
[git-p4: depot-paths = "//depot/solvespace/": change = 2003]
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]
empty (no trims) surfaces. It will generate a screwy bounding box,
which will make things break numerically later.
[git-p4: depot-paths = "//depot/solvespace/": change = 1979]
of revolution, and put them in the same form as if they had been
draw by an extrusion (so that we can use all the same special case
intersection curves).
And add code to merge coincident faces into one. That turns out to
be more than a cosmetic/efficiency thing, since edge splitting
fails at the join between two coincident faces.
[git-p4: depot-paths = "//depot/solvespace/": change = 1965]
Jonathan Westhues