For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings

 

Need to speed up your development?
Have a look at our:

Samples & Tools

 

Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

(OCC 6.5.3 regression) BRepAlgoAPI_Cut returns invalid solid

Timo Roth's picture
Forums: 

The following cut operation results in an invalid solid in OCC 6.5.3.
In OCCT 6.5.2 the result is valid.

Draw script:
restore blade.brep b
bop b_1 b_2
bopcut r
vdisplay r
vfit
vsetdispmode r 1
checkshape r

Is this reproducible?

Regards

Attachments: 
PG's picture

Opened the BREP file in OCC TH 6.5.3 win7,
before doing a 'bopcut' , checked the arguments for faulties,

Draw[13]> bopargcheck b_1 b_2 -C
Faulties, that can not be treated by BOP, are detected.

Also did a 'bopcheck' on the input shapes, b_1 is OK .
Draw[21]> bopcheck b_2
Self-intersection near edge and face
x1 x2
Self-intersection near edge and face
x3 x4
Self-intersection near edge and face
x5 x6
Self-intersection near edge and face
x7 x8
Self-intersection near faces
x9 x10
Self-intersection near faces
x11 x12

What needs to be done to fix such a shape(b_2_ with fault's ??

- PG

Forum supervisor's picture

Dear Timo,
The problem is reproducible, but as it was identified by PG,
the second argument has faulties which can't be treated by Boolean Operations.
In this case BOP can't guarantee a valid result.
Regards

jelle's picture

Valuable to point out the bopargcheck command, useful!

Timo Roth's picture

Thanks for looking at this case, but I don't think that the self-intersections stated by bopcheck are the reason for the problem. We have many similar cases where similar warnings occur but the boolean operation works well in 6.5.2 and 6.5.3. Furthermore, if you look at the self-intersections (x1, x2, ...), you can see that they are not really involved in the boolean operation (i.e. in the intersection with b_1). See the appended image blade.PNG.

As it worked well in 6.5.2, it has to do with some code changes introduced in 6.5.3.
I also changed back the code of the whole TKBO-Toolkit (except for the M_PI-macro) to the state of 6.5.2, but the problem remained. Therefore, I think it has to do with some changes of classes that are used by TKBO. Does anybody have an idea, what this could be or where to start searching?

Could someone test this case with the current OCCT from the git repository?

Thanks

Attachments: 
Pawel's picture

Hi Timo,

tested with an one-week-old version from the git repository and the result is the same:

Draw[10]> checkshape r
Shape faulty_1 on shape faulty_2 :
BRepCheck_NotClosed

Faulty shapes in variables faulty_1 to faulty_2

Pawel

Forum supervisor's picture

Dear Timo,
It is not possible to say in advance (without more deep analysis)
about the real reason of not Valid result. In general if the argument
is not accepted by Boolean operation arguments checker we can't expect
a valid result. In other words by definition Boolean operations don't
guarantee valid result for such cases. Therefore it is better to try
to remove the identified faulties before operation.
For sure you are also free to register the case in Mantis BugTracker.
Regards

Timo Roth's picture

OK, I removed the faulties and the behaviour is still the same: In OCC 6.5.3 the result is invalid and in 6.5.2 it is valid.

Here is the modified Draw script:
restore blade3.brep b
explode b
checkshape b_1
checkshape b_2
bopcheck b_1
bopcheck b_2
bopargcheck b_1 b_2
bop b_1 b_2
bopcut r
vdisplay r
vfit
vsetdispmode r 1
checkshape r

Regards

Attachments: 
Timo Roth's picture

Reported under:
http://tracker.dev.opencascade.org/view.php?id=23389

PG's picture

Dear Timo, How did u remove the faulties ( API and Test harness command) in blade.brep ?
- PG

Timo Roth's picture

Dear PG,

I didn't remove the faulties via API or Test harness commands but changed the way how I create the two faces, where the problems occured. It means, I didn't fix the faces, but regenerated them in a different way.

Regards,
Timo