MantisBT - Community
View Issue Details
0023380Community[OCCT] OCCT:Modeling Algorithmspublic2012-08-15 12:562019-09-15 10:55
[OCCT] 6.5.3 
[OCCT] 7.4.0 
0023380: (OCC 6.5.3 regression) BRepOffsetAPI_MakeFilling fails and leaves boundary faces with high tolerance
When I moved from OCCT 6.5.2 to 6.5.3, I faced a problem in connection with BRepOffsetAPI_MakeFilling (which uses BRepFill_Filling / GeomPlate). In 6.5.2 for a certain case an ugly face was created. Our application realized this and tried it again after changing one boundary condition. Then the result was good.
In 6.5.3 an exception occurs on the first try and the boundary faces are left with a very high tolerance. Then the second try fails because the tolerance is much too high.

So, my question is: Is BRepOffsetAPI_MakeFilling supposed to change the tolerances of bounding faces?

Here is my test case for Draw:

restore blower3.brep b
explode b
renamevar b_5 d
renamevar b_1 f
renamevar b_4 i
explode f E
explode d E
tolerance f
filling r 4 0 0 i f_1 f 1 d_3 d 1 b_2 0 b_3 0
tolerance f
vdisplay r
vdisplay d
vdisplay f
vdisplay b_2
vdisplay b_3

In 6.5.3 the tolerance of f differs.
Before filling: Tolerance MAX=0.00011266018876558801
After filling: Tolerance MAX=310.17121388562828

In 6.5.2 the tolerance of f stays the same.

Is the change of tolerance of neighboring faces (used as boundary conditions) expected in filling algorithm? Was this introduced in 6.5.3?

The exception is thrown in the end of BRepFill_Filling.WireFromList().

The issue was reported on the forum: [^]

Forum supervisor:
The specified issue is checked and reproduced. The script raises an exception at the command <filling ..>, which uses BRepOffsetAPI_MakeFilling class. In any case the final tolerance (310) is too large.
It indirectly testifies that some problem exist. The raised exception in any case can't be considered as a normal flow of the algorithm.
bugs modalg_7 bug23380
No tags attached.
zip (416,685) 2012-08-15 12:56
? bug23380.brep (1,049,351) 2019-09-06 14:10
Issue History
2012-08-15 12:56TimoNew Issue
2012-08-15 12:56TimoAssigned To => jgv
2012-08-15 12:56TimoFile Added:
2014-10-30 19:24TimoNote Added: 0033909
2016-09-06 10:39TimoNote Added: 0057492
2016-09-06 10:40TimoStatusnew => feedback
2017-05-31 15:42TimoReporterTimo => Markus
2019-09-05 15:34gitNote Added: 0086799
2019-09-06 14:10jgvFile Added: bug23380.brep
2019-09-06 14:11jgvAssigned Tojgv => msv
2019-09-06 14:11jgvNote Added: 0086873
2019-09-06 14:28msvNote Added: 0086877
2019-09-06 14:28msvAssigned Tomsv => jgv
2019-09-06 14:28msvStatusfeedback => assigned
2019-09-06 14:33gitNote Added: 0086879
2019-09-06 14:35gitNote Added: 0086880
2019-09-06 16:57msvTarget Version => 7.4.0
2019-09-06 17:35jgvNote Added: 0086904
2019-09-06 17:35jgvAssigned Tojgv => msv
2019-09-06 17:35jgvStatusassigned => resolved
2019-09-06 17:35jgvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=21801#r21801
2019-09-09 11:32gitNote Added: 0086976
2019-09-09 11:41msvNote Added: 0086977
2019-09-09 11:41msvAssigned Tomsv => jgv
2019-09-09 11:41msvStatusresolved => assigned
2019-09-09 14:47jgvNote Added: 0086981
2019-09-09 14:47jgvAssigned Tojgv => msv
2019-09-09 14:47jgvStatusassigned => feedback
2019-09-09 15:24msvNote Added: 0086985
2019-09-09 15:24msvAssigned Tomsv => bugmaster
2019-09-09 15:24msvStatusfeedback => reviewed
2019-09-09 18:56bugmasterTest case number => bugs/modalg_7/bug23380
2019-09-09 18:57bugmasterNote Added: 0086989
2019-09-09 18:57bugmasterStatusreviewed => tested
2019-09-15 10:51bugmasterChangeset attached => occt master a53d3975
2019-09-15 10:51bugmasterStatustested => verified
2019-09-15 10:51bugmasterResolutionopen => fixed
2019-09-15 10:55gitNote Added: 0087101

2014-10-30 19:24   
Same behaviour in OCCT 6.8.0 beta.
2016-09-06 10:39   
Same behaviour in OCCT 7.0.0.

I think something was done recently in order to avoid that algorithms change the tolerances of the original shapes. I didn't try this case on the current master. Or is this case different because the high tolerance is because of the normal flow of the algorithm is interupted by the exception?
2019-09-05 15:34   
Branch CR23380 has been created by jgv.

SHA-1: 5e68dfcd083536c8430af180f23eeb9249f43240

Detailed log of new commits:

Author: jgv
Date: Thu Sep 5 15:31:15 2019 +0300

    0023380: BRepOffsetAPI_MakeFilling fails and leaves boundary faces with high tolerance
    Avoid exception: use BRep_Builder for building wire and face instead of using BRepLib_MakeWire and BRepLib_MakeFace.
2019-09-06 14:11   
Please add the shape bug23380.brep to database.
2019-09-06 14:28   
2019-09-06 14:33   
Branch CR23380 has been updated by jgv.

SHA-1: e6b140c57893cf84d73315e5bc22b7b5a9e7c6fe

Detailed log of new commits:

Author: jgv
Date: Fri Sep 6 14:29:32 2019 +0300

    Fix regressions and add test case

2019-09-06 14:35   
Branch CR23380 has been updated forcibly by jgv.

SHA-1: 22da872ec375ee87223b185803529a0fda48c87c
2019-09-06 17:35   
Please review the branch CR23380.
2019-09-09 11:32   
Branch CR23380 has been updated forcibly by msv.

SHA-1: cc0847eb4ef42b02af7819331f6822c14be57b36
2019-09-09 11:41   
Dear Julia, the patch solves exception but does not solve large tolerance of the output. Please explain this behavior. If it is due to incorrect input data then explain what is wrong in them.
2019-09-09 14:47   
The tolerances of the faces bounding the hole that we want to fill change with changing tolerances of the bounding edges. The bounding edges change their tolerances to be correctly connected with the new face.

In this case, the problem is in the initial surface that is put as an argument to the algorithm of BRepFill_Filling. If the initial surface is set, it should be better than the initial surface that can be calculated by the algorithm itself, but it is not the case. That is why the tolerances of the result and, thus, of the bounding faces are so huge.
2019-09-09 15:24   
2019-09-09 18:57   
Combination -
OCCT branch : CR23380
master SHA - cc0847eb4ef42b02af7819331f6822c14be57b36
Products branch : master SHA - f9d0bd5e3a29d6a97b3f5f6354ea2397253ab4f8
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.

Number of compiler warnings:
No new/fixed warnings

No regressions/differences

CPU differences:
Total CPU difference: 16821.790000000117 / 16836.290000000165 [-0.09%]
Total CPU difference: 10532.520000000024 / 10553.510000000031 [-0.20%]
Total CPU difference: 18098.390625 / 18104.5625 [-0.03%]
Total CPU difference: 12352.546875 / 12227.453125 [+1.02%]

Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention
2019-09-15 10:55   
Branch CR23380 has been deleted by inv.

SHA-1: cc0847eb4ef42b02af7819331f6822c14be57b36