Fusing and coplanar feces

Hi all,
I use BRepAlgoAPI_Fuse to fuse two shapes (e.g. boxes). Although both shape volumes are fused well, their coplanar faces are not (there are "seams" on them). Is there any way how to avoid these "seams"? Or maybe some shape fix after fuse operation?

I was looking also on BRepFeat_Gluer class, but I want to fuse also more complicated shapes than boxes (e.g. box, spheres, tubes, fuses of all of them etc.) and don't know how to generally specify binding faces and edges for the Gluer ...

Thanks in advance for any help

pepek_cz's picture

I have searched the forum thoroughly and it seems to me I have touched on a "long-years bug" in BRepAlgoAPI booleans (which persist at least 5 years - e.g. look at http://www.opencascade.org/org/forum/thread_5988/) ... :(

I don't understand whether most of OCC users use all the time older (and as I learnt slower, more failure prone etc) BRepAlgo_Fuse or perform some special steps after BRepAlgoAPI_Fuse? But boolean fuse definitely must be quite common operation in most programs ...

Any help is still greatly appreciated.

Evgeny Lodyzhehsky's picture

Dear Petr Maly.

It is quite easy to run down anything making nothing to improve the state of affairs.
1.You "...have touched on a "long-years bug..." .
It seems you are expert in booleans. Aren't you?

2."I don't understand whether..."
There are a lot of things that you can not understand, but it is your own problem;

3.What is particularly wrong in current BRepAlgoAPI_Fuse?

4."But boolean fuse definitely must be quite common operation..."
Try to write a specification for booleans and make public it here for discussion. I think it will be easy for you;

5. "...greatly appreciated..."
What do you mean?

Maly Petr's picture

Dear Lodyzhensky Evgeny Nicolaich,

I am sorry, I didn't want to be offensive, just felt little bit down and was too impatient.

1. No, I'am not an expert on booleans. I just saw that exactly the same question was described 5 years back.
2. You are right. Nobody understands everything.
3. Sorry again, my fault, probably I didn't describe precisely what I mean. Lets have an example in Draw Test Harness in OCC 6.3:

Draw[1]> pload ALL
Draw[2]> axo
Draw[3]> box b1 1 1 1
Draw[4]> box b2 0 0 0 1 -1 1
Draw[5]> bop b1 b2
Draw[6]> bopfuse s
Draw[7]> fit
Draw[8]> nbs s
Number of shapes in s
EDGE : 20
WIRE : 10
FACE : 10
SHAPE : 55

We have 10 faces in result. I would expect 6 faces. When I use old BRepAlgo_Fuse I get 6 faces too.
Is there any way how to achieve 6 faces with BRepAlgoAPI?
Note I didn't say BRepAlgoAPI works wrong - I was looking for some way or shape/faces fix/upgrade after fuse operation.

4. I still believe booleans are quite common operation in most 3D modeling applications, especially kernels and frameworks. For the specification there are much more qualified people for sure.
5. I meant, it would be great if some expert would advise the solution of previously described question to me and all OCC Community.

Petr Maly

haowei's picture

Use Old Boolean Operations “BRepAlgo_Fuse” can avoid coplanar faces.

pepek_cz's picture

I've already tried - it really doesn't suffer described problem, but gives errorneous results for more complicated objects (like crazy edges, inproper holes etc) :(
The new BRepAlgoAPI is much more robust, precise and faster - except above problematic behaviour ...

Jane Hu's picture

I've seen the same problem and am looking for solutions too. I am talking in support of your topic and hopefully the 'officials' can pick it up and work on it.


haowei's picture

sorryCI only know this. :(

Eduardo Suárez's picture

When fusing weirds things happen to me as well:

Draw[4]> pload FULL
Draw[5]> pcylinder cyl1 0.300000 3.897134
Draw[6]> ttranslate cyl1 0.000000 0.000000 -0.000010
Draw[7]> trotate cyl1 0.000000 0.000000 0.000000 -0.707107 0.707107 0.000000 54.735610
Draw[8]> pcylinder cyl2 0.300000 3.897134
Draw[9]> ttranslate cyl2 4.500000 4.500000 -0.000010
Draw[10]> trotate cyl2 4.500000 4.500000 0.000000 0.707107 -0.707107 0.000000 54.735610
Draw[11]> bop cyl1 cyl2
Draw[12]> bopfuse cylnet2
Draw[13]> vinit
Draw[14]> vdisplay cylnet2

appears to me as a wrong fusion.

Any help is welcome,

PG's picture

Yes the resultant shape is faulty.

Draw[19]> checkshape cylnet2
Shape faulty_1 on shape faulty_2 :
Shape faulty_3 on shape faulty_2 :
Shape faulty_4 on shape faulty_2 :

Faulty shapes in variables faulty_1 to faulty_4

Evgeny Lodyzhehsky's picture

What is wrong with cylnet2?
I've obtained valid shape

PG's picture

The shape check says "BRepCheck_NotClosed"

BRepCheck_Analyzer Class

A framework to check the overall validity of a shape.

For a shape to be valid in Open CASCADE, it - or its component subshapes - must respect certain criteria. These criteria are checked by the function IsValid.

Once you have determined whether a shape is valid or not, you can diagnose its specific anomalies and correct them using the services of the ShapeAnalysis, ShapeUpgrade, and ShapeFix packages.

Evgeny Lodyzhehsky's picture

Dear PG.

Thanks for your detailed explanations.
1. Once again. I'm using Cascade 6.1. The 'checkshape' command writes: "This shape seems to be valid".

2. For me the best way is to cure the algorithm that produces non-valid results instead of to cure these non-valid results (by using ShapeFix, etc)

m-aronsson's picture

The boolean operations in Open Cascade has never worked to 100% and they still don't, you will have to expect som "hands on" massage of you code and shapes to get it working in some situations, it all depends on what kind of shapes you use and the type of boolean operation.

Evgeny Lodyzhehsky's picture

Dear Mikael Aronsson.

The commercial libraries do not provide 100% sucess with their algoritms of boolean operations between 3D objects.
My friend for e.g. uses 3DMax Studio and he is not delighted with the results of these booleans too. The difference is in the following: my friend has bought 3DMax Studio but you pay nothing for the Open Cascade.
It is important to feel the difference before making such end-to-end assessment.