View Issue Details

IDProjectCategoryView StatusLast Update
0026531CommunityOCCT:Modeling Algorithmspublic2016-11-09 14:49
Reportersrlockley Assigned Tobugmaster  
PrioritynormalSeveritycrash 
Status closedResolutionno change required 
PlatformWindowsOSVC++ 2013 
Product Version6.9.0 
Summary0026531: Boolean cut crashes with overlapping faces
DescriptionThe sample uploaded has two solids that touch with a coincident face and they both have a face which is coincident with a face in the body. When cut using the multiple tool setting in the current version this causes a crash in release mode due to a null pointer reference.
The main problem is that throughout the code there is an assumption that a gp_Dir can be formed, in these models there are places where this fails because the calculation of the direction raises this exception in gp_Dir

  Standard_ConstructionError_Raise_if (D <= gp::Resolution(), "");

An example is in BOP_Tools_AlgoTools3D

aS=BRep_Tool::Surface(aF);
  //
  gp_Pnt2d aPx2D;
  gp_Vec2d aVx2D;
  aC2D->D1 (aT, aPx2D, aVx2D);

In this case D1 returns aVx2D as 0,0
I have tried avoiding this errors but it seems that the failure is that bad model data is created by the Boolean initialisation, typically it creates edges that have the same start and end vertex but an intermediate knot on the BSpline curve. Since all the edges in this model are linear, the BSpline must have been created but I am unable just yet to trace why.
Steps To ReproduceI have upload four files
Body
Cut1
Cut2
and Edge and Face

using the multiple tools mode cut Cut1 and Cut2 from Body with a precision of 1e-5

The Edge and Face file shows the kind of edges that are causing the problem and the kind of face that is being operated on when in BOP_Tools_AlgoTools3D
They were writen just before where the error begins in
 BOPTools_AlgoTools3D::PointNearEdge
    (aE, aF, aT, dT2D, aPx2DNear, aPxNear);
  if (!theContext->IsPointInOnFace(aF, aPx2DNear)) {
    Standard_Integer iErr;
    Standard_Real aU1, aU2, aV1, aV2, dV, dU, dTresh;
    gp_Pnt aP;
    gp_Pnt2d aP2d;
    //
    BRepTools::UVBounds(aF, aU1, aU2, aV1, aV2);
    //
    dU=aU2-aU1;
Additional information
and documentation updates
I have tried changing the precision and this has no impact, if i change the Fuzzy tolerance to 1.0 it will pass but then many models with the same settings fail as this is too course for my model data, my normal fuzzy tolerance is 2e-5
TagsNo tags attached.
Test case numberNot needed

Attached Files

Activities

srlockley

2015-08-07 10:21

reporter  

BReps.zip (4,450 bytes)

pkv

2015-08-10 09:46

developer   ~0043930

I ask to specify the problem exactly.
Please provide Tcl script (or C++ code snippet)
that contains the exact steps to reproduce the problem.

srlockley

2015-08-11 18:55

reporter   ~0043997

Create two lists of shapes, one for the tools and one for the argument
TopTools_ListOfShape toBeProcessed;
TopTools_ListOfShape cuttingObjects;


Add the breps read from the files cut1 and cut2 to cuttingObjects list
Add the brep from body to toBeProcessed

then construct a builder as below

pBuilder = new BRepAlgoAPI_Cut();
            
pBuilder->SetArguments(toBeProcessed);
pBuilder->SetTools(cuttingObjects);
pBuilder->SetFuzzyValue(2e-5);
pBuilder->Build();

It should fail

msv

2016-10-28 18:43

developer   ~0059384

The current version does not crash on this test case. However the result is not correct. There is explanation to it.

The input shape Body has too big tolerances of its subshapes (about 1). It makes extra interferences, and in the result leads to bad shape.

If we set correct tolerances using the command btolx everything works.

restore Body b
restore Cut1 c1
restore Cut2 c2
btolx b
bclearobjects
bcleartools
baddobjects b
baddtools c1 c2
bfillds
bbop r 2

msv

2016-10-28 18:45

developer   ~0059385

Dear srlockley, please tell if this solution OK to you.

srlockley

2016-11-01 13:52

reporter   ~0059686

This makes a lot of sense, thanks for looking at it. I would like to try and repeat on my code but cannot find the documentation for btolx b , my inadequacy. Could you please advise what the Shape Healing or fixing equivalent is please and I will see if the fix works on my implementation

msv

2016-11-01 17:25

developer   ~0059717

The command btolx has no direct equivalence in API classes.
However, the following commands do (though too much heavy):
  settolerance b 1e-7 ;#ShapeFix_ShapeTolerance
  fixshape b b ;#ShapeFix_Shape

srlockley

2016-11-02 11:15

reporter   ~0059744

OK, so I have tried this in the past with the models I have. It works in some conditions and fails in others, this means if I apply this solution generally I will break other models. Obviously the issue is a mismatch between the tool which authored the models idea of the correct tolerance and the one that Opencascade thinks is correct. I fully understand that Opencascade is not wrong it is just different from the authoring tool or vice versa. Because a topologically valid but incorrect result is generated by OCC there is no way to determine what action to take to correct tolerances, for example. I see on the blogs a lot of people are processing models produced by third party tools, is there any guidance on how to use precision in OCC other than Roman's blog describing how it works?
I am happy to close this issue as I think the issue is not a bug in OCC and is a problem of the complex environment we are working in.

msv

2016-11-02 11:33

developer   ~0059747

Dear bugmaster, please close this bug.

Issue History

Date Modified Username Field Change
2015-08-07 10:21 srlockley New Issue
2015-08-07 10:21 srlockley Assigned To => msv
2015-08-07 10:21 srlockley File Added: BReps.zip
2015-08-07 13:00 msv Assigned To msv => pkv
2015-08-07 13:00 msv Status new => assigned
2015-08-07 13:00 msv Target Version => 7.1.0
2015-08-10 09:46 pkv Note Added: 0043930
2015-08-10 09:46 pkv Assigned To pkv => jgv
2015-08-11 18:55 srlockley Note Added: 0043997
2015-08-12 13:05 jgv Assigned To jgv => pkv
2016-10-28 18:43 msv Note Added: 0059384
2016-10-28 18:45 msv Note Added: 0059385
2016-10-28 18:45 msv Assigned To pkv => srlockley
2016-10-28 18:45 msv Status assigned => feedback
2016-10-28 18:45 msv Target Version 7.1.0 => Unscheduled
2016-11-01 13:52 srlockley Note Added: 0059686
2016-11-01 17:25 msv Note Added: 0059717
2016-11-02 11:15 srlockley Note Added: 0059744
2016-11-02 11:33 msv Note Added: 0059747
2016-11-02 11:33 msv Assigned To srlockley => bugmaster
2016-11-02 11:33 msv Resolution open => no change required
2016-11-09 14:49 apn Test case number => Not needed
2016-11-09 14:49 apn Status feedback => closed
2016-11-09 14:49 apn Target Version Unscheduled =>