Mon, 04/19/2004 - 23:05
I have been experimenting with openCascade boolean operations for about two weeks and my realization is that it is buggy! It works beautifully sometimes and other times it generates really terrible results. BTW, I am using only cut and fuse operations on very simple polyhedral solids. I am wondering if I am doing something wrong or whether it is actually broken. I would really appreciate it if someone can let me know whethter they have been able to get boolean operations to work robustly. I read some past threads on this forum on booleans and it looks like many people have had frustrating experiences with boolean operations.
Also, does anyone know of a good (and robust) boolean library that I can buy? I am willing to pay the OpenCascade guys for support but some past threads on this form indicate that they didn't get much help even after they paid for support. Please also let me know if someone had positive experience with the paid support.
Thanks a lot,
Mon, 04/19/2004 - 23:24
Below you will find a nice description of the boolean operations by Ames Arlo. It is related to some questions from an ACIS user regarding the robustness of booleans. Directly it has no connection to OCC but I think it is very usefull. Actually I'm using OCC for a very little period and I don't have a proper opinion about the boolean operations. But, just like Ames, I definitely have a sad opinion about all the booleans I used until now. Just like you said "Sometimes, and sometimes not..."
Here is the quotation:
"ACIS computes booleans by first constructing all the intersections
conditions (surface/surface, curve/curve, ...), then deciding how to limit
the intersections (what portions of the intersection curve are really on the
face), and resolving the model's topology. The inconsistency you're finding
is that ACIS is getting conflicting (inconsistent) information about how the
curve is contained in the model. It can think, for instance, that both
sides of a curve are present in a surface.
Fundamentally, boolean operations are not robust over the entire possible
space of geometric objects you might construct. There really has never been
a complete theory developed, especially where we permit the models to have
gaps at edges. Grazing cases, and models exhibiting inaccuracies, tend to
show such problems.
A variety of hacks exist, once you've trapped the error. You can scale the
parts down (sometimes up) to close up gaps (or to make previously too-close
points distinct). You can translate the parts closer to the origin to get
into the sweet spot of the floating point numbers. You can simplify your
parts so they don't have so much unimportant (and generally destabilizing)
geometry. You can locally adjust the positions of the offending faces/edges
so they aren't close to one another (this approach isn't so outlandish as it
seems -- look at Mulmuley, Computational Geometry for a scholarly treatment
of Randomized Algorithms; hacking the problem is a standard technique).
Understand that the most complete testing on booleans has been done in cases
of DESIGN operations, rather than arbitrary computer-generated operations.
Building CAD systems so designers can add holes, slots, etc is
bread-and-butter for most geometry engine writers, so that works a lot
better than, say, slicing a model with an arbitrarily located set of planes
(say for a rapid prototyping application). So, expect a bit of brittleness
if you're automatically constructing your geometries, and think about little
tweaks that work around the brittleness.
The concern here isn't about ACIS vs other geometry representations.
Everybody has the problem. Some work has been done in trying to implement
absolutely robust booleans, but even good theory on the problem is hard to
come by. Even exactly representing the intersection curves would help, but
runs the computational and development burdens through the roof.
Tue, 04/20/2004 - 01:22
Thank you for pointing out the ACIS library. It looks pretty solid but unfortunately it's quite expensive ($20,000 + royalties). I am aware of the fundamental precision issues when doing boolean operations but using OpenCascade I am getting really bad results. Sometimes the output contains TopoDS_Wires without any faces so I am guessing that there is something seriouly wrong with the boolean implementation in openCascade.
Tue, 04/20/2004 - 10:33
As underlined in the documentation and numerously mentioned on this forum, Boolean operations are tailored to work on solids (TopoDS_Solid). Use of other topologies (such as compounds of faces visually appearing as closed solids) may often produce invalid results. This may explain that you receive some downgraded topology (wires, etc).
Indeed, Booleans are always the most sensitive algorithms to the quality of the input models. If you import your model from another source (e.g. some CAD system) or apply some not enough accurate operations then this may lead to accumulating computational errors. Errors like large gaps, inconsistent 3D/2D curve representations, invalid wire orientations, etc can finally make boolean operations fail on some cases. Open CASCADE Technology provides various tools to verify quality (validity, tolerances, etc) that you can use to check your models.
Moreover, as Andreas highlighted (that was important, thanks to him) this sort of problems is common for all geometric kernels and you always have to deal with some work-arounds or adaptations that would work for your particular configurations.
As far as support services are concerned, you may find several testimonials on our renewed web-sites. We put some of them on the support-related pages (http://www.opencascade.org/support) as well as on the "Our customers say" page on the .com site (http://www.opencascade.com/customers/customerssay/). Consider also some complex applications our clients have been able to build with our support (or other services we provide) - http://www.opencascade.org/showroom/screenshots.
Concerning possible unsatisfaction cases you mention, let me encourage you to be at least concrete or even better please withhold from mentioning this. We highly value reputation of our clients as well as our own and therefore are not in fond of discussing their names in public.
If you really wish efficient help from the Open CASCADE team please rather consider direct contacts to firstname.lastname@example.org. I am sure it will be more effective for you anyway.
Thank you for your comprehension.
Tue, 04/20/2004 - 11:39
hello forum supervisor,
your response can make an impression about an idilic state of boolean operations in OC.
i have wrong experiences with fuse & cut operations even with the solids created by means of OC functions (prisms, cylinders, pipes). when you step over some level of complexity of the shapes the results are completely wrong. situation is better with the version 5.1 but still not satisfactory.
Tue, 04/20/2004 - 17:07
i did also bad experiences with boolean operations.
I have another question:
Did one of you find out how to accelerate these operations.
Maybe changing the internal datasructure(e.g. voxel) and than operate???
Or to bring down the accuracy! It ist not nessasary that the calculation is excact!
Tue, 04/27/2004 - 01:28
Helcman is not a common surname. I would loke to know if your family also comes from Poland, Radom in particular.
Sat, 10/26/2013 - 11:51
Can you tell me whether it is possible to merge IGES and STL file using boolean operation and export it as IGES file??
Mon, 10/28/2013 - 14:29
1. "I have been experimenting with openCascade boolean operations for about two
weeks and my realization is that it is buggy!"
Ok. May be.
Could you transfer conversation to subject domain? Please attach examples.
2. "...I am wondering if I am doing something wrong...."
Here also we will look.
3 "...many people have had frustrating experiences with boolean operations..."
Ok. But there are a lot of threads among where the reasons of failure was wrong data or
just inept usage. As for me: I have good experience with boolean operations, especialy
with the latest version.
4 "...does anyone know of a good (and robust) boolean library that I can buy?..."
"... ACIS library... it's quite expensive ($20,000 + royalties)..."
It is very sad to know. I'm very sorry.
But in case of wrong data please do not hope that ACIS library will be able
to help you.