For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings


Need to speed up your development?
Have a look at our:

Samples & Tools


Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

(OCC 6.5.3 regression?) Is BRepOffsetAPI_MakeFilling supposed to change the tolerance of bounding faces?

Timo Roth's picture

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.

I think this test case also reveals a bug in the end of BRepFill_Filling.WireFromList() where the mentioned exception occurs.

Kind regards,

Timo Roth's picture

Dear Forum supervisor,

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


Forum supervisor's picture

Dear Timo,
The specified issue is checked and reproduced. The script raises an exception at the command ,
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. So, you can register a bug in the Mantis BugTracker.

Timo Roth's picture

Registered under