View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0026531 | Community | OCCT:Modeling Algorithms | public | 2015-08-07 10:21 | 2016-11-09 14:49 |
| Reporter | srlockley | Assigned To | bugmaster | ||
| Priority | normal | Severity | crash | ||
| Status | closed | Resolution | no change required | ||
| Platform | Windows | OS | VC++ 2013 | ||
| Product Version | 6.9.0 | ||||
| Summary | 0026531: Boolean cut crashes with overlapping faces | ||||
| Description | The 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 Reproduce | I 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 | ||||
| Tags | No tags attached. | ||||
| Test case number | Not needed | ||||
|
|
|
|
|
I ask to specify the problem exactly. Please provide Tcl script (or C++ code snippet) that contains the exact steps to reproduce the problem. |
|
|
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 |
|
|
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 |
|
|
Dear srlockley, please tell if this solution OK to you. |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
Dear bugmaster, please close this bug. |
| 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 |
|
Assigned To | msv => pkv |
| 2015-08-07 13:00 |
|
Status | new => assigned |
| 2015-08-07 13:00 |
|
Target Version | => 7.1.0 |
| 2015-08-10 09:46 |
|
Note Added: 0043930 | |
| 2015-08-10 09:46 |
|
Assigned To | pkv => jgv |
| 2015-08-11 18:55 | srlockley | Note Added: 0043997 | |
| 2015-08-12 13:05 |
|
Assigned To | jgv => pkv |
| 2016-10-28 18:43 |
|
Note Added: 0059384 | |
| 2016-10-28 18:45 |
|
Note Added: 0059385 | |
| 2016-10-28 18:45 |
|
Assigned To | pkv => srlockley |
| 2016-10-28 18:45 |
|
Status | assigned => feedback |
| 2016-10-28 18:45 |
|
Target Version | 7.1.0 => Unscheduled |
| 2016-11-01 13:52 | srlockley | Note Added: 0059686 | |
| 2016-11-01 17:25 |
|
Note Added: 0059717 | |
| 2016-11-02 11:15 | srlockley | Note Added: 0059744 | |
| 2016-11-02 11:33 |
|
Note Added: 0059747 | |
| 2016-11-02 11:33 |
|
Assigned To | srlockley => bugmaster |
| 2016-11-02 11:33 |
|
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 => |