--- Operating System, Graphics card ---
OS X, Windows 7, MacBook Pro
--- Blender version with error, and version that worked ---
2.5, 2.68a and 2.68 have errors
--- Short description of error ---
Carve Library has bugs resulting in broken, non-manifold mesh output when certain (even relatively straightforward) types of geometry are boolean processed. These errors show up when running the Carve library standalone from Windows command line or from within Blender.
--- Steps for others to reproduce the error (preferably based on attached .blend file) ---
The bug as reported for the Carve, http://code.google.com/p/carve/issues/detail?id=39, shows up as well in blender using the same data. The blend file, the original .ply files, and my centred-around-zero versions are included here along with screen shots from Paraview and blender. Note the closed-off cutout as a result of a difference operation. I also removed the xyz offset from that data and the result is the same. This, along with other experience, seems to indicate that it is not a numerical or "epsilon" problem, but a real logical/algorithmic one.
We came to this point while experimenting with swept **volumes** in Blender. Using Python scripting to step and repeat a solid object while performing union or difference boolean operations at each step, we had hoped to simulate collision, some clever CSG, and complex cutting type operations.
"Screen Shot 2013-08-09 at 13.22.27.png" and "Screen Shot 2013-08-08 at 20.04.50.png"
show the results of moving a cylinder a number of times to create a single solid. One works and one fails dramatically. We cannot thus far find a set of variables that do not fail eventually, and have traced the behaviour back to the spurious output of Carve rather than any spurious input to Carve. This does not seem to be related to mesh complexity either. Some tests fail much later than others and after many iterations by which time a complex solid mesh has been built up. Other subtly different tests result in very early failure after a small number of iterations.
Clearly Carve is not robust as advertised! This kind of CGS bug, sadly, makes Blender virtually useless when using this fundamentally important primitive.
--- Suggested fixes ---
Fix Carve.
Possibly use a different another library such as GTS, CGAL???
Description
Event Timeline
Carve was never advertised to be a robust for open manifolds, it just designed to be used for closed manifolds. But in your case mesh is actually closed manifold, just does have duplicated geometry. Removing doubles would make your mesh behave properly. It is known issue in Carve library, nothing to do with blender.
GTS is not impressive code-wise and not maintained at all, CGAL doesn't have CSG operations it seems.
Thanks for the report, but it's not about being useless. Just degenerated mesh in -> garbage out.
Sergey,
Thanks for the fast response, but I don't believe this solves a broader problem. In my own original case using repetitive sum of Blender cylinder objects, I get Carve to fail easily. I believe that in even with good-in, carve produces garbage out. Certainly it is interesting to see that what Carve sees as decent input, produce bad output. Would it help if I send you my Python script and Bend file?
CGAL does indeed have a comprehensive set of functions all the way up to 3D Minkowski Sum of Polyhedra...
-- see "3D Boolean Operations on Nef Polyhedra" in http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html#part_II
I cannot speak to the robustness of CGAL though!
Cheers, Richard.
I'm pretty much sure your script wuld give a case which is already known. If you want to, do a report to Carve's bug tracker.
Other libs are not guaranteed to be the same fast and more robust at all. Couldn't see reason why pushing other libs would either help. Makes more sense to just fix some issues from carve side.
I'm having many "good-in, garbage out" scenarios with carve as well where two manifold input meshes will sometimes return non manifold results. Is Carve even actively maintained? If so, where? I saw something on code.google.com where the last issue was posted 2 years ago and last release 6 years ago and a github repository that was also inactive for 7 years. For what I'm doing right now, if boolean operations were more robust I could eliminate commercial software from my workflow.