MantisBT - Community
View Issue Details
0032557Community[OCCT] OCCT:Modeling Algorithmspublic2021-09-02 18:082021-10-24 10:23
lrineau 
ifv 
normalmajor 
assignedreopened 
LinuxDebian 6.064 bit
[OCCT] 7.5.0 
[OCCT] 7.6.0* 
bugs/moddata_3/bug32557
0032557: Modeling Data - Use of BRepBuilderAPI_NurbsConvert create 2d p-curves with errors
With the given STEP file `abc_0_31-mod.step` given in the attached zip file, the code `debug_issue.cpp` (also in the zip file) shows that the conversion to NURBS using `BRepBuilderAPI_NurbsConvert` create an incorrect wire, with 2d p-curve accumulating so much imprecision that the end points of the loop of p-curve in the wire no longer coincide.

Given the data set, the incriminated wire the one of the third face. I will attach screenshots...

The attached .cpp file loops on the edges of the wire, and displays the maximal distance between two endpoints (of p-curves) that should coincide. That process is run before and after the conversion to NURBS.
Test case
bugs/moddata_3/bug32557
No tags attached.
related to 0032454assigned ifv Community Use of BRepBuilderAPI_NurbsConvert create self intersecting 2d curves 
zip debug_issue.zip (15,645) 2021-09-02 18:08
https://tracker.dev.opencascade.org/
png abc_31_third_face.png (43,187) 2021-09-02 18:08
https://tracker.dev.opencascade.org/
png wire.png (4,643) 2021-09-02 18:12
https://tracker.dev.opencascade.org/
png wire-nurbs.png (4,573) 2021-09-02 18:12
https://tracker.dev.opencascade.org/
png wire-nurbs-zoom.png (1,699) 2021-09-02 18:12
https://tracker.dev.opencascade.org/
? bug32557.brep (19,981) 2021-09-24 15:48
https://tracker.dev.opencascade.org/
zip debug_issue_bis.zip (25,175) 2021-09-29 11:19
https://tracker.dev.opencascade.org/
? abc_0_709.step (8,751) 2021-10-12 15:13
https://tracker.dev.opencascade.org/
? abc_0_1225.step (19,381) 2021-10-12 15:13
https://tracker.dev.opencascade.org/
? abc_0_492.step (60,279) 2021-10-22 19:03
https://tracker.dev.opencascade.org/
? abc_0_685.step (34,757) 2021-10-22 19:04
https://tracker.dev.opencascade.org/
? abc_0_710.step (31,610) 2021-10-22 19:04
https://tracker.dev.opencascade.org/
? abc_0_1005.step (66,461) 2021-10-22 19:04
https://tracker.dev.opencascade.org/
? abc_0_1062.step (97,469) 2021-10-22 19:04
https://tracker.dev.opencascade.org/
Issue History
2021-09-02 18:08lrineauNew Issue
2021-09-02 18:08lrineauAssigned To => msv
2021-09-02 18:08lrineauFile Added: debug_issue.zip
2021-09-02 18:08lrineauFile Added: abc_31_third_face.png
2021-09-02 18:12lrineauFile Added: wire.png
2021-09-02 18:12lrineauFile Added: wire-nurbs.png
2021-09-02 18:12lrineauFile Added: wire-nurbs-zoom.png
2021-09-02 18:14lrineauNote Added: 0103686
2021-09-02 18:18lrineauNote Added: 0103688
2021-09-02 18:26kgvProduct Version7.5.3 => 7.5.0
2021-09-02 18:28kgvRelationship addedrelated to 0031242
2021-09-23 16:12lrineauNote Added: 0104319
2021-09-23 16:13lrineauNote Added: 0104320
2021-09-23 16:21kgvNote Added: 0104321
2021-09-23 16:25lrineauNote Added: 0104322
2021-09-23 22:35msvNote Added: 0104325
2021-09-23 22:35msvAssigned Tomsv => ifv
2021-09-24 15:12ifvNote Added: 0104330
2021-09-24 15:13ifvNote Added: 0104331
2021-09-24 15:16ifvStatusnew => assigned
2021-09-24 15:16ifvSummaryUse of BRepBuilderAPI_NurbsConvert create 2d p-curves with errors => Modeling Data - Use of BRepBuilderAPI_NurbsConvert create 2d p-curves with errors
2021-09-24 15:48ifvFile Added: bug32557.brep
2021-09-24 16:25gitNote Added: 0104334
2021-09-27 09:59kgvTarget Version => 7.6.0*
2021-09-27 10:22gitNote Added: 0104385
2021-09-27 11:22lrineauNote Added: 0104389
2021-09-27 12:37ifvTest case number => bugs/moddata_3/bug32557
2021-09-27 12:37ifvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=25802#r25802
2021-09-27 12:40ifvNote Added: 0104394
2021-09-27 12:40ifvAssigned Toifv => msv
2021-09-27 12:40ifvStatusassigned => resolved
2021-09-27 14:11msvAssigned Tomsv => bugmaster
2021-09-27 14:11msvStatusresolved => reviewed
2021-09-27 19:44msvRelationship addedrelated to 0032454
2021-09-27 19:45msvNote Added: 0104409
2021-09-29 11:19lrineauFile Added: debug_issue_bis.zip
2021-09-29 11:22lrineauNote Added: 0104424
2021-09-29 16:07kgvRelationship addedrelated to 0032596
2021-09-29 16:07kgvRelationship deletedrelated to 0032596
2021-10-02 10:34smoskvinNote Added: 0104479
2021-10-02 10:34smoskvinStatusreviewed => tested
2021-10-02 11:32smoskvinChangeset attached => occt master f277dcbb
2021-10-02 11:32smoskvinAssigned Tobugmaster => smoskvin
2021-10-02 11:32smoskvinStatustested => verified
2021-10-02 11:32smoskvinResolutionopen => fixed
2021-10-04 14:52gitNote Added: 0104502
2021-10-04 15:02gitNote Added: 0104503
2021-10-08 11:07ifvAssigned Tosmoskvin => ifv
2021-10-08 11:07ifvNote Added: 0104541
2021-10-08 11:07ifvStatusverified => feedback
2021-10-08 11:07ifvResolutionfixed => reopened
2021-10-08 11:09ifvStatusfeedback => assigned
2021-10-12 15:13lrineauFile Added: abc_0_709.step
2021-10-12 15:13lrineauFile Added: abc_0_1225.step
2021-10-12 15:17lrineauNote Added: 0104610
2021-10-20 14:59gitNote Added: 0104763
2021-10-21 15:04ifvNote Added: 0104781
2021-10-22 19:03lrineauFile Added: abc_0_492.step
2021-10-22 19:04lrineauFile Added: abc_0_685.step
2021-10-22 19:04lrineauFile Added: abc_0_710.step
2021-10-22 19:04lrineauFile Added: abc_0_1005.step
2021-10-22 19:04lrineauFile Added: abc_0_1062.step
2021-10-22 19:06lrineauNote Added: 0104802
2021-10-22 19:13lrineauNote Added: 0104803
2021-10-24 10:23gitNote Added: 0104827

Notes
(0103686)
lrineau   
2021-09-02 18:14   
I have upload a general view of the STEP face that has the incorrect wire (after the conversion to NURBS).

I have also uploaded a drawing of the wire, in the 2d parametric space, before and after the conversion to NURBS, as well as a zoom on the problematic zone.
(0103688)
lrineau   
2021-09-02 18:18   
This bug occurs with OCCT version 7.5.0 (as shipped by Linux Fedora 34), and with the master branch of OCCT (commit dated Sun Jun 27 20:13:49 2021 +0300).

The bug was not present in OCCT version 7.4.0. That version 7.4.0 was ship in Linux Fedora 32, and I recompiled it locally to check again, just before the submission of this issue.
(0104319)
lrineau   
2021-09-23 16:12   
Hi, It seems this buggy behaviour has been introduced in OCCT 7.5.0 by the commit

> commit bdd09cfaf4fe4d7643d0c1c3d1d4cf9e8037a32a
> Author: ifv <ifv@opencascade.com>
> Date: Wed Dec 18 13:53:11 2019 +0300
>
> 0031242: Scaling with different coefficients along axes produces invalid shape
>
> GeomConvert_1.cxx:
> Creation periodic BSpline surfaces from trimmed periodic surface if trim is boundaries of periodic domain is allowed
>
> BRepTools_NurbsConvertModification.cxx:
> Checking domain of 2dCurves if surfaces are periodic is added
>
> Test case tests/bugs/mesh/bug30008_2 is modified according to current behavior
>
> Test case tests/bugs/modalg_7/bug31242 is added

It seems to be a regression.

I can for now go back to OCCT 7.4.0, as a workaround.

What are your intention for that bug? Will your revert commit bdd09cfaf4fe4d7643d0c1c3d1d4cf9e8037a32a (0031242) in future OpenCASCADE releases?
(0104320)
lrineau   
2021-09-23 16:13   
Here is a Github link to the culprit commit: https://github.com/Open-Cascade-SAS/OCCT/commit/bdd09cfaf4fe4d7643d0c1c3d1d4cf9e8037a32a. [^]
(0104321)
kgv   
2021-09-23 16:21   
@lrineau, thanks for preliminary analysis, the bug #0031242 has been linked to this one (it is inaccessible to public, but there is nothing interesting in description).
> Hi, It seems this buggy behaviour has been introduced in OCCT 7.5.0 by the commit
(0104322)
lrineau   
2021-09-23 16:25   
Hi @kvg, that is interesting to now that commit bdd09cfaf4fe4d7643d0c1c3d1d4cf9e8037a32a was actually a fix for an existing bug. It means you cannot easily revert the commit, because the bug #0031242 (whatever it is) would reappear.
(0104325)
msv   
2021-09-23 22:35   
Dear Igor, could you see if this regression can be fixed by the next release?
(0104330)
ifv   
2021-09-24 15:12   
Debugging
(0104331)
ifv   
2021-09-24 15:13   
This problem can be fixed by next release
(0104334)
git   
2021-09-24 16:25   
Branch CR32557 has been created by ifv.

SHA-1: 612beace39c5bc349761dc4dbbb3cf7a3795b644


Detailed log of new commits:

Author: ifv
Date: Fri Sep 24 16:24:34 2021 +0300

    0032557: Modeling Data - Use of BRepBuilderAPI_NurbsConvert create 2d p-curves with errors
    
    BRepTools/BRepTools_NurbsConvertModification.cxx -
     Checking domain of 2dCurves if surfaces are periodic is improved
    
    tests/bugs/moddata_3/bug32557 - test case added
(0104385)
git   
2021-09-27 10:22   
Branch CR32557 has been updated forcibly by ifv.

SHA-1: 16578705170e25be3ca2f8e35bb8f805dc6f0439
(0104389)
lrineau   
2021-09-27 11:22   
I confirm branch CR32557 fixes the bug in my setup. Thanks for the fix.
(0104394)
ifv   
2021-09-27 12:40   
Branch 32557 is ready for review

Branches for integration
OCCT - CR32557
Products - not
(0104409)
msv   
2021-09-27 19:45   
Igor, could you test if it fixes also the linked bug 0032454?
(0104424)
lrineau   
2021-09-29 11:22   
Hi,

Even if branch `CR32557` fixes most of my test cases, I found one for which there is still a distance between 2d curves once converted in NURBS. See the attached file `debug_issue_bis.zip`, with the data set `abc_0_522.step` from the public ABC repository. This time, the file debug_issue.cpp uses `ShapeAnalysis_WireOrder` to find the maximal distance between edges of the wire, because the wire is not correctly ordered in the file.

@ifv It looks like the same bug, right?
(0104479)
smoskvin   
2021-10-02 10:34   
Combination -
OCCT branch : IR-2021-10-01
master SHA - 0f05f21194a6711251182a118643efc9eb6c322b
49e51745631c52b6c452c65adae4d6dfa21a1b1e
Products branch : IR-2021-10-01 SHA - a7a409985492330e4f25011465bc659dfe7d7562
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: 17464.590000000462 / 17476.150000000354 [-0.07%]
Products
Total CPU difference: 11405.930000000111 / 11390.180000000097 [+0.14%]
Windows-64-VC14:
OCCT
Total CPU difference: 19332.171875 / 19335.34375 [-0.02%]
Products
Total CPU difference: 12772.859375 / 12782.828125 [-0.08%]


Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention
(0104502)
git   
2021-10-04 14:52   
Branch CR32557_1 has been created by ifv.

SHA-1: 30a611a6005bf850b31d7ec330c4368dfc589f81


Detailed log of new commits:

Author: ifv
Date: Mon Oct 4 14:48:03 2021 +0300

    CheckAndSegment added
(0104503)
git   
2021-10-04 15:02   
Branch CR32557_1 has been updated forcibly by ifv.

SHA-1: b54f34fa1d291349a8c1d246c0474d409ece9f9d
(0104541)
ifv   
2021-10-08 11:07   
Issue is reopen because of new problem provided by @Irineau, see note #104424
(0104610)
lrineau   
2021-10-12 15:17   
The branch CR32557_1 does fix the issue with the file abc_0_522.step,
but there are other files from the ABC repository that got worst with
the new commits from CR32557_1, compared to CR32557.

I have attached two new files:

  abc_0_709.step
  abc_0_1225.step

With those two files, and a lot of other from the ABC repository, now I have an exception raised:

  terminate called after throwing an instance of 'Standard_ConstructionError'

Here is the relevant backtrace:

#5 0x00007ffff61a75a9 in __cxa_throw () from /lib64/libstdc++.so.6
#6 0x00007fff402977f5 in CheckSurfaceData (SPoles=..., SUKnots=..., SVKnots=..., SUMults=..., SVMults=..., UDegree=2,
    VDegree=1, UPeriodic=<optimized out>, VPeriodic=<optimized out>)
    at OCCT/src/Geom/Geom_BSplineSurface.cxx:85
0000007 0x00007fff40297d8f in Geom_BSplineSurface::Geom_BSplineSurface (this=0x6e5c680, this@entry=0x1, Poles=..., Weights=...,
    UKnots=..., VKnots=..., UMults=..., VMults=..., UDegree=<optimized out>, VDegree=<optimized out>,
    UPeriodic=<optimized out>, VPeriodic=<optimized out>)
    at OCCT/src/Geom/Geom_BSplineSurface.cxx:259
0000008 0x00007fff402970bf in Geom_BSplineSurface::Copy (this=<optimized out>)
    at OCCT/src/Geom/Geom_BSplineSurface.cxx:140
0000009 0x00007fff402c1b0b in GeomAdaptor::MakeSurface (HS=..., theTrimFlag=false)
    at OCCT/src/GeomAdaptor/GeomAdaptor.cxx:134
#10 0x00007fff40474356 in computePeriodicity (theSurf=..., theUPeriod=@0x7fffffffb878: 0, theVPeriod=@0x7fffffffb870: 0)
    at OCCT/src/ProjLib/ProjLib_ComputeApproxOnPolarSurface.cxx:119
0000011 0x00007fff4046f1e5 in ProjLib_ComputeApproxOnPolarSurface::BuildInitialCurve2d (this=this@entry=0x7fffffffc730, Curve=...,
    Surf=...) at OCCT/src/ProjLib/ProjLib_ComputeApproxOnPolarSurface.cxx:932
#12 0x00007fff4046e202 in ProjLib_ComputeApproxOnPolarSurface::Perform (this=this@entry=0x7fffffffc730, InitialCurve2d=...,
    Curve=..., S=...) at OCCT/src/ProjLib/ProjLib_ComputeApproxOnPolarSurface.cxx:794
0000013 0x00007fff4046d8db in ProjLib_ComputeApproxOnPolarSurface::ProjLib_ComputeApproxOnPolarSurface (this=0x7fffffffc730,
    theInitialCurve2d=..., theCurve=..., theSurface=..., theTolerance3D=<optimized out>)
    at OCCT/src/ProjLib/ProjLib_ComputeApproxOnPolarSurface.cxx:517
0000014 0x00007fff408c8a03 in BRepTools_NurbsConvertModification::NewCurve2d (this=0x6d86a60, E=..., F=..., newE=..., newF=...,
    Curve2d=..., Tol=@0x7fffffffc940: 9.9999999999999995e-08)
    at OCCT/src/BRepTools/BRepTools_NurbsConvertModification.cxx:488
0000015 0x00007fff408c4188 in BRepTools_Modifier::Rebuild (this=<optimized out>, this@entry=0x7fffffffd310, S=..., M=...,
    theNewGeom=<optimized out>, theProgress=...)
    at OCCT/src/BRepTools/BRepTools_Modifier.cxx:410
0000016 0x00007fff408c3df2 in BRepTools_Modifier::Rebuild (this=<optimized out>, this@entry=0x7fffffffd310, S=..., M=...,
    theNewGeom=<optimized out>, theProgress=...)
    at OCCT/src/BRepTools/BRepTools_Modifier.cxx:363
0000017 0x00007fff408c3df2 in BRepTools_Modifier::Rebuild (this=<optimized out>, this@entry=0x7fffffffd310, S=..., M=...,
    theNewGeom=<optimized out>, theProgress=...)
    at OCCT/src/BRepTools/BRepTools_Modifier.cxx:363
0000018 0x00007fff408c29a4 in BRepTools_Modifier::Perform (this=0x7fffffffd310, M=..., theProgress=...)
    at OCCT/src/BRepTools/BRepTools_Modifier.cxx:147
0000019 0x00007fff41040243 in BRepBuilderAPI_ModifyShape::DoModif (this=this@entry=0x7fffffffd2c0)
    at OCCT/src/BRepBuilderAPI/BRepBuilderAPI_ModifyShape.cxx:77
0000020 0x00007fff410403ad in BRepBuilderAPI_ModifyShape::DoModif (this=0x7fffffffd2c0, S=..., M=...)
    at OCCT/src/BRepBuilderAPI/BRepBuilderAPI_ModifyShape.cxx:126
0000021 0x00007fff41040701 in BRepBuilderAPI_NurbsConvert::Perform (this=this@entry=0x7fffffffd2c0, S=...)
    at OCCT/src/BRepBuilderAPI/BRepBuilderAPI_NurbsConvert.cxx:63
0000022 0x00007fff41040682 in BRepBuilderAPI_NurbsConvert::BRepBuilderAPI_NurbsConvert (this=0x7fffffffd2c0, S=...,
    Copy=<optimized out>) at OCCT/src/BRepBuilderAPI/BRepBuilderAPI_NurbsConvert.cxx:50
(0104763)
git   
2021-10-20 14:59   
Branch CR32557_1 has been updated forcibly by ifv.

SHA-1: 7ae1f65ec6d779b5236575f6f9aaddce132626c7
(0104781)
ifv   
2021-10-21 15:04   
Dear @Irineau, could you please test new variant of branch CR32557_1 on your data repository?
(0104802)
lrineau   
2021-10-22 19:06   
Hi @ifv, I have added a few test cases that fail similarly, on the last commit 7ae1f65ec6d779b5236575f6f9aaddce132626c7:

abc_0_1005.step
abc_0_1062.step
abc_0_492.step
abc_0_685.step
abc_0_710.step
(0104803)
lrineau   
2021-10-22 19:13   
Actually, the call stack is not always the same, and the exception thrown is also different:

           name status time error
abc_0_1062.step FAILED 3.05515 terminate called after throwing an instance of 'Standard_ConstructionError'
 abc_0_492.step FAILED 3.04846 terminate called after throwing an instance of 'Standard_ConstructionError'
 abc_0_685.step FAILED 3.00421 terminate called after throwing an instance of 'Standard_ConstructionError'
abc_0_1005.step FAILED 3.03978 terminate called after throwing an instance of 'Standard_RangeError'
 abc_0_710.step FAILED 3.02421 terminate called after throwing an instance of 'Standard_RangeError'

but that seems to be always somewhere in a call to `BRepBuilderAPI_NurbsConvert::Perform`.
(0104827)
git   
2021-10-24 10:23   
Branch CR32557_1 has been deleted by mnt.

SHA-1: 7ae1f65ec6d779b5236575f6f9aaddce132626c7