DiscussionsIssue archiveOCCT:Modeling Algorithms

Archived issue #0022981

BRepOffsetAPI_ThruSections fails to build a surface from closed wires

CommunityOCCT:Modeling Algorithmsclosed3 public notes

Search issues

Description

In order to reproduce the problem you can use the following Draw commands:

restore Attachment 2 (BREP) t
explode t
thrusections r 0 0 t_1 t_2 t_3 t_4 t_5 t_6 t_7 t_8 t_9 t_10 t_11
alternatively:
thrusections r 0 0 t_1 t_2 t_3

If I leave out the first wire the exception is not thrown:
thrusections r 0 0 t_2 t_3 t_4 t_5 t_6 t_7 t_8 t_9 t_10 t_11


Tested with OCC 6.5.2

Stack-Trace:
...
TKernel.dll!Standard_ConstructionError::Raise(const char * const AString) Zeile 12 + 0xcc Bytes C++
TKG3d.dll!Geom_BSplineSurface::InsertUKnots(const TColStd_Array1OfReal & Knots, const TColStd_Array1OfInteger & Mults, const double ParametricTolerance, const unsigned int Add) Zeile 1882 + 0xa Bytes C++
TKG3d.dll!Geom_BSplineSurface::Segment(const double U1, const double U2, const double V1, const double V2) Zeile 641 C++
TKOffset.dll!BRepOffsetAPI_ThruSections::CreateSmoothed() Zeile 642 C++
TKOffset.dll!BRepOffsetAPI_ThruSections::Build() Zeile 392 C++

Is it a bug or is there a problem with the wires / geometry?

Additional information

Forum supervisor:
The posted problem has been checked and reproduced.
It looks like a bug. The commands:
>>thrusections r 0 0 t_1 t_2
>>thrusections r 0 0 t_2 t_3 t_4 t_5 t_6 t_7 t_8 t_9 t_10 t_11
are performed successfully, but together with the first section it leads to exception.

Public activity

3 archived notes

Participants are labeled by their role within this record.

01Author
BSplCLib::PrepareInsertKnots, which is called by Geom_BSplineSurface::InsertUKnots, returns false because (adeltaK2 > Tolerance).
adeltaK2: 1.[revision removed]-015
Tolerance: 8.[revision removed]-016

If the parametric tolerance (epsU) is increased to 8.[revision removed]-015
before the call of InsertUKnots in Geom_BSplineSurface::Segment, the surface can be generated, but it doesn't seem to be OK in visualization (see "Attachment 1 (PNG)").
02Commenter 2
The problem seems to be fixed by fix for #0023436, at least it is not reproduced on current master. I suggest the issue can be closed after adding a test case.
03Commenter 1
Branch CR22981 was created from current state of master. The problem is fixed.
Test case - bugs/modalg_5/bug22981 - OK
Branch contains only test case and will be integrated.

Related records