Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0023380Community[OCCT] OCCT:Modeling Algorithmspublic2012-08-15 12:562017-05-31 15:42
Assigned Tojgv 
PlatformOSOS Version
Product Version[OCCT] 6.5.3 
Target VersionFixed in Version 
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.
TagsNo tags attached.
Test case number
Attached Fileszip file icon (416,685 bytes) 2012-08-15 12:56

- Relationships

-  Notes
Timo (developer)
2014-10-30 19:24

Same behaviour in OCCT 6.8.0 beta.
Timo (developer)
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?

- 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

Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker