BRepAlgoAPI_Common failed for a part in an assembly BUT succeeded for a single part.

Hi!

I'm trying to get cap geometries (which are faces) by clipping planes from the attached STEP file that consists of an assembly.
There are many bolts with thread in the assembly.

Please see the two cases below.
I think they seem to generate the same result but they don't.

1. Case1
After reading the assembly from the attached STEP file, it fails to obtain a cap face geometry if I do BRepAlgoAPI_Common with a bolt and a plane passing through the bolt.

2. Case2
However, it does not fail for the same operation if I generate a separate STEP file that only includes a bolt with no other parts and read it.

See the code snippet below.

gp_Pln* plane = new gp_Pln(gp_Pnt(p1, p2, p3), gp_Dir(z1, z2, z3));
BRepBuilderAPI_MakeFace face(*plane);
TopoDS_Shape planeShape = face.Shape();
TopoDS_Shape modelShape = ...
BRepAlgoAPI_Common common(modelShape, planeShape);
TopoDS_Shape capShape = common.Shape();

It might be worth mentioning that Case1 does not completely fail because I can find edge fragments that are not closed from common.SectionEdges().

Is there something that I'm missing about the difference between a single part and a part within an assembly?
Or are there other ways to work around it?
Can someone help me out with this?

Thanks!

Mikhail Sazonov's picture

Try to get the snapshot of the shapes before the common operation with BinTools::Write(). Then it can be used as reproducible data for registering a bug.

Soonjo Kwon's picture

Here's what I tested.

1. I first open my STEP file in the previous comment, deleted all other parts except a bolt, and then export it to STEP format (AP214) again. I did it for CAD Assistant, CATIA, Fusion 360, Inventor. Now I have 4 STEP files.
2. I tested if the common operation works for each STEP file. As a result, the one that CAD Assistant exported only failed.
3. I exported shapes from STEP files separately to binary format using BinTools::Write(). Please see the attached.
4. I read shapes in binary format again using BinTools::Read(), and tested the common operation again. The results were the same.

Please use the plane definition below.
gp_Pln* plane = new gp_Pln(gp_Pnt(127.681, 0.0, 0.0), gp_Dir(-1.0, 0, 0));

I think other CAD systems did some kind of repair or modification when importing or exporting because the number of faces is different and the common operation worked for their files.
However, I checked that all shapes were closed when imported in OCC although it is not sufficient information why they are working or not.
Is it just a problem with the specific STEP file? or is there a way to repair or make it work in OCC?

Also, should I register a bug?

Thanks,

Attachments: 
Mikhail Sazonov's picture

I had a look at the shapes. The shape bolt_CADAssistant_214 has an error that is not recognized by check validity procedure but is essential for modeling algorithms. It is that one face based on a cylindrical surface has the range along U direction more than 1 period (exactly more than 38 periods). Other shapes have in this place several faces each having U range not more than 1 period.

I think it was definitely some error during STEP read or write using OCCT STEP translator. It deserves to be reported as a bug.

Soonjo Kwon's picture

Thank you for your prompt reply.
I've reported a bug to the Issue Tracker.
https://tracker.dev.opencascade.org/view.php?id=33406