View Issue Details

IDProjectCategoryView StatusLast Update
0023380CommunityOCCT:Modeling Algorithmspublic2019-09-15 10:55
ReporterMarkus Assigned Tobugmaster  
Status closedResolutionfixed 
Product Version6.5.3 
Target Version7.4.0Fixed in Version7.4.0 
Summary0023380: (OCC 6.5.3 regression) BRepOffsetAPI_MakeFilling fails and leaves boundary faces with high tolerance
DescriptionWhen 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.
Steps To Reproducebugs modalg_7 bug23380
TagsNo tags attached.
Test case numberbugs/modalg_7/bug23380

Attached Files

  • (416,685 bytes)
  • bug23380.brep (1,049,351 bytes)



2012-08-15 12:56

developer (416,685 bytes)


2014-10-30 19:24

developer   ~0033909

Same behaviour in OCCT 6.8.0 beta.


2016-09-06 10:39

developer   ~0057492

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

administrator   ~0086799

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:10


bug23380.brep (1,049,351 bytes)


2019-09-06 14:11

developer   ~0086873

Please add the shape bug23380.brep to database.


2019-09-06 14:28

developer   ~0086877



2019-09-06 14:33

administrator   ~0086879

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

administrator   ~0086880

Branch CR23380 has been updated forcibly by jgv.

SHA-1: 22da872ec375ee87223b185803529a0fda48c87c


2019-09-06 17:35

developer   ~0086904

Please review the branch CR23380.


2019-09-09 11:32

administrator   ~0086976

Branch CR23380 has been updated forcibly by msv.

SHA-1: cc0847eb4ef42b02af7819331f6822c14be57b36


2019-09-09 11:41

developer   ~0086977

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

developer   ~0086981

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

developer   ~0086985



2019-09-09 18:57

administrator   ~0086989

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

administrator   ~0087101

Branch CR23380 has been deleted by inv.

SHA-1: cc0847eb4ef42b02af7819331f6822c14be57b36

Related Changesets

occt: master a53d3975

2019-09-05 12:31:15


Committer: bugmaster Details Diff
0023380: BRepOffsetAPI_MakeFilling fails and leaves boundary faces with high tolerance

Avoid exception: use BRep_Builder for building wire instead of using BRepLib_MakeWire.
Affected Issues
mod - src/BRepFill/BRepFill_Filling.cxx Diff File
add - tests/bugs/modalg_7/bug23380 Diff File

Issue History

Date Modified Username Field Change
2012-08-15 12:56 Timo New Issue
2012-08-15 12:56 Timo Assigned To => jgv
2012-08-15 12:56 Timo File Added:
2014-10-30 19:24 Timo Note Added: 0033909
2016-09-06 10:39 Timo Note Added: 0057492
2016-09-06 10:40 Timo Status new => feedback
2017-05-31 15:42 Timo Reporter Timo => Markus
2019-09-05 15:34 git Note Added: 0086799
2019-09-06 14:10 jgv File Added: bug23380.brep
2019-09-06 14:11 jgv Assigned To jgv => msv
2019-09-06 14:11 jgv Note Added: 0086873
2019-09-06 14:28 msv Note Added: 0086877
2019-09-06 14:28 msv Assigned To msv => jgv
2019-09-06 14:28 msv Status feedback => assigned
2019-09-06 14:33 git Note Added: 0086879
2019-09-06 14:35 git Note Added: 0086880
2019-09-06 16:57 msv Target Version => 7.4.0
2019-09-06 17:35 jgv Note Added: 0086904
2019-09-06 17:35 jgv Assigned To jgv => msv
2019-09-06 17:35 jgv Status assigned => resolved
2019-09-06 17:35 jgv Steps to Reproduce Updated
2019-09-09 11:32 git Note Added: 0086976
2019-09-09 11:41 msv Note Added: 0086977
2019-09-09 11:41 msv Assigned To msv => jgv
2019-09-09 11:41 msv Status resolved => assigned
2019-09-09 14:47 jgv Note Added: 0086981
2019-09-09 14:47 jgv Assigned To jgv => msv
2019-09-09 14:47 jgv Status assigned => feedback
2019-09-09 15:24 msv Note Added: 0086985
2019-09-09 15:24 msv Assigned To msv => bugmaster
2019-09-09 15:24 msv Status feedback => reviewed
2019-09-09 18:56 bugmaster Test case number => bugs/modalg_7/bug23380
2019-09-09 18:57 bugmaster Note Added: 0086989
2019-09-09 18:57 bugmaster Status reviewed => tested
2019-09-15 10:51 bugmaster Changeset attached => occt master a53d3975
2019-09-15 10:51 bugmaster Status tested => verified
2019-09-15 10:51 bugmaster Resolution open => fixed
2019-09-15 10:55 git Note Added: 0087101