BRepAlgoAPI_Cut incorrect behavior with TopoDS_Compound as a 2nd argument

Hello,

suppose following sample code performing a boolean cut operation:

TopoDS_Solid box = BRepPrimAPI_MakeBox(1.0,1.0,1.0);
TopoDS_Solid box2 = BRepPrimAPI_MakeBox(gp_Pnt(0,0,0.5),0.5,0.5,0.5);
TopoDS_Solid box3 = BRepPrimAPI_MakeBox(0.7,0.7,0.5);

BRep_Builder builder;
TopoDS_Compound Comp;
builder.MakeCompound(Comp);
builder.Add(Comp,box2);
builder.Add(Comp,box3);

TopoDS_Shape cutShape3 = BRepAlgoAPI_Cut(box, Comp);

BRepTools::Write(cutShape3, "cut.by.compound.brep");

When exploring the visualization (done via the FreeCAD) of the cut.by.compound.brep file, it looks really weird (see the attachment).

But when the cut is performed without the compound as following:

TopoDS_Solid box = BRepPrimAPI_MakeBox(1.0,1.0,1.0);
TopoDS_Solid box2 = BRepPrimAPI_MakeBox(gp_Pnt(0,0,0.5),0.5,0.5,0.5);
TopoDS_Solid box3 = BRepPrimAPI_MakeBox(0.7,0.7,0.5);

TopoDS_Shape cutShape = BRepAlgoAPI_Cut(box, box2);
TopoDS_Shape cutShape2 = BRepAlgoAPI_Cut(cutShape, box3);

BRepTools::Write(cutShape2, "cut-no.compound.brep");

In this case the result is ok. My quetions are following:

Am I right supposing that both algorithms should result in the same shape?

Am I doing something wrong in the case when cutting by the compound shape? Or is it a bug? (Maybe it is related to the issue #23187?)

Any hints or comments appreciated. Petr

Attachments: 
Petr Matousek's picture

I forgot to mention that I am using OCCT 6.7.1 on the Linux OS (Fedora Core 20)

Rodrigo Castro Andrade's picture

Hello Petr,

I reproduced your code and got the result you see attached, so I think this is only a visualization issue.

Good luck,
Rodrigo

Attachments: 
Rodrigo Castro Andrade's picture

Then again I forgot to mention Im on Win 8.1, using VS13 and OCCT 6.8.0 . The visualization is done with Win32 API to open the window, and OCCT to visualize the model.
I'd recommend checking documentation for changes concerning the methods youre using.

Rodrigo Castro Andrade's picture

Petr,

Please ignore my previous answers, as I had not understood what you want to know. The methods are indeed producing different results (see attached file for my no-compounds result), and I dont see why.

Attachments: 
Petr Matousek's picture

Hello Rodrigo,

thank you for spending your time with my issue.

I think that it is obvious that even the 6.8.0 version does not produce correct results in case that a compound is used as the 2nd argument of the difference. Even the resulting solid in your picture test.jpg seems closed only one of the boxes (smaller box2) was subtracted from the box. But the correct result should look like your picture test2.jpg.

Please, anyone can comment on this?

Petr

Forum supervisor's picture

Dear Petr,
In fact you are not right (it is not a bug), because you didn't take care to read corresponding documentation in time. See below the explanation.

Analysis.
---------
If you would checked the 'Comp' argument with additional check tool dedicated exactly for domain of boolean operation you would found out that it (Comp) is treated as self-interfered shape:

Use, for e.g., the following DRAW command to verify this
> bopcheck Comp
The result is:
V/V: x7 x40
V/E: x11 x42
V/E: x17 x60
E/E: x12 x42
E/E: x25 x60
V/F: x21 x67
E/F: x22 x67
E/F: x29 x67
F/F: x31 x67

In accordance with the specification
"...The argument should not be self-interfered, i.e.
all sub-shapes of the argument that have geometrical coincidence
through any topological entities (vertices, edges, faces) should share
these entities..."
[see
http://dev.opencascade.org/doc/overview/html/occt_user_guides__boolean_o...
for more details]

Thus shape Comp should not be used as argument of Boolean Operation Algorithm.

//----------------------------------------------
RECOMMENDATIONS

1. It is possible to obtain the result r = CUT([b1], [b2, b3] in one operation instead of two operations like you probably want:

# Use the following commands of Draw reproducer:
bclearobjects
bcleartools;
baddobjects b1
baddtools b2 b3

bfillds
bbop r 2
# where '2' - means CUT operation

Draw your attention, please to the next remark:
the boxes b2, b3 are the separate arguments.
- b2 is not self-interfered shape
- b3 is not self-interfered shape
while 'Comp' is self-interfered shape.

2. Take into account, please:
The shape of type TopAbs_COMPOUND is the shape, but not just list of shapes.

3. Please read more carefully the documentation before posting your remarks ...

Best regards
FSR

Petr Matousek's picture

Dear FSR,

thank you for the comprehensive explanation.

I am sorry but the documentation of the boolean operations you posted link to is new to me. As I wrote I originaly used the version 6.7.1 where the user guide explanation related to the boolean operations was not so rich (at least in my downloaded copy).

I also want to explain that I did not claim it is a bug. I was rather asking if it is or if the mistake is on my side. Now it is clear where it is. :)

I reported my issue as a bug #25756 by coincidence as I did not expect any additional answer to this topic. As it is obvious now that it is not a bug what should I do with the bug report? Please let me know.

Best regards and thank you very much, Petr

Forum supervisor's picture

Dear Petr,
I think you can simply close the issue
with some comment like "Not a bug".
Best regards
FSR

Petr Matousek's picture

Dear FSR,

sorry for bothering but I am unable to close the issue in the bug tracker. I do not see any close or status change link/button - maybe because of my weak user permissions? I also tried to assign the issue to myself but with no change. Can you please tell me how to close it? Or simply close it?

Best regards, Petr

Forum supervisor's picture

Dear Petr,
It is closed.
Best regards
FSR

Petr Matousek's picture

Reproduced also in the 6.8.0 version, reported as a bug #25756