Look at these strange edges... (about Booleans)

Hallo,
I am using OpenCASCADE for a new 3D modeling software, using
a custom OpenGL rendering.
Current results are good, in fact, but I am trying to improve
the OpenGL look of shapes, so that they look as in other 3D
cad like SolidEdge etc.
A problem is that, if you do BOOLEANS on two shapes (ex, fuse
or subtraction), in case of cohincident faces you end with
the result which is shown in this image:

http://www.deltaknowledge.com/download/cas_err_1.jpg

You see what I mean: I would like that merging two
cubes with coplanar faces, you end with a longer face and no
original edges where there were the original edges of the
coplanar faces.. This happens in most 3D kernels: why not
in OpenCascade?

Is there a way to avoid this? I tried to use the
BRep_Tool::Continuity(edge,faceA,faceB) to understand if
an edge is C0, otherwise I could make it invisible, but
looks like this does not work as I want... Look at the
following image: after FUSE there are edges which are
more that at least C1, but I always get C0 from
BRep_Tool::Continuity(), so I do not know how to set
them invisible.

http://www.deltaknowledge.com/download/cas_err_2.jpg

You can test this effect by your own, if you modify the
OpenCASCADE sample "Topology Operations", for the FUSE sample,
just by changing coordinates so that the two cubes are
collinear on some faces, for example...

TopoDS_Shape theBox1 = BRepPrimAPI_MakeBox(50,200,70);
TopoDS_Shape theBox2 = BRepPrimAPI_MakeBox(-30,150,70);
TopoDS_Shape FusedShape = BRepAlgoAPI_Fuse(theBox1,theBox2);

Maybe there is some kind of healing to upgrade two
coplanar surface to become a single one, loosing the
edge(s) in between, but I do not know... maybe I am
going too far and this feature is not yet in Cascade?

Alessandro Tasora

Lee Sangsu's picture

Hello, Allessandro.

It is normal with OCC boolean operation. And for me, it is also a problem of it. As far as I know, as yet there is no plan to improve it.
So, in my application, users can apply cannonical recognition to the result of fuse operation. it can fuse faces on the same plane. Unfortunately, the Cannonical Recognition module is commercial one from OCC company, but it has some powerful features like merging faces and edges based on same geometry. And as far as I know, there may be no other algorithm to do that.

I hope this helps you....

Sangsu Lee

Gerard Gartside's picture

I came across the same problem and never found a way of getting rid of this edge. This only happens with the new boolean operations introduced in version 5, if you use the earlier algorithms you don't get this edge, for example use BRepAlgo_Fuse instead of BRepAlgoAPI_Fuse.

P G's picture

Anybody observed any difference in PERFORMANCE (speed) of the boolean operation, between the 2 API's ... i.e BRepAlgo_Fuse and BRepALGOAPI_Fuse ?

tasora's picture

Hallo,
I made some tests with the new Cascade BRepAlgo_API... booleans and I am quite satisfied. You can see some pictures in a 'preview gallery' of my software project:
http://www.deltaknowledge.com/gallery/thumbnails.php?album=5
Note that I made some booleans between complex shapes imported with the STEP translator, and the results were OK.
Notes:
1---
I had some 'performance' problems if I imported the same objects in IGES format, not only because I had to do healing&sewing to buld again the topology, but also because the modeler saved all surfaces as Iges 'freeform nurbs', I guess, and I see that BRepAlgo_API booleans are slow when intersecting freeform surfaces (even if they represent spheres, cylinders, etc.) I read somewhere that the forthcoming Cascade release will improve the speed of the intersection between nurbs.
2---
Intersecting canonical geometry, on the other hand, was fast enough. Look at the valve flange in my gallery: the boolean took only 1-2 seconds on my 1.6GHz laptop, even with fillets etc. Not as fast as Parasolid, but enough for now. I had no problems with tolerances, but may be I was just lucky.
3---
All pictures in my gallery are made using my Revolution4D plugin (it is a plugin for the Realsoft3D rendering software, adding Cascade features to it), so the rendering is not from OCAF, but from Realsoft3D (you can see either OpenGL views or ray tracing examples too).
4---
The robustness of the booleans algorithm improved a lot in recent releases, but I still hope that also other important methods such as chamfering, rounding and shell thickening could be improved either in speed and in features... Waiting for Cascade 6?
5---
Thank to the OpenCascade team for their opensource project.. Keep on the great work!

Regards,

tasora's picture

Hallo Gerard,
this is really strange, indeed! May be that earlier booleans did some kind of canonical recognition to merge faces after operations..
However, I would not use old booleans, since the new algorithms are much faster and more robust (not as fast as Parasolid, maybe, but enough for me).
The straightforward solution may be to use the new canonical recognition module, as suggested by Sangsu Lee -but this is a commercial Cascade component.
regards,