MantisBT - Community
View Issue Details
0023380Community[OCCT] OCCT:Modeling Algorithmspublic2012-08-15 12:562019-09-15 10:55
Markus 
bugmaster 
normalminor 
verifiedfixed 
[OCCT] 6.5.3 
[OCCT] 7.4.0 
bugs/modalg_7/bug23380
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:
http://www.opencascade.org/org/forum/thread_23592/?forum=3 [^]

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 blower3.zip (416,685) 2012-08-15 12:56
https://tracker.dev.opencascade.org/
? bug23380.brep (1,049,351) 2019-09-06 14:10
https://tracker.dev.opencascade.org/
Issue History
2012-08-15 12:56TimoNew Issue
2012-08-15 12:56TimoAssigned To => jgv
2012-08-15 12:56TimoFile Added: blower3.zip
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

Notes
(0033909)
Timo   
2014-10-30 19:24   
Same behaviour in OCCT 6.8.0 beta.
(0057492)
Timo   
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?
(0086799)
git   
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.
(0086873)
jgv   
2019-09-06 14:11   
Please add the shape bug23380.brep to database.
(0086877)
msv   
2019-09-06 14:28   
Done.
(0086879)
git   
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

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

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

SHA-1: cc0847eb4ef42b02af7819331f6822c14be57b36
(0086977)
msv   
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.
(0086981)
jgv   
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.
(0086985)
msv   
2019-09-09 15:24   
Reviewed.
(0086989)
bugmaster   
2019-09-09 18:57   
Combination -
OCCT branch : CR23380
master SHA - cc0847eb4ef42b02af7819331f6822c14be57b36
5f5b1aed1c6e139bbd34314eca77ae7abcd8895c
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

Regressions/Differences/Improvements:
No regressions/differences

CPU differences:
Debian80-64:
OCCT
Total CPU difference: 16821.790000000117 / 16836.290000000165 [-0.09%]
Products
Total CPU difference: 10532.520000000024 / 10553.510000000031 [-0.20%]
Windows-64-VC14:
OCCT
Total CPU difference: 18098.390625 / 18104.5625 [-0.03%]
Products
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
(0087101)
git   
2019-09-15 10:55   
Branch CR23380 has been deleted by inv.

SHA-1: cc0847eb4ef42b02af7819331f6822c14be57b36